Tokens pro Sekunde bei einem lokalen LLM messen

Warum Tokens pro Sekunde darüber entscheiden, ob sich eine GPU lohnt

Tokens pro Sekunde geben an, wie schnell Ihr Server Ausgabetext erzeugt. Dieser Wert entscheidet, ob das Mieten einer GPU günstiger ist als die Abrechnung einer API pro Token. Eine GPU-Instanz wird unabhängig von ihrer Auslastung stündlich abgerechnet. Eine gehostete API wird nach Tokens abgerechnet. Die GPU ist daher nur dann günstiger, wenn Sie während des Großteils der bezahlten Stunden eine ausreichend hohe Ausgaberate erreichen.

Dafür benötigen Sie eine Messung und keine Zahl aus einer beliebigen Quelle. Auf dieser Seite werden die vier relevanten Werte definiert. Anschließend werden die Befehle gezeigt, mit denen Sie diese Werte ermitteln, sowie die Berechnung, die daraus eine Entscheidung macht.

Warum eine veröffentlichte Angabe zu Tokens pro Sekunde nicht Ihrer Zahl entspricht

DigitalOcean hat im Juli 2026 Durchsatzwerte für eine einzelne NVIDIA H200 veröffentlicht, auf der llama3.3-70b-instruct mit FP8 (8-Bit-Gleitkomma) unter vLLM ausgeführt wurde. Die Werte sind nützlich, gelten aber nicht automatisch für Sie.

[
  {
    "config": "H200, one stream",
    "tok_s": "47"
  },
  {
    "config": "H100, saturated",
    "tok_s": "236"
  },
  {
    "config": "H200, saturated",
    "tok_s": "2,036"
  },
  {
    "config": "H200, saturated, in+out",
    "tok_s": "4,071.6"
  }
]

Jede Zeile oben stammt von dieser Seite. Zwei davon sind die unteren Grenzwerte einer dort angegebenen Spanne. Lesen Sie diese beiden Werte daher als Mindestwerte. Nichts in dieser Tabelle wurde von uns gemessen.

Beginnen Sie mit den letzten beiden Zeilen. Der angegebene Gesamtwert beträgt 4,071.6 tok/s, während die Rate nur für die Ausgabe 2,036 tok/s beträgt. Der Gesamtwert zählt Eingabe- und Ausgabetokens zusammen. Dieser Test verwendete 1,024 Eingabetokens und 1,024 Ausgabetokens. Daher entspricht die Ausgabe fast genau der Hälfte des Gesamtwerts. Diese Aufteilung ist wichtig, weil die Ausgabe der langsamere Teil ist. Beim Prefill, also beim Lesen des Prompts, werden alle Eingabetokens in einem Durchlauf verarbeitet. Beim Decode, also beim Erzeugen der Antwort, wird jeweils ein Token erzeugt. Ein Gesamtwert für den Durchsatz mittelt einen günstigen Vorgang mit einem aufwendigen Vorgang.

Betrachten Sie nun die erste Zeile. Dieselbe H200 erreicht bei jeweils nur einer Anfrage 47 tok/s. Der Wert bei voller Auslastung ist auf identischer Hardware also mehr als vierzigmal höher. Dieser Unterschied entsteht, weil die GPU während eines einzelnen Decode-Schritts die meiste Zeit auf den Speicher wartet. Gleichzeitige Anfragen nutzen diese Leerlaufzeit. Die zweite Zeile mit 236 tok/s zeigt eine einzelne H100 mit demselben Modell. Sie wird durch den KV-Cache begrenzt, also den Key- und Value-Cache im Speicher, den eine laufende Unterhaltung pro Anfrage auf der Karte belegt. Eine Karte mit 80 GB kann bei einem 70B-Modell weniger gleichzeitige Anfragen halten. Daher erreicht sie bei der Auslastung einen niedrigeren Wert.

Wenn Sie das Modell oder das Verhältnis von Eingabe zu Ausgabe ändern, ändern sich alle oben genannten Werte. Veröffentlichte Werte helfen Ihnen bei der Erwartungsbildung, legen aber nicht Ihr Budget fest. Dieselbe Regel gilt für das ehrliche Benchmarking eines VPS bei Datenträger- und Netzwerkleistung.

