Token Management in Multi-Tenant AI Inference Platforms

Este artículo presenta "token pools", una abstracción de control que gestiona la capacidad de inferencia en plataformas de IA multiinquilino mediante unidades nativas (como tokens y caché KV) para equilibrar dinámicamente la utilización de recursos y las garantías de servicio, permitiendo un control granular de ráfagas y mecanismos de equidad basados en deuda sin modificar el tiempo de ejecución subyacente.

Lo esencial

Imagina que un plataforma de Inteligencia Artificial (como un chatbot avanzado) es como un restaurante de lujo muy popular.

En este restaurante, los "mesas" son las tarjetas gráficas (GPUs) potentes que hacen los cálculos, y los "comensales" son los usuarios que piden respuestas. El problema es que algunos clientes piden platos sencillos (una pregunta corta), mientras que otros piden banquetes gigantescos (preguntas largas que requieren mucha memoria y tiempo).

El Problema: El Caos en el Restaurante

Hasta ahora, los restaurantes de IA gestionaban las colas de dos formas que no funcionaban bien:

1. Mesas reservadas fijas: Si un cliente tenía una mesa reservada, nadie más podía usarla, incluso si el cliente no estaba comiendo. ¡Desperdicio de espacio!
2. Contadores de tickets: Decían "solo 100 tickets por minuto". Pero esto no distinguía entre un cliente que pide una hamburguesa (rápido) y uno que pide un banquete de 20 platos (lento). Si el cliente del banquete llegaba, ocupaba la cocina por mucho tiempo y los demás tenían que esperar horas, aunque solo hubieran pedido una ensalada.

Cuando llegaba un momento de mucha afluencia (una "tormenta perfecta"), el restaurante se colapsaba: todos esperaban, la comida se enfriaba (la IA se volvía lenta) y los clientes importantes se enfadaban.

La Solución: "Las Tarjetas de Crédito de Tokens" (Token Pools)

El autor, William Cunningham, propone una idea brillante: dejar de contar "tickets" y empezar a contar "comida".

Imagina que en lugar de tickets, el restaurante entrega a cada cliente una Tarjeta de Crédito Virtual llena de "créditos de tokens".

• Un Token es como una "mordida" de comida.
• La tarjeta tiene un límite de cuánto puede gastar el cliente en total, pero también tiene reglas sobre qué tipo de "mordidas" puede pedir.

¿Cómo funciona este sistema mágico?

1. Tres tipos de recursos (La Mesa, la Memoria y la Velocidad)
El sistema no solo mide cuántas personas hay, sino tres cosas vitales:

• Velocidad (Tokens/segundo): ¿Qué tan rápido se cocina?
• Memoria (KV Cache): ¿Cuánto espacio ocupa la receta en la memoria del chef? (Algunos platos requieren que el chef recuerde todo lo que se dijo antes).
• Concurrencia: ¿Cuántos platos se pueden cocinar al mismo tiempo en la misma estufa?

2. Las Categorías de Clientes (Clases de Servicio)
No todos los clientes son iguales. El sistema asigna tarjetas de diferentes colores:

• Tarjeta Dorada (Dedicada/Garantizada): Tienen una mesa reservada que nunca se les quita. Si el restaurante está lleno, ellos comen primero. Su comida siempre llega caliente y rápida.
• Tarjeta Verde (Elástica): Tienen un límite, pero si sobra comida, pueden pedir más. Si falta, pueden esperar un poco, pero el sistema les "debe" comida para el futuro.
• Tarjeta Roja (Spot/Preemptible): Son los clientes que llegan cuando sobra comida. Si llega un cliente Dorado, ¡pum! A los de la Tarjeta Roja los sacan de la mesa inmediatamente para que los Dorados se sienten. Es arriesgado, pero barato.

3. El Mecanismo de "Deuda" (La Magia de la Justicia)
Aquí está la parte más inteligente. Imagina que un cliente de Tarjeta Verde tuvo que esperar mucho porque el restaurante estaba lleno. El sistema lleva la cuenta de su "Deuda".

• Cuando el restaurante se vacía un poco, el sistema le da prioridad a ese cliente de Tarjeta Verde para "pagar su deuda". Le sirve un plato extra rápido para compensar la espera.
• Esto evita que un cliente se quede sin comer nunca, pero también asegura que los clientes Dorados siempre tengan prioridad.

4. El Portero Inteligente (Control de Acceso)
En lugar de dejar que todos entren a la cocina y luego ver si hay espacio, hay un portero en la puerta (el Gateway).

