Plataforma de Inferencia

1. El problema de diseño

Servir un MoE de checkpoint mixto NVFP4+FP8 de 171 GiB en tres RTX PRO 6000 de 96 GB tiene un primer obstáculo aritmético: el modelo no cabe entero en ninguna tarjeta, y el tensor-parallel clásico (partir cada capa entre GPUs) introduce comunicación por PCIe/NVLink en el camino crítico de cada token. Nuestra elección fue la contraria: réplicas completas con paralelismo de tensor 1, y una cola de distribución delante. Cada GPU es un motor de inferencia autónomo; la elasticidad no la da el chip, la da la topología. Todo lo que sigue —memoria, balanceo, gateway— está diseñado alrededor de esa decisión.

2. Topología del pool

• Las réplicas no se publican: solo escuchan en 127.0.0.1:810N del host. El único punto de entrada externo es la cola HAProxy, de modo que subir o bajar una GPU del servicio es invisible para los clientes.
• Un solo nombre publicado (qwen3.8-flash-next): el mismo endpoint y el mismo model sirven a todas las aplicaciones del centro — agentes de código, aula, generación de contenido, vídeo.
• Orquestación con perfiles Docker Compose: el fichero base define el servicio; los overrides docker-compose.2replicas.yml y docker-compose.512k.yml cambian la forma del despliegue sin duplicar configuración.

3. Servir con una, dos o tres GPUs: el pool es elástico

Con réplicas TP=1, escalar es una operación aritmética trivial — pero cada GPU tiene competidores. La GPU 2 del Titán también da servicio a TTS (6 voces), render de vídeo, OCR y embeddings. El pool se dimensiona por perfiles según la campaña:

Números de nuestros benches y logs (ver benchmarks oficiales). El coste de sacrificar la tercera réplica —40 % de pico y un tercio de concurrencia— se asume deliberadamente: con dos réplicas completas la GPU 2 puede síntesis de voz y render de vídeo sin drenar el pool a mano cada vez. La tercera réplica está definida pero a replicas: 0: documentada y viva, a un flag de distancia.

Dos consecuencias elegidas de este diseño:

• Sin punto único de fallo: una réplica que muere solo resta capacidad; HAProxy la saca del pool en ~6 s y las sesiones en vuelo de esa GPU se reencolan en las demás. No hay EngineCore compartido que tumbe el servicio entero (algo que nosotros mismos probamos, ver §5).
• Migración de modelo sin corte: al cambiar el modelo de la plataforma, las réplicas publicaron temporalmente los alias del anterior para que todos los clientes siguieran respondiendo durante el cambio de minuto, y se retiraron el mismo día con todos los clientes ya repuntados.

4. El plan de memoria: por qué TP=1 con offload gana al TP=2

# Producción real por réplica (abreviada; idéntica en las 3)
vllm serve /model \
  --served-model-name qwen3.8-flash-next \
  --tensor-parallel-size=1 --distributed-executor-backend=mp  # mp, no ray: requisito del offload PLE \
  --max-model-len=524288 \
  --gpu-memory-utilization=0.97 \
  --kv-cache-memory=15569256448 \
  --enable-prefix-caching \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder \
  --reasoning-parser qwen3 --max-num-seqs=16 \
  --hf-overrides{"text_config":{"rope_parameters":{"rope_type":"yarn","factor":2.0,...}}}
env VLLM_PLE_CPU_OFFLOAD=1  VLLM_PLE_OFFLOAD_READY_TIMEOUT=1800
# nativo 262.144 ctx → YaRN×2 para 524.288; checkpoint con revisión pinneada, montado RO

5. La cola de distribución: HAProxy y lo que aprendimos balanceando

Con réplicas independientes, la calidad del servicio depende de la cola que hay delante. Nuestra configuración y las tres lecciones medidas que la justifican:

El incidente del conector PLE (por qué cada réplica puede morir sin tumbar nada)

6. El gateway: LiteLLM hablando dos dialectos

vLLM solo habla OpenAI; nuestro stack usa también Claude Code, que habla el Messages API de Anthropic (bloques tipados, tool_use, thinking). LiteLLM publica ambos protocolos (/v1/messages y /v1/chat/completions) sobre el mismo pool y añade lo que el motor de inferencia no debe gestionar nunca: claves virtuales por usuario, límites de gasto y registro de consumo. Delante, nginx publica el gateway por TLS con la CA interna del centro.

Dos perfiles de modelo, medidos y documentados en el propio fichero de configuración:

7. Operación y control

• Revisión pinneada en todo: checkpoint con hash de commit HF, imágenes Docker por digest, versiones en un versions.env central. Reconstruir el pool dentro de un año debe dar exactamente el mismo sistema.
• Preflight y humo: un script de preflight valida GPUs/puerto/memoria antes de arrancar réplicas, y pruebas smoke automáticas tras cada despliegue.
• Drenado por réplica: mantener una GPU = sacarla del pool por el socket de HAProxy, esperar a las generaciones vivas, intervenir, devolverla — sin ventana de servicio cortado para el resto del centro.
• Telemetría: los /metrics de cada engine (TTFT, ITL, KV, prefijos) son la fuente de los benchmarks publicados: el mismo dato que opera el sistema es el que se documenta hacia fuera.