Zum Hauptinhalt springen

Optische Kontextkompression: Text als Bild senden

Experte

Jeder Long-Context-Trick der letzten zwei Jahre versuchte, den Tokenizer günstiger zu machen: besseres Chunking, besseres Retrieval, sparsamere Attention. Eine andere Forschungslinie stellt eine seltsamere Frage — was, wenn du den Text überhaupt nicht mehr tokenisierst, ihn in ein Bild renderst und den Vision-Encoder die Kompression übernehmen lässt?

Es klingt wie ein Witz. Ist es nicht. Apples LensVLM landete diese Woche mit genau diesem Ansatz auf der Startseite von Hacker News, und es sitzt auf einem Jahr an Ergebnissen — DeepSeek-OCR, Glyph von Tsinghua/Zhipu — die zeigen, dass eine Seite Text als Pixel weit weniger Tokens kostet als als Zeichen, bis sie es plötzlich nicht mehr tut.

Diese Seite behandelt den Mechanismus (er ist einfacher, als du denkst), die Zahlen bei Claude, GPT und Gemini (sie widersprechen sich heftig), die Genauigkeitsklippe, in die alle laufen, und ein 15-Minuten-Experiment, um herauszufinden, wo diese Klippe bei deinen Dokumenten liegt.

What you'll learn
  • Erklären, warum die Rendering-Auflösung ein kontinuierlicher Kompressionsregler ist, während ein Text-Tokenizer überhaupt keinen Regler hat
  • Die Bild-Token-Formeln pro Anbieter lesen — Claudes 28x28-Patches, OpenAIs 32x32-Patches, Geminis 258-Token-Tiles — und vorhersagen, in welche Richtung ein gegebener Input geht
  • Die gemessenen anbieterübergreifenden Verhältnisse zitieren: 0,135 bei Anthropic, 0,194 bei OpenAI, 0,242 bei Google — und den Fall, in dem Gemini 6,95x mehr verlangt
  • Die Klippe benennen: Die Genauigkeit bricht ein, sobald Glyphen unter die effektive Auflösung des Vision-Encoders schrumpfen, und der Anbieter skaliert dich stillschweigend hinein
  • Entscheiden, wann optische Kompression sich lohnt (langes statisches Referenzmaterial) und wann sie ein Kunstfehler ist (alles, was das Modell bearbeiten oder exakt zitieren muss)

Der Mechanismus: Auflösung ist der Regler, den ein Tokenizer nie hatte​

Ein Text-Tokenizer gibt dir einen ungefähr festen Umtauschkurs. Englische Prosa liegt bei etwa vier Zeichen pro Token, Quellcode etwas schlechter, und es gibt keine Einstellung, die das ändert. Du kannst Text löschen oder du kannst dafür bezahlen.

Ein Vision-Encoder funktioniert genau umgekehrt. Er bildet ein Bild einer gegebenen Größe auf eine feste Anzahl visueller Tokens ab, unabhängig davon, wie viel Information du in diese Pixel gepackt hast. Rendere 40 Textzeilen in ein 1000x1000-Bild, und du bezahlst für ein 1000x1000-Bild. Rendere 400 Zeilen in dasselbe 1000x1000-Bild, mit einem Zehntel der Schriftgröße, und du bezahlst genau dasselbe.

Das ist die ganze Idee. Die Rendering-Auflösung wird zu einem kontinuierlichen Kompressionsregler — und anders als Chunking oder Zusammenfassung ist sie auf visuelle Weise verlustbehaftet: Nichts wird entfernt, alles wird nur kleiner.

Jeder Anbieter verwandelt Pixel anders in Tokens, und die Unterschiede zählen mehr als das Marketing:

