Show HN : Echo — des résultats au niveau de Fable avec des modèles à poids ouverts, pour un tiers du coût

• Echo combine plusieurs modèles à poids ouverts, comme GLM-5.2 et Kimi K2.7, requête par requête, afin de dépasser les limites d’une approche qui confie toutes les tâches à un seul modèle
• Pour chaque requête, il détermine la quantité de calcul et les modèles participants, et ajuste même la façon de combiner les résultats, afin d’utiliser moins de ressources d’inférence pour les prompts simples
• Dans sa première configuration d’évaluation, il a systématiquement surpassé le meilleur modèle individuel du pool et obtenu des résultats globaux comparables à Fable pour environ un tiers du coût d’inférence
• Même des modèles globalement plus faibles peuvent être utiles sur certains problèmes ou dans certaines combinaisons, leurs capacités étant complémentaires, mais il reste des cas où les décisions d’allocation et de combinaison sont mauvaises
• Une interface de chat et une API compatible OpenAI ont été publiées ; la même approche est en cours de test sur des tâches de code et d’agents, où la mesure de la qualité est plus difficile

---

Sélection des modèles et combinaison des résultats

• Dans les premières expériences, GLM-5.2, Kimi K2.7 et d’autres modèles ont été soumis aux mêmes évaluations, en supposant que l’on savait à l’avance quels modèles seraient utiles pour chaque problème et quelle méthode de combinaison des sorties serait appropriée
  • Ce système hypothétique obtient des performances nettement supérieures à celles de n’importe quel modèle individuel inclus dans le pool
  • Comme les bonnes décisions ne peuvent être identifiées qu’après avoir observé les résultats, il n’est pas utilisable en déploiement réel ; Echo tente de récupérer une partie de cet avantage sans information préalable
• Selon les caractéristiques de la requête, il choisit la quantité de calcul nécessaire, les modèles participants et la méthode de combinaison des résultats
  • Il alloue relativement peu d’inférence aux prompts simples
  • Pour d’autres problèmes, il configure plusieurs modèles afin qu’ils traitent différentes parties
• Les capacités des modèles sont complémentaires, si bien qu’un modèle dont les performances globales sont nettement plus faibles peut se révéler très utile sur certains problèmes ou dans certaines combinaisons

Résultats d’évaluation et test public

• Dans la première configuration d’évaluation, il a enregistré des performances systématiquement supérieures à celles du meilleur modèle individuel et a obtenu des résultats globaux à peu près équivalents à ceux de Fable pour environ un tiers du coût
• Sur certaines requêtes, il prend de mauvaises décisions d’allocation du calcul ou de combinaison des modèles ; ces cas d’échec sont actuellement analysés
• Pour les tâches de code et d’agents, il est beaucoup plus difficile de mesurer la qualité de chaque décision ; la même approche y est donc testée séparément
• Pour des tests externes, une interface de chat Echo et une API compatible OpenAI sont proposées
• Une vidéo présentant le fonctionnement ainsi que la méthodologie d’évaluation, les résultats par modèle, les coûts et les limites actuelles ont été publiées, avec une demande de retours sur les échecs anormaux ou les cas d’allocation de ressources peu intuitifs

[GN⁺]

Commentaires sur Hacker News

• C’est un dark pattern classique : on montre un champ de saisie Message Echo qui semble permettre d’obtenir une réponse, puis on renvoie vers la page d’inscription
  J’ai été bloqué dès la première action suggérée par le site, donc je suis parti immédiatement et je ne reviendrai pas

  • J’ai ressenti exactement la même chose, et je déteste tellement ce genre de dark pattern que ce produit ne m’intéresse plus du tout désormais
  • C’est en train d’être supprimé
  • À l’inverse, autoriser des requêtes avant connexion obligerait le créateur à prendre en charge le coût des premières requêtes, avec le risque d’une grosse facture en cas d’abus
    Du point de vue de quelqu’un qui construit un produit d’IA, c’est aussi un choix compréhensible

