# Build vs. buy en IA: ¿modelo propio o API?

> Build vs. buy en IA es elegir entre usar un modelo por API o alojarlo tú. Casi siempre gana la API, salvo con volúmenes enormes o datos regulados.

*Tags: ia, arquitectura, negocio, producto*

---


> [!info] Definición Rápida
> **Build vs. buy en IA** es la decisión de usar un modelo a través de una API de terceros (buy) o de alojar y operar un modelo abierto en infraestructura propia o rentada (build). La respuesta correcta depende del volumen de tokens, de los datos que maneja el producto y de la capacidad técnica del equipo, no de cuál opción suena más seria.


## ¿Qué significa build y qué significa buy?

En "buy" pagas por uso a un proveedor que mantiene el modelo, la infraestructura y las actualizaciones. Tu costo crece con cada llamada. En "build" alojas un modelo abierto, lo sirves con un motor de inferencia y pagas por GPUs, personal y operación. Hay un punto intermedio: usar un modelo abierto alojado por un proveedor de inferencia, que te cobra por token sin que operes la infraestructura. Vale la pena tenerlo en mente, porque muchas comparaciones lo omiten. Para entender qué cambia entre modelos cerrados y abiertos, revisa [[modelos-abiertos-vs-cerrados|modelos abiertos vs. cerrados]].

## ¿Por qué la API suele ganar en costo total?

Alojar un modelo tiene costos fijos aunque nadie lo use. El blog de ingeniería de Tian Pan (abril de 2026) estima que un modelo de 70.000 millones de parámetros en 4 a 8 GPUs H100 rentadas cuesta entre 15.000 y 40.000 dólares al mes antes de contar personal, y calcula un punto de equilibrio de 34 meses con supuestos optimistas. Ese mismo texto sostiene que el personal, no el hardware, es el costo dominante.

Los cálculos de volumen varían según la fuente. Un artículo de 2026 de Marka sitúa el punto de equilibrio frente a modelos frontera en unos 100 a 256 millones de tokens al mes, y un análisis académico en arXiv (Cost-Benefit Analysis of On-Premise LLM Deployment) concluye que alojar solo es viable, en general, desde unos 50 millones de tokens al mes o con requisitos estrictos de residencia de datos. La mayoría de los productos no llega a esos volúmenes. Son estimaciones, y cambian con los precios, pero el patrón se repite: por debajo de cierto consumo, la API es más barata. Mide también los tokens de entrada y de salida por separado. Los de salida suelen costar más que los de entrada, así que una función que escribe respuestas largas puede cambiar el cálculo aunque su total de tokens parezca pequeño.

## ¿Cuándo sí conviene alojar tu propio modelo?

Hay cuatro razones que justifican el costo:

- **Volumen masivo y repetitivo.** Clasificación, extracción o resúmenes de millones de documentos al día.
- **Datos que no pueden salir de tu infraestructura.** Salud, banca o requisitos de residencia de datos. En ese caso el cumplimiento decide, sin importar el costo.
- **Latencia controlada.** Una llamada a una API suma tiempo de red y de cola que no controlas. Para interacciones con metas de latencia muy estrictas, eso pesa; para trabajo asíncrono, no.
- **Independencia del proveedor.** Un modelo propio no cambia de precio ni se retira sin aviso.

## ¿Qué es el enfoque híbrido?

Es la recomendación más repetida en la bibliografía sobre el tema. Mantén el trabajo complejo y de alto valor en una API de modelo grande, y manda el trabajo masivo, como clasificar o extraer, a un modelo pequeño alojado por ti. El texto de Tian Pan cuenta el caso de un equipo de fintech cuyo gasto en API subió de 15.000 a 60.000 dólares mensuales; al migrar todo a infraestructura propia pasó a 85.000 entre servidores, un ingeniero de DevOps a medio tiempo e incidentes de producción, y solo bajó a 8.000 cuando separó qué tráfico iba a cada lado. Es un caso reportado por un blog, no un estudio independiente, así que tómalo como ilustración. El mismo texto estima que alojar solo el tráfico masivo recorta el gasto total de IA entre 40 % y 70 % para equipos que gastan de 10.000 a 50.000 dólares al mes en APIs.

