Wie viele Tokens kostet ein Bild? 15 APIs im Vergleich
Inhalt
- Wie rechnen die Anbieter ein Bild ab?
- Wie viele Tokens kostet ein einzelnes Bild?
- Wovon hängt die Token-Zahl eines Bildes ab?
- Welche drei Abrechnungsschemata gibt es?
- Wo liegen die Grenzen für die Herunterskalierung genau?
- Ändern Form, Inhalt oder Dateiformat die Rechnung?
- Welche Maßnahmen senken die Input-Kosten für Bilder tatsächlich?
- FAQ
Dasselbe Bild mit 1024x1024 Pixeln kostet bei GPT-5.6 693 Input-Tokens, bei Qwen 3.8 Max 988, bei Gemini 1,089 und bei Claude 1,372. Nach Anwendung der jeweiligen Input-Preise kostet ein Bild über 15 Vision-Modelle hinweg zwischen $0.00005 und $0.0137. Dieser Unterschied entsteht fast vollständig durch den Input-Preis des jeweiligen Modells, nicht durch dessen Bild-Tokenizer. Fünf Anbieter veröffentlichen Abrechnungsregeln für Bilder; bei drei davon widersprechen unsere Messwerte der Dokumentation. Diese Untersuchung ergänzt unsere Analyse der Text-Tokenizer: Wir haben dieselben lokal erzeugten PNGs an alle Vision-Modelle im Katalog gesendet und die Bildkosten als Differenz der Prompt-Tokens mit und ohne Bild ermittelt. Getestet wurden sechs Größen, fünf Seitenverhältnisse, drei Inhaltstypen, drei Dateiformate und Stapel mit einem bis vier Bildern.
TL;DR
- Ein Bild mit 1024x1024 Pixeln: 693 Tokens bei GPT-5.6, 1,089 bei Gemini, 1,372 bei Claude; die Kosten reichen von $0.00005 (qwen3-vl-flash) bis $0.0137 (claude-fable-5).
- Drei Abrechnungsschemata: Patch-Formeln (Qwen: exakt (side/32)²+2), Kacheln mit Obergrenze (GPT stoppt bei 693) und Pauschalen (Gemini berechnet immer 1,089, auch für Thumbnails).
- Drei dokumentierte Regeln stimmen nicht mit den Messwerten überein: Claude-Flaggschiffmodelle skalieren erst bei ≈1,920px statt 1,568 herunter, Gemini berechnet pauschal 1,089 statt der dokumentierten 258, und Qwen nutzt ein 32px- statt eines 28px-Rasters.
- Dateiformat und Inhalt änderten kein einziges Token: Für die Abrechnung zählt nur die Geometrie.
Wie rechnen die Anbieter ein Bild ab?
Fünf der sieben Modellfamilien veröffentlichen eine Regel. Drei dieser fünf Regeln halten einer Messung nicht stand. Die folgende Tabelle fasst den gesamten Artikel zusammen. Alle weiteren Abschnitte liefern entweder die Messdaten zu einer Abweichung oder beschreiben ein Kostenverhalten, das in keiner Dokumentation erwähnt wird:
| Familie | Laut Dokumentation | Unsere Messwerte |
|---|---|---|
| OpenAI | 32px-Patches mit einem Patch-Budget pro Modell (Dokumentation) | Verlauf stimmt überein: 6 Tokens bei 64px, feste Obergrenze von 693 Tokens |
| Anthropic | (w x h)/750, Herunterskalierung ab einer langen Kante von 1,568px (Dokumentation) | Formel bei 512-1,024px exakt; die Grenze von 1,568 gilt nur für Haiku, die Flaggschiffmodelle rechnen bis ≈1,920px weiter |
| Bilder bis 384px kosten 258 Tokens, größere Bilder 258 pro 768px-Kachel (Dokumentation) | Pauschal 1,089 bei jeder Größe, einschließlich eines 64px-Icons; für den dokumentierten Parameter media_resolution funktionierte auf der getesteten API-Oberfläche keine Schreibweise | |
| Alibaba | ein Token pro 28x28px, mindestens 4 (Dokumentation) | Bei qwen3-vl passt ein 32px-Raster token-genau ((side/32)²+2), Mindestwert 66, Obergrenze bei 1,600px |
| Moonshot | dynamische Token-Zahl, keine Formel veröffentlicht, Bilder bis 4K werden akzeptiert (Dokumentation) | konsistent: quadratisches Wachstum, bis 3,072px keine Obergrenze gefunden (11,674 Tokens) |
| MiniMax / ByteDance | keine öffentliche Formel gefunden | quadratisches Wachstum mit Obergrenze bei 2,048px; pauschal 1,298 pro Bild |
Das Muster in der rechten Spalte ist klar: Alle dokumentierten Regeln beziehen sich auf die Geometrie, also auf Patches, Kacheln oder Divisoren. Geometrie lässt sich messen, deshalb haben wir sie gemessen. Stimmen beide Spalten nicht überein, übernimmt jede Budgetkalkulation diesen Fehler: Eine Pipeline für Claude-Flaggschiffmodelle, die mit der dokumentierten Grenze von 1,568px plant, veranschlagt für große Bilder rund 45% zu wenig. Eine Gemini-Pipeline, die für Thumbnails 258 Tokens erwartet, zahlt für jedes Icon das 4.2-Fache.
Wie viele Tokens kostet ein einzelnes Bild?
In unserer Testmatrix waren es je nach Modell und Größe zwischen 6 und 5,486. Die Token-Zahl macht allerdings nur die Hälfte der Rechnung aus. Die folgende Tabelle zeigt dasselbe PNG mit 1024x1024 Pixeln auf allen Vision-Modellen im Katalog, jeweils mit dem Input-Preis des Modells:
| Modell | Tokens (1024²) | ≈ Wörter englischer Text | × Input-Preis des Modells pro 1K Tokens | Input-Preis /1M | Kosten pro Bild |
|---|---|---|---|---|---|
| qwen3-vl-flash | 1,026 | ≈770 | 1.03x | $0.05 | $0.00005 |
| qwen3-vl-plus | 1,026 | ≈770 | 1.03x | $0.20 | $0.0002 |
| minimax-m3 | 1,371 | ≈1,030 | 1.37x | $0.30 | $0.0004 |
| Dola-Seed-2.0-pro | 1,298 | ≈970 | 1.30x | $0.50 | $0.0006 |
| gpt-5.6-luna | 693 | ≈520 | 0.69x | $1.00 | $0.0007 |
| gemini-3.7-flash | 1,089 | ≈820 | 1.09x | $0.75 | $0.0008 |
| claude-haiku-4-5 | 1,373 | ≈1,030 | 1.37x | $1.00 | $0.0014 |
| gemini-3.6-flash | 1,089 | ≈820 | 1.09x | $1.50 | $0.0016 |
| qwen3.8-max | 988 | ≈740 | 0.99x | $2.00 | $0.0020 |
| gemini-3.1-pro-preview | 1,089 | ≈820 | 1.09x | $2.00 | $0.0022 |
| claude-sonnet-5 | 1,372 | ≈1,030 | 1.37x | $2.00 Einführungspreis | $0.0027 |
| kimi-k3 | 1,379 | ≈1,030 | 1.38x | $3.00 | $0.0041 |
| claude-opus-5 | 1,372 | ≈1,030 | 1.37x | $5.00 | $0.0069 |
| claude-fable-5 | 1,372 | ≈1,030 | 1.37x | $10.00 | $0.0137 |
Drei Schlüsse ergeben sich daraus. Erstens wird das Bild tatsächlich wie Text auf das Kontextbudget angerechnet: Bei 0.75 englischen Wörtern pro Token belegt ein 1024px-Bild so viel Kontext wie ein Dokument mit 520 bis 1,030 Wörtern. Deshalb sind Kontextfenster und Budgets bei bildlastigen Unterhaltungen deutlich schneller ausgeschöpft als bei reinem Text. Zweitens bestimmt fast ausschließlich der Tarif die Kosten in Dollar. Die Token-Zahlen liegen innerhalb eines Faktors von 2 (693 bis 1,379). Ein Bild kostet bei jedem Modell daher das 0.69- bis 1.38-Fache dessen, was das Modell für 1,000 Input-Tokens verlangt. Die Dollar-Spalte bildet im Wesentlichen den jeweiligen Input-Preis ab. Drittens verwenden Modellfamilien exakt denselben Tokenizer: Beide qwen3-vl-Varianten, beide GPT-5.6-Varianten, alle drei Gemini-Modelle und alle vier Claude-Modelle lieferten für jedes quadratische Bild identische oder nahezu identische Werte. Dasselbe Muster mit einem Tokenizer pro Familie haben wir bereits bei Text gemessen.
Wovon hängt die Token-Zahl eines Bildes ab?
Fünf Faktoren verändern die Rechnung, drei oft vermutete Faktoren dagegen nicht. Alle weiteren Abschnitte untersuchen jeweils eine Zeile dieser Tabelle:
| Faktor | Auswirkung | Gilt für |
|---|---|---|
| Abrechnungsschema | Patch-Formel vs. Kacheln mit Obergrenze vs. Pauschale | siehe Schematabelle unten |
| Auflösung (Fläche) | wichtigster Faktor, annähernd quadratisches Wachstum | jedes Modell außer den beiden Pauschalmodellen |
| Obergrenze für die Herunterskalierung | Pixel jenseits der Grenze werden nie abgerechnet | 1,600px (Qwen), ≈1,920px (Claude-Flaggschiffmodelle), 1,568px (Haiku), Obergrenze von 693 Tokens (GPT); Kimi hat keine |
| Seitenverhältnis | nachrangig: umschließende Raster verteuern Streifen, Grenzen für die lange Kante verbilligen extreme Formate | GPT +84% bei 3:1, dann -11% bei 8:1; Haiku -71% bei 8:1 |
| Bildanzahl | streng additiv, kein Mengenrabatt | alle 15 Modelle |
| Inhalt (Foto vs. Text vs. leer) | keine Auswirkung | jedes gemessene Modell |
| Dateiformat (PNG/JPEG/WebP) | keine Auswirkung | jedes gemessene Modell |
| Dateigröße in Bytes | keine Auswirkung | jedes gemessene Modell |
Die drei Faktoren ohne Einfluss sind relevant, weil sich beide gegenteiligen Annahmen hartnäckig halten: Keine API in dieser Matrix berücksichtigt für die Rechnung die Kompressionsrate oder die Komplexität des Bildinhalts. Die Geometrie bestimmt die Tokens.
Welche drei Abrechnungsschemata gibt es?
Patch-Formeln, Kacheln mit Obergrenze und Pauschalen. Bei kleinen Bildern führen sie zu völlig unterschiedlichen Preisen. Wir haben eine sechsstufige Größenreihe mit quadratischen Bildern von 64px bis 2,048px getestet:
| Modell | 64px | 128px | 256px | 512px | 1,024px | 2,048px | Schema |
|---|---|---|---|---|---|---|---|
| qwen3-vl (beide) | 66 | 66 | 66 | 258 | 1,026 | 2,502 | Patches: (side/32)²+2, min. 8x8, Obergrenze 1,600px |
| qwen3.8-max | 28 | 28 | 28 | 220 | 988 | 2,464 | Patches, niedrigerer Mindestwert |
| gpt-5.6 (beide) | 6 | 21 | 78 | 309 | 693 | 693 | Kacheln, feste Obergrenze 693 |
| gemini (alle drei) | 1,089 | 1,089 | 1,089 | 1,089 | 1,089 | 1,089 | Pauschale, unabhängig von der Größe |
| Dola-Seed-2.0-pro | 1,298 | 1,298 | 1,298 | 1,298 | 1,298 | 1,298 | Pauschale, unabhängig von der Größe |
| kimi-k3 | 17 | 33 | 108 | 369 | 1,379 | 5,486 | quadratisch, keine Obergrenze gefunden |
| minimax-m3 | 18 | 27 | 102 | 363 | 1,371 | 5,186 | quadratisch, Obergrenze bei 2,048px |
| claude (alle vier) | 12 | 28 | 103 | 364 | 1,372 | 4,764 | (w x h)/750, Obergrenze durch Herunterskalierung |