Die vier wichtigen Kennzahlen

• Time to first token, TTFT. Die Verzögerung zwischen dem Senden einer Anfrage und dem Eintreffen des ersten Ausgabetokens. Sie setzt sich aus Prefill-Zeit und Wartezeit in der Warteschlange zusammen. Diese Verzögerung nimmt der Benutzer direkt wahr.
• Ausgabetokens pro Sekunde und Stream. Gibt an, wie schnell eine Antwort ausgegeben wird, sobald sie begonnen hat. Ab etwa 20 tok/s ist die Ausgabe bereits schneller, als die meisten Menschen lesen können. Eine höhere Geschwindigkeit bringt hier daher wenig.
• Gesamtdurchsatz der Ausgabe unter Volllast. Die Summe über alle gleichzeitig aktiven Streams, wenn der Server vollständig ausgelastet ist. Das ist die Kapazitätskennzahl. Sie bestimmt, wofür Sie die GPU bezahlen.
• p50 und p99 der TTFT unter paralleler Last. p50 ist der mittlere Wert für eine Anfrage. p99 ist der Wert, unter dem 99 von 100 Anfragen liegen. Wartezeiten in der Warteschlange zeigen sich zuerst in p99.

Die ersten beiden Werte verbessern sich, wenn der Server wenig ausgelastet ist. Der dritte verbessert sich, wenn der Server stark ausgelastet ist. Sie stehen im Zielkonflikt. Deshalb beschreibt keine einzelne Kennzahl einen Server für Inferenzdienste.

Legen Sie die Ein- und Ausgabelängen vor der Messung fest

Der Durchsatz hängt von der Form des Datenverkehrs ab. Ein Prompt mit 4,000 Tokens und einer Antwort mit 50 Tokens ist eine Prefill-lastige Aufgabe. Ein Prompt mit 200 Tokens und einer Antwort mit 2,000 Tokens ist eine Decode-lastige Aufgabe. Derselbe Server erreicht bei diesen beiden Varianten sehr unterschiedliche Tokenraten pro Sekunde. Wählen Sie daher ein Verhältnis, schreiben Sie es neben jede aufgezeichnete Zahl und vergleichen Sie niemals Werte aus unterschiedlichen Verhältnissen. 1,024 Eingabe-Tokens und 1,024 Ausgabe-Tokens sind ein sinnvoller Standard, weil mehrere Anbieter Werte für dieses Verhältnis veröffentlichen. Wenn Sie Ihren tatsächlichen Datenverkehr kennen, verwenden Sie diesen.

Begrenzen Sie auch die Ausgabelänge. Ein Modell, das nach 60 Tokens sein Stop-Token erreicht, erzeugt einen kürzeren Lauf, der nicht mit einem vollständigen Lauf vergleichbar ist: TTFT nimmt einen größeren Anteil ein und senkt dadurch den vom Benchmark berechneten Ausgabedurchsatz, obwohl jede Anfrage früher abgeschlossen wird. Das --ignore-eos-Flag im vLLM-Benchmark-Client sorgt dafür, dass jede Anfrage genau die angeforderte Anzahl an Tokens erzeugt. Dadurch bleiben zwei Läufe vergleichbar. Die Modellauswahl verändert diese Werte stärker als jedes Flag: ein Qwen-3-Modell auf die GPU eines einzelnen VPS zu bringen behandelt die Speicherseite dieser Entscheidung.

Zuerst einen einzelnen Stream messen

Beginnen Sie mit dem einfachsten Fall. Das ist ein Plausibilitätstest und zugleich ein oberer Grenzwert. Ollama gibt eigene Zeitmessungen aus.

ollama run llama3.1:8b --verbose "Write 200 words about disk scheduling."

