Lo que de verdad limita — y factura — a un LLM
Un LLM no lee letras ni palabras: lee tokens — fragmentos que decide su propio tokenizador. Y cobra (y limita) por token, no por palabra ni por carácter.
Misma frase, mismo significado — 33% más tokens en GPT-4. Ningún tokenizador es "más correcto", solo distinto.
El límite se agota rapidísimo con historial de chat largo — no solo con documentos grandes.
| Modelo (ene. 2026) | Context window | ≈ páginas |
|---|---|---|
| GPT-5.2 | 400.000 tokens | ~600 |
| Claude Opus 4.5 | 200.000 tokens | ~300 |
| Claude Sonnet 4.5 | 200K estándar / 1M beta | ~300 / ~1.500 |
| Gemini 3 Pro / Flash | 1.000.000 tokens | ~1.500 |
Revisa en LM Studio la configuración del modelo cargado y mira "Context Length" (n_ctx). Casi siempre está muy por debajo de 128K — subirlo consume mucha más RAM/VRAM. la caché KV crece con cada token extra: el mismo coste O(n²) de atención, ahora en memoria
Divide en fragmentos independientes. No pierde info, solo hace que quepa.
Comprime en cascada. Pierde detalle a cambio de visión global.
Solo envías la sección relevante. Sin pérdida si eliges bien.
*Chunking reduce tokens por llamada, no el total — es lo que evita el error de límite.
Caso real: informe de 80 páginas (~120.000 tokens), analizar solo riesgos financieros.
84% menos coste — misma información relevante, porque el documento tenía índice claro.
Medir tokens reales y ver los límites de tu setup local con tus propios ojos.
Pega un texto tuyo en platform.openai.com/tokenizer. Anota tokens, caracteres y el ratio. ¿Se acerca a 3,4?
En LM Studio revisa el "Context Length" de Llama 3.1 8B. Calcula a cuántas páginas equivale (1 token≈0,75 palabras, ~500 palabras/página).
Pega un documento largo hasta acercarte a ese límite. ¿Trunca, da error, o "olvida" la parte media? — "lost in the middle", relacionado con self-attention.