AnbieterWie Bilder gezählt werdenPraktische Konsequenz
Claude28x28-Pixel-Patches: Ein Bild kostet ceil(width/28) x ceil(height/28) visuelle TokensGünstig pro Pixel und hart begrenzt (siehe unten)
OpenAI32x32-Pixel-Patches, multipliziert mit einem modellspezifischen Multiplikator; der High-Detail-Modus erlaubt bis zu 2500 PatchesEin 1024x1024-Bild sind 1024 Patches, abgerechnet als ceil(1024 x 1.2) = 1229 Tokens bei einem Modell mit 1,2x-Multiplikator
GeminiJedes Bild, dessen beide Kantenlängen ≤ 384 px sind, kostet pauschal 258 Tokens; größere Bilder werden in 768x768-Tiles zerlegt, je 258 TokensEs gibt eine harte Untergrenze. Ein briefmarkengroßes Bild mit drei Codezeilen kostet immer noch 258 Tokens
What you'll learn
  • Ein Text-Tokenizer hat einen festen Umtauschkurs. Ein Vision-Encoder hat einen Regler: gleiche Bildgröße, gleicher Preis, egal wie viel Text du hineinschüttest.
  • Claude rechnet pro 28x28-Patch ab, OpenAI pro 32x32-Patch mal Modellmultiplikator, Gemini pro 258-Token-Tile mit einer 258-Token-Untergrenze.
  • Geminis Untergrenze ist der Grund, warum kurze Inputs als Bilder TEURER werden — es gibt kein günstiges kleines Bild.

Die gemessenen Zahlen und die eine, die in die falsche Richtung geht​

Im Juli 2026 erledigte eine anbieterübergreifende Studie (arXiv 2607.21672) die langweilige, notwendige Arbeit: Sie nahm echten Quellcode — fünf Sprachen, neun Längen von 20 bis 2.000 Zeilen, 15 Modell-Aliase, 675 gepaarte Text/Bild-Paare — und fragte die API jedes Anbieters selbst, wie viele Input-Tokens sie zählte, als Text und als gerendertes Bild.

Aggregierte Bild-zu-Text-Token-Verhältnisse:

AnbieterBild-/Text-Token-VerhältnisReduktion
Anthropic0,13586,5 % weniger gezählte Tokens
OpenAI0,19480,6 % weniger
Google (Vertex AI)0,24275,8 % weniger

So weit, so einheitlich gut. Das interessante Ergebnis ist die Form, nicht der Durchschnitt. Bei Anthropic und OpenAI zählten Bilder in jeder getesteten Größe niedriger — selbst bei 20 Zeilen. Bei Gemini kostete ein Bild mit 20 Codezeilen 6,95x so viele Tokens wie der Text, und Bilder fielen erst bei etwa 200 Zeilen unter den Text.

Das ist die 258-Token-Untergrenze bei der Arbeit. Unterhalb von etwa 200 Zeilen kaufst du ein ganzes Tile, um eine Handvoll Glyphen zu beherbergen.

Watch out
  • Diese Studie hat ausschließlich die Token-BUCHFÜHRUNG gemessen. Die Autoren sagen es explizit: Sie misst keine semantische Treue, keine Aufgabengenauigkeit, keine Latenz, keine Geldkosten und keine Effizienz von Coding-Agenten.
  • Eine 7x kleinere Token-Zahl, die 40 % deiner Fragen falsch beantwortet, ist keine 7x-Einsparung. Die Token-Zahl ist die einfache Hälfte dieser Entscheidung.
  • Anbieterverhältnisse sind nicht übertragbar. Dieselbe Pipeline, die bei Claude 86 % spart, kann dich bei Gemini für kurze Inputs 7x kosten.

Der nicht offensichtliche Teil: Die Obergrenze macht den größten Teil der Arbeit​

Hier ist, was diese aggregierten Verhältnisse bei langen Dateien so spektakulär aussehen lässt — und warum sie eine Falle sind.

Claude lässt dich kein beliebig großes Bild kaufen. Jedes Modell sitzt in einer Auflösungsstufe mit einem Limit für die lange Kante und einem Limit für visuelle Tokens, und alles Größere wird vor der Verarbeitung herunterskaliert:

StufeModelleMax. lange KanteMax. visuelle Tokens
HochauflösendClaude 4.7 und später2576 px4784
StandardAlle anderen Modelle1568 px1568

Lies das als Preisobergrenze. Bei einem Modell der Standardstufe kostet ein Bild höchstens 1568 visuelle Tokens — ob es 200 Codezeilen oder 2.000 enthält. Schütte mehr Text hinein, und die Rechnung bewegt sich nicht.

