Ingeniería

Sobreingeniería sin usar la calculadora

· 5 min read · Fabián Almenara

Todo el mundo opina sobre que es mejor usar. Y creo que se está poniendo mucho valor en el código o en el modelo. Qué modelo uso si este o aquel. Pero no se trata del modelo solamente. Cuando vamos a poner las cosas a funcionar en entornos reales, el código o el LLM pasa a un segundo plano porque la gestión de la infraestructura, por ejemplo, es muy tediosa e importante

La calculadora que casi no sacamos antes de montar infraestructura de IA

Llevamos dos semanas evaluando qué motor de embeddings usar en el Enterprise Brain de Ilbira. La conclusión no es técnica. Es sobre cómo decidimos.

En local, con Ollama, bge-m3 funciona perfecto. Multilenguaje, buen rendimiento, self-hosted, coste marginal cero. Sobre el papel es la opción correcta, y además es la que se recomienda constantemente en redes: monta tu propia infraestructura, no dependas de los grandes proveedores.

El problema aparece en cuanto lo llevas a producción.

El problema en producción

Desplegado en Cloud Run con instancias mínimas a cero, TEI con bge-m3 nos sale por 2 dólares al mes, para el volumen que tenemos ahora: 500 documentos, 100 queries al día. Bien.

Pero el escalado a cero tiene un coste que no se ve hasta que lo mides: la primera petición después de un rato de inactividad tiene que arrancar el contenedor entero, y esa latencia de arranque en frío no siempre es aceptable. La solución obvia es mantener una instancia siempre encendida.

La documentación oficial de Cloud Run es clara en esto: las instancias mínimas se facturan durante todo su ciclo de vida, estén o no procesando peticiones. No es letra pequeña, es el comportamiento por diseño. En nuestro caso, esa instancia siempre encendida dispara el coste a 54 dólares al día.

Y aquí está lo que nadie te cuenta cuando te recomienda self-hosted por sistema: usar el embedding estándar de Gemini vía API nos cuesta 0,17 dólares al mes. Para el mismo volumen.

Esto no es un problema solo nuestro

Cuando empecé a mirar si nuestros números eran razonables, encontré que el debate build vs buy en infraestructura de IA está mucho más maduro de lo que parece en redes. Un informe reciente de a16z basado en entrevistas a CIOs de empresas grandes señala que el TCO entre modelos abiertos y cerrados se está acercando, en parte porque los proveedores han bajado agresivamente el coste de la inferencia. Cuando el TCO converge, la pregunta deja de ser cuál es más barato en abstracto y pasa a ser cuál es más barato para tu volumen concreto.

Un paper académico de este año sobre despliegues on-premise de LLMs va en la misma dirección: propone un marco de cálculo de punto de equilibrio precisamente porque, según sus propios autores, faltaba un análisis sistemático y cuantitativo que comparase ambas opciones. Si hace falta un paper para formalizarlo, es porque la mayoría de equipos lo está decidiendo sin ese cálculo.

Un análisis de build vs buy centrado en producto llega a una conclusión parecida desde otro ángulo: por debajo de cierto volumen mensual de tokens, las APIs gestionadas ganan en coste total una vez que metes en la ecuación la infraestructura y el equipo necesario para mantenerla. El aviso importante ahí es que muchos equipos siguen tomando esta decisión con supuestos de hace dos años, cuando la brecha de calidad entre modelos abiertos y cerrados era mucho mayor.

Dónde está realmente el punto de equilibrio

Para embeddings específicamente, los números que circulan van todos en la misma dirección. Un comparativo de coste de embeddings a escala sitúa el punto de equilibrio entre self-hosted y API en algo así como 300.000 a 2 millones de documentos al mes, dependiendo de si comparas contra el modelo pequeño o el grande de la API. Otro análisis centrado en modelos de embedding sitúa ese umbral en 10 a 15 millones de embeddings mensuales para que el self-hosting empiece a compensar frente a una API de pago.

Nosotros hacemos 100 queries al día. Nuestro punto de equilibrio propio, con los precios reales de Cloud Run y Gemini, cae en 93.000 queries al día. Estamos casi tres órdenes de magnitud por debajo del punto en el que el self-hosted empieza a tener sentido económico, y eso sin contar que cambiar de motor más adelante significa reindexar toda la base, que tampoco es gratis.

El caso de la multimodalidad

Nos pasa lo mismo con la propuesta de usar el embedding multimodal de Gemini para indexar planos. Cuesta 5 veces más que el embedding de texto normal. La pregunta correcta no es si la multimodalidad mola, es cuántas veces la vamos a necesitar de verdad ahora mismo, con el Brain indexando sobre todo documentos markdown.

La lección de fondo

El valor no está en qué motor de embeddings usas. Está en todo lo que hay que mantener alrededor: la infraestructura, la seguridad, los tests de paridad entre entornos, la reindexación el día que cambias de modelo.

Hay una recomendación que se repite en el sector, y que uno de los análisis que cité arriba resume bien: empieza por la API, mide tu uso real, y solo revisa el análisis de self-hosting cuando cruces un umbral de tráfico que lo justifique. No al revés.

La independencia tecnológica importa, y hay razones legítimas para self-hostear que no son solo económicas: privacidad de datos, cumplimiento normativo, o simplemente no depender de un proveedor externo para algo crítico. Pero esa decisión se toma con la calculadora en la mano, no por dogma. A veces la decisión más avanzada técnicamente es la más cara y la menos necesaria.

Fuentes

Blog