BLOG | OFICINA DEL CTO

IA, inferencia y tokens, ¡vaya combinación!

Miniatura de Lori MacVittie
Lori MacVittie
Publicado el 16 de octubre de 2025

Muy bien, chicos, paren ya. Oigo palabras como "tokens" y "modelos" usadas como jerga de la Generación Z en un video de TikTok, y casi siempre se usan mal. 

Dije lo que dije. 

Ya es momento de explicar cómo construimos aplicaciones basadas en inferencias, dónde creamos y consumimos los tokens, y cómo encajan todas las piezas del rompecabezas. Pon un café y entremos de lleno. 

¿Qué es un servidor de inferencias?

No tendría que empezar por aquí, pero voy a hacerlo. Cuando hablamos de “inferencia”, nos referimos a cómo un modelo de lenguaje extenso (LLM) analiza y procesa su enorme volumen de datos. Tú no llamas directamente a un LLM. No existe algo como una “API para LLM”, y te lanzaré una “mirada de madre” si dices eso. 

Las API que usas para invocar la inferencia pasan, espera, por un servidor de inferencia. 

Los servidores de inferencia ejecutan modelos de IA, tal como los servidores de aplicaciones ejecutan Java y muchos otros lenguajes de desarrollo. Normalmente, no se ejecuta un modelo localmente sin un servidor de inferencia. Entre las opciones más populares están Ollama, vLLM, NVIDIA Triton y HuggingFace Text Generation Interface (TGI). 

Ahora, al igual que en los servidores de aplicaciones, donde normalmente despliegas un paquete de aplicaciones, despliegas un “paquete de IA” (un modelo) en un servidor de inferencia. El servidor sirve para ofrecer las capacidades del modelo de IA a través de una API con un conjunto reducido de puntos finales (por ejemplo, /generate, /completions o /embeddings en REST o gRPC) centrados en tareas de inferencia del modelo como generación de texto, tokenización o embeddings.

Para interactuar con un servidor de inferencia, se crea una aplicación. Sí, una aplicação tradicional (que podría ser moderna, claro está) que se comunicará con el servidor de inferencia. 

Los usuarios también cuentan con una app, ya sea en el navegador o en el móvil, que suele utilizar una API común y sencilla para comunicarse con la app que has creado. ¡Y listo! Cuentas con un flujo completo de mensajes desde el cliente a la app, al servidor de inferencia y de vuelta. 

Sí, es simplemente una nueva versión del modelo de tres niveles para aplicaciones web, cambiando la capa de datos por una capa de inferencia. Lo sé, es bastante decepcionante, ¿verdad? 

Diagrama de flujo de la aplicación AI

La forma más sencilla de una aplicación de IA es una aplicación web de tres capas en la que el nivel de datos se sustituye por un servidor de inferencia.

  1. Recibes una solicitud JSON, optas por usar generación aumentada por recuperación (RAG) y luego llamas al servidor de inferencia con JSON. RAG significa normalmente crear una representación vectorial de la consulta, buscar contenido similar en un índice vectorial o de búsqueda, y combinar esos fragmentos en el prompt. Todo eso sigue siendo tráfico en formato JSON. Aún no se han generado tokens del modelo.
  2. El servidor de inferencia analiza el JSON y divide el texto en tokens del modelo, comprueba el contexto y las cuotas, agrupa las solicitudes compatibles, ejecuta el modelo y luego decodifica los tokens de salida de nuevo a texto. Devuelve una respuesta JSON al solicitante. Si se transmite, los tokens se decodifican y envían conforme se generan. La mayoría de las API también incluyen un bloque de uso con el conteo de tokens de entrada y salida.

Eso es inferencia. Es simplemente un nuevo tipo de carga de trabajo de aplicación que premia la misma disciplina operativa que siempre hemos valorado, pero ahora expresada en tokens, contexto y flujos en lugar de sesiones, cookies y consultas.

¿Dónde están los tokens, exactamente?

Aquí es donde suele haber confusión y se usan términos que incumplen la Directiva Principal de la terminología. Los tokens son unidades de palabras que procesa un LLM. Un tokenizador, en el servidor de inferencia, los genera oficialmente. 

Puedes incorporar un tokenizador en tu aplicación para contar tokens de antemano, facilitando la predicción de costos y los límites locales de tasa, aunque el recuento definitivo de tokens se realiza en la pila de inferencia. Los tokens representan el modelo, no el tráfico de red; la transmisión usa texto JSON. Solo verás los ID de tokens si la API los entrega explícitamente. 

Por defecto, la infraestructura no ve los tokens. Solo ve JSON. Los tokens no circulan por la red. Si quieres que la infraestructura actúe sobre los tokens, debes contarlos en el gateway con el mismo tokenizador o utilizar los conteos que emite el servidor modelo. Los tokens son la moneda de la IA, pero permanecen dentro de la pila de inferencia a menos que los hagas visibles. 

La implicación de la inferencia en la infraestructura

La inferencia no es algo místico. Es una carga de trabajo de aplicación con nuevos controles. El tráfico es JSON. Los tokens son unidades del modelo. Las incrustaciones son vectores. Si mezclas esos conceptos, diseñarás controles incorrectos, establecerás precios inadecuados y diagnosticarás la capa equivocada. Por ejemplo, enrutar según el tamaño de JSON en lugar del conteo de tokens puede sobrecargar un modelo con solicitudes de contexto largo. 

Si quieres que la infraestructura actúe sobre tokens, enséñale cómo hacerlo. Coloca un tokenizador en la puerta de enlace o utiliza los conteos que el servidor modelo emite. Si no, tus enrutadores solo ven texto, no tokens, y tomarán decisiones a nivel de texto mientras tus costes se acumulan a nivel de token. Recuerda que el tokenizador debe coincidir con el del modelo (por ejemplo, el tokenizador de GPT-4 es distinto al de LLaMA) para asegurar un conteo correcto. Un tokenizador que no coincida puede provocar cálculos erróneos de costes o límites.

Considera la disponibilidad como útil y fiable, no solo como activa. Controla los tokens por segundo, el tiempo hasta el primer token y errores de contexto (como superar los límites de la ventana de contexto o salidas incoherentes por saturación) igual que controlabas las consultas por segundo y los aciertos en la caché. Registra todo con seriedad. El tráfico de inferencia no equivale a datos de entrenamiento a menos que lo especifiques. Si guardas indicaciones y resultados, protégelos.

Nombra las cosas correctamente. Mide la capa adecuada. Establece límites donde importan, como cuotas basadas en tokens en la puerta de enlace para evitar gastos excesivos. Haz eso y la inferencia funcionará como el resto de tu sistema: predecible, asequible y sencilla en el mejor sentido. Los tokens compran decisiones dentro del modelo, no el ancho de banda de tu red. Llama a las cosas por su nombre para mantener a tus usuarios satisfechos y tus facturas bajas.