LLM en tiempo real en GPUs comunes

Si estás construyendo un producto con LLM, seguramente ya viste el mismo patrón: la demo funciona, pero cuando intentas llevarla a producción aparecen tres fricciones muy concretas. La primera es el costo por token. La segunda es la latencia, sobre todo cuando varios usuarios piden respuestas largas al mismo tiempo. La tercera es la dependencia de GPUs caras o de infraestructura que no encaja bien con un equipo de producto que necesita iterar rápido.

La buena noticia es que no siempre necesitas hardware exótico para tener inferencia en tiempo real. Hay enfoques que permiten correr modelos grandes en GPUs comunes y acercarte a tasas de procesamiento que antes parecían reservadas para clusters más pesados. El ángulo práctico aquí no es solo técnico: si puedes servir más tokens por segundo por request, cambias tu costo unitario, reduces cola, y abres opciones para despliegues locales o híbridos en empresas que no quieren mandar todo a una nube pública.

Qué significa inferencia en tiempo real de verdad

Cuando hablamos de inferencia en tiempo real, no estamos hablando de “rápido” en abstracto. Estamos hablando de una experiencia donde el usuario empieza a ver tokens en menos de 1 segundo, y el sistema mantiene un ritmo suficiente para que la conversación, el autocomplete o el agente no se sientan trabados. En productos internos, eso puede ser la diferencia entre una herramienta que el equipo adopta y una que termina abandonada.

La métrica que importa no es solo el tiempo total de respuesta. También importa el throughput por request, medido en tokens por segundo, porque eso determina cuántos usuarios puedes atender en paralelo con la misma GPU. Si un sistema logra miles de tokens por segundo por request, no solo mejora la percepción de velocidad. También mejora la eficiencia de uso del hardware, que es donde realmente se gana o se pierde dinero.

Latencia, throughput y experiencia de usuario

Hay tres números que conviene separar:

1. Time to first token: cuánto tarda en aparecer el primer token.
2. Tokens por segundo: cuán rápido avanza la respuesta una vez que empezó.
3. P95 de latencia: cuánto tarda el sistema en el peor 5% de los casos, que es donde se rompe la experiencia.

Si tu app de soporte responde en 300 ms al primer token pero luego entrega a 6 tokens por segundo, el usuario siente que el sistema piensa demasiado. Si en cambio arrancas rápido y sostienes un flujo alto, puedes ocultar parte de la complejidad del modelo. Esto es especialmente útil en interfaces tipo chat, redacción asistida y agentes que hacen varias llamadas encadenadas.

La inferencia en tiempo real también cambia la arquitectura del producto. Ya no diseñas solo para “responder”, sino para “responder mientras el usuario sigue trabajando”. Eso abre espacio para streaming, cancelación de requests, prefetched context y UX más parecida a un copiloto que a un formulario tradicional.

Por qué 3k tokens por segundo por request importa

La cifra de 3.000 tokens por segundo por request suena extrema, pero su valor real no está en el número aislado. Lo que importa es lo que representa para la capacidad total del sistema. Si tu GPU puede servir un request muy pesado sin degradar tanto el rendimiento, puedes consolidar más tráfico en menos nodos.

En un equipo de producto, eso se traduce en algo muy concreto: menos instancias, menos complejidad operativa y menos dependencia de una sola clase de hardware premium. En LatAm, donde el costo de infraestructura y la disponibilidad de ciertas GPUs puede variar bastante por país y proveedor, esto no es un detalle menor. También te da más margen para probar despliegues on-premise o en una nube local sin que el presupuesto se dispare.

Qué cambia cuando usas GPUs comunes

Cuando hablamos de GPUs comunes, hablamos de hardware que sí puedes conseguir sin entrar en una cadena de suministro rara: tarjetas de gama media o alta usadas en estaciones de trabajo, servidores compactos o nodos de cloud estándar. No estamos hablando necesariamente de los modelos más caros del mercado. El punto es que la inferencia eficiente reduce la necesidad de comprar lo más premium para tener una experiencia aceptable.

Esto tiene impacto directo en tres frentes. Primero, el costo inicial de entrada. Segundo, el costo operativo mensual. Tercero, la velocidad con la que tu equipo puede experimentar con modelos, cuantización y serving stack sin esperar a un cluster ideal que quizá nunca llega.

Costo total de propiedad