Das Pixelbudget auch nicht. Die Glyphen werden einfach kleiner.

Genau das ist der Fehlermodus, den die LensVLM-Autoren benennen: Die Genauigkeit "verschlechtert sich schnell, wenn die Kompression steigt: Zeichen schrumpfen unter die effektive Auflösung des Vision-Encoders und werden dadurch nicht mehr unterscheidbar." Das Herunterskalieren passiert stillschweigend — kein Fehler, keine Warnung, und die Token-Zahl sieht fantastisch aus, bis genau zu dem Punkt, an dem das Modell selbstbewusst verschwommenen Text liest.

What you'll learn
  • Ein Bild bei Claude ist ein Behälter zum Festpreis: ≤1568 visuelle Tokens im Standard, ≤4784 in der hochauflösenden Stufe (Claude 4.7+).
  • Spektakuläre Kompressionsverhältnisse bei großen Dateien entstehen meist dadurch, dass der Anbieter dich in diese Obergrenze herunterskaliert — nicht dadurch, dass der Encoder clever ist.
  • Der Token-Zähler kann Lesbarkeit nicht sehen. Deine Eval muss es, und genau deshalb ist das Experiment weiter unten nicht optional.

Was die Forschung als echte Obergrenze nennt​

Drei Papers umschließen den nutzbaren Bereich. Keines behauptet, du könntest unbegrenzt komprimieren.

DeepSeek-OCR (arXiv 2510.18234, MIT-lizenziert, ~23,9k Sterne) hat die ganze Idee als "contexts optical compression" gerahmt und dem Zerfall eine Zahl gegeben: Wenn Text-Tokens innerhalb von 10x der Vision-Tokens liegen, hält sich die OCR-Präzision bei etwa 97 %. Bei 20x Kompression fällt die Präzision auf grob 60 %. Sein Encoder bietet feste Modi — 512x512 mit 64 Vision-Tokens, 640x640 mit 100, 1024x1024 mit 256, 1280x1280 mit 400 — und bei 100 Vision-Tokens pro Seite übertraf er GOT-OCR2.0 mit 256 Tokens pro Seite auf OmniDocBench, während er mit unter 800 Tokens die über 6.000 von MinerU2.0 übertraf.

Glyph (arXiv 2510.17800, Tsinghua + Zhipu AI) griff das Kontextfenster statt OCR an: Langen Text zu Bildern rendern, einem VLM vorsetzen und 3–4x Token-Kompression bei einer Genauigkeit erreichen, die mit Qwen3-8B auf Long-Context-Benchmarks vergleichbar ist — plus grob 4x schnelleres Prefilling und Decoding und etwa 2x schnelleres SFT-Training. Unter aggressiver Kompression berichten sie von einem VLM mit 128K-Kontext, das Textaufgaben auf 1M-Token-Niveau erreicht. Bemerkenswert: Sie haben das Rendering nicht handoptimiert — eine LLM-gesteuerte genetische Suche suchte nach Schrift, Layout und Auflösung, die Genauigkeit gegen Kompression ausbalancieren. Die Rendering-Konfiguration ist ein Hyperparameter, kein Detail.

LensVLM (arXiv 2605.07019, Apple, Mai 2026) ergänzte das fehlende Stück — einen Ausweg aus der Klippe. Aufgebaut auf Qwen3.5-9B-Base, liefert es Kompressionsstufen von 5x, 10x und 15x und gibt dem Modell ein read_page-Tool: alles komprimiert scannen, dann nur die Seiten, die du wirklich brauchst, auf volle Auflösung zurück expandieren. Es hält eine Genauigkeit, die mit der Volltext-Obergrenze vergleichbar ist, bei 4,3x effektiver Kompression und übertrifft Retrieval-basierte, Textkompressions- und visuelle Kompressions-Baselines bis 10,1x über sieben Text-QA-Benchmarks hinweg. Die Gewichte liegen auf Hugging Face als apple/LensVLM-9B unter Apples Research-Model-Lizenz; der Code ist unter apple-aiml-research/ml-lensvlm.

