11 Trucos para Hacer tu Aplicación de IA Rápida

tl;dr: La mayor parte de la latencia en IA viene de la elección del modelo, la cantidad de tokens de salida y los round-trips de herramientas. Arregla eso primero - después optimiza caché, presupuestos de razonamiento y tamaño de contexto. Las mejoras se acumulan.

Hallazgos Clave

• Selección de modelo + límites de salida tienen la mejor relación impacto-esfuerzo
• Haz streaming de todo - respuestas, resultados de herramientas, datos estructurados - el usuario nunca debería quedarse mirando una pantalla en blanco
• Cada llamada a herramienta interrumpe la generación y arriesga un cache miss - diseña herramientas por caso de uso, no wrappers CRUD
• La estructura del prompt determina la tasa de cache hit - estático arriba, dinámico abajo, 80–95% de cache hits alcanzable
• Compacta agresivamente, falla rápido - resume el historial en cada turno, valida salida estructurada mid-stream, mueve todo el post-procesado a colas en segundo plano

En los últimos dos años hemos estado construyendo interfaces conversacionales de IA para nuestros clientes - y recientemente lanzamos Cuttlekit, nuestra visión del futuro de la UI generativa. Hacer que la IA se sienta rápida ha sido una prioridad máxima. Esto es lo que hemos aprendido.

1. Elige un Modelo Rápido

La elección del modelo sigue siendo la palanca de latencia más grande: empieza con el modelo más rápido que haga el trabajo de forma fiable, y escala solo cuando la calidad lo requiera.

Los modelos frontier suelen dar los mejores resultados, pero también suelen ser los más lentos. Los modelos pequeños son mucho más baratos, mucho más rápidos y a menudo suficientes para formateo, extracción, clasificación, respuestas cortas y muchas tareas de UI. Nuestro modelo de referencia actual es Gemini Flash - gran calidad a una fracción de la latencia. Aquí va un resumen de lo que hay disponible.

Modelos pequeños

Variantes de modelos fundacionales

Cada proveedor importante ofrece variantes más pequeñas y rápidas de sus modelos insignia. Sacrifican algo de profundidad de razonamiento por una latencia drásticamente menor:

• Gemini Flash / Flash Lite - excelente ratio calidad-velocidad, uno de los mejores modelos que hemos probado para aplicaciones de alto rendimiento
• OpenAI Mini & Nano models - modelos ligeros optimizados para velocidad y coste, buenos con salidas estructuradas
• Anthropic Haiku - el modelo más rápido de la familia Claude, ideal para pipelines de alto throughput

Modelos OSS rápidos

Los modelos open source suelen encajar bien para aplicaciones sensibles a la latencia. Puedes autoalojarlos para latencia mínima, usar las APIs de los propios creadores del modelo, o ejecutarlos a través de proveedores de inferencia especializados (ver más abajo). Especialmente los modelos chinos puntúan alto en benchmarks:

• Deepseek - buen razonamiento con pocos parámetros
• Qwen - familia de modelos de Alibaba, competitiva en código y tareas multilingües
• Hermes de NousResearch - fine-tuneado para seguimiento de instrucciones y function calling
• Minimax - modelos multimodales rápidos
• GLM de Zhipu AI - modelos multilingües con fuerte soporte para chino
• Mistral - modelos europeos de pesos abiertos, excelentes para despliegues alojados en la UE

Proveedores enfocados en rendimiento

Si no quieres autoalojar, estos proveedores se especializan en inferencia de baja latencia con modelos open source:

• Groq - silicio personalizado (LPUs) diseñado para inferencia; ofrece modelos Llama, Qwen y Kimi con TPS excepcional
• TogetherAI - amplio catálogo de modelos OSS con throughput competitivo y endpoints serverless
• Fireworks.ai - plataforma de inferencia optimizada con serving de baja latencia y soporte para fine-tuning
• OpenRouter - meta-router para comparar latencia y coste entre proveedores sin cambiar código

Modelos de difusión de texto

Una nueva clase de modelos que generan toda la salida de una vez en lugar de token por token, lo que los hace inherentemente más rápidos que los transformers autorregresivos. Todavía en fase temprana, pero vale la pena seguirlos:

• InceptionLabs Mercury - primer modelo de difusión de texto en producción
• Google Gemini Diffusion - la entrada de Google en la generación de texto paralela
• Bytedance Seed Diffusion - modelo de difusión de texto de Bytedance, actualmente en beta

Métrica: Tokens per second (TPS) - lo rápido que el modelo produce salida. Compara entre modelos y proveedores para encontrar tu punto óptimo velocidad/calidad.