El costo total de propiedad no es solo el precio de la tarjeta. Incluye energía, refrigeración, tiempo de operación, observabilidad y, sobre todo, el número de GPUs que necesitas para atender una carga dada. Si puedes aumentar el throughput por request, reduces la cantidad de hardware necesario para el mismo SLA.

En productos con tráfico variable, eso es clave. No necesitas sobredimensionar para el pico si puedes escalar mejor con menos nodos y una cola más controlada. Para un equipo pequeño, pasar de depender de 4 o 5 GPUs caras a 1 o 2 GPUs estándar bien aprovechadas puede ser la diferencia entre lanzar o posponer el producto.

Despliegue local e híbrido

Hay casos donde la nube pública no es la mejor respuesta. Si trabajas con datos sensibles, clientes corporativos o entornos regulados, un despliegue local o híbrido puede ser más atractivo. También ayuda cuando el costo de egreso, la latencia de red o la soberanía de datos complican el uso de un endpoint externo.

Con inferencia de alto rendimiento en GPUs comunes, puedes plantear una arquitectura híbrida más realista: parte del tráfico va a un modelo local para tareas frecuentes o sensibles, y otra parte se deriva a un endpoint externo para picos o casos complejos. Eso te permite segmentar por costo y por riesgo, en lugar de tratar todo igual.

Cómo se logra ese rendimiento

El salto de rendimiento no suele venir de una sola magia. Normalmente sale de combinar varias optimizaciones: batching eficiente, kernels más rápidos, cuantización, cachés mejor gestionadas y un serving stack que no desperdicie ciclos. Si una pieza falla, el resto no compensa del todo.

La idea central es simple: una GPU común puede hacer mucho más de lo que parece si evitas trabajo innecesario. En vez de gastar memoria y compute en operaciones redundantes, reduces overhead y dejas que la tarjeta se concentre en lo que importa, que es generar tokens.

Batching, KV cache y scheduling

El batching es uno de los multiplicadores más obvios. Si agrupas requests compatibles, aprovechas mejor la GPU. Pero batching mal hecho también puede subir la latencia del primer token, así que no se trata de meter todo junto sin criterio.

La KV cache también pesa mucho. Reutilizar estados intermedios evita recalcular contexto completo en cada paso, algo que se vuelve crítico cuando el prompt crece. Y el scheduling de requests, especialmente en sistemas multiusuario, define si tu servidor se comporta como una autopista o como un embudo.

Cuantización y precisión práctica

La cuantización reduce memoria y puede mejorar el throughput, aunque siempre con trade-offs. En la práctica, muchos equipos terminan probando 8-bit o 4-bit para acomodar modelos más grandes en hardware más accesible. Lo importante es medir si la pérdida de precisión afecta tu caso de uso real, no solo un benchmark aislado.

Para clasificación, extracción o asistencia interna, una ligera caída de calidad puede ser aceptable si a cambio duplicas la capacidad o reduces drásticamente el costo. Para tareas críticas, quizá prefieras más precisión y menos agresividad. La decisión no es ideológica, es de producto.

Stack de serving y ejecución

El serving stack también importa. No es lo mismo correr un modelo en un script que servirlo con un runtime optimizado para baja latencia, colas y streaming. Si el stack maneja bien el scheduling y la memoria, puedes sacar mucho más partido de la misma GPU.

La documentación oficial de proyectos como vLLM explica varias de estas técnicas de serving y optimización para inferencia eficiente: https://docs.vllm.ai/ . También vale la pena revisar las guías de PyTorch para optimización de inferencia, especialmente si vas a integrar tu propio pipeline: https://pytorch.org/docs/stable/torch.compiler.html .

Qué deberías medir antes de llevarlo a producción

No te quedes con una demo que responde bien en una sola máquina y con un solo usuario. Antes de producción, necesitas medir el sistema bajo carga realista. Eso incluye prompts largos, requests concurrentes, cancelaciones, variación en longitud de salida y picos de tráfico.

La evaluación correcta no solo te dice si el modelo “funciona”. Te dice cuánto cuesta cada interacción, dónde se rompe la latencia y cuánta holgura tienes antes de necesitar otra GPU. Esa información es la que te permite decidir si el despliegue local o híbrido tiene sentido.

Métricas mínimas para tu tablero

Estas son las métricas que yo pondría primero:

• Time to first token en ms, con percentiles P50, P95 y P99.
• Tokens por segundo por request, no solo promedio global.
• Utilización de GPU y memoria usada.
• Longitud media y p95 de prompt.
• Costo estimado por 1.000 tokens.
• Tasa de errores por timeout o OOM.

