Vale, chicos, parad ahora mismo. No paro de oír términos como «tokens» y «modelos» usados como si fueran jerga de la generación Z en un vídeo de TikTok, y la mayoría de las veces se emplean de forma totalmente incorrecta.
He dicho lo que he dicho.
Ya va siendo hora de explicar cómo se crean las aplicaciones basadas en inferencia, dónde se generan y consumen los tokens y cómo encajan las distintas piezas del rompecabezas. Así que prepárate un café y entremos de lleno en materia.
¿Qué es un servidor de inferencia?
No debería tener que empezar por aquí, pero lo haré. Cuando hablamos de «inferencia», nos referimos en realidad a la forma en que un modelo de lenguaje de gran tamaño (LLM) razona a partir de su ingente cantidad de datos. No se llama directamente a un LLM. En realidad, no existe tal cosa como una «API de LLM», y te echaré «la mirada de madre» si dices eso.
Las API utilizadas para invocar la inferencia pasan, agárrate, por un servidor de inferencia.
Los servidores de inferencia son entornos de ejecución para modelos de IA, del mismo modo que los servidores de aplicaciones lo son para Java y muchos otros lenguajes de desarrollo. Por lo general, no se ejecuta un modelo localmente sin un servidor de inferencia. Entre las opciones más populares se encuentran Ollama, vLLM, NVIDIA Triton y HuggingFace Text Generation Interface (TGI).
Ahora, al igual que en los servidores de aplicaciones —en los que normalmente se despliega un paquete de aplicación—, en un servidor de inferencia se despliega un «paquete de IA» (un modelo). El servidor proporciona las capacidades del modelo de IA mediante una API con un conjunto mínimo de endpoints (por ejemplo, /generate, /completions o /embeddings en REST o gRPC), centrados en tareas de inferencia del modelo como la generación de texto, la tokenización o los embeddings.
Para interactuar con un servidor de inferencia, creas una aplicación. Sí, una aplicación tradicional (que podría ser moderna porque, por supuesto, podría serlo) y esta se comunicará con el servidor de inferencia.
Los usuarios también disponen de una aplicación, ya sea en un navegador o en un teléfono, que normalmente utiliza una API de toda la vida para comunicarse con la aplicación que has creado. ¡Y voilà! Ya tienes un flujo completo de mensajes que va del cliente a la aplicación, de esta al servidor de inferencia y de vuelta al cliente.
Sí, en realidad no es más que una nueva versión de la aplicación web de tres capas, en la que la capa de datos se sustituye por la capa de inferencia. Lo sé, es terriblemente decepcionante, ¿verdad?
La forma más sencilla de una aplicación de IA es una aplicación web de tres capas en la que la capa de datos se sustituye por un servidor de inferencia.
- Recibe una solicitud JSON, realiza opcionalmente una generación aumentada por recuperación (RAG) y, a continuación, llama al servidor de inferencia con JSON. La RAG suele consistir en crear una incrustación de la consulta del usuario, buscar contenido similar en un índice vectorial o de búsqueda e incorporar esos fragmentos al prompt. Todo ello sigue siendo tráfico en formato JSON. Aún no se ha creado ningún token del modelo.
- El servidor de inferencia analiza el JSON y tokeniza el texto en los tokens del modelo, comprueba el contexto y las cuotas, agrupa las solicitudes compatibles, ejecuta el modelo y, a continuación, convierte los tokens de salida de nuevo en texto. Devuelve una respuesta JSON al solicitante. Si se usa streaming, los tokens se decodifican y se envían a medida que se generan. La mayoría de las API también incluyen un bloque de uso con el recuento de tokens de entrada y salida.
Eso es la inferencia. Simplemente un nuevo tipo de carga de trabajo de aplicaciones que recompensa la misma disciplina operativa que siempre hemos valorado, ahora expresada en tokens, contexto y flujos, en lugar de sesiones, cookies y consultas.
Entonces, ¿dónde están los tokens?
Aquí es donde la gente suele confundirse y utilizar palabras de formas que contravienen la Primera Directiva de la terminología. Los tokens son unidades de palabras procesadas por un LLM. Los genera oficialmente un tokenizador en el servidor de inferencia.
Puedes incluir un tokenizador en tu aplicación para contar los tokens de antemano con el fin de estimar los costes y aplicar límites de frecuencia locales, pero el recuento definitivo de tokens se realiza en la pila de inferencia. Los tokens son una representación del modelo, no tráfico de red; por la conexión se transmite texto JSON. Solo verás los identificadores de los tokens si la API los devuelve explícitamente.
De forma predeterminada, la infraestructura no ve los tokens, sino JSON. Los tokens no se transmiten por la red. Si quieres que la infraestructura actúe en función de los tokens, debes contarlos en la puerta de enlace con el mismo tokenizador o utilizar los recuentos que emite el servidor del modelo. Los tokens son la moneda de cambio de la IA, pero se encuentran principalmente dentro de la pila de inferencia, a menos que los expongas.
La repercusión de la inferencia en la infraestructura
La inferencia no tiene nada de místico. Es una carga de trabajo de aplicación con nuevos parámetros. El tráfico es JSON. Los tokens son unidades del modelo. Los embeddings son vectores. Si confundes estos conceptos, diseñarás controles inadecuados, fijarás el precio de forma incorrecta y depurarás la capa equivocada. Por ejemplo, enrutar en función del tamaño del JSON en lugar del número de tokens podría sobrecargar un modelo con solicitudes de contexto largo.
Si quieres que la infraestructura opere en función de los tokens, enséñale a hacerlo. Coloca un tokenizador en la puerta de enlace o utiliza los recuentos que emite el servidor del modelo. De lo contrario, tus enrutadores verán texto, no tokens, y tomarán decisiones basadas en el texto mientras tus facturas se calculan en función de los tokens. Ten en cuenta que los tokenizadores deben coincidir con los del modelo (por ejemplo, el tokenizador de GPT-4 es distinto del de LLaMA) para garantizar recuentos precisos. El uso de tokenizadores que no coincidan podría dar lugar a cálculos incorrectos de costes o límites.
Considera que la disponibilidad implica que el sistema sea utilizable y funcione correctamente, no solo que esté activo. Supervisa los tokens por segundo, el tiempo hasta el primer token y los fallos de contexto (como superar los límites de la ventana de contexto u obtener resultados incoherentes debido a un contexto saturado) del mismo modo que antes supervisabas las consultas por segundo y los aciertos de caché. Conserva los registros con rigor. El tráfico de inferencia no constituye datos de entrenamiento a menos que así lo decidas. Si conservas las instrucciones y los resultados, protégelos.
Llama a las cosas por su nombre. Mide la capa adecuada. Establece límites donde realmente importan, como cuotas basadas en tokens en la puerta de enlace para evitar sobrecostes. Si lo haces, la inferencia se comportará como el resto de tu infraestructura: será predecible, asequible y aburrida en el mejor de los sentidos. Los tokens sirven para tomar decisiones dentro del modelo, no para comprar ancho de banda en tu red. Llama a cada cosa por su nombre y mantendrás contentos a tus usuarios y a raya tus facturas.
Sobre el autor
Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.
Más artículos de Lori Mac VittieArtículos relacionados del blog
Tu próximo SRE podría ser una máquina
El control se concentra en el punto donde se expresa la intención: prompts, tokens y enrutamiento. El reto arquitectónico consiste en definir dónde puede actuar la IA, cuándo debe ceder el control y cómo revertir sus acciones.
El secreto para escalar la IA es superar la ley de Conway
La IA no escalará por sí sola. Sin un plano de control unificado que elimine las barreras entre herramientas y responsabilidades, la inferencia se convierte en la capa más frágil y que más coordinación exige.
La identidad es la guardiana de la IA agéntica
A medida que la IA agéntica transforma las máquinas de herramientas en actores, la identidad se convierte en el control fundamental: quién puede actuar, en nombre de quién y con qué alcance, aplicándose en línea durante la inferencia.
La inferencia es ahora el centro de gravedad operativo
Las operaciones multimodelo y la automatización basada en API trasladan el control a las capas de inferencia —prompts, tokens y controles, enrutamiento y moderación—, donde deben gestionarse los costes, los riesgos y el rendimiento.
¡IA, inferencia y tokens, madre mía!
Las aplicaciones de IA se ejecutan en servidores de inferencia y su funcionamiento depende de los tokens, no del tráfico. Descubre por qué comprender los tokens y los datos JSON es fundamental para diseñar una infraestructura más inteligente.