Model Routing

No te cases con un solo modelo. Enruta las peticiones por complejidad de la tarea: usa un modelo rápido y barato para consultas simples y reserva el modelo frontier para tareas que realmente necesiten razonamiento profundo. Esto reduce la latencia media significativamente sin sacrificar calidad donde importa.

Hay varias formas de implementar routing, de simple a sofisticado:

Simple: Clasificación basada en LLM

Usa un modelo pequeño y rápido con un prompt de clasificación para decidir qué modelo maneja la petición:

System: Classify the user message as either SIMPLE or COMPLEX.
SIMPLE: greetings, factual lookups, short answers, formatting.
COMPLEX: multi-step reasoning, code generation, analysis, creative writing.
Respond with a single word: SIMPLE or COMPLEX.

Esto añade una llamada LLM rápida antes de la petición real - pero esa llamada usa un modelo pequeño con mínimos tokens de salida, así que la sobrecarga es baja.

Más inteligente: Clasificación basada en logprobs

Algunos proveedores (en particular OpenAI) exponen logprobs - la log-probabilidad que el modelo asigna a cada token de salida. En vez de generar una respuesta completa, solicita un solo token con max_tokens: 1 y logprobs: true, y compara directamente las probabilidades de tus tokens de clasificación:

// Response with logprobs
{
  "token": "SIMPLE",
  "logprob": -0.12
}

Los logprobs siempre son logaritmos naturales (base e) de probabilidades. Para convertir: e^(-0.12) ≈ 0.89, así que el modelo está 89% seguro de que la respuesta es SIMPLE. Si eso supera tu umbral, enruta al modelo rápido. Si no, usa el modelo frontier.

Esto es más rápido y barato que generar una respuesta de clasificación completa porque solo produces un token y tomas la decisión desde la distribución de probabilidad.

Avanzado: Clasificación basada en embeddings

Usa un encoder model para calcular el embedding del prompt de entrada y compáralo usando cosine similarity con embeddings precalculados de tus categorías de clasificación. No necesitas ninguna llamada a un LLM generativo en tiempo de inferencia - solo un pase de embedding más una comparación vectorial rápida.

1. Pre-calcula embeddings para prompts representativos de cada categoría
2. En tiempo de ejecución, genera el embedding del prompt entrante
3. Compara contra tus embeddings de referencia usando cosine similarity
4. Enruta según la coincidencia más cercana

Esto es extremadamente rápido porque los modelos de embedding son mucho más baratos y rápidos que los generativos, y la comparación de cosine similarity en sí es esencialmente gratuita.

Proveedores como Jina AI ya ofrecen esto como solución llave en mano - clasificación zero-shot y few-shot sin entrenar un modelo.

Más sofisticado: Clasificador fine-tuneado

Para máxima precisión, fine-tunea un modelo de clasificación pequeño apilando una capa densa sobre un encoder model pre-entrenado. Lo entrenas con ejemplos etiquetados de tu tráfico real, así que el clasificador aprende tus patrones de routing específicos.

Buenos modelos base para esto:

• EmbeddingGemma - modelo de embedding de Google basado en Gemma 3
• Jina AI Embeddings - modelos de embedding multilingües diseñados para clasificación y retrieval
• Mixedbread Embeddings - modelos de embedding de alta calidad con buenos resultados en benchmarks

Esto te da un clasificador de sub-milisegundo que corre en CPU con precisión casi perfecta para tu carga de trabajo - pero requiere datos de entrenamiento etiquetados y un paso de entrenamiento previo.

2. Minimiza los Tokens de Salida

Los tokens de salida son la parte más costosa computacionalmente de la inferencia. Por eso la mayoría de proveedores cobran 2–4x más por tokens de salida que por tokens de entrada. Cada token que el modelo no genera es tiempo ahorrado, dinero ahorrado y latencia reducida.

Salida estructurada: optimiza tu esquema

Para salida estructurada (JSON, function calls), tu esquema de salida determina directamente la cantidad de tokens. Nombres de atributos más cortos y valores compactos significan menos tokens. Usa el Tokenizer Playground para comprobar cómo se tokeniza tu esquema - la diferencia puede ser significativa:

15% menos tokens por elemento - y eso se acumula rápido cuando estás transmitiendo cientos de resultados. Siempre puedes mapear la salida compacta del LLM a tu esquema de dominio completo en un paso de post-procesado. El modelo no necesita claves legibles para humanos - tu código sí. Cada token no generado es un buen token.

Generación de texto: instruye para brevedad

Para respuestas de texto, sé explícito en tu system prompt:

