El informe que dijo "no migren todavía"
El PoC salió bien. El servidor levantaba, respondía, aguantaba 10 personas y costaba centavos al día. Y la recomendación que escribí fue: no migren todavía. No por miedo: por las cuentas.
Esta es la última pieza de la serie, y la más útil si estás pensando en servir tu propio modelo.
La tentación
Cuando algo funciona, el siguiente paso parece obvio: "entonces migremos". Pero un PoC responde ¿es posible?; la migración responde ¿es mejor?. Y "mejor" incluye tres cosas que el PoC no tocó: costo a escala, calidad y red.
Las cuentas (con números)
La comparación es contra la alternativa real: una suscripción por asiento, a ~$200/mes de precio de lista. Para 30 personas, eso son $6.000/mes.
El costo propio a 30 ingenieros se descompone en:
| Concepto | Estimado mensual |
|---|---|
| GPUs (4× L40S) | $3.184 (reservado: ~$2.230) |
| Gateway y monitoreo | ~$150 |
| Operación | $800–1.000 |
| Fallback a un modelo grande para tareas difíciles | $600–1.200 |
| Total | $4.700–5.500 (reservado: $3.800–4.600) |
O sea: 8–21% de ahorro sin reservar y 24–37% reservando. El ahorro crece con el tamaño del equipo, porque los costos fijos (gateway, operación) se reparten:
| Ingenieros | Propio (reservado) | Ahorro vs suscripciones | Costo por ingeniero |
|---|---|---|---|
| 10 | $1.650–2.050 | 0–17% | — |
| 30 | $3.800–4.600 | 24–37% | ~$155–185 |
| 60 | $5.600–7.000 | 42–53% | — |
| 100 | $7.700–10.000 | 50–62% | ~$96–119 |
(Estimaciones del informe del PoC; los costos de GPU son reales y medidos, las proyecciones de equipo no.)
La conclusión incómoda: a 30 personas el ahorro no paga el riesgo. A 100 sí. Y el punto de equilibrio aparece mucho antes si el equipo ya trabaja con modelos abiertos a diario.
El detalle que casi hunde la cuenta: el tiempo encendido
La GPU factura por hora, no por token. En el PoC, el costo real fue <$15 porque el pod estuvo encendido horas sueltas. Pero una instancia "siempre disponible" se paga completa aunque nadie la use. Y si el uso es intermitente, el costo por token se dispara: al 10% de utilización, el mismo token cuesta 10 veces más.
De ahí la regla: el self-hosted gana con uso sostenido; la API gana con uso intermitente. Sin excepciones.
Las 3 cosas que faltan medir (y por eso no migramos)
- Calidad. El dataset de evaluación tiene 5 tareas y nunca se corrió. Sin eso, no sabemos si el modelo open-source hace el trabajo con la calidad suficiente. Es el hueco más importante, y lo dice el propio informe.
- Red privada. Los ~1.000 ms de internet que dominaban el TTFT bajan a decenas de milisegundos en una VPC. Eso puede voltear la decisión de latencia. No se midió. → El cuello de botella no era la GPU: era la red
- 30 concurrentes en 2 GPUs. El plan lo predecía; nunca se probó. Solo probamos 1/5/10 en una GPU. → 48 KB por token
Lo que sí propuse: un piloto acotado
Antes de cualquier compromiso grande, un piloto de ~$1.000: 2 GPUs, dos semanas, 30 usuarios y criterios de falsación explícitos (TTFT, tokens/s por usuario, sin OOM, y calidad mínima con un dataset de verdad). Si falla, se corrige el plan; si gana, se escala con datos.
Ese es el punto del método: $15 para evitar una decisión de miles al mes, y $1.000 para evitar una de decenas de miles al año.
Lo que me llevo de toda la serie
- Un PoC que dice "todavía no" es un éxito, no un fracaso. Nos ahorró comprometer presupuesto en algo que aún no cumple.
- Lo caro no es la GPU: es el tiempo encendido, la operación y la calidad no medida.
- Separa las capas. Latencia, memoria, red y costo se miden por separado o te miente la capa equivocada.
- Publica también lo que faltó medir. La sección de huecos es la más útil del informe.
La serie completa, con todos los números, está en la guía Mi primer servidor de inferencia propio. Y el marco de todo, en Inference Engineering: de cero a producción.
¿Migrarías con estas cuentas? ¿Qué te faltaría medir antes? Cuéntame en los comentarios: es exactamente la conversación que hay que tener antes de firmar.