Was 2.122 Token pro Sekunde aussagen – und was sie offenlassen

Am 27. September veröffentlichte NaiveAI den technischen Artikel zu Naive-N0.5-Flash. NaiveRT, optimiert für das Decoding eines einzelnen Datenstroms bei Rollouts im Reinforcement Learning, erreicht laut Bericht mit einem fusionierten DFlash-Entwurfsmodell für spekulatives Decoding 2.122 Token pro Sekunde. Die genannten Bedingungen sind entscheidend: acht GPUs, das beste Zeitfenster von einer Sekunde aus 41 HTML/SVG-Anfragen, deaktiviertes Denken und eine nicht mitgerechnete Eingabeverarbeitung (Prefill). Das ist eine Messung des Entwicklers, kein von SlateMoth unabhängig reproduziertes Ergebnis. [1]

Die entscheidende Frage lautet, welchen Teil der tatsächlichen Wartezeit diese Messung abdeckt. Eine maximale Decoding-Rate beschreibt nur einen Abschnitt einer Anfrage. Sie sagt nicht unmittelbar, wie lange eine Codeänderung, ein Bericht oder eine Agentenaufgabe bis zum Abschluss dauert. Wer Modelle bewertet, kann ein vielversprechendes technisches Ergebnis fairer einordnen, wenn diese Fragen getrennt bleiben.

Wir schlagen drei Uhren vor. Die erste läuft vom Absenden einer Anfrage bis zur ersten brauchbaren Ausgabe und umfasst das für die anfragende Person spürbare Warten sowie die Verarbeitung der Eingabe. Die zweite misst die verbleibende Generierungszeit von dieser ersten Ausgabe bis zur vollständigen Antwort. Die dritte erfasst die gesamte Aufgabe vom Absenden bis zur Abnahme, einschließlich Werkzeugaufrufen, Tests und nötigen Wiederholungen. Wird ein Abschnitt schneller, verkürzt sich die Gesamtzeit nicht zwangsläufig im selben Verhältnis.

Nehmen wir eine hypothetische Codeänderung: Das Laden des Projekts und das Warten auf die erste Ausgabe dauern 12 Sekunden, die Generierung 8 Sekunden und die Tests 40 Sekunden. Selbst wenn die Generierung viermal schneller wird, sinkt die Gesamtzeit nur von 60 auf 54 Sekunden – eine Ersparnis von 10 %. Diese Zahlen dienen der Veranschaulichung; sie sind keine Messungen von NaiveAI. Bevor man einen gemeldeten Geschwindigkeitsgewinn auf den gesamten Arbeitsablauf überträgt, muss man messen, wo die Zeit tatsächlich vergeht.

Ein kurzer Spitzenwert lässt zudem offen, ob die Generierung während einer langen Antwort oder bei gleichzeitigen Anfragen ähnlich schnell bleibt. Fragen Sie nach der Dauer vollständiger Antworten und nach Latenzverteilungen unter der erwarteten Auslastung. Die Geschwindigkeit einer einzelnen Anfrage ist vom Gesamtdurchsatz zu trennen: Mehr Anfragen pro Sekunde zu bedienen und die Aufgabe einer Person früher abzuschließen, sind verschiedene Ziele.

Die Modellkarte nennt insgesamt 309 Milliarden Parameter, davon 15,5 Milliarden aktive Parameter. Laut den Hinweisen zur Bereitstellung mit FP8 belegen die Gewichte ungefähr 315 GB; für die Inferenz wird zusätzlicher GPU-Speicher benötigt. Dort steht auch, dass die Architektur mit Sparse Attention den vollständigen KV-Cache beibehält. Diese Angaben verhindern ein häufiges Missverständnis: Aus der Zahl der aktiven Parameter folgt nicht, dass das gesamte Modell in den Speicher passt, den ein dichtes Modell dieser Größe benötigen würde. [2]

