Tokens pro Sekunde bei einem lokalen LLM messen

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

Tokens pro Sekunde geben an, mit welcher Rate 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 pro Stunde abgerechnet, unabhängig davon, ob sie ausgelastet ist oder nicht. Eine gehostete API wird pro Token abgerechnet. Die GPU ist daher nur dann günstiger, wenn Sie während des Großteils der bezahlten Stunden eine ausreichend hohe Ausgaberate erreichen.

Sie benötigen daher eine Messung und keinen Wert aus einer fremden Quelle. Diese Seite definiert die vier relevanten Werte. Anschließend werden die Befehle beschrieben, mit denen Sie diese Werte ermitteln, sowie die Berechnung, die daraus eine Entscheidung ableitet.

Warum eine veröffentlichte Token-pro-Sekunde-Zahl nicht Ihrem Wert entspricht

DigitalOcean hat im Juli 2026 Durchsatzwerte für eine einzelne NVIDIA H200 veröffentlicht, die llama3.3-70b-instruct unter vLLM in FP8 (8-Bit-Gleitkomma) ausführt. Die Werte sind nützlich, gelten aber nicht für Ihre Umgebung.

[
  {
    "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 ist dieser Seite entnommen. Zwei der Werte bilden die Untergrenze einer dort angegebenen Spanne. Lesen Sie diese beiden Werte daher als Mindestwerte. Keine Zahl in dieser Tabelle wurde von uns gemessen.

Beginnen Sie mit den letzten beiden Zeilen. Die Schlagzeilenzahl beträgt 4,071.6 Tok/s, während die Rate nur für die Ausgabe 2,036 Tok/s beträgt. Die Schlagzeilenzahl zählt Eingabe- und Ausgabetokens zusammen. Dieser Test verwendete 1,024 Eingabetokens und 1,024 Ausgabetokens. Daher entfällt fast genau die Hälfte der Schlagzeilenzahl auf die Ausgabe. Diese Aufteilung ist wichtig, weil Ihnen die Ausgabe in Rechnung gestellt wird und weil sie der langsamere Teil ist. Beim Prefill werden alle Eingabetokens in einem Durchlauf verarbeitet. Beim Decode wird jeweils nur ein Token erzeugt. Eine Schlagzeilenzahl für den Gesamtdurchsatz mittelt einen günstigen Wert mit einem teuren.

Sehen Sie sich nun die erste Zeile an. Dieselbe H200 erzeugt bei der Verarbeitung einer Anfrage nach der anderen 47 Tok/s. Damit liegt der Wert unter Vollauslastung bei identischer Hardware mehr als vierzigmal höher. Dieser Abstand 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 beschreibt eine einzelne H100 mit demselben Modell. Sie wird durch den KV-Cache begrenzt, also den Key- und Value-Cache, den anfragespezifischen Speicher, den eine laufende Konversation auf der Karte belegt. Eine Karte mit 80 GB kann bei einem 70B-Modell weniger gleichzeitige Anfragen aufnehmen. Daher erreicht sie die Sättigung bei einem niedrigeren Wert.

Wenn Sie das Modell oder das Verhältnis von Eingabe zu Ausgabe ändern, ändern sich alle oben genannten Werte. Veröffentlichte Werte legen Ihre Erwartungen fest, nicht Ihr Budget. Dieselbe Regel gilt für eine realistische VPS-Benchmark auf Datenträger und Netzwerk.

Die vier entscheidenden 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. Der Benutzer nimmt diesen Wert unmittelbar wahr.
• Ausgabetokens pro Sekunde und Stream. Wie schnell eine Antwort geschrieben wird, sobald ihre Ausgabe begonnen hat. Ab ungefähr 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 laufenden Streams, wenn der Server vollständig ausgelastet ist. Dieser Wert beschreibt die Kapazität und deckt die GPU-Kosten.
• p50- und p99-TTFT bei gleichzeitigen Anfragen. p50 ist der mittlere Wert der Anfragen. Bei p99 liegen 99 von 100 Anfragen unter diesem Wert. Warteschlangen wirken sich zuerst auf p99 aus.

Die ersten beiden Werte verbessern sich, wenn der Server wenig ausgelastet ist. Der dritte verbessert sich, wenn der Server stark ausgelastet ist. Diese Werte stehen in einem Zielkonflikt. Deshalb beschreibt keine einzelne Kennzahl einen Inferenzserver.

Legen Sie die Eingabe- und Ausgabelängen fest, bevor Sie messen

Der Durchsatz hängt von der Form des Datenverkehrs ab. Ein Prompt mit 4,000 Tokens und einer Antwort mit 50 Tokens ist Prefill-lastig. Ein Prompt mit 200 Tokens und einer Antwort mit 2,000 Tokens ist Decode-lastig. Derselbe Server meldet für diese beiden Fälle sehr unterschiedliche Tokens pro Sekunde. Wählen Sie daher ein Verhältnis, schreiben Sie es neben jede erfasste Zahl und vergleichen Sie niemals unterschiedliche Verhältnisse. 1,024 Tokens Eingabe und 1,024 Tokens Ausgabe 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 schneller wirkt, weil TTFT dann einen größeren Anteil daran hat. Das Flag --ignore-eos 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 beeinflusst diese Werte stärker als jedes Flag: ein Qwen-3-Modell auf einer einzelnen VPS-GPU unterbringen behandelt den Speicherbedarf dieser Auswahl.

Zuerst einen einzelnen Datenstrom messen

Beginnen Sie mit dem einfachsten Fall. Das dient als Plausibilitätsprüfung und bildet zugleich die Obergrenze. Ollama gibt die eigenen 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ß. Dadurch 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. Durch Division durch 1,000,000,000 erhalten Sie Sekunden. Genau diese Division schreibt Ollamas eigene API-Dokumentation für Tokens pro Sekunde vor. Wenn der Server noch nicht läuft, beschreibt ein LLM mit Ollama auf einem VPS selbst hosten die Installation und die systemd-Unit.

Für TTFT ist eine Streaming-Anfrage erforderlich. curl kann diese Zeit für Sie 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 ist der 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 mit einer Abweichung von ungefähr einem Event als TTFT. Für den Vergleich zweier Durchläufe auf demselben Server ist er ausreichend genau.

Messwerte mit nur einem Datenstrom lassen das System in zweifacher Hinsicht besser erscheinen. Die TTFT ist so niedrig wie nie zuvor, weil keine andere Anfrage vor Ihnen in der Warteschlange steht. Auch die Rate pro Datenstrom ist so hoch wie nie zuvor, weil die gesamte Karte eine einzige Anfrage verarbeitet. Keiner dieser Werte zeigt, wie viele Anfragen das System tatsächlich bewältigen kann.

Wie führt man einen Concurrency-Sweep durch?

Bei einem Sweep wird eine feste Arbeitslast mit steigender Concurrency ausgeführt. Für jeden Schritt werden die Ergebnisse erfasst. vLLM liefert das dafür erforderliche Client-Programm mit. Es 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 schrittweise erhöht. --num-prompts gibt die Gesamtzahl der gesendeten Anfragen an. Setzen Sie diesen Wert ungefähr auf 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 durchschnittliche Zeit pro Ausgabetoken nach dem ersten Token. 25 ms pro Token entsprechen daher 40 Token pro Sekunde und Stream. Die Division des Ausgabedurchsatzes durch die Concurrency liefert dasselbe Ergebnis.

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

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
  }
]

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

