Show HN: Echo — Fable-Niveau-Ergebnisse mit Open-Weight-Modellen zu einem Drittel der Kosten

• Echo kombiniert mehrere Open-Weight-Modelle wie GLM-5.2 und Kimi K2.7 je Anfrage, um die Grenzen eines Ansatzes auszugleichen, bei dem ein einzelnes Modell alle Aufgaben übernimmt
• Für jede Anfrage werden Rechenaufwand und beteiligte Modelle festgelegt und sogar die Methode zur Zusammenführung der Ergebnisse angepasst, sodass für einfache Prompts wenig Inferenzressourcen verwendet werden
• In der ersten Evaluationskonfiguration lag es durchgängig vor dem besten Einzelmodell im Pool und erreichte ähnliche Gesamtergebnisse wie Fable bei etwa einem Drittel der Inferenzkosten
• Selbst insgesamt schwächere Modelle haben Fähigkeiten, die sich für bestimmte Probleme oder Kombinationen nützlich ergänzen, doch Fehlentscheidungen bei Zuweisung und Zusammenführung kommen weiterhin vor
• Eine Chat-Oberfläche und eine OpenAI-kompatible API wurden veröffentlicht; außerdem wird getestet, ob derselbe Ansatz auch bei Coding- und Agent-Aufgaben funktioniert, bei denen die Qualitätsmessung schwieriger ist

---

Modellauswahl und Ergebniszusammenführung

• In ersten Experimenten wurden GLM-5.2, Kimi K2.7 und weitere Modelle in dieselbe Evaluation geschickt; dabei wurde angenommen, dass man für jedes Problem im Voraus wüsste, welche Modelle nützlich sind und wie sich die Ausgaben sinnvoll kombinieren lassen
  • Dieses hypothetische System erzielte eine deutlich höhere Leistung als jedes einzelne Modell im Pool
  • Es lässt sich in der Praxis nicht einsetzen, weil gute Entscheidungen erst nach Sichtung der Ergebnisse erkennbar sind; Echo ist der Versuch, einen Teil dieses Vorteils auch ohne Vorabinformationen zurückzugewinnen
• Je nach Eigenschaften der Anfrage wählt es den nötigen Rechenaufwand, die beteiligten Modelle und die Methode zur Zusammenführung der Ergebnisse
  • Für einfache Prompts wird vergleichsweise wenig Inferenz zugewiesen
  • Bei anderen Problemen werden mehrere Modelle so eingesetzt, dass sie unterschiedliche Teile bearbeiten
• Die Fähigkeiten der Modelle sind komplementär, sodass selbst Modelle mit klar geringerer Gesamtleistung bei bestimmten Problemen oder Kombinationen sehr nützlich sein können

Evaluationsergebnisse und öffentlicher Test

• In der ersten Evaluationskonfiguration wurde durchgängig eine höhere Leistung als beim besten Einzelmodell erzielt; verglichen mit Fable erreichte Echo ungefähr dieselben Gesamtergebnisse zu rund einem Drittel der Kosten
• Bei manchen Anfragen werden Rechenzuweisung oder Modellkombination falsch entschieden; diese Fehlfälle werden derzeit analysiert
• Bei Coding- und Agent-Aufgaben ist es deutlich schwieriger, die Qualität jeder Entscheidung zu messen; daher wird separat geprüft, ob derselbe Ansatz dort Bestand hat
• Für externe Tests stehen die Echo-Chat-Oberfläche und die OpenAI-kompatible API zur Verfügung
• Veröffentlicht wurden außerdem ein Video zur Funktionsweise sowie Informationen zu Evaluationsmethodik, Ergebnissen einzelner Modelle, Kosten und aktuellen Grenzen; zugleich wird um Feedback zu ungewöhnlichen Fehlfällen oder wenig intuitiven Ressourcenzuweisungen gebeten

[GN⁺]

Meinungen auf Hacker News