Ojo: la cifra de 34 meses y el ahorro de 40 % a 70 % salen de un solo blog y suponen volúmenes concretos; úsalas para plantear la conversación, no como pronóstico de tu producto.

## ¿Qué costos se olvidan?

| Costo | Por qué se olvida |
|---|---|
| Personal de MLOps | Parece un costo de ingeniería normal, pero es la mayor parte del total |
| Actualizaciones del motor de inferencia | Cada cambio de modelo puede requerir días de trabajo |
| Auditorías de seguridad (SOC 2, HIPAA) | Se pagan cada año, aunque el modelo no cambie |
| Código de colas, reintentos y backoff | Tu API propia necesita una capa que el proveedor ya tiene |
| Tráfico de salida y almacenamiento | Pequeños por unidad, grandes en conjunto |

## Pasos para decidir

1. Mide tu consumo real durante una semana: cuántos tokens por día, de qué tipo de tarea.
2. Separa las tareas: cuáles son complejas y cuáles son repetitivas. Suele concentrarse la mayor parte del consumo en pocos tipos de consulta.
3. Revisa si hay datos regulados. Si los hay, la pregunta cambia.
4. Compara el costo total mensual de la API con el de alojar, incluido el personal.
5. Empieza con API. Mueve a un modelo propio solo las tareas donde el número ya lo justifica.
6. Repite la cuenta cada trimestre, porque los precios de los modelos bajan rápido.

## Ejemplo ilustrativo

Ejemplo ilustrativo: un equipo de un producto de atención al cliente gasta 3.000 dólares al mes en una API. Casi todo el gasto viene de clasificar tickets entrantes. Antes de alojar un modelo, el equipo calcula que un servidor con un modelo pequeño cuesta cerca de 1.500 dólares al mes más el tiempo de una persona que lo mantenga. La conclusión no es automática: si esa persona cuesta más que el ahorro, la API sigue siendo la opción. Si el tráfico crece diez veces, el cálculo cambia.

## ¿Cuánto tiempo sirve la decisión?

Poco. Los precios de las APIs y la calidad de los modelos abiertos cambian cada pocos meses, así que una comparación hecha hoy puede no sostenerse el próximo trimestre. Por eso conviene tratar la decisión como revisable: anota el volumen de tokens, el costo mensual y el umbral que dispararía una revisión, y repite la cuenta cuando alguno de esos números cambie.

## Errores comunes

- Comparar solo el precio por token, sin el costo de personal y operación.
- Alojar un modelo grande cuando un modelo pequeño resuelve la tarea.
- Ignorar la latencia y la residencia de datos hasta el final del proyecto.
- Tomar cifras de un blog como si fueran válidas para tu caso.
- Decidir una vez y no revisar la decisión cuando cambian los precios.

## Cuándo NO alojar tu propio modelo

Cuando el volumen es bajo, cuando el equipo no ha operado inferencia en producción o cuando el producto todavía está validando si la función sirve. En esas etapas, cada hora de MLOps es una hora que no vas a dedicar al diseño de la experiencia. Para decidir si la función vale el costo, revisa [[roi-de-features-de-ia|ROI de features de IA]] antes de invertir en infraestructura. Y si la pregunta es qué modelo usar para cada tarea, [[modelos-pequenos-vs-grandes|modelos pequeños vs. grandes]] es el siguiente paso.

## Fuentes

- [Tian Pan, The Build-vs-Buy LLM Infrastructure Decision Most Teams Get Wrong (abril 2026)](https://tianpan.co/blog/2026/04/15/build-vs-buy-llm-infrastructure)
- [Marka, Self-Hosted LLM vs API: The Real Cost and Security Trade-offs for Enterprise in 2026](https://www.marka.net.ua/news/self-hosted-llm-vs-api-the-real-cost-and-security-trade-offs-for-enterprise-in-2026/)
- [arXiv, A Cost-Benefit Analysis of On-Premise Large Language Model Deployment: Breaking Even with Commercial LLM Services](https://arxiv.org/html/2509.18101v3)


---

Source: https://www.fernandoux.com/es/wiki/ia/build-vs-buy-modelos/