Die relevante Zeile ist eval rate. Sie gibt die Anzahl der Ausgabetokens pro Sekunde an. prompt eval rate ist die Prefill-Rate, und load duration ist die Zeit, die zum Laden des Modells in den VRAM benötigt wird. Beim ersten Aufruf nach einem Kaltstart ist load duration groß, daher ist total duration nicht aussagekräftig. Führen Sie den Befehl zweimal aus und lesen Sie das zweite Ergebnis ab. Ollama entlädt ein inaktives Modell standardmäßig nach fünf Minuten. Eine lange Pause zwischen den Durchläufen führt daher wieder zum Kaltstart.

Dieselben Felder liefert auch die API. Sie lässt sich einfacher skripten.

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Write 200 words about disk scheduling.",
  "stream": false
}' | jq '{eval_count, eval_duration,
         tok_s: (.eval_count / (.eval_duration / 1000000000))}'

eval_duration wird in Nanosekunden angegeben. Wenn Sie den Wert durch 1,000,000,000 teilen, erhalten Sie Sekunden. Genau diese Division empfiehlt Ollamas eigene API-Dokumentation für die Berechnung der Tokens pro Sekunde. Wenn der Server noch nicht läuft, beschreibt das Self-Hosting eines LLM mit Ollama auf einem VPS die Installation und die systemd-Unit.

Für TTFT ist eine Streaming-Anfrage erforderlich. curl kann die Zeit dafür messen.

curl -s -o /dev/null -N \
  -w 'ttfb=%{time_starttransfer}s  total=%{time_total}s\n' \
  http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen/Qwen3-8B",
       "messages":[{"role":"user","content":"Write 200 words about disk scheduling."}],
       "stream":true,"max_tokens":256}'

time_starttransfer bezeichnet den Zeitpunkt, an dem das erste Byte des Antwort-Bodys eintrifft. Bei einer gestreamten Chat-Vervollständigung gehört dieses Byte zum ersten Server-Sent Event. Dabei handelt es sich entweder um das erste Inhaltstoken oder um ein Delta, das nur die Rolle enthält und unmittelbar davor gesendet wird. Betrachten Sie den Wert daher als TTFT mit einer Abweichung von ungefähr einem Event. Für den Vergleich zweier Durchläufe auf demselben Server ist er genau genug.

Einzelstream-Werte lassen die Hardware in zweifacher Hinsicht besser erscheinen. Die TTFT ist so niedrig wie nie zuvor, weil keine andere Anfrage vor Ihnen wartet. Die Rate pro Stream ist ebenfalls so hoch wie nie zuvor, weil die gesamte Karte eine einzige Anfrage verarbeitet. Keine der beiden Messungen zeigt, wie viele Anfragen die Hardware tatsächlich verarbeiten kann.

Wie führen Sie einen Concurrency-Sweep durch?

Bei einem Sweep wird eine feste Arbeitslast mit steigender Concurrency ausgeführt. Für jeden Schritt wird das Ergebnis erfasst. vLLM liefert den Client dafür mit. Er verwendet die OpenAI API und funktioniert daher auch mit Ollama und allen anderen OpenAI-kompatiblen Diensten.

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model Qwen/Qwen3-8B \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 1024 \
  --ignore-eos \
  --num-prompts 160 \
  --max-concurrency 16 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,99

--max-concurrency begrenzt die gleichzeitig laufenden Anfragen. Dieser Wert wird beim Sweep verändert. --num-prompts ist die Gesamtzahl der gesendeten Anfragen. Setzen Sie diesen Wert auf ungefähr das Zehnfache der Concurrency, um einen stabilen Durchschnitt zu erhalten. Die Zusammenfassung gibt Output token throughput (tok/s): und Total token throughput (tok/s): aus. Unter einer Überschrift Time to First Token folgen außerdem Mean TTFT (ms):, Median TTFT (ms): und P99 TTFT (ms):.

Die Ausgabe enthält keine Rate pro Stream. Diese lässt sich jedoch mit einer Division berechnen. Mean TPOT (ms): ist die mittlere Zeit pro ausgegebenem Token nach dem ersten Token. 25 ms pro Token entsprechen daher 40 Tokens pro Sekunde und Stream. Die Division des Output-Durchsatzes durch die Concurrency liefert dasselbe Ergebnis.