• Ein typisches Dark Pattern: Erst wird ein Message-Echo-Eingabefeld gezeigt, das so aussieht, als könne man eine Antwort erhalten, danach wird man auf die Registrierungsseite geschickt.
  Da schon die erste vom Site-Design ausgelöste Aktion ausgebremst wurde, bin ich sofort gegangen und werde nicht wiederkommen.

  • Ich habe genau dasselbe empfunden, und weil ich solche Dark Patterns so sehr hasse, habe ich jetzt keinerlei Interesse mehr an diesem Produkt.
  • Wir entfernen das gerade.
  • Andererseits müsste der Betreiber die Kosten der ersten Anfrage tragen, wenn Anfragen vor dem Login erlaubt wären, und Missbrauch könnte zu einer hohen Rechnung führen.
    Aus Sicht eines AI-Produkts ist diese Entscheidung durchaus nachvollziehbar.

• Danke an alle, die Echo genutzt und Feedback gegeben haben; genau deshalb haben wir so früh veröffentlicht.
  Wir werden weiterhin Evaluierungen veröffentlichen, die den Abstand zum aktuellen State of the Art genauer zeigen, einschließlich schwierigerer Coding- und Agenten-Benchmarks, und auch das öffentliche Evaluierungs-Dashboard ausbauen. Die im UI des Evaluierungs-Dashboards und im Registrierungsablauf gefundenen Probleme haben wir in der Produktionsumgebung behoben.
  Zum Ausprobieren von Echo ist keine Kreditkarte erforderlich, und jedes Konto erhält 10 US-Dollar Gratis-Credits für API und Chat.
  Über einfaches Model Routing hinaus untersuchen wir, wie sich Inferenzressourcen effizient auf Open-Weight-Modelle verteilen lassen. Dabei entscheiden wir nicht nur, welches Modell verwendet wird, sondern auch, wie viel Rechenaufwand in eine Anfrage fließt und wie Zwischenergebnisse kombiniert werden.
  Ensembling an sich ist schon seit vor Random Forests bekannt, aber der Kern von Echo besteht darin, dies zu modellieren und zu nutzen, ohne für jede Anfrage die Kosten des gesamten Ensembles zu zahlen. Auch wenn es konzeptionell Ähnlichkeiten mit Fusion oder Fugu gibt, unterscheiden sich Architektur und Optimierungsziele.

  • Kleines Feedback: create password verlangt Sonderzeichen, aber die standardmäßig von Googles Passwortmanager generierten Passwörter enthalten keine Sonderzeichen.
    Eine zweistellige Länge mit alphanumerischen Zeichen scheint ausreichend, aber die Idee selbst ist großartig.
  • Ich frage mich, warum ihr ein Dark Pattern verwendet habt. Ich war interessiert, jetzt nicht mehr.
  • Obwohl ich die Registrierung nur einmal versucht habe, trat der Fehler too many authentication attempts auf.
  • Ihr solltet das Dark Pattern entfernen.
  • Ihr betont ständig Open Weights, legt aber überhaupt nicht offen, welche Modelle ihr verwendet.
    Ohne Transparenz weiß ich nicht, welchen Vorteil die Nutzung von Open-Weight-Modellen für Endnutzer haben soll.

• Die Beschreibung Ergebnisse auf Fable-Niveau zu einem Drittel der Kosten wirkt für Nutzer des stark subventionierten 200-Dollar-Monatstarifs nicht besonders attraktiv.
  Ich weiß nicht, wie lange dieser Tarif bestehen bleibt, aber bis dahin ist selbst ein Drittel der öffentlichen API-Preise nicht sonderlich verlockend.

  • Nachdem ich im 200-Dollar-Monatstarif mein wöchentliches Fable-Kontingent aufgebraucht hatte, führte ich mit 200 Dollar Promo-Credits einen mittelgroßen Coding-Plan aus und verbrauchte 120 Dollar in 1 Stunde und 15 Minuten.
    Es liefen mehrere Subagenten gleichzeitig, und Claude vergaß die Anweisung, günstigere Modelle zu verwenden, sodass mehrere Fable-Instanzen liefen; aber Abrechnung pro Token ist schwer zu verkraften. 200 Dollar im Monat sind schon teuer, aber 200 Dollar über Nacht sind absurd.
  • Unternehmenskunden, die es beruflich nutzen, können subventionierte Tarife nicht verwenden, daher macht ein solcher Tarif am Gesamtverbrauch vermutlich nur einen kleinen Anteil aus.
  • Dieser Tarif wird wohl bis zum Börsengang (IPO) bestehen bleiben, danach aber vermutlich nicht mehr lange.
    Wenn ein Nutzer für 200 Dollar im Monat API-Credits im Wert von 10.000 Dollar verbraucht, liegt die Marge pro Nutzer bei -98 %, was der Profitabilität nicht hilft.
  • Wenn es darum geht, Nutzungslimits oder eine Kontosperrung beim Überschreiten einer Grenze zu vermeiden, ist das eine andere Geschichte.
  • Laut einer E-Mail, die ich heute von Anthropic erhalten habe, wird Fable 5 ab dem 20. Juli auf ein Usage-Credit-Modell umgestellt.
    Man kann es weiter nutzen, aber dafür sind Pay-as-you-go-Credits erforderlich, und es zählt nicht zu den Nutzungslimits des Abotarifs.

