Ripple-65B Preview vs Ripple-65B : pourquoi le second nom n’a aucun modèle derrière lui

Recherchez Ripple-65B Preview et vous trouverez un modèle documenté : un checkpoint dense de 65B sous Apache 2.0 de Ricursive Intelligence, créé le 4 novembre 2026, avec une fiche, quatre dépôts et un score de 80,52 rapporté par le fournisseur sur Terminal-Bench 2.1. Recherchez Ripple-65B — le même nom avec le suffixe retiré — et vous trouverez ce modèle, encore et encore, sous différents noms de fichiers. Il n'existe pas de version finale distincte. L'organisation Hugging Face répertorie quatre dépôts publics — Ripple-65B-Preview, Ripple-65B-Preview-NVFP4, Ripple-65B-Base-Preview et Ripple-65B-Preview-DFlash2 — et aucun d'entre eux n'omet le mot « Preview ».

Cela fait de cette page de comparaison une page inhabituelle, et la façon honnête de l'écrire est de le dire d'emblée. Ripple-65B n'est pas un concurrent de Ripple-65B Preview. C'est un nom que les gens recherchent, un espace réservé pour une sortie qui n'a pas eu lieu et — plus utilement — l'occasion de répondre à la question que ces recherches posent vraiment : obtenez-vous le modèle fini, ou obtenez-vous un instantané que le labo vous a dit être léger en post-entraînement ?

Ce que « Preview » signifie sur cette carte en particulier

Le suffixe n’est pas décoratif ici, et Ricursive est inhabituellement explicite à ce sujet. La fiche modèle décrit cette version comme relativement légèrement post-entraînée : 200 milliards de tokens de mi-entraînement, 183 milliards de tokens de fine-tuning supervisé, 13,5 milliards de tokens SFT à contexte long, 700 étapes de RL, en plus d’un pré-entraînement de 12 000 milliards de tokens avec une longueur de séquence de 8K. Tout est entraîné depuis zéro, et le cadrage de l’entreprise est que le budget de post-entraînement était délibérément faible par rapport au pré-entraînement.

Cette combinaison — une base énorme, un alignement léger — est ce qui produit un checkpoint qui obtient 80,52 sur Terminal-Bench 2.1 tout en se situant à 44,3 sur DeepSWE 1.1 et 39,4 sur SciCode. La performance agentique au terminal est un vrai travail. L’étendue en ingénierie logicielle semble être la partie qu’un entraînement post-entraînement plus long toucherait en premier. Un Ripple-65B final serait, selon cette lecture, un meilleur modèle précisément sur les axes où la Preview est la plus faible.

Ricursive ne s'est engagé à rien de tel. Il n'y a pas de feuille de route, pas de mention « version finale au T4 » dans l'article de lancement, et pas de dépôt successeur daté. Lorsqu'ArtificialWatch a suivi le lancement, il a noté que « la GA sans l'étiquette Preview est encore à venir » — un résumé exact d'un état qui n'a pas changé depuis.

Les quatre dépôts, et à quoi chacun sert réellement

La confusion autour des noms s’aggrave avant de s’améliorer, car deux des quatre dépôts donnent l’impression qu’ils pourraient être le modèle final, et aucun des deux ne l’est.

• Ripple-65B-Preview — le checkpoint instruct principal. BF16, 64 782 689 360 paramètres, 129,6 Go répartis sur 16 fragments, Apache 2.0, sans restriction d'accès. C'est celui auquel renvoient tous les chiffres de benchmark.

• Ripple-65B-Preview-NVFP4 — le même modèle instruct quantifié avec ModelOpt, 39 616 865 360 paramètres stockés, étiqueté 8 bits. Pas un modèle différent ; un conteneur plus petit pour les mêmes poids.

• Ripple-65B-Base-Preview — créé le 14 octobre 2026, trois semaines avant la sortie instruct. Il s'agit du modèle de base pré-entraîné, évalué séparément : MMLU 83,7, MMLU-Pro 61,5, GPQA Diamond 38,4, HumanEval 70,9, MBPP Sanitized 81,5. Ces chiffres semblent alarmants à côté des 89,6 et 85,2 de la fiche instruct, jusqu'à ce que l'on se rappelle qu'il s'agit de scores de modèle de base — avant SFT, avant RL, répondant dans un style de complétion. C'est le bon point de départ si vous comptez effectuer votre propre post-entraînement, et le mauvais si vous voulez un assistant.

• Ripple-65B-Preview-DFlash2 — 4,04 milliards de paramètres, un modèle de proposition pour le décodage spéculatif. Il propose des tokens que le modèle 65B doit vérifier et ne peut rien générer par lui-même ; sa fiche indique sans détour qu'il « nécessite le modèle cible pour générer du texte ».

Quatre dépôts, un modèle, dont trois variantes d’un checkpoint et un composant. Personne n’en a publié un cinquième.

Si un Ripple-65B final était réellement commercialisé, qu’est-ce qui changerait ?

C’est la partie constructive de la comparaison, et il vaut mieux être concret plutôt que de faire allusion à un « meilleur post-entraînement ».

• L’histoire du contexte serait probablement réglée. La Preview annonce jusqu’à 1M, entraînée sur des séquences de 2M de tokens lors de ses étapes à contexte long, tandis que les offres commerciales ont proposé 16 384 et, plus récemment, mis en avant 128K. Une version finale est le moment naturel pour un laboratoire d’indiquer ce pour quoi le modèle est réellement validé plutôt que ce que l’architecture prend en charge.