• Merci à tous ceux qui ont utilisé Echo et donné leur avis, c’est précisément pour cela que nous avons lancé tôt
  Nous allons continuer à publier des évaluations montrant plus précisément l’écart avec le meilleur niveau actuel, y compris sur des benchmarks de code et d’agents plus difficiles, et nous prévoyons aussi d’élargir le tableau de bord public d’évaluation. Les problèmes repérés dans l’interface du tableau de bord et dans le processus d’inscription ont été corrigés en production
  L’essai d’Echo ne nécessite pas de carte bancaire, et chaque compte reçoit 10 $ de crédits gratuits utilisables via l’API et le chat
  Au-delà du simple routage de modèles, nous explorons comment allouer efficacement les ressources d’inférence entre des modèles à poids ouverts. Il s’agit de décider non seulement quel modèle utiliser, mais aussi combien de calcul consacrer à une requête et comment combiner les résultats intermédiaires
  Les ensembles existent bien avant les random forests, mais le cœur d’Echo est de les modéliser et de les exploiter sans payer le coût de l’ensemble complet à chaque requête. Il existe des similarités conceptuelles avec Fusion ou Fugu, mais l’architecture et les objectifs d’optimisation sont différents

  • Petit retour : create password exige des caractères spéciaux, mais le mot de passe généré par défaut par Google Password Manager n’en contient pas
    Une combinaison alphanumérique de deux chiffres de longueur semble suffisante, mais l’idée elle-même est excellente
  • Je me demande pourquoi vous avez utilisé un dark pattern. J’étais intéressé, mais ce n’est plus le cas
  • J’ai essayé de m’inscrire une seule fois et j’ai quand même reçu l’erreur too many authentication attempts
  • Il faut supprimer le dark pattern
  • Vous insistez sans cesse sur les poids ouverts sans jamais révéler quels modèles vous utilisez
    Sans transparence, je ne vois pas quel avantage cela apporte à l’utilisateur final d’utiliser des modèles à poids ouverts

• La promesse de résultats de niveau Fable pour un tiers du coût ne paraît pas très attractive pour les utilisateurs du forfait à 200 $ par mois fortement subventionné
  Je ne sais pas combien de temps ce forfait sera maintenu, mais d’ici là, même un tiers du prix de l’API publique n’est pas si attirant

  • Avec le forfait à 200 $ par mois, après avoir épuisé l’usage hebdomadaire de Fable, j’ai exécuté un plan de code de taille moyenne avec 200 $ de crédits promotionnels et j’ai dépensé 120 $ en 1 h 15
    Plusieurs sous-agents tournaient en parallèle, et Claude a oublié l’instruction d’utiliser des modèles bon marché, donc plusieurs instances Fable ont tourné, mais la facturation au token est difficilement soutenable. 200 $ par mois est déjà cher, mais 200 $ en une nuit, c’est absurde
  • Les clients entreprises qui l’utilisent pour le travail ne peuvent pas profiter d’un forfait subventionné, donc ce type de forfait représente probablement une faible part de l’usage total
  • Ce forfait sera sans doute maintenu jusqu’à l’IPO, mais probablement pas longtemps après
    Si un utilisateur à 200 $ par mois consomme l’équivalent de 10 000 $ de crédits API, la marge par utilisateur est de -98 %, ce qui n’aide pas le compte de résultat
  • C’est différent si l’objectif est d’éviter des limites d’usage ou une suspension de compte une fois une certaine ligne franchie
  • Selon l’e-mail reçu aujourd’hui d’Anthropic, Fable 5 passera à un système de crédits d’usage à partir du 20 juillet
    Il restera disponible, mais il faudra des crédits à l’usage, et cela ne comptera pas dans les limites d’utilisation du forfait d’abonnement

• Je ne serais pas surpris que, dans les prochaines années, la notion de meilleur modèle devienne une niche
  Dans la plupart des systèmes en production, le gagnant pourrait être un orchestrateur qui sait quand utiliser un modèle bon marché, quand basculer vers un modèle puissant et quand combiner plusieurs sorties

  • Je me demande si ce n’est pas l’idée derrière Gemini CLI
  • Il y a énormément de directions possibles pour évoluer, mais cela finira probablement par converger vers un monde où le meilleur modèle devient une notion de niche
    La grande tendance, ce sont les modèles embarqués sur l’appareil, avec des modèles intégrés dans la puce elle-même et un remplacement du chipset tous les quelques ans. Dans un tel environnement, les grands fournisseurs cloud seraient perdants

• L’une des conclusions les plus intéressantes est que le choix du modèle pourrait compter davantage que la taille du modèle
  Le secteur s’est concentré sur des modèles plus grands, mais il semble qu’un routage intelligent des requêtes vers une combinaison appropriée de modèles spécialisés puisse apporter des gains bien plus importants à un coût bien inférieur
  Les modèles faibles ne sont pas devenus inutiles : ils excellent chacun dans des domaines différents, et leur valeur peut fortement augmenter lorsqu’ils sont combinés avec d’autres modèles. Je me demande toutefois si cela reste vrai pour les tâches de code et d’agents, où le choix correct du modèle est bien plus difficile

  • Un ensemble fort de petits modèles spécialisés par tâche et faiblement corrélés pourrait produire des résultats très intéressants
    Les tâches d’agents et de code sont plus complexes à cause de leur granularité. Il faut décider quand et comment utiliser chaque modèle, et à quel niveau d’abstraction — session, objectif, tâche, tour de dialogue ou appel d’outil —, et cela fait actuellement l’objet de recherches actives