What you'll learn
  • Etwa 10x ist der Punkt, an dem die veröffentlichte Evidenz unbequem wird: 97 % Präzision unter 10x, ~60 % bei 20x (DeepSeek-OCR).
  • Glyphs 3-4x ist die konservative, genauigkeitserhaltende Einstellung — und sie brachte ~4x schnelleres Prefill mit dazu.
  • LensVLMs Beitrag ist die Notausstiegsluke: selektive Re-Expansion, damit eine schlechte Seite nicht die ganze Antwort versenkt.

Warum selektive Expansion Retrieval schlägt (und wann nicht)​

Auf dem Papier sieht das wie RAG mit zusätzlichen Schritten aus. Ist es nicht, und der Unterschied lohnt sich zu verstehen.

Retrieval indexiert das gesamte Korpus vor, bevor irgendeine Frage existiert. Du chunkst, embeddest und speicherst — und jede nachgelagerte Antwort erbt, was deine Chunk-Grenzen zerstört haben: eine Tabelle, die auf zwei Chunks aufgeteilt ist, eine Fußnote, die von ihrer Behauptung abgeschnitten ist, eine Funktion, die von ihren Imports getrennt ist.

Optisches Scan-and-Expand dreht das um. Das ganze Dokument betritt den Kontext als komprimierte visuelle Tokens, intakt, Layout und alles. Das Modell liest die niedrig aufgelöste Version, entscheidet, welche Seiten für diese Frage zählen, und zahlt nur für diese den vollen Preis. Keine Vorindexierung, keine Chunk-Grenzen, kein Embedding-Modell, das mit dem Korpus synchron gehalten werden muss.

Die LensVLM-Analyse ergänzt eine nützliche Verfeinerung: Textexpansion funktioniert am besten für gerenderten Text, während hochauflösende Bildexpansion zu native Dokumenten passt, bei denen das Layout aufgabenrelevante Information trägt. Eine gerenderte Seite zurück in Zeichen zu expandieren ist günstiger und sauberer; eine gescannte Rechnung auf volle Auflösung zu expandieren erhält die räumliche Struktur, die du überhaupt gebraucht hast.

Wo Retrieval weiterhin gewinnt: Korpora, die weit größer sind als jedes Kontextfenster, alles, was exakte Provenienz und Zeichenoffsets braucht, und jede Pipeline, in der du beweisen musst, welche Quelle welchen Satz erzeugt hat.

Probiere es in 15 Minuten an deinen eigenen Dokumenten​

Übernimm das nicht aufgrund irgendjemandes aggregiertem Verhältnis — auch nicht der Werte auf dieser Seite. Die entscheidenden Variablen sind deine: deine Schrift, deine Zeilenlänge, dein Anbieter, deine Fragen.

Guided walkthrough1 of 5
  1. Nimm ein Dokument, das du wirklich einem Modell vorsetzt. Rendere es dreimal als PNG — bequem, halbe Größe, Viertelgröße — mit einer Monospace-Schrift und dem Renderer, den du gerade hast (Pillow, Headless Chrome, wkhtmltoimage). Halte den Text in allen drei identisch; nur die Pixelmaße ändern sich. PNG, nicht JPEG: Anthropics eigene Vision-Hinweise warnen, dass Artefakte verlustbehafteter Kompression kleinen Text schwer lesbar machen, und das ist genau der Fall, in dem das zubeißt.

Zähle denselben Inhalt bei Claude auf beide Weisen

# 1. Render text to PNG at a chosen width (Pillow)
python - <<'PY'
from PIL import Image, ImageDraw, ImageFont
text = open("document.txt").read()
font = ImageFont.truetype("DejaVuSansMono.ttf", 14)   # try 14, 9, 6
lines = text.splitlines()
img = Image.new("RGB", (1400, 18 * len(lines) + 20), "white")
d = ImageDraw.Draw(img)
for i, line in enumerate(lines):
  d.text((10, 10 + 18 * i), line, font=font, fill="black")
img.save("document.png")   # split into page-sized images if it is tall
PY