Führen Sie den Sweep anschließend in einer Schleife aus und speichern Sie jeden Lauf.

for C in 1 4 16 32 64 128; do
  vllm bench serve \
    --backend openai-chat \
    --base-url http://127.0.0.1:8000 \
    --endpoint /v1/chat/completions \
    --model Qwen/Qwen3-8B \
    --dataset-name random \
    --random-input-len 1024 \
    --random-output-len 1024 \
    --ignore-eos \
    --num-prompts $(( C * 10 )) \
    --max-concurrency "$C" \
    --percentile-metrics ttft,tpot,itl,e2el \
    --metric-percentiles 50,99 \
    --save-result --result-filename "sweep-c$C.json"
done

for f in sweep-c*.json; do
  jq -r --arg f "$f" \
    '[$f, .output_throughput, .total_token_throughput,
      .median_ttft_ms, .p99_ttft_ms] | @tsv' "$f"
done

Was zeigt ein Concurrency-Sweep tatsächlich?

[
  {
    "label": "1 stream",
    "per_stream_tok_s": 92,
    "total_tok_s": 92,
    "ttft_p50_ms": 48,
    "ttft_p99_ms": 61
  },
  {
    "label": "4 streams",
    "per_stream_tok_s": 88,
    "total_tok_s": 352,
    "ttft_p50_ms": 71,
    "ttft_p99_ms": 96
  },
  {
    "label": "16 streams",
    "per_stream_tok_s": 71,
    "total_tok_s": 1136,
    "ttft_p50_ms": 152,
    "ttft_p99_ms": 244
  },
  {
    "label": "32 streams",
    "per_stream_tok_s": 54,
    "total_tok_s": 1728,
    "ttft_p50_ms": 287,
    "ttft_p99_ms": 498
  },
  {
    "label": "64 streams",
    "per_stream_tok_s": 34,
    "total_tok_s": 2176,
    "ttft_p50_ms": 611,
    "ttft_p99_ms": 1240
  },
  {
    "label": "128 streams",
    "per_stream_tok_s": 18,
    "total_tok_s": 2304,
    "ttft_p50_ms": 1490,
    "ttft_p99_ms": 3820
  }
]

Die 6 Zeilen veranschaulichen die Form, die ein Sweep auf einer kleinen mietbaren GPU-Instanz bei plausiblen Größenordnungen annimmt. Sie sind keine Messung Ihres Servers und keine Herstellerangabe. Führen Sie die obige Schleife aus und ersetzen Sie die Werte durch Ihre eigenen.

Betrachten Sie die Form, denn sie lässt sich verallgemeinern. Bei einem Stream erzeugt die gesamte Instanz 92 Tokens pro Sekunde bei einer p99-TTFT von 61 ms. Bei 128 streams erreicht der Gesamtdurchsatz 2304 Tokens pro Sekunde und ist damit fünfundzwanzigmal höher. Gleichzeitig sinkt die Geschwindigkeit jedes einzelnen Streams auf 18 Tokens pro Sekunde, und die p99-TTFT steigt auf 3820 ms. Der Gesamtdurchsatz steigt, weil Batching ungenutzte Wartezeiten beim Speicherzugriff in nutzbare Rechenzeit umwandelt. Die Geschwindigkeit pro Stream sinkt, weil dieselbe Rechenleistung nun geteilt wird.

Die letzte Verdopplung ist entscheidend. Der Wechsel von 64 auf 128 Streams erhöht den Gesamtdurchsatz um weniger als sechs Prozent, während sich die p99-TTFT ungefähr verdreifacht. Das bedeutet, dass Anfragen in die Warteschlange gelangen, statt verarbeitet zu werden. Ursache ist entweder ein voller KV-Cache oder eine vom Server erreichte Scheduling-Grenze wie max_num_seqs in vLLM. Der sinnvolle Betriebspunkt liegt früher: Bei 32 Streams liefert die Instanz weiterhin 1728 Tokens pro Sekunde, also 75 Prozent ihres Spitzenwerts, bei 54 Tokens pro Sekunde je Stream und einer p99-TTFT von 498 ms. Geben Sie diesen Punkt als Ihre Kapazität an. Den Spitzenwert der Kurve können Sie nicht als Grundlage für den Betrieb mit Benutzern verwenden.

