Plan: servir mi propio modelo para bajar la factura

La factura de los asistentes de código crecía con el equipo, y la pregunta era simple: ¿se puede servir un modelo open-source nosotros mismos y pagar menos? La respuesta honesta es "depende", y depende de números que nadie tiene hasta que los mide. Así que hicimos un PoC: dos ingenieros, una GPU alquilada y una regla: nada se compra sin haber medido.

Esta es la serie de lo que encontramos: ocho capítulos con los números reales, incluidos los que no nos gustaron.

El objetivo (y lo que no buscábamos)

Objetivo: validar con mediciones propias si conviene servir un modelo open-source en infraestructura alquilada en vez de pagar una suscripción por asiento.

Lo que NO buscábamos: entrenar nada, reemplazar al modelo grande en las tareas difíciles, ni montar algo en producción. Era falsación barata: antes de gastar miles al mes, gastar decenas y ver dónde se rompe.

Los criterios de éxito que nos pusimos (impresos en cada salida del benchmark):

TTFT p90 < 1500 ms  |  >= 40 tok/s por usuario  |  0 fallos

Ninguno de los tres se cumplió en el primer barrido. Esa es, en parte, la historia.

El stack

opencode  →  LiteLLM (gateway)  →  vLLM (servidor)
(cliente)     keys, UI, logs        inferencia
              Postgres

• vLLM como servidor: es el estándar de facto para servir modelos abiertos (batching continuo, prefix caching, API compatible con OpenAI).
• LiteLLM como gateway: keys virtuales por persona, presupuestos, UI y logs. Sin esto no sabes quién consume qué.
• opencode como cliente, apuntando al gateway como si fuera cualquier proveedor.

El modelo: por qué MoE

Qwen3-Coder-30B-A3B-Instruct-FP8:

La razón del MoE es económica: solo se activa una fracción de los parámetros por token, así que se mueve como un modelo chico pero sabe como uno grande. Y FP8 es lo que lo hace caber en una GPU de 48 GB con contexto largo. → MoE por dentro: 30B totales, 3B activos

El hardware y el costo

Ese contraste es el corazón del experimento: $15 para saber, contra $796/mes para suponer. El detalle completo de las cuentas está en el último capítulo. → El informe que dijo "no migren todavía"

Las reglas del PoC

1. Medir antes de opinar. Cada escenario se mide con un script reproducible, no "a ojo".
2. Falsación barata. Primero la GPU más chica que pueda funcionar; se escala solo si los números lo justifican.
3. Un solo cambio por vez. Cambiar prompt y concurrencia a la vez no enseña nada.
4. Anotar todo, incluido lo que falla. De ahí salió el capítulo de los 7 bugs.
5. Saber qué NO se midió. La calidad del modelo quedó fuera de esta prueba (y lo decimos).

Lo que viene en la serie

1. Plan (este capítulo)
2. Los 7 bugs del entorno alquilado
3. El error de mi propio benchmark
4. Prefix caching: la misma carga, 3× más rápido
5. El cuello de botella no era la GPU: era la red
6. 48 KB por token: por qué 48 GB no aguantan 30 sesiones
7. MoE por dentro: 30B totales, 3B activos
8. El informe que dijo "no migren todavía"

El marco conceptual de todo esto está en la guía Inference Engineering: de cero a producción.

¿Has calculado alguna vez cuánto te costaría servir tu propio modelo? Cuéntame en los comentarios con qué números lo justificas (o con qué números lo descartas).

Referencias

• vLLM documentation
• Qwen3-Coder-30B-A3B-Instruct - Hugging Face
• Repo del PoC: scripts de benchmark, resultados y runbooks