En casi todo diagrama de arquitectura agéntica hay una caja rotulada LLM Runtime, con logos de proveedores de un lado y de modelos abiertos del otro. Se ve como una preferencia de catálogo. Es la decisión que más plata mueve del diagrama entero, y la única que la mayoría de los equipos toma por una razón que no aplica.
La respuesta corta: autoalojar un modelo abierto casi nunca sale más barato que llamar a un proveedor, porque los mismos modelos abiertos se venden por API a un precio cercano al costo crudo de la GPU. Lo que domina el costo no es el modelo, es la forma del tráfico. Autoalojar se justifica por control, y hay cuatro casos en que sí conviene.
¿Qué es el runtime y por qué se decide aparte?
Es dónde y cómo se ejecuta el modelo. Y se decide aparte porque responde preguntas que ninguna otra capa responde.
La capa de orquestación decide qué hacer, con qué contexto, en qué orden y con qué controles. Esa discusión ya la dimos en las 13 capas de un sistema de IA real. El runtime es otra cosa: es la infraestructura que ejecuta la inferencia, y sus preguntas son costo, latencia, control y residencia del dato.
Mezclarla con el resto es lo que hace que la decisión se tome mal. Se elige el runtime al principio del proyecto, cuando no existe todavía el único dato que la resuelve, que es cómo se va a ver tu tráfico real.
¿Qué mueve el costo de verdad?
La forma del tráfico. No el modelo, no el proveedor, no la negociación.
Este es el punto que cambia la conversación. Una GPU se paga por hora, esté trabajando o esperando. Si tu tráfico llega en ráfagas cortas separadas por horas muertas, pagas el día completo por usar el equipo unos minutos. Un análisis publicado sobre un mismo modelo servido en una misma GPU muestra la magnitud del efecto.
Datos
| Concurrencia sostenida | Costo |
|---|---|
| 1 petición por segundo | 15.3 |
| 25 peticiones por segundo | 0.9 |
Diecisiete veces de diferencia sin cambiar el modelo ni el hardware. Solo cambió cuánta gente lo estaba usando al mismo tiempo.
De ahí sale la regla incómoda: la infraestructura propia premia el tráfico parejo y castiga el disperso. Y el tráfico de la mayoría de las empresas es disperso, porque sigue el horario laboral de un país.
¿Cuándo autoalojar sale más barato?
Cuando sostienes utilización alta, y eso es más exigente de lo que suena.
Las estimaciones publicadas coinciden en el orden de magnitud: autoalojar compite cuando la GPU se mantiene por encima de dos tercios de uso buena parte del tiempo, con decenas de peticiones simultáneas en vuelo de forma sostenida [1]. No en el pico del martes: sostenido.
Y falta el costo que nunca entra en la hoja de cálculo. Un ingeniero de plataforma alcanza a operar unas pocas GPUs, y el costo total termina siendo un múltiplo del alquiler crudo del hardware una vez sumas monitoreo, actualizaciones, guardias y reemplazo de modelos [1].
Hay un último dato que casi nadie considera y que cierra el argumento: los mismos modelos abiertos se venden por API. Un proveedor especializado sirve Llama, Qwen o Mistral a un precio cercano al costo crudo de la GPU, con la utilización promediada entre todos sus clientes en vez de la tuya sola. Si querías el modelo abierto por el modelo, ya lo puedes comprar sin comprar el problema operativo.
¿La ley me obliga a tener el modelo en casa?
Casi nunca, y esta confusión cuesta proyectos enteros.
Es la razón que más escucho para autoalojar en la región, y en la mayoría de los casos está mal planteada. Ni Colombia ni Brasil exigen que el procesamiento ocurra en hardware local.
En Colombia, la Ley 1581 y el Decreto 1377 permiten la transferencia internacional de datos personales mediante cláusulas contractuales verificadas por la autoridad de control [2]. En Brasil, la LGPD no impone localización estricta: permite transferencias transfronterizas hacia países con nivel adecuado de protección, o amparadas en consentimiento, contratos o disposiciones legales específicas, exigiendo medidas técnicas y administrativas adecuadas [3].
Lo que la norma pide es base legal y protección demostrable, no un servidor en el edificio. Un contrato de tratamiento bien hecho con un proveedor que no entrena con tus datos cumple; comprar GPUs no exime de nada por sí solo, y además te vuelve responsable de la seguridad que antes era del proveedor.
Esto no dice que el requisito nunca exista. Dice que el requisito hay que leerlo antes de comprar hardware, y que muchas veces viene del contrato de un cliente y no de la ley.
Entonces, ¿cuándo sí conviene?
Cuatro casos, y ninguno es el precio por token.
Volumen alto y parejo. Si tu tráfico es sostenido, con concurrencia real durante buena parte del día, la cuenta empieza a cerrar. Es el único caso económico legítimo.
Un cliente que no acepta que su dato salga. No la ley: el contrato. Es una razón comercial válida y perfectamente común en banca, salud y sector público.
Latencia que un proveedor remoto no alcanza. Si el caso vive dentro de una planta, un punto de venta o un sistema de tiempo real, la distancia física es el argumento.
Necesitar que el modelo no cambie debajo de ti. Un proveedor deprecia versiones y ajusta comportamientos. Si tu sistema depende de una salida estable y tienes evaluaciones que lo comprueban, fijar el modelo tiene valor real.
¿Cómo se decide sin apostar?
Con tres números que hoy no tienes, y que se consiguen en un trimestre.
| Paso | Qué haces | Qué obtienes |
|---|---|---|
| 1 | Empieza con la API del proveedor | Salir a producción sin comprometer capital |
| 2 | Aísla el runtime detrás de una interfaz propia | Que cambiarlo sea un reemplazo de módulo |
| 3 | Mide volumen, concurrencia y distribución horaria | Los tres números que resuelven la cuenta |
| 4 | Recién ahí compara contra autoalojar | Una decisión, no una apuesta |
El paso 2 es el que más se salta y el más barato de hacer al principio. Si el código que habla con el modelo está separado de la lógica del negocio, cambiar de runtime en seis meses cuesta días. Si está regado por todo el sistema, cuesta un proyecto, y esa es exactamente la razón por la que muchos equipos se quedan con la decisión que tomaron el primer día sin datos.
Cómo lo aplicamos en MasterDragon
Empezamos siempre en proveedor, y dejamos la puerta abierta desde el día uno.
En la práctica eso significa que el runtime vive detrás de una interfaz nuestra, con el modelo declarado en configuración y no en el código. Nos ha permitido cambiar de modelo por tarea sin tocar la lógica, que además es la palanca de costo más grande que existe antes de pensar en hardware.
Y cuando un cliente plantea autoalojar, la primera pregunta no es técnica: es si el requisito viene de la ley, del contrato de un cliente suyo, o de una intuición sobre el ahorro. En el tercer caso, que es el más frecuente, la respuesta suele ser medir tres meses antes de comprar nada.
Si estás definiendo la arquitectura y quieres saber cuál runtime te conviene, habla con nuestros ingenieros. Puedes empezar por cómo construimos tu software y revisar nuestro portafolio de productos AI-native ya lanzados. La cuenta completa del gasto en IA está en el costo de la IA no es la licencia, es el consumo, lo que hay debajo de un agente que aguanta producción en las 13 capas de un sistema de IA real, y cómo diseñar para poder cambiar una pieza sin tumbar el resto en arquitectura empresarial componible.
Referencias
- Análisis comparativos de costo entre autoalojamiento de modelos de pesos abiertos con vLLM y APIs de proveedores (2026), incluyendo umbrales de utilización, efecto de la concurrencia sobre el costo por millón de tokens y costo total de operación frente al alquiler crudo de GPU.
- Congreso de la República de Colombia. (2012). Ley 1581 de 2012, y Decreto 1377 de 2013, sobre protección de datos personales y transferencia internacional mediante cláusulas contractuales verificadas por la Superintendencia de Industria y Comercio.
- Brasil. (2018). Lei Geral de Proteção de Dados Pessoais, Lei 13.709/2018, en vigor desde 2020, sobre transferencias internacionales hacia países con nivel adecuado de protección y medidas técnicas y administrativas exigibles.