Für eine Bereitstellungsentscheidung sollten die verwendeten Gewichte und ihre Präzision, die Hardware und ihre Verbindungen, die Runtime-Version, die Kontextlänge und die Zahl gleichzeitiger Anfragen festgehalten werden. Anschließend sind Speicherverbrauch und Ausfälle genau für diese Konfiguration zu messen. Ein Rechenpfad mit weniger aktiven Parametern kann wertvoll sein, ohne jede Bereitstellung klein zu machen. Quantisierung, Auslagerung oder eine andere Serving-Engine sind eigenständige Konfigurationen, deren Leistung nicht einfach aus dem ursprünglichen Spitzenwert abgeleitet werden darf.

Eine Grenze des derzeit Veröffentlichten muss sichtbar bleiben. Der technische Beitrag bezeichnet NaiveRT als Open Source, sagt aber auch, dass die erwähnten Quellcodeinhalte bis zum 12. Oktober verfügbar sein werden. Bei unserer Prüfung am 28. September lieferte das im Beitrag verlinkte NaiveRT-Repository den Status 404. Deshalb konnten wir die Runtime und ihre Benchmark-Skripte unter dieser Adresse nicht prüfen. Das beweist weder, dass das Ergebnis falsch ist, noch, dass keine Modellgewichte verfügbar sind. Es begrenzt lediglich, was wir zum Zeitpunkt der Prüfung verifizieren konnten. [1] [3]

Solange die relevanten Materialien nicht eingesehen und der Versuch nicht wiederholt werden können, sollte die Geschwindigkeit als vom Entwickler gemeldetes Ergebnis unter den genannten Bedingungen gelten. Ein Geschwindigkeitstest mit deaktiviertem Denken belegt auch nicht die Leistung bei Arbeiten, die längeres Schlussfolgern erfordern. Qualität und Dauer sollten gemeinsam im Modus gemessen werden, der für die jeweilige Aufgabe tatsächlich genutzt wird.

Beginnen Sie mit einer kleinen Auswahl repräsentativer Aufgaben und definieren Sie vor dem Test, was als Erfolg zählt. Bei einer Codeänderung könnten das das gewünschte Verhalten, bestandene Regressionstests und unveränderte, nicht betroffene Dateien sein. Bei Dokumenten könnten die erforderlichen Fakten und tragfähige Quellenangaben entscheidend sein. Messen Sie den gesamten Versuch einschließlich Fehlschlägen und Nacharbeit, statt nur das eindrucksvollste Ergebnis zu behalten.

Halten Sie Aufgabenauswahl, Werkzeugberechtigungen und Abnahmeregeln konstant, während Sie Modell oder Bereitstellungskonfiguration ändern. Erfassen Sie die Zeit bis zur ersten Ausgabe, die gesamte Dauer, den Anteil abgenommener Aufgaben und die Kosten je abgenommener Aufgabe. Berücksichtigen Sie kurze und lange Eingaben, übliche parallele Last und wiederholte Durchläufe. Ein einzelnes schnelles Beispiel rechtfertigt weitere Untersuchungen, beschreibt aber nicht die Erfahrung aller Nutzer.

Am meisten verspricht schnelleres Decoding bei Aufgaben, in denen die Generierung tatsächlich den größten Teil der Wartezeit ausmacht. Lange, überwiegend sequenzielle Ausgaben können deutlich profitieren, sofern die Qualität erhalten bleibt. Ein Arbeitsablauf, der vor allem von Recherche, langsamen Werkzeugen oder menschlicher Prüfung abhängt, profitiert womöglich weniger. Beides schmälert die technische Leistung nicht; es zeigt, wo ein Team zuerst testen sollte.

Der Bericht von NaiveAI liefert Teams eine konkrete, prüfenswerte Hypothese: Eine andere Inferenzarchitektur könnte generierungsintensive Arbeit beschleunigen. Wir haben die veröffentlichte Methodik gelesen, das Modell aber nicht ausgeführt und den Spitzenwert nicht reproduziert. Als Nächstes wären zugänglicher Runtime-Code, eine wiederholbare Konfiguration und Ergebnisse für repräsentative Aufgaben wichtig. Eine sinnvolle Entscheidung für den Einsatz hängt davon ab, wie schnell ein System bei der eigenen Arbeitslast ein akzeptables Ergebnis liefert.