• Cuando un cliente pide entrar, el portero mira su tarjeta, calcula cuánto va a pedir (¿un plato rápido o un banquete?) y ve si hay espacio en la cocina.
• Si no hay espacio para un banquete, el portero le dice: "Lo siento, vuelve en 5 minutos" (rechaza la petición antes de que empiece a cocinar).
• Si hay espacio, entra.
• Si el restaurante está lleno, el portero deja entrar solo a los Dorados y a los Verdes que tienen mucha "deuda", y les dice a los Rojos que se vayan.

¿Qué pasó en los experimentos?

El autor probó esto en un laboratorio con una sola tarjeta gráfica (como un restaurante pequeño):

• Experimento 1 (Protección): Cuando un grupo de clientes "baratos" (Tarjeta Roja) intentó llenar el restaurante, el sistema los detuvo en la puerta. Los clientes "importantes" (Tarjeta Dorada) siguieron comiendo a la misma velocidad, sin notar el caos. Sin este sistema, todos habrían esperado horas.
• Experimento 2 (Justicia): Cuando dos clientes "Elásticos" (Tarjeta Verde) compitieron por espacio, uno pidió algo muy rápido (un asistente de código) y el otro algo lento (un reporte de datos). El sistema dio prioridad al rápido. Pero cuando el lento estuvo esperando mucho, su "deuda" aumentó y el sistema le dio más espacio poco a poco para que no se quedara sin comer.

En Resumen

Este sistema es como un director de orquesta para la Inteligencia Artificial. En lugar de dejar que la música se vuelva un ruido ensordecedor cuando hay demasiados músicos, el director (el sistema de gestión de tokens) decide quién toca, cuándo toca y cuánto tiempo toca, basándose en la importancia de la pieza y en quién ha esperado más tiempo.

El resultado: La IA es más rápida para los que la necesitan urgentemente, más justa para los que esperan, y el restaurante (el servidor) nunca se queda vacío ni se rompe por exceso de trabajo.

Resumen técnico

Aquí tienes un resumen técnico detallado del artículo "Token Management in Multi-Tenant AI Inference Platforms" (Gestión de Tokens en Plataformas de Inferencia de IA Multi-tenant), presentado por William J. Cunningham de DataRobot.

1. El Problema

Las plataformas de inferencia de IA multi-tenant enfrentan un desafío fundamental: equilibrar la alta utilización de recursos con las garantías de nivel de servicio (SLO) bajo una demanda variable. Los enfoques convencionales son insuficientes por las siguientes razones:

• Endpoints dedicados: Aíslan bien a los inquilinos, pero dejan capacidad "varada" (idle) cuando los modelos no se utilizan, lo que es ineficiente para la cola larga de modelos poco usados.
• Límites de velocidad (Rate Limits) tradicionales: Gestionan la admisión de solicitudes basándose en contadores simples (ej. tokens por minuto), ignorando el costo heterogéneo de ejecución. Dos solicitudes pueden consumir cantidades de GPU y memoria KV cache muy diferentes dependiendo de la longitud de la secuencia y la arquitectura, pero los límites tradicionales las tratan por igual.
• Falta de conservación de trabajo (Work-conservation): Ningún enfoque permite que la capacidad ociosa de un inquilino sea utilizada por otro.
• Incapacidad ante ráfagas: Los sistemas actuales no manejan bien las ráfagas de tráfico características de la inferencia (ej. ráfagas de longitud de prompt que agotan la memoria KV, o ráfagas de salida en modelos de razonamiento).

2. Metodología: "Token Pools" (Pools de Tokens)

El autor propone una nueva abstracción de control llamada Token Pools. En lugar de gestionar contenedores o GPUs directamente, el sistema gestiona la capacidad en unidades nativas de inferencia.

A. Modelo de Recursos

La capacidad se descompone en tres recursos programables:

1. Throughput de Tokens ($\lambda$): Tokens por segundo (limita la velocidad de producción).
2. Capacidad de KV Cache ($\chi$): Memoria en bytes necesaria para el estado de atención (crítico para contextos largos).
3. Concurrencia ($r$): Número de secuencias de inferencia activas simultáneamente.

B. Clases de Servicio y Entitlements

Los inquilinos obtienen "derechos" (entitlements) sobre el pool, clasificados en una jerarquía de protección:

• Dedicado/Garantizado: Asignación base reservada que nunca se reduce.
• Elástico: Tiene garantías promedio a largo plazo; puede usar capacidad extra (burst) pero se reduce si es necesario, acumulando "deuda".
• Spot: Sin garantía base, consume solo capacidad sobrante; es el primero en ser throttled (limitado).
• Preemptible: Puede ser eliminado completamente.

