Source: https://aiprimetech.io/es/blog/reduce-llm-token-usage/ Jun 20, 2026 · 7 min · API # Cómo reducir el uso de tokens mediante ingeniería sin perjudicar la calidad A Por [AI Prime Tech](https://aiprimetech.io/es/) · Con asistencia de IA El mes pasado revisé un agente de atención al cliente que consumía entre 18,000 y 42,000 tokens de entrada por ticket antes de escribir una sola palabra. El problema real del usuario solía ocupar menos de 300 tokens. El resto era contexto «por si acaso»: el historial completo de la conversación, todas las páginas de políticas internas recuperadas mediante búsquedas por palabras clave, JSON resultados de herramientas copiados literalmente y un prompt de sistema de 900 tokens que había ido creciendo durante seis meses. La solución no fue «usar un modelo más pequeño» ni «reducir max_tokens y esperar que funcione». Redujimos la mediana del uso de tokens aproximadamente un 68% y mantuvimos estable la calidad de las respuestas mediante un trabajo de ingeniería poco llamativo: recortar el contexto, recuperar evidencia más específica, resumir el estado, exigir el cumplimiento de esquemas de salida y medir los tokens con rigor. Este artículo trata sobre ese tipo de trabajo. No sobre reducir prompts al mínimo por deporte. Ni sobre trucos que empeoran el modelo. Solo sobre formas prácticas de gastar menos tokens sin volver menos inteligente tu sistema. ## El uso de tokens es un problema de arquitectura La mayoría de los equipos trata el coste de los tokens como un problema de precios de los modelos. En la práctica, suele ser un problema de enrutamiento de la información. Una llamada típica a un LLM en producción tiene cuatro categorías de tokens: - Tokens de instrucciones: prompt de sistema, prompt de desarrollador, reglas de formato y restricciones de seguridad. - Tokens de contexto: historial del chat, documentos recuperados, resultados de herramientas y registros de bases de datos. - Tokens de razonamiento y tarea: la solicitud real del usuario y los detalles intermedios de la tarea. - Tokens de salida: la respuesta generada, el objeto JSON, la consulta SQL, el resumen o la llamada a una herramienta. Cuando el uso de tokens se descontrola, el contexto y la salida suelen ser los culpables. El modelo no resulta caro porque el usuario haya hecho una pregunta difícil. Resulta caro porque la aplicación ha metido el mundo entero en el prompt y luego ha permitido que el modelo se extienda sin medida. Un primer ejercicio útil es registrar el uso de tokens por sección, no solo el tamaño total de la solicitud: ``` { "request_id": "ticket_81291", "model": "sonnet-4.6", "tokens": { "system": 742, "history": 3890, "retrieval": 12640, "tool_results": 2110, "user": 184, "output": 931 }, "latency_ms": 4820 } ``` Cuando ves este desglose, el camino hacia la optimización resulta evidente. No necesitas debatir si Claude Opus 4.8, Sonnet 4.6, GPT-5.5, Gemini 3, Fable 5 o un modelo abierto como Qwen o DeepSeek es «el mejor» en abstracto. Primero debes dejar de enviar 12,000 tokens irrelevantes de contenido recuperado. ## Empieza con un presupuesto de tokens por ruta Me gusta asignar presupuestos por ruta del producto, no de forma global. La revisión de contratos legales, un agente de programación y un bot de preguntas frecuentes no deberían compartir los mismos supuestos sobre tokens. Ejemplo de presupuesto para un asistente de soporte: | Vía | Presupuesto de entrada | Presupuesto de salida | Clase de modelo | Notas | Clasificar el ticket | 600 | 50 | Modelo económico y rápido | Etiquetas, urgencia e idioma | Recuperar evidencia | 1,500 | 0 | Embeddings/búsqueda | No requiere generación | Redactar la respuesta | 4,000 | 600 | Modelo potente de gama media o alta | Usa evidencia seleccionada | Resumir el hilo | 1,000 | 250 | Modelo económico y rápido | Actualiza el estado de la memoria | Análisis para escalar el caso | 6,000 | 900 | Modelo potente | Solo para casos complejos La idea no es que estas cifras sean correctas en todos los casos. Son restricciones iniciales deliberadamente modestas. Lo útil es que cada etapa deba justificar los tokens que utiliza. Un error habitual: si solo estableces max_tokens para la salida, la entrada puede seguir creciendo sin que lo adviertas. Los límites de salida evitan las respuestas largas; no impiden que se acumule contenido recuperado. ## Recorta el contexto antes de la recuperación, no después Muchos sistemas recuperan documentos a partir del último mensaje del usuario, pero siguen incluyendo todo el historial de la conversación en el prompt final. Eso significa que las digresiones antiguas, las llamadas fallidas anteriores a herramientas y los supuestos obsoletos permanecen en el contexto. En su lugar, mantén un estado de trabajo compacto: ``` { "user_goal": "Get refund for duplicate annual subscription charge", "known_facts": [ "User paid twice on 2025-01-08", "Invoice IDs: inv_1042 and inv_1077", "Account email: user@example.com" ], "constraints": [ "Refund policy allows duplicate-charge refunds within 90 days", "User prefers email follow-up" ], "open_questions": [ "Whether one charge has already been reversed" ], "last_updated_turn": 12 } ``` Así, tu llamada final incluye: - El estado compacto. - El último mensaje del usuario. - Solo los fragmentos relevantes de políticas recuperados. - Quizá el último intercambio de la conversación o los dos últimos, si importa mantener la continuidad del tono. No incluyas a ciegas todos los mensajes anteriores. El historial del chat no es memoria; es una transcripción. La memoria es el estado sintetizado que se necesita para continuar la tarea. En la práctica, uso tres capas: - Intercambios recientes: los últimos 1–4 intercambios, según la sensibilidad de la tarea. - Resumen acumulativo: hechos y decisiones estables. - Recuperación externa: documentos, registros de bases de datos y resultados de herramientas. Esto suele dar mejores resultados que introducir la transcripción sin procesar, porque el modelo recibe menos ruido y menos instrucciones contradictorias. ## La recuperación debe ser selectiva, no decorativa La generación aumentada por recuperación suele empezar como una mejora de calidad y acabar convirtiéndose en una fuga de tokens. El patrón de fallo es fácil de detectar: top-k se establece en 10 o 20, cada fragmento tiene 1,000 tokens y el prompt final contiene un montón de documentos vagamente relacionados. Una recuperación mejor suele ser una recuperación más barata. Un flujo práctico de recuperación: ``` def build_context(query, user_state): search_query = rewrite_for_search(query, user_state) candidates = vector_search( query=search_query, top_k=30, filters={"product": user_state["product"]} ) reranked = rerank_cross_encoder( query=search_query, docs=candidates, top_k=6 ) selected = [] token_budget = 1800 for doc in reranked: snippet = extract_relevant_span(doc.text, query=search_query, max_tokens=300) if token_count(selected) + token_count(snippet) <= token_budget: selected.append({ "doc_id": doc.id, "title": doc.title, "text": snippet }) return selected ``` Los detalles importantes: - Recupera más candidatos de los que piensas incluir. - Reordénalos por relevancia antes de la generación. - Extrae los pasajes relevantes en lugar de pasar fragmentos completos. - Aplica un presupuesto de tokens para la recuperación. - Conserva los identificadores de los documentos para que el modelo pueda citar o referenciar la evidencia internamente. El tamaño de los fragmentos importa. Si son demasiado pequeños, el modelo pierde contexto. Si son demasiado grandes, cada coincidencia arrastra texto irrelevante. Para la documentación de productos y las páginas de políticas, suelo empezar con unos 300–600 tokens por fragmento, conservando los encabezados, y después ajusto según los casos de fallo. ¿Qué ocurre realmente cuando introduces demasiado contexto recuperado? El modelo suele perder precisión. Intenta conciliar políticas próximas pero irrelevantes, incorpora salvedades obsoletas o responde a la versión equivocada de la pregunta. Reducir los tokens puede mejorar la calidad porque elimina distracciones. ## Resumir es comprimir con responsabilidad Resumir puede ahorrar grandes cantidades de contexto, pero los resúmenes descuidados son peligrosos. Si un resumen omite una restricción, tu agente puede hacer lo incorrecto con total confianza. Prefiero los resúmenes estructurados a la prosa: ``` { "task": "Debug failing OAuth callback in staging", "environment": { "service": "auth-api", "branch": "release-2025-02-14", "runtime": "node 20" }, "confirmed": [ "Callback returns 302 to /login", "Provider sends code and state", "State validation passes" ], "suspected": [ "Session cookie is not persisted after callback" ], "rejected": [ "Provider credentials are invalid", "Redirect URI mismatch" ], "next_steps": [ "Inspect Set-Cookie attributes in staging response", "Compare SameSite and Secure flags with production" ] } ``` Esto consume menos tokens y es más fiable que: El usuario está depurando OAuth y ha probado varias cosas… Un buen paso de resumen debe conservar: - El objetivo del usuario. - Los hechos concretos. - Las decisiones ya tomadas. - Las restricciones y preferencias. - Los intentos fallidos. - Las preguntas pendientes. - Los identificadores, nombres de archivo, marcas de tiempo y otras referencias exactas. No elimines los valores exactos al resumir, salvo que sean realmente irrelevantes. «El usuario tiene un problema con una factura» es barato, pero inútil. «Cargo duplicado: inv_1042 y inv_1077 el 2025-01-08» es el tipo de compresión que buscas. Para los agentes que funcionan durante periodos prolongados, también guardo versiones de los resúmenes. Si el modelo genera un mal resumen, necesitas poder inspeccionar cuándo se desvió el estado. ## Evita respuestas divagantes con esquemas Una cantidad sorprendente de tokens se desperdicia en la salida. El prompt dice «sé conciso», pero el modelo escribe un preámbulo, salvedades, una recapitulación y una oferta de ayuda. Para las salidas que consumen otros sistemas, usa esquemas. No pidas «una respuesta en JSON» sin más; define la estructura y rechaza cualquier otra cosa. Ejemplo de llamada de clasificación: ``` { "type": "object", "additionalProperties": false, "required": ["category", "priority", "needs_human", "reason"], "properties": { "category": { "type": "string", "enum": ["billing", "bug", "account", "how_to", "other"] }, "priority": { "type": "string", "enum": ["low", "normal", "high", "urgent"] }, "needs_human": { "type": "boolean" }, "reason": { "type": "string", "maxLength": 160 } } } ``` Para las respuestas dirigidas al usuario, proporciona un formato con un límite estricto: ``` Write the answer in this structure: - First sentence: direct answer, max 25 words. - Then 2-4 bullets with concrete steps. - Do not include a greeting. - Do not include "let me know if you need anything else." - Stop after the final bullet. ``` Esto funciona mejor que «sé breve» porque le da al modelo una estructura. Un problema habitual: un valor bajo de max_tokens puede truncar una salida útil a mitad de una idea. Un esquema o un formato restringido reduce la longitud de la salida sin sacrificar su integridad. El truncamiento es un último recurso, no una estrategia de formato. ## Usa las secuencias de parada con cuidado Las secuencias de parada son útiles cuando la generación tiene un límite natural. Por ejemplo, si el modelo está generando una sección de un documento basado en una plantilla, puedes detenerlo en el marcador de la siguiente sección. ``` { "model": "gpt-5.5", "messages": [ { "role": "user", "content": "Generate only the Risk Summary section for this review..." } ], "max_tokens": 500, "stop": ["\n## Mitigations", "\n## Appendix"] } ``` Las secuencias de parada son menos útiles para las respuestas abiertas del asistente porque pueden cortar contenido válido. También se comportan de manera diferente entre API y familias de modelos, especialmente cuando intervienen llamadas a herramientas o salidas estructuradas. Trátalas como mecanismos para respetar los límites, no como una técnica principal de compresión. Usos adecuados: - Generar una sección de una plantilla conocida. - Evitar que el modelo continúe con ejemplos. - Detenerse en un delimitador durante el procesamiento por lotes. - Restringir prompts antiguos de tipo completado. Usos arriesgados: - Detenerse en signos de puntuación comunes. - Detenerse en palabras que pueden aparecer en respuestas normales. - Usar secuencias de parada en lugar de un esquema de salida adecuado. - Suponer un comportamiento idéntico en Claude, GPT, Gemini y las pasarelas de modelos abiertos. ## Reparte las tareas entre modelos más económicos No todos los pasos necesitan tu modelo más potente. En los sistemas de producción, suelo asignar subtareas a modelos más pequeños o económicos: | Subtarea | Requisito habitual | Opción adecuada | Detección de idioma | Clasificación sencilla | Modelo pequeño o económico | Categoría del ticket | Salida de etiquetas estructurada | Modelo pequeño o mediano | Reformulación de consultas | Transformación breve | Modelo pequeño o mediano | Reordenación de documentos | Reordenador especializado o modelo pequeño | No generativo cuando sea posible | Respuesta final | Razonamiento y tono | Modelo más potente | Excepción a la política | Matices y riesgo | Modelo de máxima potencia Aquí es donde el acceso a varios modelos resulta útil desde el punto de vista operativo. Puedes querer Sonnet 4.6 para la mayor parte de la redacción mediante agentes, GPT-5.5 para un proceso de razonamiento complicado, Gemini 3 para determinados flujos de trabajo multimodales o de contexto largo, Fable 5 cuando realmente se necesita la ventana de contexto de 1M, y modelos abiertos como Llama, Qwen, DeepSeek, MiniMax o Kimi para tareas internas controladas. Lo importante desde el punto de vista de la ingeniería es el enrutamiento, no la fidelidad a una marca. La limitación: la sobrecarga de la orquestación es real. Cada llamada adicional a un modelo añade latencia, modos de fallo, complejidad en el registro y más aspectos que evaluar. Si un clasificador económico ahorra 300 tokens, pero añade 600 ms y otra vía de reintento, puede que no merezca la pena. Un patrón que me gusta: ``` if route == "simple_faq": model = "haiku-4.5" elif route == "standard_support": model = "sonnet-4.6" elif route == "legal_or_financial_exception": model = "opus-4.8" else: model = "sonnet-4.6" ``` Los nombres concretos cambiarán. La política debe mantenerse: usa el modelo más económico que cumpla de forma fiable el nivel de calidad exigido por la tarea. ## Mide con rigor los tokens de entrada y salida La optimización de tokens falla cuando los equipos solo observan el coste medio por solicitud. Necesitas distribuciones desglosadas por ruta y etapa. Registra al menos: - Tokens de entrada por sección del prompt. - Tokens de salida. - Cantidad de documentos recuperados y tokens de recuperación. - Nombre y versión del modelo. - Percentiles de latencia. - Tasa de aciertos de caché, si se usa caché de prompts o de contexto. - Número de reintentos. - Indicadores de calidad perceptibles para el usuario. - Tasas de escalamiento a personas o de corrección humana. Un panel útil muestra p50, p90 y p99. Los errores relacionados con los tokens suelen encontrarse en la cola de la distribución. Ejemplo de línea de registro: ``` { "route": "support.draft_answer", "model": "sonnet-4.6", "input_tokens": 3820, "output_tokens": 514, "retrieved_docs": 4, "retrieval_tokens": 1320, "latency_ms": 3100, "cache_hit": false, "quality": { "user_thumb": "up", "human_edited": false } } ``` Ten cuidado con las afirmaciones del tipo «redujimos los tokens un 40 %». ¿Aumentaron los reintentos? ¿Aumentaron los escalamientos? ¿Los usuarios hicieron más preguntas de seguimiento porque las respuestas se volvieron demasiado escuetas? ¿El modelo más económico generó más JSON no válido, lo que obligó a realizar llamadas de corrección? La métrica rigurosa no es los tokens por llamada. Es los tokens por tarea completada con éxito. ## Un contexto largo no es permiso para descuidar el trabajo Las ventanas de contexto grandes son realmente útiles. La categoría de contexto de 1M de Fable 5, las fortalezas de Gemini en contexto largo y los modos de contexto largo de los modelos más avanzados permiten flujos de trabajo que resultaban difíciles hace unos años: análisis de código de todo un repositorio, revisión de documentos extensos, transcripciones de varias horas y conjuntos densos de material de investigación. Pero el contexto largo es una capacidad, no una arquitectura predeterminada. Las llamadas con contexto largo pueden ser apropiadas cuando: - La respuesta depende de muchas partes distantes de la entrada. - La recuperación pasaría por alto relaciones entre documentos. - La tarea es exploratoria y todavía no sabes qué importa. - El coste de perder un detalle es mayor que el coste de leer más. Suelen ser un desperdicio cuando: - El usuario hace una pregunta factual muy concreta. - Unos pocos fragmentos de las fuentes son suficientes. - El contexto contiene información duplicada u obsoleta. - El modelo se está usando como filtro de base de datos. Un patrón habitual es usar contexto largo para el análisis fuera de línea y producir artefactos compactos para atender solicitudes en línea. Por ejemplo, analiza una vez un corpus completo de políticas y luego genera un mapa estructurado de políticas, embeddings, resúmenes y casos de prueba. El asistente en ejecución no debería releer todo el corpus para cada ticket. ## Un flujo de trabajo práctico de optimización Cuando me hago cargo de un sistema LLM que consume muchos tokens, suelo hacer lo siguiente en este orden: - Primero, instrumenta el sistema Añade el recuento de tokens por sección. No optimices a ciegas. - Limita el contexto de recuperación Establece un presupuesto estricto de tokens para la recuperación. Reordena los resultados y extrae fragmentos. - Sustituye la acumulación de transcripciones por un estado Conserva los turnos recientes junto con una memoria estructurada. - Restringe las salidas Usa esquemas para las salidas destinadas a otros sistemas y formatos explícitos para las dirigidas al usuario. - Enruta las subtareas Traslade la clasificación, la reescritura y la generación de resúmenes a modelos más económicos cuando sean fiables. - Evalúe la calidad a nivel de tarea Compare las resoluciones satisfactorias, no solo el coste por llamada. - Vigile la cola de la distribución Investigue los picos de tokens en p95 y p99. A menudo revelan fallos en la recuperación de información o un historial que crece sin control. Esta es una medida de protección sencilla que he utilizado en servicios: ``` TOKEN_LIMITS = { "support.classify": {"input": 800, "output": 80}, "support.retrieve": {"input": 500, "output": 0}, "support.draft": {"input": 4500, "output": 700}, "support.summarize": {"input": 1800, "output": 300}, } def assert_token_budget(route, prompt_sections, max_output_tokens): input_tokens = { name: count_tokens(text) for name, text in prompt_sections.items() } total_input = sum(input_tokens.values()) limits = TOKEN_LIMITS[route] if total_input > limits["input"]: raise TokenBudgetError(route, total_input, input_tokens) if max_output_tokens > limits["output"]: raise TokenBudgetError(route, max_output_tokens, {"output": max_output_tokens}) ``` Fallar pronto es mejor que descubrir una semana después que una consulta de recuperación defectuosa ha consumido su presupuesto en archivos PDF irrelevantes. ## Recomendaciones prácticas - La reducción de tokens debe comenzar por la visibilidad: registre los tokens de entrada y salida por sección del prompt, ruta y modelo. - La recuperación de información es mejor que acumular contenido cuando es selectiva: reordene los resultados por relevancia, extraiga fragmentos y aplique un presupuesto de contexto. - Los resúmenes deben representar un estado estructurado, no ser prosa vaga. Conserve los hechos exactos, los identificadores, las restricciones y los intentos fallidos. - Los esquemas de salida reducen las divagaciones de forma más segura que simplemente reducir max_tokens. - Las secuencias de parada son útiles para delimitar la salida, pero no sustituyen a las salidas estructuradas. - Asigne las subtareas sencillas a modelos más económicos solo cuando la latencia adicional y los modos de fallo compensen. - Evalúe el ahorro según los tokens por tarea completada con éxito, no según los tokens por llamada individual. - Los modelos de contexto largo son potentes, pero no eliminan la necesidad de una arquitectura de la información. [Inferencia](/es/blog/tag/inference/)[Prompts](/es/blog/tag/prompts/)[Modelos](/es/blog/tag/models/)[API](/es/blog/tag/api/) A [AI Prime Tech](https://aiprimetech.io/es/) AI Prime Tech publica este blog. Los artículos se redactan con asistencia de IA; comprueba los detalles específicos de cada versión, como los identificadores de modelos, los precios y los límites, en la documentación oficial antes de basarte en ellos. Obtén acceso más económico a la API de Claude Una sola clave de API para Claude Opus 5.5, Sonnet 5, Haiku 4.5 y Fable 5.1, además de GPT-6 modelos. Pago por uso, sin suscripción. [Obtén tu clave de API →](/register) AI Prime Tech es una pasarela de API independiente de terceros. Claude™ y Anthropic® son marcas comerciales de Anthropic, PBC. No se implica ninguna afiliación ni respaldo.