Ollama und vLLM messen nicht dasselbe

Führen Sie diesen Sweep gegen einen standardmäßig konfigurierten Ollama-Server aus, verändert sich die Gesamtdauer kaum. OLLAMA_NUM_PARALLEL hat standardmäßig den Wert 1. Deshalb läuft eine Anfrage, während die übrigen warten. Diese Warteschlange lässt die p99-TTFT ansteigen, während die gesamte Ausgabemenge unverändert bleibt. Erhöhen Sie den Wert, bevor Sie Messungen durchführen.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

Starten Sie den Server mit sudo systemctl restart ollama neu und prüfen Sie anschließend, ob das Modell weiterhin in den Speicher passt. Jeder parallele Slot erhält einen eigenen Anteil am Kontextfenster. In der Ollama-Dokumentation steht daher, dass ein Kontext von 2K bei 4 parallelen Anfragen 8K zuweist. Erhöhen Sie die Anzahl der Slots zu weit, wird das Modell aus dem VRAM verdrängt. Prüfen Sie ollama ps: Eine PROCESSOR-Spalte mit einem Wert wie 48%/52% CPU/GPU bedeutet, dass sich ein Teil des Modells auf der CPU befindet. Der Durchsatz sinkt dann bei zunehmender Parallelität, statt zu steigen. Nach Ausschöpfung der parallelen Slots werden Anfragen bis zu OLLAMA_MAX_QUEUE eingereiht. Der Standardwert ist 512. Danach antwortet der Server mit 503.

vLLM verwendet Continuous Batching. Neue Anfragen werden in den laufenden Batch aufgenommen, sobald Slots frei werden. Die Kurve steigt weiter, bis eine Ressource erschöpft ist. Meist ist das der KV-Cache. Eine konfigurierte Begrenzung wie max_num_seqs oder der Scheduling-Overhead der CPU kann den Anstieg jedoch früher abflachen. Ollama ist für ein Modell auf einer Maschine und einen geringen Einrichtungsaufwand optimiert. Daher liefern die beiden Engines bei demselben Sweep unterschiedliche Ergebnisse. Genau darum geht es in Ollama und vLLM als Serving-Engines im Vergleich. Dokumentieren Sie für jede Zahl, welche Engine und welche Version sie erzeugt hat.

Fünf Möglichkeiten, das Falsche zu messen

• Der Client ist weit entfernt. Ein Benchmark von Ihrem Laptop über das Internet addiert Ihre Round-Trip-Zeit zu jedem TTFT. Sie messen dann Ihre Heimverbindung. Führen Sie den Client in derselben Region wie den Server aus.
• Das Modell war nicht vorgewärmt. Die erste Anfrage muss die Gewichte laden. Bei vLLM kann zusätzlich die Graph-Erfassung anfallen. Senden Sie einen Aufwärmbatch und verwerfen Sie das Ergebnis.
• Das Prefix-Caching hat für Sie geantwortet. vLLM aktiviert das automatische Prefix-Caching standardmäßig. Wenn Sie immer wieder denselben Prompt senden, messen Sie den Cache statt des Prefill. Das TTFT sinkt dann auf einen Bruchteil des tatsächlichen Werts. --dataset-name random vermeidet dieses Problem, weil sich jeder Prompt unterscheidet. Starten Sie den Server zur Sicherheit mit --no-enable-prefix-caching.
• Die Ausgaben waren kurz. Bei Antworten mit 32 Token dominiert das TTFT jede Anfrage. Ihre Token-pro-Sekunde-Zahl beschreibt dann in Wirklichkeit den Prefill. Verwenden Sie --ignore-eos mit einer realistischen Ausgabelänge.
• Sie haben nur die Parallelität 1 angegeben. Damit erhalten Sie das günstigste TTFT in der Tabelle. Als Kostengrundlage ist dieser Wert nur dann geeignet, wenn sich Ihre tatsächlichen Anfragen nie überschneiden. Wenn sie sich überschneiden, hängen die Kosten vom Durchsatz ab, den Sie bei der durch Ihren tatsächlichen Datenverkehr erzeugten Parallelität erreichen. Messen Sie deshalb auch unter diesen Bedingungen.