Answer in 1–2 sentences max. No preamble, no filler, no "Sure! Here's...".
Skip summaries and recaps. Lead with the answer.
If a list, use short bullet points, not paragraphs.

Métrica: Number of output tokens (NOT) - tokens totales generados por respuesta. Haz seguimiento en todos tus prompts y optimiza primero los peores casos.

3. Haz Streaming de Todo

Streaming es el estándar de la industria - los usuarios lo esperan. No reduce el tiempo total de generación, pero mejora drásticamente la velocidad percibida porque los usuarios empiezan a leer mientras el modelo genera. Un TTFT de 200–400ms se siente instantáneo; una espera de 3 segundos en blanco se siente rota.

Para salida estructurada, usa JSONL - un elemento por línea en vez de un array JSON completo. Elementos de tareas, filas de tabla, resultados de búsqueda - cada uno se renderiza en cuanto se genera, sin esperar al corchete de cierre.

Haz streaming también de la salida de las llamadas a herramientas. Cuando tu agente invoca otro LLM - un resumidor, un sub-agente - esa llamada interna debería hacer streaming de vuelta al usuario. De lo contrario: streaming rápido al inicio, pausa muerta durante la ejecución de la herramienta, y después más texto. Haz streaming de toda la cadena, no solo del modelo exterior.

Métrica: Time to first token (TTFT) - cuánto tarda el usuario en ver la primera salida. Streaming no cambia el tiempo total, pero reduce el TTFT a casi cero.

4. Mantén tu Superficie de Herramientas Pequeña

Cada llamada a herramienta interrumpe la generación - el AI SDK gestiona la llamada, ejecuta la herramienta y alimenta el resultado de vuelta a la siguiente llamada LLM. Cada round-trip añade latencia, y si hay un cache miss (diferente máquina, caché expirada), se recalcula todo el contexto. Minimiza el número de llamadas a herramientas.

Diseña herramientas por caso de uso, no CRUD

No expongas tu API REST tal cual al modelo. Diseña herramientas en torno a lo que la IA necesita lograr, no tu estructura de datos:

Reglas para la salida de herramientas:

• Devuelve solo los datos que la IA necesita para la tarea actual - nunca dumps crudos de la API
• Pagina los resultados - no devuelvas 500 elementos cuando la IA necesita 5
• Pre-formatea los datos en la herramienta - cantidades monetarias, fechas, traducciones - para que la IA no gaste tokens convirtiéndolos

MCP: vigila tu presupuesto de tokens

MCP (Model Context Protocol) puede ser un sumidero masivo de tokens. El coste se acumula desde múltiples ángulos:

• Tamaño del esquema - cada definición de herramienta se inyecta en el prompt
• Cantidad de herramientas - una sola conexión MCP carga todas sus herramientas, no solo las que necesitas
• Overhead de serialización - MCP añade wrapping a nivel de protocolo en cada llamada y resultado
• Tamaño del payload de resultados - las herramientas MCP suelen devolver más datos de los que el modelo necesita

Múltiples proveedores MCP pueden añadir fácilmente decenas de miles de tokens a cada petición. Para producción, prefiere integraciones directas de herramientas donde controles exactamente qué herramientas se exponen y cuántos datos devuelven. Usa MCP para desarrollo y prototipado.

Ejecución de código en sandboxes

La industria se está moviendo de arquitecturas pesadas en herramientas hacia dejar que el LLM escriba y ejecute código en un entorno sandbox. En vez de 10 herramientas especializadas, dale al modelo un sandbox de código y unos pocos SDKs - él escribe la integración. Anthropic fue pionero en este enfoque y demostró una reducción de tokens de hasta el 98.7% comparado con cadenas de herramientas MCP equivalentes.

Proveedores SaaS de sandbox:

• E2B - microVMs Firecracker con ~150ms de arranque, SDKs para Python/JS
• Daytona - sandboxes basados en Docker con ~90ms de arranque
• Vercel Sandbox - microVMs efímeras integradas con el Vercel AI SDK
• Cloudflare Workers - sandboxing basado en isolates V8, cold starts extremadamente rápidos

Self-hosted / OSS:

• Boxlite - sandbox de micro-VM local-first, sin daemon necesario
• Microsandbox - sandbox de microVM self-hosted construido en Rust, arranque sub-200ms

Usa Python o TypeScript - los LLMs los conocen bien y no requieren pasos de compilación que ralentizarían el loop de interacción.

Métrica: Tool call overhead - número de round-trips y tokens totales consumidos por definiciones de herramientas y resultados por petición. Menos herramientas, resultados más ligeros, respuestas más rápidas.

5. Optimiza para Prompt Caching