Achten Sie auf die Form, denn diese Form lässt sich verallgemeinern. Bei einem Stream verarbeitet 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 Wartezeiten auf den Speicher in nutzbare Arbeit 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 der KV-Cache voll ist und Anfragen in der Warteschlange stehen, statt verarbeitet zu werden. 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 Kapazität für den produktiven Betrieb ansetzen.

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 ist standardmäßig auf 1 gesetzt. Daher wird jeweils nur eine Anfrage ausgeführt, während die übrigen warten. Diese Warteschlange lässt die p99-TTFT ansteigen, während die gesamte Ausgabemenge konstant bleibt. Erhöhen Sie diesen 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 wird daher darauf hingewiesen, dass ein Kontext von 2K bei 4 parallelen Anfragen 8K zuweist. Erhöhen Sie die Anzahl der Slots weit genug, wird das Modell aus dem VRAM ausgelagert. Prüfen Sie ollama ps: Wenn die Spalte PROCESSOR einen Wert wie 48%/52% CPU/GPU enthält, befindet sich ein Teil des Modells auf der CPU. Der Durchsatz sinkt dann bei steigender Parallelität, statt anzusteigen. Nach Ausschöpfung der parallelen Slots werden Anfragen bis zu OLLAMA_MAX_QUEUE in die Warteschlange eingereiht. Dieser Wert beträgt standardmäßig 512. Danach antwortet der Server mit 503.