Si tu tablero no te muestra al menos eso, estás volando a ciegas. Y cuando una GPU se llena, los síntomas suelen aparecer tarde: primero sube la cola, luego crece la latencia, después llegan los timeouts.

Prueba de carga realista

Un buen test no usa solo prompts cortos. Debería incluir escenarios como estos:

Si el sistema aguanta bien en el caso fácil pero cae en prompts largos, no estás listo. En producción, el comportamiento raro es el comportamiento normal.

Implicaciones para equipos de producto en LatAm

En LatAm, la discusión sobre LLM no se parece tanto a la de Silicon Valley. Acá el presupuesto, la conectividad, la disponibilidad de hardware y la cercanía con los datos pesan más. Por eso una estrategia que funcione en GPUs comunes puede ser mucho más útil que una arquitectura idealizada que solo vive en benchmarks.

Si trabajas en Ecuador, México, Colombia, Chile o Perú, seguramente ya viste que el costo de operar infraestructura de IA puede volverse un problema antes de que el producto encuentre tracción. Tener una opción de inferencia local o híbrida te da margen para validar en clientes reales sin quemar presupuesto demasiado pronto.

Casos de uso donde sí vale la pena

Hay escenarios donde este enfoque encaja especialmente bien:

• Asistentes internos para ventas, soporte o legal.
• Búsqueda semántica con respuesta generada sobre documentos privados.
• Copilotos de CRM o ERP con datos sensibles.
• Automatización de back office donde la latencia importa, pero no necesitas un modelo gigantesco para cada paso.

En estos casos, el objetivo no es presumir un benchmark. El objetivo es que el equipo use la herramienta todos los días sin pelear con tiempos de espera ni con tickets de infraestructura.

Decisión local, nube o híbrido

Una forma práctica de decidir es esta: si tus datos son sensibles, tu latencia es crítica y tu carga es relativamente predecible, el despliegue local gana puntos. Si tu carga es muy variable y todavía estás explorando producto, la nube te da flexibilidad. Si tienes ambas cosas, el híbrido suele ser el punto medio más sensato.

La clave es que el serving eficiente en GPUs comunes baja la barrera para cualquiera de las tres opciones. Ya no dependes de una apuesta única por hardware caro. Puedes empezar pequeño, medir, y mover tráfico según costo y necesidad.

Cómo aterrizarlo en tu equipo

Si quieres llevar esto a un producto real, no empieces por comprar hardware. Empieza por definir la carga y el SLA. Necesitas saber cuántos usuarios concurrentes esperas, qué longitud promedio tienen los prompts y qué nivel de latencia tolera tu caso de uso.

Después arma un piloto pequeño con observabilidad desde el día uno. Si no puedes medir tokens por segundo, memoria, cola y errores, no vas a saber si la optimización funcionó o solo se sintió mejor en una demo.

Plan de implementación en 5 pasos

1. Define el caso de uso: chat, extracción, clasificación o agente.
2. Mide la carga real: longitud de prompt, salida y concurrencia esperada.
3. Elige un stack de serving optimizado: revisa documentación oficial y evita improvisar en producción.
4. Prueba cuantización y batching: compara latencia, calidad y costo.
5. Instrumenta todo: time to first token, throughput, memoria y errores.

Si tu equipo es pequeño, este plan te evita dos errores comunes: sobrecomprar infraestructura y subestimar el costo del mantenimiento. Ambos salen caros.

Qué no hacer

No diseñes el sistema solo para el benchmark más favorable. Tampoco asumas que un modelo más grande siempre dará mejor producto. Muchas veces el cuello de botella no es la capacidad del modelo, sino la forma en que sirves la inferencia.

También conviene no mezclar demasiadas optimizaciones al mismo tiempo. Si cambias modelo, cuantización, runtime y esquema de batching en una sola iteración, luego no sabrás qué mejoró y qué empeoró. Mejor avanzar por etapas y registrar cada cambio.

Tabla resumen

Si tu equipo de producto está evaluando LLM, la pregunta no es solo qué modelo usar. La pregunta real es cómo servirlo con una arquitectura que no te obligue a gastar de más para obtener una experiencia usable. Ahí es donde las GPUs comunes, bien optimizadas, dejan de ser una opción secundaria y pasan a ser una base seria para producir.