• DeepSWE et SciCode seraient les chiffres à surveiller. C’est là que la Preview est en retrait par rapport à des modèles qu’elle devance ailleurs, et ce sont les benchmarks qui réagissent le plus directement à davantage de RL et de SFT sur de vrais dépôts.

• Un score indépendant existerait probablement d’ici là. Artificial Analysis n’a aujourd’hui aucune entrée pour quelque identifiant Ripple que ce soit, ce qui signifie que chaque chiffre en circulation est déclaré par le fournisseur. Une version GA est le moment où les agrégateurs commencent généralement à référencer un modèle.

• La licence resterait probablement Apache 2.0. Rien dans le lancement ne suggère que Ricursive ait l’intention de revenir là-dessus, et c’est l’atout le plus précieux de cette publication.

Rien de tout cela n’est annoncé. C’est une inférence tirée de ce que la fiche dit de son propre budget de post-entraînement, et elle doit être lue comme telle.

Le piège du nommage, et pourquoi cela compte en pratique

Si vous intégrez ce modèle dans un fichier de configuration, la distinction cesse d’être théorique. L’identifiant qui se résout est ricursiveAI/Ripple-65B-Preview. Une requête pour ricursiveAI/Ripple-65B ne renvoie rien, car rien de ce nom n’existe — et un pipeline qui bascule silencieusement vers une correspondance approximative échouera ou, pire, servira discrètement un checkpoint de base là où vous attendiez un modèle instruct.

Le même piège existe en sens inverse avec le modèle de base. Ripple-65B-Base-Preview est un véritable dépôt avec de vrais poids, et c’est un artefact véritablement différent de la version instruct : des scores différents, un comportement différent, un objectif différent. Quiconque compare les scores de « Ripple-65B » sur Internet mélange presque certainement le 89,6 MMLU de la fiche instruct avec le 83,7 de la fiche de base sans remarquer qu’ils proviennent de deux dépôts différents.

Trois règles pratiques suivent. Fixez l’identifiant exact du dépôt et un hash de révision, pas un nom de famille. Ne partez pas du principe qu’un point de terminaison hébergé et le téléchargement BF16 sont le même produit — celui hébergé peut être en NVFP4, peut correspondre à une révision différente et aura presque certainement une limite de contexte différente. Et si un outil ou un classement liste « Ripple-65B » sans le suffixe, vérifiez de quel dépôt il s’agit avant de citer le chiffre.

Ce que vous pouvez faire avec Preview aujourd’hui

Pas mal, en fait, et plus qu'il y a une semaine. Les poids sont en accès libre et sous Apache 2.0, donc il n'y a aucune étape d'approbation. Depuis le 5 novembre, vLLM a intégré le support natif — un RicursiveConfig intégré, des parseurs de raisonnement et d'appels d'outils, et une recette utilisant par défaut NVFP4 sur un seul B300 — ce qui signifie que le checkpoint se charge sans --trust-remote-code dans le moteur que la plupart des équipes utilisent déjà. Une pull request SGLang parallèle est encore ouverte, donc vLLM est actuellement le seul moteur courant où il s'agit d'une architecture prise en charge plutôt que d'un script externe.

Sur le plan commercial, le modèle est proposé à environ 0,20 $ par million de jetons en entrée et 0,60 $ par million de jetons en sortie, les entrées mises en cache étant facturées à une fraction de ce tarif. Ces tarifs correspondent à la Preview, puisqu’il n’y a rien d’autre à servir.

OrcaRouter ne le propose pas. Cela mérite d’être dit clairement, car une page de comparaison qui se termine en laissant entendre que vous pouvez accéder aux deux côtés via nous serait trompeuse — il n’y a qu’un seul côté, et nous ne l’hébergeons pas. Ce que nous routons, c’est l’écosystème alentour : Kimi K3.1 Pro à 2,00 $ et 10,00 $ par million avec un contexte de 1M, DeepSeek V4 Pro à 0,66 $ et 1,98 $ avec un contexte de 1M et une sortie de 384K, Qwen3.8 Max à 2,00 $ et 6,00 $. Si la raison pour laquelle vous lisez à propos d’un codeur à poids ouverts de 65B est que vous voulez un modèle agentique économique sans cycle d’approvisionnement, ce sont ceux qui utilisent la même clé que tout le reste, avec basculement automatique et tarification au prix coûtant. Ripple est celui que vous hébergez ou achetez séparément.

La réponse courte

Si quelqu’un vous demande la différence entre Ripple-65B Preview et Ripple-65B, la réponse exacte est que le second n’existe pas encore. Le Preview est le modèle : 65B dense, Apache 2.0, 12 billions de tokens de préentraînement, légèrement post-entraîné, 80,52 sur Terminal-Bench 2.1 selon sa propre mesure, non classé par aucun tableau indépendant, et servi avec une fenêtre de contexte qui dépend de celui qui le sert.

Ce qu’apporterait une version finale, c’est une valeur de contexte stabilisée, de meilleurs résultats sur les benchmarks d’ingénierie logicielle où la Preview est la plus faible, et probablement la première vérification externe dont le modèle ait jamais fait l’objet. Tant que Ricursive ne l’a pas livrée, chaque comparaison "Ripple-65B" que vous lisez — y compris celles qui prétendent le comparer à la Preview — compare un modèle à un terme de recherche.