Prompt caching es una de las optimizaciones de latencia con mayor impacto. Los proveedores cachean el estado KV (los cálculos internos) del prefijo de tu prompt. En la siguiente petición, si el prefijo coincide, esos cálculos se saltan por completo. Los tokens cacheados se procesan a una fracción del coste y latencia de los tokens frescos.

Soporte por proveedor

No todos los proveedores manejan el caching igual:

• OpenAI - automático, sin opt-in. Mínimo 1,024 tokens de prefijo.
• Anthropic - opt-in vía breakpoints cache_control en la petición API. Mínimo 1,024 tokens (Sonnet/Haiku), 2,048 (Opus).
• Google Gemini - opt-in vía recursos explícitos de “cached content”. Umbral más alto: mínimo 32,768 tokens.
• Groq - automático, se aplica a prefijos repetidos. Buena documentación introductoria.

Cómo maximizar la tasa de cache hit

Estructura tu prompt de más estático a más dinámico. La caché coincide desde arriba - en el momento en que algo cambia, todo lo que sigue es un cache miss.

1. System prompt (estático) - instrucciones, formato de salida, definiciones de herramientas. Esto nunca cambia entre peticiones y siempre debería ir arriba.
2. Documentos (semi-dinámico) - base de conocimiento, datos de referencia, contexto recuperado. Cambia ocasionalmente.
3. Historial (semi-dinámico) - turnos de conversación. Crece pero el prefijo se mantiene estable.
4. Mensaje del usuario (dinámico) - la petición actual. Siempre al final.

Evita poner contenido dinámico en tu system prompt. Un error común: inyectar un timestamp como "Current time: 2026-04-01T19:45:00Z" en el mensaje de sistema. Esto invalida toda la caché en cada petición porque el prefijo cambia. Si necesitas la hora actual, ponla en el mensaje del usuario al final.

Precalienta la caché - envía una petición de preparación al inicio de la sesión (por ejemplo, con un mensaje de usuario vacío) para que la primera interacción real ya encuentre una caché caliente.

Métrica: Cache hit rate - porcentaje de tokens de entrada servidos desde caché. Monitoriza esto en el dashboard de tu proveedor. Un prompt bien estructurado puede lograr 80–95% de cache hit rates en aplicaciones conversacionales.

6. Desactiva (o Reduce) el Razonamiento

El razonamiento extendido puede mejorar mucho la calidad de la salida - pero a costa de latencia. El razonamiento ahora está activado por defecto en la mayoría de modelos fundacionales - si no lo has configurado, estás pagando este impuesto de latencia en cada petición.

Desactiva el razonamiento para tareas simples, o establece un presupuesto de tokens ajustado para tareas que se benefician de algo de razonamiento. Ten en cuenta que algunos modelos (p.ej. Gemini 2.5 Pro) no permiten desactivar el razonamiento completamente - solo puedes reducir el presupuesto. Prueba dónde la calidad cae por debajo de lo aceptable para tu caso de uso. También puedes combinar esto con la técnica de model routing de la sección 1 - usa un clasificador para ajustar dinámicamente el presupuesto de razonamiento por petición, enrutando consultas simples con razonamiento desactivado y complejas con un presupuesto mayor.

Configuración por proveedor

• OpenAI - parámetro reasoning_effort: low, medium, high. Pon low o desactívalo para tareas simples. También soporta max_completion_tokens para limitar la salida total incluyendo razonamiento.
• Anthropic - parámetro thinking con budget_tokens configurable. Pon type: "disabled" para desactivarlo, o un presupuesto bajo (p.ej. 1024 tokens) para razonamiento ligero.
• Google Gemini - thinking_config con thinking_budget. Pon 0 para desactivar, o limita la cantidad de tokens.

Métrica: Number of thinking tokens (NTT) - tokens gastados en razonamiento antes del primer token de salida. Monitoriza esto - suele ser el mayor contribuyente al TTFT en modelos modernos.

7. Compactación Agresiva de Memoria

No necesitas guardar el historial exacto de la conversación - un resumen compacto suele ser suficiente. Los LLMs tienden a generar respuestas largas, y esas respuestas pasan a formar parte del contexto de cada petición subsiguiente. Una conversación de 6 turnos puede fácilmente llegar a 1,000+ tokens de historial, la mayoría redundantes.

Compacta la conversación después de cada interacción - resume el intercambio y reemplaza el historial completo. Ejecuta la compactación de forma asíncrona después de la respuesta para no bloquear al usuario, usando un modelo rápido y barato. Los resultados de llamadas a herramientas suelen ser los peores - trúncalos agresivamente.