• Es würde mich nicht überraschen, wenn das Konzept des besten Modells in den nächsten Jahren zur Nische wird.
  In den meisten Produktionssystemen könnte der Orchestrator gewinnen, der weiß, wann ein günstiges Modell genutzt wird, wann auf ein stärkeres Modell umgeschaltet wird und wann mehrere Ausgaben kombiniert werden.

  • Ist das nicht die Idee hinter der Gemini CLI?
  • Es gibt sehr viele mögliche Entwicklungspfade, aber am Ende dürfte es darauf hinauslaufen, dass das beste Modell zu einem Nischenkonzept wird.
    Der große Trend sind On-Device-Modelle; denkbar ist auch, dass Modelle direkt in den Chip-Die wandern und man alle paar Jahre den Chipsatz austauscht. In so einem Umfeld würden große Cloud-Anbieter verlieren.

• Eine der interessantesten Schlussfolgerungen ist, dass Modellauswahl wichtiger sein kann als Modellgröße.
  Die Branche hat sich auf größere Modelle konzentriert, aber wenn Anfragen intelligent an die passende Kombination spezialisierter Modelle geroutet werden, scheinen deutlich größere Verbesserungen zu viel geringeren Kosten möglich.
  Schwächere Modelle sind nicht nutzlos geworden; sie sind in unterschiedlichen Bereichen stark, und in Kombination mit anderen Modellen kann ihr Wert erheblich steigen. Ich frage mich allerdings, ob das auch bei Coding- und Agentenaufgaben gilt, bei denen die passende Modellauswahl deutlich schwieriger ist.

  • Wenn man kleine Modelle, die jeweils auf eine Aufgabe spezialisiert und zugleich wenig korreliert sind, stark ensembliert, kann das sehr interessante Ergebnisse liefern.
    Agenten- und Coding-Aufgaben sind wegen ihrer Granularität komplexer. Man muss entscheiden, wann und wie jedes Modell eingesetzt wird und auf welcher Abstraktionsebene – Sitzung, Ziel, Aufgabe, Gesprächsrunde oder Tool-Aufruf. Daran wird derzeit aktiv geforscht.

• Ich habe tatsächlich einige Mängel in der User Experience gefunden.
  Thinking wird ständig angezeigt, sodass es so wirkt, als sei alles hängen geblieben oder es gebe ein Netzwerkproblem, und das linke Panel zur Prompt-Eingabe lässt sich nicht erweitern oder in der Größe ändern. Wenn ich darum bitte, Code zu erzeugen, bricht die Ausgabe immer wieder ab und startet dann von vorn, ohne die vorherige Unterhaltung fortzusetzen.

• Wenn man die Komplexität eines Problems nicht im Voraus kennt und nicht garantiert ist, dass die weitere Unterhaltung an dasselbe Modell geht, funktioniert dieser Ansatz nicht gut.
  Wenn man dieselbe Unterhaltung per Round Robin an mehrere Modelle schickt, zerstört man den Cache, wodurch es am Ende sogar teurer werden kann als ein System, das Caching berücksichtigt.

  • Man kann die Ralph-Wiggum-Technik verwenden: https://ghuntley.com/ralph/
  • Auch Cache-Hits sollten Teil der Strategie sein.