vLLM verwendet kontinuierliches Batching. Neue Anfragen werden in den laufenden Batch aufgenommen, sobald Slots frei werden. Die Kurve steigt weiter an, bis der KV-Cache erschöpft ist. Ollama ist auf ein Modell, eine 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. Notieren Sie zu jeder Zahl, welche Engine und welche Version sie erzeugt hat.

Fünf Wege, die falsche Messgröße zu erfassen

• Der Client ist weit entfernt. Ein Benchmark von Ihrem Laptop über das Internet addiert Ihre Round-Trip-Zeit zu jedem TTFT. Sie messen damit Ihre Heimverbindung. Starten Sie den Client in derselben Region wie den Server.
• Das Modell war nicht vorgewärmt. Die erste Anfrage umfasst das Laden der Gewichte. Bei vLLM kann zusätzlich die Graph-Erfassung anfallen. Senden Sie einen Aufwärmbatch und verwerfen Sie das Ergebnis.
• Das Prefix-Caching hat die Antwort geliefert. vLLM aktiviert Prefix-Caching standardmäßig. Wenn Sie wiederholt denselben Prompt senden, messen Sie statt des Prefill-Vorgangs den Cache. Dadurch sinkt der TTFT auf einen Bruchteil des tatsächlichen Werts. --dataset-name random vermeidet das, weil jeder Prompt unterschiedlich ist. Starten Sie den Server mit --no-enable-prefix-caching, um sicherzugehen.
• Die Ausgaben waren kurz. Bei Antworten mit 32 Tokens dominiert der TTFT jede Anfrage. Ihre Tokens pro Sekunde beschreiben dann im Wesentlichen den Prefill-Vorgang. Verwenden Sie --ignore-eos mit einer realistischen Ausgabelänge.
• Sie haben die Parallelität mit 1 angegeben. Das ist die freundlichste Zahl im Datenblatt und sagt nichts über die Kosten aus.

Überführen Sie Ihre gemessene Zahl in eine Entscheidung

Verwenden Sie den gesättigten Ausgabedurchsatz aus Ihrem Sweep, nicht die Rate für einen einzelnen Datenstrom, und vergleichen Sie ihn mit der Preisgestaltung pro Token. Der Break-even-Punkt ergibt sich durch eine Division:

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

Rechnen wir das mit den Preisen von DigitalOcean aus dem Juli 2026 durch. Der dedizierte H200-Inferenzendpunkt kostete 4.47 $ pro Stunde, das entsprechende Serverless-Angebot 0.65 $ pro 1 Million Tokens. 4.47 geteilt durch 0.65 ergibt 6.88 Millionen Tokens pro Stunde. Geteilt durch 3,600 Sekunden sind das ungefähr 1,910 ausgegebene Tokens pro Sekunde. Die Preise stammen von DigitalOcean. Die Division stammt von uns.