# 2. Ask Claude what each version actually costs
curl https://api.anthropic.com/v1/messages/count_tokens \
-H "x-api-key: $ANTHROPIC_API_KEY" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{
  "model": "claude-opus-5-5",
  "messages": [{"role":"user","content":[
    {"type":"image","source":{"type":"base64","media_type":"image/png","data":"'"$(base64 -i document.png)"'"}},
    {"type":"text","text":"Answer only from this document."}
  ]}]
}'

Wann es sich lohnt — und wann es ein Kunstfehler ist​

Greife zu optischer Kompression, wenn:

  • Das Material lang, statisch und nur zum Lesen ist — Policy-Handbücher, Standards, API-Referenzen, juristische Korpora, die du wiederholt abfragst, aber nie bearbeitest.
  • Die Quelle bereits visuell ist — gescannte PDFs, Formulare, Rechnungen, Foliensätze. Du hättest ohnehin Bild-Tokens bezahlt; das Rendern ist gratis.
  • Layout Bedeutung trägt — Tabellen, mehrspaltige Dokumente, alles, wo die Serialisierung zu Markdown die Beziehungen zerstört, die du brauchst.
  • Du viele Seiten gleichzeitig im Blick brauchst und Retrieval immer wieder quer durch die Antwort schneidet.

Behalte den Textpfad, wenn:

  • Das Modell den Inhalt bearbeiten, diffen oder patchen muss. Ein Coding-Agent braucht Zeilennummern, exakten Whitespace und byte-genaues Zitieren; nichts davon überlebt eine Rundreise durch Pixel.
  • Ein einziges falsches Zeichen unakzeptabel ist — Kontonummern, Dosierungen, juristische Zitate, Konfigurationswerte. Hier zeigt sich die Auflösungsklippe zuerst.
  • Der Input kurz ist. Bei Gemini zahlst du mehr, und bei jedem Anbieter tauschst du echte Genauigkeit gegen einen Rundungsfehler bei den Kosten.
  • Du exakte Zitat-Offsets zurück in die Quelle brauchst.
Watch out
  • Übergroße Bilder werden bei Claude stillschweigend herunterskaliert, sofern du nicht explizit stattdessen einen Fehler verlangst — deine Lesbarkeit kann sich ohne jedes Signal in der Antwort verschlechtern.
  • Mehr als 20 Bildblöcke in einer Claude-Anfrage zu senden löst ein strengeres Dimensionslimit pro Bild für JEDES Bild in dieser Anfrage aus; halte jedes unter 2000 px pro Seite oder die Anfrage bei 20 Blöcken.
  • Die Bildobergrenzen pro Anfrage liegen bei 100 für Modelle mit 200k Kontext und ansonsten 600, und ein Anfragegrößenlimit von 32 MB beißt üblicherweise zuerst — nutze die Files API und referenziere Bilder per file_id.
  • Prompt-Caching gilt auch für Bildinhaltsblöcke in User-Turns, aber Mindestlängen für cachebare Prompts gelten weiterhin; bestätige es mit cache_read_input_tokens in der Antwort, statt es anzunehmen.
Vokabular der optischen Kompression
Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 8

Quiz​

Check yourself

0/5
  1. Eine anbieterübergreifende Studie fand Bild-zu-Text-Token-Verhältnisse von 0,135 (Anthropic), 0,194 (OpenAI) und 0,242 (Google). Was ist der wichtigste Vorbehalt, bevor du auf diese Zahlen hin handelst?
  2. Warum kostet das Rendern von 20 Codezeilen als Bild bei Gemini 6,95x MEHR als der Text, bei Claude und OpenAI aber weniger?
  3. Bei einem Claude-Modell der Standardstufe renderst du 200 Zeilen in ein Bild und dann 2.000 Zeilen in ein Bild derselben Maße. Was passiert mit der Token-Zahl?
  4. Was fügt LensVLMs read_page-Tool gegenüber reiner visueller Kompression hinzu?
  5. Welche Arbeitslast passt am SCHLECHTESTEN zu optischer Kontextkompression?

Quellen & weiterführende Literatur​

Weiter​