Aus Ihrem Messwert eine Entscheidung ableiten

Nehmen Sie den Output-Durchsatz, den Ihr Sweep bei der Concurrency Ihres realen Datenverkehrs ergibt, und vergleichen Sie ihn mit dem Preis pro Token. Dieser Wert entspricht nur dann dem Wert unter Auslastung, wenn sich genügend Anfragen überschneiden, um den Batch vollständig zu füllen. Eine Arbeitslast, die immer nur eine Anfrage gleichzeitig sendet, muss die Rate für einen einzelnen Stream verwenden. Der Break-even-Punkt lässt sich mit einer Division berechnen, sobald Sie die Input-Tokens berücksichtigen, die mit jedem Output-Token eintreffen:

cost_per_million_output = price_out + price_in * (input_tokens / output_tokens)
break_even_tok_s = (price_per_hour / cost_per_million_output) * 1000000 / 3600

Rechnen Sie dies mit den Preisen von DigitalOcean aus Juli 2026 durch. Der dedizierte H200-Inference-Endpunkt kostete $4.47 pro Stunde. Serverless Llama 3.3 70B kostete $0.65 pro Million Input-Tokens und $0.65 pro Million Output-Tokens. Bei dem oben verwendeten Verhältnis von 1:1 bringt jede Million Output-Tokens eine Million Input-Tokens mit sich. Der effektive Preis beträgt daher $1.30 pro Million Output-Tokens. 4.47 geteilt durch 1.30 ergibt ungefähr 3.44 Millionen Output-Tokens pro Stunde. Geteilt durch 3,600 Sekunden sind das ungefähr 955 Output-Tokens pro Sekunde. Zusammen mit Input und Output sind es ungefähr 1,910 Tokens pro Sekunde. Die Preise stammen von DigitalOcean. Die Division stammt von uns. Als wir am 25. Oktober 2026 nachgesehen haben, kostete der H200-Endpunkt weiterhin $4.47 pro Stunde. DigitalOcean hatte serverless Llama 3.3 70B jedoch am 18. August 2026 abgekündigt und verwies auf Llama 4 Maverick. Dieses Modell war mit $0.25 pro Million Input-Tokens und $0.87 pro Million Output-Tokens gelistet. Es handelt sich um ein anderes Modell. Daher ist ein eigener Sweep erforderlich, bevor der Vergleich aussagekräftig ist.

Das entscheidende Wort ist dauerhaft. Wenn bei voller Auslastung zwei Stunden pro Tag 955 Output-Tokens pro Sekunde erreicht werden, entspricht das nicht dauerhaft 955 Output-Tokens pro Sekunde. Sie bezahlen auch die übrigen zweiundzwanzig Stunden. Das Mieten der GPU als GPU Droplet senkt den erforderlichen Wert nicht. Am 25. Oktober 2026 listete DigitalOcean den H200 im Droplet-Preisverzeichnis mit $4.47 pro Stunde bei On-Demand-Nutzung. Das entsprach dem Preis des Endpunkts. Die günstigsten NVIDIA Droplets, RTX 4000 für $0.76 pro Stunde sowie L40S oder RTX 6000 für $1.57 pro Stunde, sind zu klein für ein 70B-Modell in FP8. Nach den oben genannten Werten muss ein H200, der bei voller Auslastung 2,036 Output-Tokens pro Sekunde erreicht, über jede bezahlte Stunde hinweg durchschnittlich ungefähr 47 Prozent dieses Spitzenwerts erreichen, um lediglich $0.65 pro Million Input- und Output-Tokens zu entsprechen. Unterhalb dieses Werts ist die Abrechnung pro Token günstiger. Nicht langsame Tokens, sondern ungenutzte GPU-Stunden machen Self-Hosting normalerweise unwirtschaftlich.