Lo que debe sobrevivir a la compactación: objetivos del usuario, restricciones activas, entidades referenciadas, tareas pendientes y preferencias. Una sumarización con pérdida que descarte esto degradará la calidad silenciosamente. Tu prompt de compactación debería preservarlos explícitamente.

Algunos proveedores ya soportan esto de serie - consulta la API de compactación de Anthropic y su cookbook de memoria de sesión.

Esto puede reducir las tasas de cache hit, pero procesar menos tokens suele pesar más que el cache miss - especialmente cuando cambiar el historial de conversación causaría un miss de todas formas.

Métrica: Average context length (ACL) - promedio de tokens del prompt completo a través de las peticiones. Si crece con el tiempo, compacta más agresivamente.

8. Sé un Cavernícola

Menos tokens de entrada = menos procesamiento = respuesta más rápida. Esto aplica a tu system prompt (donde vive la mayor parte del bloat) y las partes del prompt orientadas al usuario. Elimina palabras de relleno, lenguaje florido, ejemplos excesivos e instrucciones duplicadas. Los LLMs son sorprendentemente buenos entendiendo prompts comprimidos.

Caveman compression es un framework práctico para esto. La idea central: elimina artículos, conectores y calificadores redundantes - quédate solo con las palabras que llevan significado. “You are a helpful assistant that should always provide” se convierte en “Provide”. Feo, efectivo.

No lo hagas a ciegas: la compresión agresiva funciona mejor para scaffolding de instrucciones repetitivo, pero ten cuidado con reglas de seguridad, manejo de edge-cases y cualquier cosa donde la precisión de la redacción importe.

Verifica con embeddings

¿Cómo sabes que tu prompt comprimido sigue transmitiendo la misma información? Usa un modelo de embedding para comparar la similitud semántica entre la versión original y la comprimida. Genera embeddings de ambos prompts (o de oraciones/párrafos individuales) y calcula cosine similarity - si está por encima de 0.95, no has perdido significado. Esto te permite comprimir agresivamente con confianza.

Métrica: Number of input tokens (NIT) - tokens de entrada totales por petición. Audita tu system prompt regularmente - tiende a crecer con el tiempo a medida que se acumulan instrucciones.

9. Mueve el Trabajo Costoso a Colas en Segundo Plano

Mantén el loop de interacción principal corto. Solo la respuesta debería bloquear al usuario. Llamadas a herramientas de larga duración y cualquier post-procesado deberían sacarse del loop principal a una cola en segundo plano.

Si una herramienta realiza una operación con side-effects (escritura en BD, llamada API), hazla async - confirma inmediatamente, ejecuta en segundo plano. Post-procesado como compactación de memoria, actualizaciones de embeddings, analytics y logging van todos a la cola. Lanza tareas independientes en paralelo, no secuencialmente.

10. Falla Rápido y Reintenta

Cuando generas salida estructurada para conducir una UI - conversacional, agéntica o generativa - el LLM puede producir datos inválidos que rompen cosas. No esperes a que se genere la respuesta completa para validar. Valida cada fragmento estructurado conforme llega en el stream. En el momento en que algo inválido aparece, detén el stream inmediatamente y reintenta. No tiene sentido generar cientos de tokens más de una respuesta rota.

En la práctica: parsea cada línea JSONL o fragmento estructurado conforme llega y valida contra tu esquema. En cuanto un fragmento falla, aborta el stream, añade el error al prompt (para que el modelo aprenda del error), y reintenta. Esto es más rápido que generar una respuesta rota completa y regenerar desde cero.

11. Almacena en Buffer las Peticiones Rápidas

Esto es más relevante para copilots de IDE, editores en tiempo real y UIs que cambian rápidamente donde los usuarios lanzan múltiples inputs en rápida sucesión. Menos aplicable a chat estándar o flujos transaccionales.

Almacena las peticiones entrantes en una cola y agrúpalas en una única llamada LLM en vez de procesar cada una secuencialmente.

Si una nueva petición reemplaza la actual, considera cancelar la generación en curso - puede que no merezca la pena terminar una respuesta obsoleta. Avanzado: usa las interrupciones de llamadas a herramientas como checkpoints - cada llamada a herramienta pausa la generación, dándote un momento natural para revisar la cola en busca de nuevos mensajes. Este es el patrón que usa Cursor.

Los once trucos son aplicables hoy, y la mayoría se pueden adoptar de forma incremental. No los apliques todos a la vez: identifica la parte más lenta de tu loop de interacción y arregla esa primero.

Si estás construyendo interfaces de IA y quieres discutir cualquiera de estos trade-offs - escríbenos.