Die Qwen-Formel ist exakt genug für Budgetkalkulationen: Ein quadratisches Bild mit 1,024px kostet (1024/32)² + 2 = 1,026 Tokens. Das haben wir token-genau bestätigt. Es gilt ein aufgefülltes Minimum von 8x8 Patches (66) sowie eine Obergrenze für die Herunterskalierung bei 1,600px. Alle getesteten Größen zwischen 1,600 und 1,920px ergaben exakt 2,502 Tokens. GPT verwendet bis 693 Tokens Kacheln und berechnet nie mehr: Ein Bild mit 1,024px kostet genauso viel wie eines mit 2,048px. Die beiden Pauschalmodelle sind für Thumbnail-Traffic eine Kostenfalle: Gemini berechnet für ein 64px-Icon 1,089 Tokens, also genauso viel wie für einen 4K-Screenshot nach der Herunterskalierung. Seed berechnet 1,298. Am anderen Ende skalierte Kimi K3 über die Obergrenzen aller anderen Modelle hinaus weiter: Ein quadratisches Bild mit 3,072px kostete 11,674 Tokens. Es war das einzige Modell in der Matrix, bei dem wir keine Herunterskalierung feststellen konnten.
Wo liegen die Grenzen für die Herunterskalierung genau?
Jede Modellfamilie außer Kimi verkleinert große Bilder vor der Abrechnung. Maßgeblich sind die gemessenen Grenzen, nicht die dokumentierten. Bei Claude ist eine genauere Betrachtung sinnvoll, weil die Abweichung bei claude-sonnet-5 und höher reale Kosten verursacht: 1,568px ergeben 3,139 Tokens, 1,728px ergeben 3,847, 1,920px ergeben 4,764. Danach bleibt der Wert konstant; auch 2,048px und 2,304px kosten 4,764. Das Flaggschiff-Trio rechnet etwa 45% mehr reale Pixel ab als laut Dokumentation vorgesehen. claude-haiku-4-5 ist das einzige Modell, das sich wie dokumentiert verhält. Wer die Upload-Pipeline kontrolliert, sollte Bilder vor dem Encoding auf die gemessene Grenze des jeweiligen Modells verkleinern. Pixel jenseits dieser Grenze werden entweder zusätzlich berechnet (Kimi) oder stillschweigend verworfen (alle anderen). Übergroße Uploads verbrauchen damit nur Bandbreite.
Ändern Form, Inhalt oder Dateiformat die Rechnung?
Alle gemessenen Formeffekte lassen sich durch zwei Faktoren erklären, die beide nichts mit der Dateigröße zu tun haben: ob das Modell die Fläche oder ein umschließendes Raster zählt und wo die Grenze für die Herunterskalierung der langen Kante liegt. Inhalt und Format hatten dagegen nirgendwo einen Einfluss: Ein einfarbiges 512px-Bild, ein Rauschbild und eine Textseite kosteten bei jedem gemessenen Modell gleich viele Tokens. Dasselbe galt für dasselbe Bild mit 243KB (PNG), 176KB (JPEG) und 174KB (WebP).
Für den Faktortest bleibt die Fläche konstant bei einem Megapixel, während sich das Seitenverhältnis ändert:
| Modell | 1:1 | 2:1 | 3:1 | 4:1 | 8:1 (2,896px lange Kante) |
|---|---|---|---|---|---|
| gpt-5.6 (beide) | 693 | 1,271 | 1,278 | 1,230 | 616 |
| claude Flaggschiff-Trio | 1,372 | 1,355 | 1,411 | 1,409 | 1,107 |
| claude-haiku-4-5 | 1,373 | 1,356 | 1,068 | 788 | 396 |
| minimax-m3 | 1,371 | 1,352 | 1,410 | 1,298 | 650 |
| kimi-k3 | 1,379 | 1,361 | 1,417 | 1,415 | 1,361 |
| qwen3-vl (beide) | 1,026 | 1,037 | 992 | 1,026 | 992 |
| gemini (alle drei) | 1,089 | 1,081 | 1,083 | 1,056 | 1,034 |
| Dola-Seed-2.0-pro | 1,298 | 1,277 | 1,304 | 1,298 | 1,315 |
Die Zeilen lassen sich anhand dieser beiden Faktoren erklären. Qwen, Kimi, Gemini und Seed bleiben konstant: Hier zählt nur die Fläche oder es gilt eine feste Pauschale, ohne Aufschlag für die Form. GPT ist das einzige Modell mit einem umschließenden Abrechnungsraster. Streifen kosten dort trotz gleicher Pixelzahl bis zu 84% mehr als ein Quadrat. Bei 8:1 überschreitet die lange Kante jedoch die Grenze, sodass die Herunterskalierung den Aufschlag wieder aufhebt: 616 Tokens und damit weniger als beim Quadrat. Bei den Modellen mit einer Grenze für die Herunterskalierung tritt derselbe Umschlagpunkt jeweils an der eigenen Grenze auf: Haiku wird ab 3:1 günstiger, weil die lange Kante mit 1,774px über der Grenze von 1,568 liegt: zunächst 1,068, dann 788 und schließlich 396. Die Claude-Flaggschiffmodelle werden erst bei 8:1 günstiger, wenn 2,896px ihre Grenze von ungefähr 1,920px überschreiten: 1,107. Bei MiniMax passiert das ebenfalls bei 8:1 jenseits der Grenze von 2,048px: 650. Für breite Dokumente und Screenshots folgt daraus: Bei GPT sollte man Streifen selbst aufteilen oder verkleinern. Bei Haiku sind extreme Seitenverhältnisse stillschweigend die günstigsten Claude-Pixel.
Welche Maßnahmen senken die Input-Kosten für Bilder tatsächlich?
Drei Maßnahmen helfen, in dieser Reihenfolge. Erstens: auf die Obergrenze des Modells verkleinern. Bei Kimi werden alle Pixel oberhalb der Grenzen anderer Modelle weiterhin berechnet, während sie bei allen anderen Modellen verworfen werden. Zweitens: detail: "low" bei GPT. Bei 512px ändert der Wert nichts; alle Einstellungen kosten 309 Tokens. Bei 2,048px begrenzt low das Bild jedoch auf 309 Tokens statt 693 bei high oder auto. Das senkt die Kosten um 55%. Es war der einzige bildbezogene Parameter pro Request, den wir bei irgendeinem Modell gefunden haben. Drittens: das Abrechnungsschema passend zum Workload wählen. Pauschalmodelle wie Gemini und Seed eignen sich schlecht für Thumbnails und Icons, aber gut für durchgehend große Scans. Patch- und Kachelmodelle rechnen kleine Bilder angemessen ab: Ein 64px-Icon kostet bei GPT 6 Tokens, bei Kimi 17.
Mehrere Bilder in einem Request bringen bei keinem Modell einen Rabatt. Stapel mit 1, 2 und 4 Kopien in einer Nachricht wurden bei allen 15 Modellen streng additiv abgerechnet, jede Kopie zum vollen Einzelpreis. Bei Pauschalmodellen fällt das besonders stark ins Gewicht: Vier 256px-Thumbnails in einem Gemini-Request kosten 4,356 Bild-Tokens, dieselben vier bei qwen3-vl-flash nur 264.
FAQ
Wie viele Tokens kostet ein Bild mit 1024x1024 Pixeln?
Beim selben PNG haben wir folgende Werte gemessen: 693 bei GPT-5.6, 988 bei Qwen 3.8 Max, 1,026 bei qwen3-vl, 1,089 bei Gemini, 1,298 bei ByteDance Seed, 1,371 bei MiniMax, 1,372 bei Claude und 1,379 bei Kimi K3. Der Unterschied um den Faktor 2 bei den Tokens ist weniger relevant als der darauf angewandte Tarif: Die Kosten reichen von $0.00005 (qwen3-vl-flash) bis $0.0137 (claude-fable-5).
Beeinflussen Dateiformat oder Kompression die Token-Kosten eines Bildes?
Nein, bei keinem der gemessenen Modelle. Dasselbe 512px-Bild kostete als PNG (243KB), JPEG (176KB) und WebP (174KB) gleich viele Tokens. Auch einfarbige Bilder, Rauschen und textreiche Inhalte wurden identisch abgerechnet. Für die Abrechnung zählen nur die Pixelmaße. Komprimierung spart Bandbreite, keine Tokens.
Reduziert detail: "low" die Bild-Tokens?
Bei GPT-5.6 ja, aber nur oberhalb der Schwelle für kleine Bilder: Ein 2,048px-Bild kostete mit low 309 Tokens statt 693 mit high oder auto, also 55% weniger. Bei 512px ergaben alle drei Einstellungen 309. Kein anderes Modell in der Matrix bot einen funktionierenden Parameter pro Request, mit dem sich die Bildkosten steuern ließen.
Werden Bilder günstiger, wenn ich mehrere in einem Request bündele?
Nein. 1, 2 und 4 Kopien desselben Bildes wurden bei jedem Modell streng additiv zum vollen Einzelpreis abgerechnet. Batching spart Request-Overhead und Latenz, aber keine Bild-Tokens. Bei Pauschalmodellen wie Gemini und Seed sind viele kleine Bilder in einem Request die teuerste mögliche Konstellation.
Gemessen am 2026-08-13/14 über das Synthorai-Gateway mit 17 Modellen (15 Vision-Modelle, 2 reine Textmodelle als Kontrollen): lokal erzeugte PNGs mit exakten Abmessungen; Bildkosten als Differenz der Prompt-Tokens zwischen einem Request mit Bild und einer gesalzenen Baseline mit demselben Text ohne Bild. Getestet wurden eine sechsstufige Größenreihe (64-2,048px), Grenzwerttests bis 3,072px, sechs Seitenverhältnisse mit 1MP (1:1 bis 8:1 plus ein Hochformat mit 1:4), drei Inhaltstypen, PNG/JPEG/WebP, detail low/high/auto bei GPT, Stapel mit 1/2/4 Bildern sowie eine Sichtprüfung mit einem Codewort bei jedem Modell. Die Dollarbeträge ergeben sich aus den gemessenen Tokens und dem am Messtag auf der jeweiligen Modellseite angegebenen Input-Preis (Sonnet 5 zum Einführungspreis von $2). Abrechnungsregeln für Vision können sich ohne Ankündigung ändern. Vor der Übernahme eines einzelnen Tabellenwerts sollte die Größenreihe erneut gemessen werden.