• Ich habe Anthropic Opus 4.8 und Fable 5 eine Weile genutzt und auch die neuesten OpenAI-Modelle getestet; alle erzeugen viel zu viel unnötigen Output.
  Ich habe nicht wegen des Preises, sondern wegen der Qualität angefangen, andere Modelle auszuprobieren, und in meinem Arbeitsbereich war GLM 5.2 Fable 5 in jeder Hinsicht deutlich überlegen. Es ist eher überraschend, wenn es eine Aufgabe nicht erfolgreich abschließt.
  Kimi K2.7 braucht etwas mehr Anweisungen, fühlt sich aber besser an als Opus 4.8; K3 habe ich noch nicht ausprobiert. Die neuesten OpenAI-Modelle sind bei Softwaredesign und Implementierung absurd schlecht.
  Diese Einschätzung bezieht sich nur auf meinen Arbeitsbereich, der stark von Datenanalyse, Machine Learning und Software Engineering geprägt ist.

• Es gibt weder Benchmarks noch Angaben zu den verwendeten Modellen, nur ein KI-generiertes Video und eine Anmeldeseite.
  Das erinnert mich an den Architekturwitz: „Wir haben den Monolithen in Microservices umgewandelt und damit jeden Ausfall zu einem Mordrätsel gemacht.“

  • Der öffentliche Evaluator ist unter https://echo.tracerml.ai/eval/ verfügbar.
    Derzeit werden 907 gespeicherte Zeilen aus 7 Benchmark-Familien öffentlich angezeigt; Prompts, Outputs, Bewertungen und Kostenaufzeichnungen lassen sich einsehen, und es soll noch mehr hinzukommen.
    Die Routing-Policy pro Anfrage selbst ist das Produkt und wird daher nicht offengelegt, aber wir können einen Teil der nutzbaren Open-Weight-Modelle, Versionsdaten, die gesamte Allokationsverteilung und die Evaluationskonfiguration veröffentlichen, soweit dabei keine anfragespezifischen Tricks preisgegeben werden. Ein neues Video ist ebenfalls in Arbeit.
  • Die Benchmarks sind unter https://echo.tracerml.ai/eval/ zu finden.
    Es sind keine guten Benchmarks, aber immerhin existieren sie.
  • Im Kern scheint das darauf hinauszulaufen, OpenRouter nachzubauen. OpenRouter ist eine clevere Infrastrukturabstraktion, die bestimmte Anbieter über Failover, Nutzungsmessung, automatisches Umschalten usw. abstrahiert und ziemlich gut funktioniert.
    Schade ist, dass es eher wie der Versuch wirkt, Investoren zu sagen: „OpenRouter ist ein Unicorn geworden, also kann ich per Vibe Coding etwas Ähnliches bauen“, statt ein echtes Problem zu lösen.
    Es als Fable-Niveau zu bezeichnen, wirkt außerdem intellektuell bequem oder unehrlich.
  • Das erinnert mich an tenderloves Satz: „Microservices machen aus einem Funktionsaufruf ein Distributed-Computing-Problem.“
  • Soweit ich weiß, sind Apps, die durch Login geschützt sind, bei Show HN nicht erlaubt.

• Ich frage mich, ob das einfach Dogpile.com neu gebaut ist, das die Ergebnisse von Ask Jeeves, AltaVista und Lycos zusammengeführt hat. Die Zeit scheint zyklisch zu sein.

  • Gute Ideen bleiben meist gut, auch wenn sich Zeit und Werkzeuge ändern.
  • Ensemble-Modelle haben auch bei Kaggle immer die beste Performance geliefert.
    Wir haben denselben Ansatz umgesetzt: https://trustedrouter.com/blog/prometheus-2-new-draco-state-...
  • Der Ansatz besteht darin, nicht für jede Aufgabe des Dienstes dieselbe EC2-Instance-Größe zu verwenden.
  • Man kann auch dreieckige Räder bauen, aber es gibt einen Grund, warum Räder rund sind.
  • Man kann es als Mixture of Models betrachten.
    Andere AI-Gateway-Produkte wie OpenRouter, JusCode und Fireworks empfehlen seit Kurzem ebenfalls eine ähnliche Konfiguration, also dürfte daran durchaus etwas Nützliches sein.