Jeder Token pro Sekunde ist Geld

Auf den meisten Plattformen ist eine langsame Abhängigkeit ein langsames Produkt. Auf unserer ist sie jemandes Einkommen. Hosts werden pro Token bezahlt, den ihre Maschine produziert, Durchsatz übersetzt sich also direkt in Euro pro Stunde — und eine Karte, die mit halber Rate dekodiert, verdient halb so viel bei gleichem Strom, gleichem Verschleiß und denselben Stunden, in denen sie für nichts anderes verfügbar ist.

Das ändert, wie wir Performance behandeln. Sie ist kein Nice-to-have, zu dem wir kommen, wenn Zeit ist. Sie ist die Zahl, auf der unsere Hosts bezahlt werden, also wird sie gemessen, bevor sie ausgeliefert wird.

Wir wählen den Engine-Build per Benchmark, nicht per Versionsnummer

Jeder Host fährt dieselbe Inferenz-Engine, per Digest in mahout gepinnt und beim Download verifiziert. Die naheliegende Politik wäre, dem neuesten Upstream-Release zu folgen. Tun wir nicht, denn „neuestes" ist eine Vermutung über Performance, und wir können schlicht nachmessen.

Ein Kandidaten-Build wird gegen den aktuellen auf echten Consumer-Karten gebenchmarkt, mit demselben Modell und denselben Flags, und der Pin bewegt sich nur, wenn der Kandidat gewinnt. Die Release-Notes eines großen Projekts können nicht zuverlässig sagen, was mit einem Backend auf einer Hardware-Klasse passiert ist, und der Abstand zwischen zwei Builds im Abstand weniger Monate kann ein Mehrfaches des Durchsatzes betragen — in beide Richtungen.

Das Werkzeug für den Vergleich liegt im mahout-Repository; das hier ist also reproduzierbar, keine Behauptung.

Spekulatives Dekodieren, wo die Gewichte es erlauben

Manche offenen Modelle werden mit einem kleinen Vorhersagekopf veröffentlicht, der die nächsten paar Token aus dem eigenen Hidden State des Modells errät. Die Engine verifiziert diese Vermutungen in einem einzigen Durchlauf; liegen sie richtig, kosten mehrere Token ungefähr so viel wie einer. Auf einem gesunden Build ist das mehr als das Dreifache der einfachen Dekodierrate wert — der größte einzelne Hebel, der auf Consumer-Hardware heute verfügbar ist.

Es ist eine Eigenschaft der Gewichte, keine Einstellung, sie gilt also für die Katalog-Builds, die einen solchen Kopf mitbringen. Wo er existiert, nutzt mahout ihn.

Die richtige Karte, ohne dass Sie etwas konfigurieren

Viele Enthusiasten-Maschinen haben zwei GPUs. mahout wählt die mit dem meisten freien Speicher, weist die Engine an, genau diese Karte zu nutzen, und druckt die Wahl aus, bevor auch nur ein Byte heruntergeladen wird. Freier statt gesamter Speicher — wenn Sie die große Karte gerade selbst benutzen, nimmt es leise die andere, statt mit Ihnen darum zu kämpfen.

Und die langweiligen, entscheidenden Dinge

Ein quantisierter KV-Cache, der die Kosten einer langen Konversation etwa auf ein Viertel senkt. Flash Attention an. Kontextlänge und Parallelität pro Build statt global gesetzt. Und vor allem: Builds so dimensioniert, dass das Modell vollständig auf der GPU bleibt — ein Modell, das in den Systemspeicher überläuft, dekodiert um ein Mehrfaches langsamer, und keine Cleverness anderswo holt das zurück.

Was wir nicht tun werden

Eigene Engine-Binaries kompilieren. Wir haben es gemessen: Ein lokal kompilierter Build desselben Release landet innerhalb von etwa zehn Prozent des offiziellen Archivs. Zehn Prozent sind es nicht wert, zum Verteiler eines unsignierten Binaries zu werden, das auf den Computern anderer Leute läuft — also liefern wir das Upstream-Artefakt aus und stecken die Mühe in seine Auswahl.

Und wir nennen Ihnen keine Durchsatzzahl für Ihre Hardware. Führen Sie mahout bench aus und bekommen Sie eine gemessene, signiert auf Ihrer eigenen Maschine. Die vollständige Referenz steht in der Wissensdatenbank.