Entscheidend ist das Wort dauerhaft. Wenn Sie zwei Stunden pro Tag bei Sättigung 1,910 Tokens pro Sekunde erreichen, entspricht das nicht einem dauerhaft aufrechterhaltenen Durchsatz von 1,910 Tokens pro Sekunde, weil Sie auch für die übrigen zweiundzwanzig Stunden bezahlen. Der von DigitalOcean selbst angegebene Wechselpunkt für den günstigeren GPU Droplet für 3.44 $ pro Stunde liegt bei einer dauerhaft aufrechterhaltenen durchschnittlichen Auslastung von 72.2 Prozent. Unterhalb dieses Werts ist der Preis pro Token günstiger. Leerlaufende GPU-Stunden und nicht langsame Tokens machen Self-Hosting meist unwirtschaftlich.

Ihre Entscheidung basiert daher auf zwei Eingaben. Der Sweep liefert Ihnen die Obergrenze. Ihr Traffic-Muster bestimmt, welchen Anteil dieser Obergrenze Sie tatsächlich nutzen. Multiplizieren Sie beide Werte und übertragen Sie das Ergebnis auf den Break-even-Vergleich zwischen GPU-VPS und API-Preis pro Token. Dort können Sie für Ihr Volumen die passende Entscheidung ablesen.

FAQ

Wie viele Tokens pro Sekunde sind für ein selbst gehostetes LLM gut?

Darauf gibt es zwei Antworten, weil die Kennzahl zwei Aufgaben erfüllt. Für eine Person, die die Ausgabe liest, sind bereits mehr als etwa 20 ausgegebene Tokens pro Sekunde und Stream schneller als die Lesegeschwindigkeit. Mehr bringt dann keinen Vorteil. Für die Kosten ist der gesättigte Gesamtdurchsatz der Ausgabe entscheidend. Gut ist jeder Wert, der die Gewinnschwelle überschreitet. Bei $0.65 pro Million Tokens und einem Serverpreis von $4.47 pro Stunde liegt diese Schwelle bei Preisen im Juli 2026 bei etwa 1,910 dauerhaft ausgegebenen Tokens pro Sekunde. Ein einzelner Stream auf einem großen Modell erreicht diesen Wert nicht. Deshalb gibt es Batching.

Warum bleibt der Ollama-Durchsatz gleich, wenn ich gleichzeitige Anfragen hinzufüge?

OLLAMA_NUM_PARALLEL hat standardmäßig den Wert 1. Der Server verarbeitet daher pro Modell jeweils eine Anfrage und reiht die übrigen bis zum Wert von OLLAMA_MAX_QUEUE ein (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, da jeder parallele Slot den zugewiesenen Kontext vervielfacht und dadurch ein Teil des Modells auf die CPU verschoben werden kann.

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

Beides, da sich die Werte bei steigender Last entgegengesetzt entwickeln. TTFT bestimmt, was ein Benutzer wahrnimmt. Der gesättigte Ausgabedurchsatz bestimmt, was auf Ihrer Rechnung erscheint. Erfassen Sie bei jedem Schritt der gleichzeitigen Anfragen p50- und p99-TTFT. Wählen Sie anschließend die höchste Parallelität, bei der p99 TTFT für Sie noch akzeptabel ist. Melden Sie den Durchsatz an diesem Punkt als Ihre Kapazität. Verwenden Sie nicht den Maximalwert am oberen Ende der Kurve.

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

Nein. Die Kosten pro Token entsprechen 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, verursacht daher weiterhin hohe Kosten pro Token. Entscheidend ist die Auslastung, nicht die Spitzengeschwindigkeit. Achten Sie außerdem auf die Einheiten. Ein angegebener Gesamtdurchsatz an Tokens umfasst auch Eingabetokens. Bei einem Verhältnis von 1:1 zwischen Eingabe und Ausgabe liegt er daher ungefähr beim Doppelten der Ausgaberate, die Ihnen in Rechnung gestellt wird.