Ihre Entscheidung hat daher zwei Eingaben. Der Sweep liefert die Obergrenze. Ihr Datenverkehr bestimmt, welchen Anteil dieser Obergrenze Sie tatsächlich nutzen. Multiplizieren Sie beide Werte. Vergleichen Sie das Ergebnis anschließend unter GPU VPS im Vergleich zum Break-even-Punkt einer Abrechnung pro Token mit der Abrechnung pro Token. Dort können Sie das Ergebnis für Ihr Volumen ablesen.

FAQ

Was ist eine gute Token-Anzahl pro Sekunde für ein selbst gehostetes LLM?

Es gibt zwei Antworten, weil diese Kennzahl zwei Aufgaben erfüllt. Für eine Person, die die Ausgabe liest, sind bereits mehr als ungefähr 20 ausgegebene Tokens pro Sekunde und Stream schneller als die Lesegeschwindigkeit. Mehr bringt dann keinen Vorteil. Für die Kosten zählt der gesamte Ausgabedurchsatz, den Sie unter Ihrer tatsächlichen Last dauerhaft erreichen können. Gut ist der Wert, der Ihren Break-even erreicht. Bei $0.65 pro Million Tokens, für Eingabe und Ausgabe gleichermaßen, und einem Serverpreis von $4.47 pro Stunde liegt diese Schwelle bei einem Verhältnis von 1:1 und den Preisen von July 2026 bei ungefähr 955 dauerhaft erreichten ausgegebenen Tokens pro Sekunde. Ein einzelner Stream mit einem großen Modell erreicht diesen Wert nie. Deshalb gibt es Batching.

Warum bleibt mein Ollama-Durchsatz gleich, wenn ich parallele Anfragen hinzufüge?

OLLAMA_NUM_PARALLEL ist standardmäßig auf 1 gesetzt. Der Server verarbeitet deshalb pro Modell jeweils eine Anfrage und reiht die übrigen ein, bis OLLAMA_MAX_QUEUE erreicht ist (standardmäßig 512), bevor er 503 zurückgibt. Die Gesamtausgabe bleibt gleich, während p99 TTFT steigt. Das weist auf eine Warteschlange und nicht auf eine ausgelastete GPU hin. Setzen Sie die Variable in einem systemd-Drop-in und starten Sie den Dienst neu. Prüfen Sie anschließend ollama ps, weil jeder parallele Slot den zugewiesenen Kontext vervielfacht und dadurch ein Teil des Modells auf die CPU ausgelagert werden kann.

Sollte ich die Zeit bis zum ersten Token oder Tokens pro Sekunde messen?

Beides, weil sich die Werte bei steigender Last in entgegengesetzte Richtungen entwickeln. TTFT bestimmt, was ein Benutzer wahrnimmt. Der gesättigte Ausgabedurchsatz bestimmt, was auf Ihrer Rechnung steht. Erfassen Sie bei jedem Schritt der Parallelität p50 und p99 TTFT. Wählen Sie anschließend die höchste Parallelität, bei der p99 TTFT für Sie noch akzeptabel ist. Geben Sie den bei diesem Punkt erreichten Durchsatz als Ihre Kapazität an, nicht das Maximum am oberen Ende der Kurve.

Bedeutet ein höherer Wert für Tokens pro Sekunde immer niedrigere Kosten pro Token?

Nein. Die Kosten pro Token ergeben sich aus dem Stundenpreis geteilt durch die Anzahl der Tokens, die der Server in dieser Stunde tatsächlich erzeugt hat. Ein schneller Server, der den größten Teil des Tages ungenutzt bleibt, hat daher weiterhin hohe Kosten pro Token. Entscheidend ist die Auslastung, nicht die Spitzengeschwindigkeit. Achten Sie außerdem auf die Einheiten. Ein angegebener Gesamtdurchsatz in Tokens zählt Eingabe-Tokens mit. Bei einem Verhältnis von Eingabe zu Ausgabe von 1:1 liegt er daher ungefähr beim Doppelten der Ausgaberate. Wenn der Vergleichs-API sowohl Eingabe- als auch Ausgabe-Tokens in Rechnung stellt, müssen Sie beide Anteile vor dem Vergleich einpreisen.