• J’ai effectivement repéré plusieurs défauts d’expérience utilisateur
  Thinking reste affiché en continu, donnant l’impression que tout est bloqué ou qu’il y a un problème réseau, et il est impossible d’agrandir ou de redimensionner le panneau de gauche où l’on saisit le prompt. Quand on demande de générer du code, la sortie s’interrompt sans cesse puis redémarre depuis le début, sans pouvoir reprendre la conversation précédente

• Cette approche ne fonctionnera pas bien si l’on ne peut pas connaître à l’avance la complexité du problème et si rien ne garantit que la suite de la conversation sera envoyée au même modèle
  Si une même conversation est envoyée en round robin à plusieurs modèles, le cache est cassé, ce qui risque de coûter encore plus cher qu’un système qui tient compte du cache

  • On peut utiliser la méthode Ralph Wiggum : https://ghuntley.com/ralph/
  • Les cache hits doivent aussi faire partie de la stratégie

• J’ai utilisé Anthropic Opus 4.8 et Fable 5 pendant un moment, et j’ai aussi testé les derniers modèles d’OpenAI, mais tous génèrent beaucoup trop de sorties inutiles
  J’ai commencé à tester d’autres modèles non pas à cause du prix, mais à cause de la qualité, et dans mon domaine de travail, GLM 5.2 est largement supérieur à Fable 5 sur tous les plans. Il est presque étonnant qu’il échoue parfois à terminer une tâche avec succès
  Kimi K2.7 demande un peu plus d’instructions, mais offre une meilleure expérience qu’Opus 4.8, et je n’ai pas encore essayé K3. Les derniers modèles d’OpenAI sont absurdement mauvais en conception et en implémentation logicielle
  Cette évaluation est limitée à mon domaine de travail, qui comprend beaucoup d’analyse de données, de machine learning et de génie logiciel

• Il n’y a ni benchmark ni informations sur les modèles utilisés, seulement une vidéo générée par IA et une page d’inscription
  Ça me rappelle la blague d’architecture : « on a transformé le monolithe en microservices et fait de chaque panne une enquête pour meurtre »

  • L’évaluateur public est disponible sur https://echo.tracerml.ai/eval/
    Il expose actuellement 907 lignes enregistrées sur 7 familles de benchmarks, avec les prompts, sorties, évaluations et historiques de coûts, et d’autres seront ajoutés
    Comme la politique de routage par requête est le produit lui-même, elle n’est pas publiée, mais nous pouvons divulguer une partie de la liste des modèles open weight utilisables, les dates de version, les ratios d’allocation globaux et les paramètres d’évaluation, tant que cela ne révèle pas les recettes secrètes par requête. Une nouvelle vidéo est aussi en cours de production
  • Les benchmarks sont sur https://echo.tracerml.ai/eval/
    Ce ne sont pas de bons benchmarks, mais au moins ils existent
  • En substance, ça semble vouloir reproduire OpenRouter. OpenRouter est une astucieuse abstraction d’infrastructure qui abstrait un fournisseur donné avec basculement, mesure d’usage, commutation automatique, etc., et ça marche plutôt bien
    C’est dommage, car cela ressemble davantage à une tentative de dire aux investisseurs « OpenRouter est devenu une licorne, donc moi aussi je peux fabriquer quelque chose de similaire en vibe coding » qu’à une volonté de résoudre un vrai problème
    Le fait d’appeler ça niveau Fable paraît aussi intellectuellement paresseux ou malhonnête
  • Ça me rappelle la formule de tenderlove : « les microservices transforment les appels de fonction en problème de calcul distribué »
  • Sauf erreur de ma part, une application protégée par connexion n’est pas autorisée sur Show HN

• Je me demande si c’est simplement le retour de Dogpile.com, qui agrégeait les résultats d’Ask Jeeves, AltaVista et Lycos. On dirait que le temps est cyclique

  • Les bonnes idées restent généralement bonnes même quand l’époque et les outils changent
  • Les modèles d’ensemble ont toujours obtenu les meilleures performances sur Kaggle
    Nous avons nous aussi implémenté la même approche : https://trustedrouter.com/blog/prometheus-2-new-draco-state-...
  • C’est une approche qui n’utilise pas la même taille d’instance EC2 pour toutes les tâches d’un service
  • On peut fabriquer des roues triangulaires, mais s’il y a une raison pour laquelle les roues sont rondes
  • On peut voir cela comme un Mixture of Models
    D’autres produits récents de passerelle IA comme OpenRouter, JusCode et Fireworks recommandent aussi cette configuration, donc il y a probablement là quelque chose d’utile