Contents — find the section you need

Change parameters and verify

Open the panel, then press Run to load Python. You can stop execution and reset parameters. Results are computed on this device. No Python installation is required.

Local execution steps below are optional for reproducing the source results; they are not required for the browser experiment.

The experiment controls are in English.

Open experiment panel in a new tab

Download reproduction source

Die Anzahl der Token pro Sekunde allein erklärt nicht die Wartezeit nach dem Senden einer Anfrage. Messen Sie den Inhalt der ersten Antwort, die Generierungsrate, die Fertigstellungszeit und den Speicherverbrauch separat. Dieser Artikel beschreibt ein Messverfahren und einen Client; es wurden keine Benchmarks mit realen Modellen oder Hardware-Rankings durchgeführt.

Zeitgrenzen definieren

Diagram 1 · Use the button to switch views
Zeitgrenzen für Anfrage, Denkprozesse, erste Antwort und Fertigstellung.

TTFT bezeichnet normalerweise die Zeit bis zum ersten Token, aber ein HTTP-Fragment besteht nicht unbedingt aus einem Token. Dieses Skript meldet TTFC, die Zeit bis zum ersten nicht leeren response-Fragment. Es erfasst separat den Inhalt des ersten Denkprozesses nach der Rückgabe. Diese Client-Metrik umfasst Warteschlangenbildung, Laden, Verarbeitung von Eingabeaufforderungen und Transport.

Die Generierungsrate verwendet stattdessen die Anzahl der vom Server generierten Token und die Generierungsdauer. Ollama-Dauern werden in Nanosekunden angegeben; die Definitionen der Generate API wurden am 07.09.2026 überprüft.

\text{generation rate [token/s]}=\frac{\text{eval\_count}}{\text{eval\_duration [ns]}}\times10^9

Dies ist nicht der Durchsatz der gesamten Anfrage. Unterschiedliche Tokenizer bedeuten außerdem, dass die Anzahl der Token pro Antwort allein kein fairer Vergleich des japanischen Antwortvolumens oder der -qualität ist.

Bedingungen korrigieren

Modell-Digest, Quantisierung, Ollama-Version, CPU/GPU, RAM/VRAM, Leistungsgrenzen, Parallelität und Eingabeaufforderung protokollieren. Die zurückgegebenen Zählerstände beibehalten, da identischer Text unterschiedlich tokenisiert werden kann. Die erste Anfrage mit einem nicht geladenen Modell von nachfolgenden Anfragen mit dem residenten Modell trennen.

Wiederholte Eingabeaufforderungen können Caches verwenden. Tests mit residentem Modell und gleicher Eingabeaufforderung sowie Tests mit residentem Modell und neuer Eingabe separat behandeln. Die Ausführungsreihenfolge protokollieren, da thermische Bedingungen und Hintergrundprozesse die Vergleiche verfälschen können.

Datenstrom lesen

llm_benchmark.py neben prompt.txt mit Ihrem Vergleichstext platzieren. Es verwendet ausschließlich die Python-Standardbibliothek. Ersetzen Sie YOUR_MODEL durch ein installiertes Modell:

python3 llm_benchmark.py --model YOUR_MODEL --prompt-file prompt.txt --runs 5 > runs.jsonl

Der Standardendpunkt ist 127.0.0.1:11434/api/generate. Anfragen verwenden temperature=0, seed=42, num_predict=128, num_ctx=4096 und keep_alive=5m. Dies sind experimentelle Einstellungen und keine Garantie für Deterministik oder Eignung für jedes Modell. Überprüfen Sie die Ausgabeanzahl und done_reason auf vorzeitigen Abbruch oder abweichendes Verhalten.

Ausgaben und Fehler validieren

Jede JSON-Zeile enthält ttfc_s, first_thinking_s, client_total_s, generation_tokens_s sowie Serveranzahl und -dauer. Fehlende Antwortfragmente führen zu null TTFC; eine Generierungsdauer von null führt zu null Durchsatz. Unterbrochene Streams und API-Fehler haben den Status „error“ und werden niemals als Erfolge mit null Sekunden angezeigt.

Parsing, Zeitmessung und Fehlerbehandlung wurden mit synthetischen Streaming-Antworten getestet, nicht mit der tatsächlichen Ollama-Generierung. Beginnen Sie mit fünf Durchläufen zur Validierung des Verfahrens und erhöhen Sie die Wiederholungszahl anschließend mit expliziten Aufwärmregeln. Geben Sie die Anzahl der Erfolge, den Median und die Spannweite an; präsentieren Sie kein 95%-Konfidenzintervall für eine kleine Stichprobe als präzise.

Speicher separat messen

Das Skript misst den Speicher nicht. Die running-model API liefert Informationen zur Speichernutzung, einschließlich size_vram, jedoch nicht zur Systemauslastung oder zu vorübergehenden Spitzenwerten. Erfassen Sie die OS-/GPU-Metriken kontinuierlich während Leerlauf und Generierung und geben Sie das Beobachtungsintervall an.

Prozess-RAM, Seitencache und GPU-Zuweisungen sind unterschiedliche Größen; ihre Addition kann zu Doppelzählungen führen. Überprüfen Sie die Grenzen insbesondere auf Systemen mit einheitlichem Speicher. Eine Änderung der Speicherbelegung, wie z. B. die teilweise CPU-Verarbeitung, sollte nicht ausschließlich als Unterschied in der Modellleistung beschrieben werden.

Erstellen Sie eine aussagekräftige Vergleichstabelle

Berücksichtigen Sie Modell/Quantisierung, Eingabe-/Ausgabe-Tokens, Speichernutzungs-/Cache-Bedingungen, Erfolge, Median der TTFC, Median der Generierungsrate, Gesamtzeit und Speichermetrik/Messintervall. Bewerten Sie die Richtigkeit der Antworten separat. Verbinden Sie für die Energieberechnung dieselbe Arbeitslast mit Wh mithilfe der Serverleistungsmessung.

What to read next

Compare generation speed with energy per completed workload.Messung des Stromverbrauchs von Heimservern: Leerlauf, Inferenz und SpeicherungReview the backgroundEinführung in das maschinelle Lernen: Generative ModelleExplore another aspect of this fieldEinführung in Objekterkennung und semantische Segmentierung – Lesen der Frage „Was ist wo?“ aus einem Bild