Comparar local, nube, híbrido y coste total

Local y API no son dos filosofías. Son dos formas de operar una capacidad, y una arquitectura híbrida puede combinar ambas.

La comparación debe hacerse sobre la misma tarea, dataset y nivel de servicio.

Define alternativas reales

API gestionada

Tu aplicación envía solicitudes a un servicio externo.

Ventajas posibles:

• menor infraestructura propia;
• elasticidad;
• acceso rápido a modelos nuevos;
• operación delegada.

Costes/riesgos:

• coste variable;
• dependencia de proveedor;
• red;
• política de datos;
• límites;
• cambios de modelo o API.

Self-hosted local/on-prem

La organización opera inferencia.

Ventajas posibles:

• control de infraestructura;
• ejecución offline;
• datos dentro del perímetro definido;
• versión controlada;
• coste marginal predecible si hay utilización.

Costes/riesgos:

• inversión;
• capacidad fija;
• operación;
• actualizaciones;
• seguridad;
• obsolescencia.

Híbrida

Ejemplos:

• modelo local para clasificación; API para casos complejos;
• RAG local; generación externa;
• edge para offline; cloud para batch;
• local por sensibilidad; API por capacidad.

Híbrido no es automáticamente mejor: duplica caminos y controles.

Mide calidad primero

Si el modelo local no alcanza calidad mínima, una ventaja de coste no compensa.

Usa el mismo:

• dataset;
• rúbrica;
• prompts;
• herramientas;
• contexto.

Compara:

quality_local vs quality_api

No compares benchmarks públicos de modelos diferentes como sustituto de tu tarea.

Latencia

Mide:

• TTFT;
• tiempo total;
• p50/p95;
• warm/cold;
• concurrencia.

NVIDIA y MLCommons distinguen latencia y throughput como métricas diferentes.

Una API puede tener latencia de red pero más capacidad. Un local puede ganar en single-user y perder bajo carga.

Throughput

Pregunta:

«¿Cuántas unidades de trabajo por segundo/hora necesito?»

No solo tokens/s.

Para clasificación puede ser documentos/hora.

Para chat:

• requests/s;
• tokens/s.

Mide la unidad de negocio.

Disponibilidad

Local:

• PSU;
• host;
• GPU;
• disco;
• red;
• operador.

API:

• proveedor;
• Internet;
• región;
• cuota.

Híbrido puede ofrecer fallback si ambos caminos están evaluados.

No asumas que «on-prem = alta disponibilidad». Un único servidor es un single point of failure.

Coste total

Local

Incluye:

CAPEX

• hardware;
• instalación;
• red;
• almacenamiento.

OPEX

• electricidad;
• refrigeración;
• espacio;
• monitorización;
• backups;
• soporte;
• personal;
• renovación.

Opportunity cost

• horas de ingeniería;
• complejidad.

API

Incluye:

• tokens/requests;
• storage;
• tools;
• retrieval;
• red;
• soporte;
• observabilidad;
• retries.

Híbrido

Incluye ambos más el coste de mantener routing y dos entornos.

Utilización

Hardware comprado pero inactivo tiene coste.

Calcula:

coste_por_tarea =
TCO_periodo / tareas_completadas_periodo

No uses capacidad teórica como utilización real.

Horizonte

Compara:

• 12 meses;
• 24;
• 36.

Incluye:

• crecimiento;
• renovación;
• depreciación;
• cambios de precio.

No adivines precios futuros. Usa escenarios.

Coste de actualización

Una API puede actualizar modelo sin hardware.

Local puede necesitar:

• modelo;
• runtime;
• memoria;
• GPU.

Pero API también puede obligar migraciones por deprecación.

Incluye cambio como coste.

Seguridad y privacidad

Local puede reducir exposición a un tercero concreto, pero añade responsabilidad sobre:

• host;
• red;
• admin;
• backups.

API delega parte de operación, pero exige revisar proveedor.

No puntúes «privacidad = 10 local, 5 cloud».

Descompón requisitos.

Matriz ponderada

Ejemplo:

Los pesos son tuyos.

Además mantén MUST separados: una media no compensa un requisito incumplido.

Sensibilidad

Cambia:

• uso 2×;
• API +30 %;
• energía;
• hardware;
• personas;
• calidad.

Observa si la decisión cambia.

Si cambia con una variación pequeña, la decisión es frágil.

Normaliza la unidad de comparación

Evita comparar:

• una API con 100 usuarios concurrentes;
• un servidor local probado con uno.

Define una unidad:

1.000 documentos procesados
1.000 conversaciones
1 millón de tokens útiles
100 horas de servicio

La unidad debe representar trabajo real.

Registra:

• calidad mínima;
• latencia;
• disponibilidad.

Solo entonces compara coste.

Capacidad pico y capacidad media

Una empresa puede usar el sistema poco durante el día y necesitar un pico al cierre de mes.

Local debe dimensionarse para:

• pico;
• cola;
• batch.

API puede absorber picos, pero:

• rate limits;
• precio;
• disponibilidad.

Una arquitectura híbrida puede usar local para base y API para overflow si los datos y política lo permiten.

No diseñes overflow después de comprar hardware.

Reserva y redundancia

Un único host local puede ser barato, pero una necesidad de alta disponibilidad puede duplicar:

• GPU;
• almacenamiento;
• red;
• energía.

Incluye capacidad de reserva en TCO cuando el SLO la requiera.

No compares un servidor sin redundancia con un servicio externo redundante como si ofrecieran el mismo nivel de servicio.

Coste de ingeniería

Estima horas para:

• evaluación;
• instalación;
• actualización;
• incidentes;
• parches;
• benchmark;
• migración.

Multiplica por un coste interno aproximado.

No conviertas la hora en una precisión financiera falsa; usa escenarios.

Break-even

Puedes calcular un punto de equilibrio:

fixed_local + variable_local × usage
=
fixed_api + variable_api × usage

Pero un break-even económico solo importa si ambos cumplen los mismos MUST.

No digas «local compensa a partir de X tokens» si la calidad local no cumple.

Valor de opción

Una API puede ofrecer acceso rápido a modelos nuevos.

Local puede ofrecer operación offline.

Esos beneficios no son fáciles de reducir a euros.

Regístralos como criterios separados en vez de ocultarlos en una cifra TCO.

Riesgo de obsolescencia

Hardware:

• vida útil;
• compatibilidad;
• capacidad de modelos futuros.

API:

• deprecations;
• precio;
• proveedor.

Crea escenarios:

Base condiciones actuales.

Stress +50 % volumen.

Adverse modelo local necesita más memoria / API sube coste.

Una decisión robusta debería seguir siendo razonable en varios escenarios.

Ejercicio

Construye un spreadsheet con:

• baseline;
• local;
• API;
• híbrido;
• 3 horizontes;
• 3 escenarios.

Incluye coste por outcome.

Resultado de la lección

Debes terminar con una comparación defendible y sensible a supuestos. La siguiente lección mostrará qué componentes necesita una opción local para convertirse en un servicio mantenible y no en un proceso ejecutado manualmente en una workstation.