- ▸ Plus de 10 secondes et 0,03 $ : le coût d'un agent GPT-5.6-sol
- ▸ 100x moins cher : l'argument des modèles à poids ouverts
- ▸ Castform veut rendre le post-entraînement aussi simple que le prompt
- ▸ Neon fournit le contexte : Lakebase Postgres et extensions de recherche
Une requête de recherche multi-tours coûte environ 0,03 $ et dépasse dix secondes avec GPT-5.6-sol. Des petits modèles open-weights post-entraînés visent le même résultat pour cent fois moins cher. Ce comparatif oppose l’approche propriétaire à la combinaison Castform + Neon sur le coût, la latence et l’infrastructure de récupération. Analyse fondée sur la documentation publiée par Neon, arrêtée au 5 août 2026 — elle ne remplace pas votre propre test avant de choisir.
| Critère | GPT-5.6-sol (propriétaire) | Petits modèles open-weights post-entraînés (Castform + Neon) |
|---|---|---|
| Coût par requête de recherche multi-tours | ~0,03 $ end-to-end (source : Neon, 5 août 2026) | ordre de grandeur ~0,0003 $ (calcul dérivé du « 100x moins cher ») |
| Latence sur une requête multi-tours | > 10 s (source : Neon) | non communiquée précisément |
| Capacités brutes « out of the box » | supérieures (source : Neon) | inférieures avant post-entraînement (source : Neon) |
| Infrastructure de récupération | API fermée | Lakebase Postgres + extensions de recherche Neon |
| Prérequis pour l’utilisateur | clé API | post-entraînement RL via Castform, sans internals ML/GPU |
L’essentiel – Une requête de recherche multi-tours atteint plus de 10 secondes et coûte environ 0,03 $ end-to-end avec GPT-5.6-sol, selon la documentation de Neon. – Les petits modèles à poids ouverts sont annoncés « 100x moins chers », soit un ordre de grandeur autour de 0,0003 $ par requête une fois la logique appliquée. – Ces modèles ouverts restent moins performants bruts, mais le post-entraînement par renforcement vise à combler l’écart sur une tâche précise comme la recherche. – Castform positionne ce post-entraînement comme « aussi accessible que le prompt engineering », pendant que Neon fournit le contexte via Lakebase Postgres.
Plus de 10 secondes et 0,03 $ : le coût d’un agent GPT-5.6-sol
Le point de départ du comparatif est chiffré. D’après la documentation de Neon, une requête de recherche multi-tours traitée par GPT-5.6-sol dépasse dix secondes et coûte environ 0,03 $ de bout en bout. L’éditeur qualifie ce profil de « prohibitivement lent et coûteux » pour ce type d’usage.
Trois centimes de dollar par requête paraissent négligeables à l’échelle d’un test isolé. Le calcul change d’échelle dès qu’un produit sert des volumes réels. À un million de requêtes, la facture atteint l’ordre de 30 000 $ ; à dix millions, elle approche 300 000 $. Neon ne fait pas explicitement ce calcul dans son billet, mais il découle directement du coût unitaire publié.
La latence pèse autant que le prix. Un agent de recherche qui enchaîne plusieurs tours de raisonnement et d’appels ajoute chaque étape au temps total perçu par l’utilisateur. Dépasser dix secondes sur une seule requête ferme la porte à tout usage interactif, où la réponse est attendue en moins de deux ou trois secondes.
Ce constat cadre le reste de l’analyse. La question n’est pas la qualité brute de GPT-5.6-sol, que Neon ne conteste pas, mais son adéquation à une tâche répétée à grande échelle. Sur la recherche multi-tours, le coût marginal et le délai deviennent le facteur limitant, pas l’intelligence du modèle.
100x moins cher : l’argument des modèles à poids ouverts
Face à ce profil, Neon avance un chiffre franc : les petits modèles open-weights sont « 100x moins chers ». Rapporté au coût de 0,03 $ par requête de GPT-5.6-sol, cela place l’ordre de grandeur du modèle ouvert autour de 0,0003 $ par requête. Le rapport de un à cent est l’argument central de la démonstration.
Cet écart ne se limite pas à une ligne de facture. Il change la nature des décisions produit. Un coût cent fois plus bas autorise à multiplier les tours de recherche, à relancer une requête sans surveiller le compteur, ou à ouvrir une fonctionnalité à l’ensemble des utilisateurs plutôt qu’à un segment payant. Le budget cesse d’être le premier arbitre de l’architecture.
La documentation pose toutefois une limite honnête. Hors post-entraînement, ces modèles ouverts affichent des capacités « en retrait » par rapport aux modèles fermés d’API. L’économie ne suffit pas seule : un modèle cent fois moins cher mais nettement moins bon ne remplace pas GPT-5.6-sol sur la tâche visée.
Tout l’enjeu du comparatif tient dans cette tension. L’écart de prix est massif et documenté. L’écart de capacité brute existe aussi. La combinaison Castform + Neon se présente précisément comme le pont entre les deux : garder le coût du modèle ouvert, rattraper la performance sur une tâche ciblée.
Castform veut rendre le post-entraînement aussi simple que le prompt
Deux objections reviennent quand un développeur envisage de spécialiser un modèle ouvert. Neon les cite telles quelles : « We don’t have the training data » et « Fine-tuning is too difficult and requires infrastructure we don’t have ». Absence de données d’entraînement, complexité du fine-tuning, infrastructure manquante — ces trois freins écartent la plupart des équipes.
Castform répond à ce blocage sur le terrain de l’accessibilité. Selon la documentation de Neon, l’outil vise à permettre aux développeurs de post-entraîner des modèles par apprentissage par renforcement (RL) « sans avoir à gérer les internals du machine learning et des GPU ». L’objectif affiché est de rendre le post-entraînement « aussi abordable que le prompt engineering ».
La promesse déplace la frontière de compétence. Le prompt engineering est aujourd’hui à la portée d’un développeur applicatif ; le RL post-training ne l’est pas. En rangeant le second dans la même catégorie de difficulté que le premier, Castform prétend transformer une tâche d’expert ML en tâche d’ingénierie logicielle ordinaire. La documentation décrit l’intention ; elle ne fournit pas de mesure indépendante du gain de temps.
Neon fournit le contexte : Lakebase Postgres et extensions de recherche
Un modèle spécialisé ne suffit pas : il lui faut de quoi chercher. Neon décrit un « bon agent » comme fort sur deux axes, dont le premier est le contexte — la capacité à trouver, lire et manipuler les données brutes. C’est le rôle de l’infrastructure Neon.
Selon la documentation, Neon (Lakebase Postgres) et ses nouvelles extensions de recherche couvrent cette première brique de contexte. L’agent interroge une base Postgres, exploite les fonctions de recherche natives et récupère les données pertinentes avant de raisonner. Le modèle post-entraîné apporte la décision ; Neon apporte la matière.
Cette répartition explique pourquoi le comparatif oppose une combinaison à un modèle unique. GPT-5.6-sol est un modèle. Castform + Neon est un assemblage : un modèle ouvert spécialisé par Castform, alimenté par le contexte servi par Neon. Comparer les deux revient à confronter deux façons d’assembler une chaîne de récupération, pas seulement deux moteurs.
De la recherche en une requête à l’agent, puis au modèle spécialisé
La documentation de Neon retrace une évolution en trois temps de la recherche assistée. Aux débuts, la récupération augmentée (RAG) reposait sur une requête unique : une question, une recherche, une réponse. Vers 2025, les agents ont gagné du terrain et les développeurs ont bâti des workflows de recherche « multi-hop », enchaînant plusieurs étapes de recherche et de raisonnement.
Ce passage au multi-hop a amélioré la qualité des réponses sur les questions complexes. Il a aussi introduit le coût que le comparatif documente : chaque saut ajoute un appel au modèle, donc du temps et de l’argent. Les plus de 10 secondes et 0,03 $ de GPT-5.6-sol sont le prix de cette approche agentique poussée.
La troisième étape, celle défendue par Neon, consiste à spécialiser un petit modèle ouvert sur exactement cette tâche de recherche multi-tours. L’idée n’est pas de renoncer à l’agentique, mais d’en exécuter la boucle avec un moteur cent fois moins cher, rendu compétent par post-entraînement. Le comparatif oppose ainsi une génération d’architecture à la suivante, pas seulement deux fournisseurs.
Pour quel profil choisir Castform + Neon plutôt que GPT-5.6-sol
Le développeur sans compétence ML. Le premier profil visé est l’ingénieur applicatif qui n’a jamais entraîné de modèle. Les deux objections citées par Neon — pas de données, fine-tuning trop difficile — le décrivent précisément. Pour lui, l’argument n’est pas d’abord le prix mais l’accessibilité : Castform revendique un post-entraînement RL « aussi abordable que le prompt engineering ». Si cette promesse tient au test, ce profil accède à la spécialisation sans embaucher d’expert ML.
L’usage pro à fort volume. Le deuxième profil est l’équipe produit qui sert des recherches à grande échelle et surveille son coût unitaire. Ici, le facteur décisif est chiffré : 0,03 $ par requête avec GPT-5.6-sol contre un ordre de grandeur cent fois moindre côté modèle ouvert. À des volumes de plusieurs millions de requêtes, l’écart se compte en centaines de milliers de dollars par an. Ce profil a le plus à gagner à basculer, à condition de valider la qualité après post-entraînement.
Le développeur-intégrateur. Le troisième profil assemble la chaîne complète : modèle spécialisé plus infrastructure de contexte. Neon lui adresse Lakebase Postgres et ses extensions de recherche pour la récupération, Castform pour le post-entraînement. Ce profil accepte de gérer un assemblage plutôt qu’un simple appel d’API, en échange du contrôle sur le coût et sur le comportement du modèle. Pour un besoin ponctuel et sans contrainte de volume, l’API fermée de GPT-5.6-sol reste plus rapide à brancher.
Le choix se résume à un arbitrage documenté. GPT-5.6-sol offre des capacités brutes supérieures et une intégration immédiate, pour 0,03 $ et plus de 10 secondes par requête. Castform + Neon vise le même résultat sur la recherche pour un ordre de grandeur cent fois plus bas, au prix d’un travail de spécialisation et d’assemblage. Pour approfondir ces arbitrages, voir aussi notre dossier sur le vrai coût des LLM par million de tokens et notre analyse de l’essor des modèles à poids ouverts.
FAQ
Les modèles open-source sont-ils aussi performants que GPT-5.6-sol nativement ?
Non. La documentation de Neon indique que, « out of the box », les capacités des petits modèles ouverts restent en retrait par rapport aux modèles fermés d’API. L’écart se comble par post-entraînement par renforcement, ciblé sur une tâche précise comme la recherche multi-tours — pas sur l’ensemble des usages généralistes.
Quel est l’avantage principal de Castform pour un développeur ?
Réaliser un post-entraînement par renforcement sans gérer les internals du machine learning et des GPU. Neon décrit l’objectif comme rendre le post-training « aussi abordable que le prompt engineering ». Concrètement, un développeur applicatif spécialise un modèle sans passer par une expertise ML dédiée ni monter une infrastructure d’entraînement.
À retenir
- Coût unitaire : GPT-5.6-sol facture environ 0,03 $ et dépasse 10 secondes par requête de recherche multi-tours, quand les petits modèles ouverts visent un ordre de grandeur cent fois plus bas (~0,0003 $), selon Neon.
- Condition de bascule : l’économie ne vaut que si le post-entraînement RL, promu par Castform, rattrape l’écart de capacité brute sur la tâche ciblée — à valider par test.
- Assemblage : le comparatif oppose un modèle unique fermé à une chaîne ouverte (Castform pour la spécialisation, Lakebase Postgres et extensions de recherche Neon pour le contexte).
À suivre : l’élément manquant reste une mesure indépendante de la qualité après post-entraînement. Tant que Neon publie l’argument de coût sans benchmark public tiers, la vérification revient à chaque équipe. Le prochain jalon à surveiller d’ici la fin 2026 est la publication de scores comparés sur une tâche de recherche standardisée, seule donnée capable de confirmer le rapport prix-performance annoncé.