C. Mecanismo de Prioridad y Deuda

El sistema utiliza una fórmula de peso ($w_e$) para decidir qué solicitudes admitir o rechazar. Este peso combina:

• La clase de servicio.
• La urgencia del SLO (objetivos de latencia).
• La intensidad de las ráfagas recientes.
• Deuda de Servicio ($d_e$): Un mecanismo de retroalimentación integral. Si un inquilino elástico recibe menos recursos de los prometidos, acumula deuda. Esta deuda aumenta su prioridad en futuras asignaciones, asegurando una convergencia hacia un reparto justo (fair-share) a lo largo del tiempo.

D. Arquitectura del Sistema

• Capa de Control: Se sitúa sobre la infraestructura existente (Kubernetes, vLLM, TensorRT-LLM) sin modificar los motores de inferencia subyacentes.
• Nodos Virtuales: Utiliza "Virtual Nodes" en Kubernetes para representar la capacidad del pool de tokens. El planificador de Kubernetes se reutiliza para la admisión de capacidad de tokens.
• Control de Admisión en la API: La decisión de admitir o rechazar una solicitud se toma en la puerta de enlace (gateway) antes de que llegue al runtime. Si la capacidad es insuficiente, las solicitudes de baja prioridad reciben un error HTTP 429 con instrucciones de reintento, evitando la acumulación de colas que degradaría la latencia para todos.

3. Contribuciones Clave

1. Formalización de Token Pools: Definición de recursos de inferencia nativos (throughput, KV cache, concurrencia) y un mecanismo de prioridad que integra clases de servicio, SLOs y deuda.
2. Arquitectura de Sistema: Diseño que utiliza nodos virtuales de Kubernetes para la admisión de capacidad de tokens, permitiendo la integración con flujos de trabajo existentes (GitOps) sin reescribir los backends de inferencia.
3. Mecanismo de Deuda: Un algoritmo de control proporcional-integral que ajusta dinámicamente la prioridad de los inquilinos elásticos para garantizar equidad a largo plazo sin intervención manual.

4. Resultados Experimentales

Los experimentos se realizaron en un clúster de Kubernetes con un backend vLLM (modelo Qwen3-8B).

• Experimento 1: Protección entre Clases (Cross-Class Protection)

  • Escenario: Sobrecarga del 38% con tráfico de "Spot" y "Garantizado".
  • Resultado: Con Token Pools, la latencia P99 para trabajos garantizados se mantuvo estable en <1.2 segundos. El sistema rechazó selectivamente el tráfico de Spot (47% de throttling).
  • Comparación: Sin control de admisión, la latencia P99 se degradó a >19 segundos para todos los inquilinos debido a la acumulación de colas.

• Experimento 2: Equidad Sensible al SLO (SLO-Aware Fair Share)

  • Escenario: Dos inquilinos elásticos con diferentes requisitos de latencia (500ms vs 30s) compiten por capacidad reducida (fallo de nodo).
  • Resultado: El sistema priorizó automáticamente al asistente de codificación (SLO estricto) sobre la tubería de datos (SLO flexible).
  • Mecanismo de Deuda: El inquilino con SLO flexible acumuló deuda durante la escasez, lo que aumentó su prioridad progresivamente, evitando el hambre (starvation) y logrando una convergencia justa una vez recuperada la capacidad.

5. Significado e Impacto

Este trabajo es significativo porque cierra la brecha entre las decisiones de admisión (que ocurren en la puerta de enlace) y los costos de ejecución reales (determinados por el runtime de inferencia).

• Eficiencia Operativa: Permite una gestión de capacidad granular sin necesidad de reemplazar motores de inferencia maduros o reescribir planificadores de clústeres.
• Garantías de Servicio: Ofrece una solución robusta para la coexistencia de cargas de trabajo críticas y de bajo costo (spot) en la misma infraestructura, protegiendo a los usuarios críticos sin desperdiciar recursos.
• Adaptabilidad: El mecanismo de deuda permite que el sistema se adapte dinámicamente a cambios en la demanda y la capacidad, automatizando decisiones que antes requerían reconfiguración manual de límites estáticos.

En resumen, Token Pools proporciona una base principista para la gestión de capacidad en plataformas de IA multi-tenant, resolviendo la tensión entre la alta utilización de recursos y las garantías de nivel de servicio mediante una abstracción nativa de inferencia y control de admisión inteligente.