Un petit gabarit relatif, une grande promesse
Ripple-65B Preview est une sortie qui attire l’attention précisément parce qu’elle oppose deux métriques: une taille raisonnable pour un grand modèle moderne, et un score très élevé sur un benchmark d’agents de programmation. Ricursive Intelligence a publié un modèle dense de 65 milliards de paramètres, en open weights et sous licence Apache 2.0, présenté comme une variante généraliste d’une technologie liée à sa plateforme de conception de puces . Le chiffre central est 80,52 sur Terminal-Bench 2.1, généralement arrondi à 80,5, que Ricursive présente comme un état de l’art américain open-weight pour le codage agentique .
Le message est clair: Ripple-65B n’essaie pas d’impressionner par un nombre total de paramètres proche du trillion. Il s’agit d’un modèle dense, donc les 65 milliards de paramètres sont activés à chaque token. Plusieurs rivaux cités dans la comparaison sont au contraire des modèles mixture-of-experts, avec un total de paramètres bien plus élevé mais un nombre de paramètres actifs plus faible lors de l’inférence . Dans le tableau repris par les médias, Ripple devance Reflection Beam à 80,1, Meta Muse Spark Open à 76,4, Thinking Machines Inkling à 63,8 et NVIDIA Nemotron 3 Ultra à 56,4 sur Terminal-Bench 2.1 . Face aux 975 milliards de paramètres totaux d’Inkling, la formule “jusqu’à 15 fois plus grand” est donc défendable, à condition de préciser qu’elle parle des paramètres totaux, pas des paramètres actifs .
Pourquoi Terminal-Bench compte
Terminal-Bench est un benchmark important parce qu’il ne mesure pas seulement la capacité d’un modèle à écrire un extrait de code dans le vide. Il teste des comportements plus proches d’un agent: exécuter des actions dans un environnement de terminal, utiliser des outils, suivre plusieurs étapes et résoudre des tâches logicielles . Pour les équipes qui construisent des assistants de développement autonomes ou semi-autonomes, ce type de résultat est plus parlant qu’un simple test de complétion de code.
L’enjeu est économique autant que technique. Si un modèle dense de 65B peut conserver une capacité agentique comparable à celle de systèmes open-weight bien plus massifs, le coût de déploiement change. Un modèle de 65 milliards de paramètres reste lourd, mais il est plus envisageable à servir, quantifier, mettre en cache ou auto-héberger qu’un système de plusieurs centaines de milliards de paramètres. MarkTechPost indique que la sortie comprend trois checkpoints: un modèle instruction-tuned en BF16, une version NVFP4 et un modèle de base BF16, tous sous Apache 2.0 . Cette combinaison entre poids ouverts et licence permissive transforme le score en option d’ingénierie, pas seulement en argument marketing.
Ricursive affirme aussi que le modèle a été pré-entraîné from scratch sur 12 trillions de tokens, principalement en anglais et en code, avec une prise en charge pouvant aller jusqu’à 1 million de tokens de contexte . La société décrit le modèle comme relativement légèrement post-entraîné, avec un accent sur le codage agentique, ce qui explique pourquoi les revendications les plus fortes concernent les tâches terminal et software engineering plutôt qu’un leadership général sur tous les benchmarks .
Le choix du dense comme stratégie
Le point technique le plus intéressant est peut-être le refus de suivre mécaniquement la mode des architectures mixture-of-experts. Ricursive dit avoir choisi un Transformer dense modernisé pour réduire la complexité d’infrastructure tout en conservant de bonnes performances de raisonnement et d’agent . Le modèle est décrit comme “fin et profond”, avec une dimension interne de 5120 et 80 couches, ainsi que plusieurs choix d’architecture comme gated attention, global NoPE, value residuals et activation clipping .
Ce choix a des conséquences pratiques. Les modèles MoE peuvent être très efficaces lorsqu’ils sont bien routés, mais ils compliquent le service, la distribution mémoire et parfois la prévisibilité opérationnelle. Un modèle dense de 65B est plus simple à raisonner: tout le modèle tourne, les besoins mémoire sont plus lisibles et les stratégies de quantification sont plus directes. ArtificialWatch souligne que cette distinction est essentielle pour comparer les tailles, car Ripple utilise ses 65B paramètres à chaque token alors que Reflection Beam, par exemple, active 23B de ses 501B paramètres totaux .
Ricursive ajoute une dimension de coût à ce récit. Les rapports publiés indiquent que l’entreprise revendique environ 40% d’utilisation effective des FLOPs pendant l’entraînement et le post-entraînement, avec un sharding simple, sans kernels personnalisés et sans quantification pendant l’entraînement . La société évoque également un coût total de recherche et développement de 32 millions de dollars, incluant les expériences de “laddering”, les mélanges de données, les évaluations, le débogage, les données synthétiques et les runs finaux . Si cette comptabilité se confirme, Ripple-65B est autant une histoire d’efficacité qu’une histoire de score.
Un score fort, mais pas un verdict universel
Le 80,5 sur Terminal-Bench est impressionnant, mais il faut le lire avec prudence. VentureBeat note que le leadership revendiqué par Ricursive porte sur des concurrents américains sélectionnés et sur des tests précis, et que les mêmes documents montrent Ripple derrière d’autres modèles open-weight sur certains benchmarks . Dans la comparaison publiée, Ripple est en tête sur Terminal-Bench 2.1 et SWE-bench Pro v2.0 Hard, mais Meta mène sur DeepSWE dans le même tableau, et d’autres modèles sont plus forts sur certaines évaluations de mathématiques, de connaissances ou de sécurité .
C’est une nuance importante. Un modèle peut être excellent dans les tâches de codage en terminal sans être le meilleur choix pour toute tâche logicielle, toute programmation scientifique ou tout workflow d’entreprise. MarkTechPost relève également des points faibles issus du propre tableau de Ricursive, notamment SciCode, DeepSWE et MCP Atlas . La lecture juste n’est donc pas “Ripple bat tout le monde”. Elle est plutôt: “Ripple semble exceptionnellement fort pour sa taille sur certaines évaluations agentiques choisies par Ricursive.”
La question de la reproductibilité reste ouverte. ArtificialWatch indique qu’aucun leaderboard indépendant n’avait encore noté Ripple au moment de son rapport . MarkTechPost décrit aussi plusieurs chiffres comme auto-déclarés ou issus des fournisseurs, avec des valeurs complétées par Ricursive dans son propre environnement lorsque les cartes de modèles rivales étaient incomplètes . Cela ne disqualifie pas le résultat, mais cela le rend provisoire tant que des tiers n’ont pas exécuté les mêmes checkpoints avec des paramètres transparents.
Disponibilité et limite de contexte côté API
Ripple-65B Preview n’est pas seulement une annonce. Les rapports actuels indiquent que les poids sont publics et non restreints sur Hugging Face, avec des artefacts BF16 et NVFP4 expérimentaux . VentureBeat rapporte que le modèle est disponible au téléchargement et via certains partenaires API, dont Together AI, GMI Cloud et OpenRouter, avec Fireworks attendu ensuite . Writeble mentionne également les poids BF16 et NVFP4 expérimentaux disponibles sur Hugging Face .
La partie API ajoute toutefois une réserve concrète. Une surveillance du catalogue OpenRouter a repéré l’identifiant ricursiveai/ripple-65b-preview avec un prix listé de 0,20 dollar par million de tokens en entrée et 0,60 dollar par million de tokens en sortie, mais avec une fenêtre de contexte de 16 384 tokens dans cette entrée . VentureBeat signale aussi cet écart entre la capacité de contexte d’un million de tokens annoncée par Ricursive et la limite affichée sur l’endpoint OpenRouter . En pratique, les développeurs doivent distinguer trois choses: ce que le modèle est censé supporter, ce que les checkpoints peuvent permettre dans une pile de service adaptée, et ce qu’un fournisseur hébergé expose réellement aujourd’hui.
Le vrai combat: prouver que le score tient
Ripple-65B arrive dans un marché où les agents de code sont jugés autant sur leur coût, leur latence et leur contrôlabilité que sur leurs scores bruts. Les modèles fermés de frontière restent dominants dans beaucoup de workflows, mais les modèles open-weight gagnent en crédibilité lorsque les entreprises veulent auditer, auto-héberger ou adapter leurs systèmes. Un modèle dense de 65B sous Apache 2.0 occupe une zone intéressante: pas petit, pas trivial à faire tourner sur n’importe quelle machine, mais nettement plus accessible que les plus grands systèmes MoE.
Cette sortie rappelle aussi que le nombre total de paramètres ne décide pas de tout. La recette d’entraînement, la qualité des données, le post-entraînement, le harness agentique, la gestion du contexte et l’implémentation de service peuvent peser autant que la taille brute. L’intérêt de Ripple n’est pas seulement qu’un modèle 65B obtienne un bon score, mais qu’il suggère qu’un travail ciblé d’ingénierie peut encore déplacer la frontière d’efficacité.
Le vrai “boss battle” reste donc la reproductibilité. Si des évaluateurs indépendants confirment le 80,5 sur Terminal-Bench 2.1 avec des environnements comparables, Ripple-65B deviendra une option open-weight très sérieuse pour les agents de code. Si le score varie fortement selon le harness, la longueur de contexte ou l’échafaudage agentique, la sortie restera importante, mais comme rappel de la fragilité des benchmarks modernes. Pour l’instant, le verdict raisonnable est enthousiaste mais prudent: Ripple-65B Preview est un modèle 65B prometteur, permissif, efficace sur le papier, et encore en attente de confirmation hors des tableaux de Ricursive.
Commentaires
Sois le premier à commenter.