La pregunta no es dónde cuesta menos un token
Una empresa quiere un asistente que lea documentos y prepare respuestas. Parece sencillo: pagar un servicio remoto por uso o comprar y operar una máquina local. El primero muestra una factura; el segundo parece gratis tras comprarlo. Pero mantenimiento, tiempo inactivo y capacidad en picos pueden cambiar la decisión. Este artículo ayuda a responsables operativos y técnicos a construir una comparación comprobable antes de hablar de marcas o modelos. La pregunta es: ¿con qué volumen resulta más barato lo local y puede atender realmente ese volumen?
Construimos ecuaciones de coste mensual, calculamos el equilibrio y añadimos una restricción de capacidad. Precios, volúmenes y rendimiento numérico son supuestos didácticos, no tarifas actuales, presupuestos ni medidas de un ordenador. No ejecutamos modelos ni pruebas de carga. Sí ejecutamos cálculos de coste y sensibilidad, guardando resultados y figuras. No recomendamos proveedor: explicamos qué evidencia recoger y cuándo una comparación favorable está incompleta.
Primero hacer comparables los servicios
Una petición debe representar el mismo trabajo en ambas vías: objetivo, documentos comparables, calidad mínima y tiempo aceptable. Si el modelo local responde rápido pero exige corrección y el remoto resuelve la tarea, el coste por llamada no compara servicios equivalentes. Contar solo tokens, unidades de texto procesadas, también puede engañar: trabajo y longitud de respuestas varían. Abajo suponemos peticiones homogéneas; los datos reales necesitan clases de carga o un coste medio ponderado por la mezcla de casos.
FinOps Foundation distingue métricas de eficiencia de recursos y de resultados de trabajo. Ayuda a elegir denominador, pero no demuestra que la nube sea más barata ni que la IA aporte valor a una empresa concreta. Ecuaciones y escenarios son análisis nuestros, no resultados de la Foundation.
Separar disponibilidad y utilización
F es el coste mensual de mantener disponible una vía aunque no lleguen solicitudes; v es el coste adicional medio de una petición homogénea. En local F puede incluir asignación económica de máquina, gestión y capacidad reservada; en remoto, integración y compromisos mínimos. El trabajo humano no siempre es fijo y la energía no siempre variable: clasificar según comportamiento real. Comprar con efectivo disponible no elimina el coste de uso ni su posible dedicación a otra tarea.
Usar un horizonte común. No comparar una compra inicial con una factura mensual sin explicar vida útil, mantenimiento y valor residual. Coste mensual equivalente y flujo de caja responden preguntas distintas. Aquí F es un parámetro mensual supuesto, no depreciación fiscal ni oferta. Los gastos iniciales deben distribuirse o mostrarse aparte con hipótesis claras. No contar dos veces compra y cuota asignada de esa misma compra.
El modelo más sencillo que podemos verificar
N son peticiones mensuales y C euros del mes. L y C indican local y nube; F está en euros mensuales y v en euros por petición. Para un mes fijo sumamos disponibilidad y uso. Se supone v constante, sin saltos de capacidad y con igual mezcla de peticiones. Tramos, descuentos, caché y autoescalado requieren otras funciones; no caben mágicamente en una recta universal.
Usamos F_L = 600 euros/mes y v_L = 0,0002 euros/petición; F_C = 50 y v_C = 0,005 en las mismas unidades. Son valores inventados para ilustrar. Con 1000 peticiones, local cuesta 600,20 euros y nube 55; al dividir entre mil salen 0,6002 y 0,055 euros por petición, incluidos fijos. Con cero peticiones quedan 600 y 50 euros, pero el coste por petición es indefinido. Llamarlo cero cuando nadie usa el sistema ocultaría el coste inactivo que queremos evaluar.
El equilibrio: un umbral condicionado por supuestos
Para igualar costes imponemos C_L = C_C y separamos términos fijos y proporcionales. Si local tiene fijo mayor y variable menor, el volumen puede compensar la diferencia. Solo dividimos si v_C difiere de v_L. Con variables iguales no existe ese umbral: deciden los fijos. Un resultado negativo no es un objetivo positivo de clientes; hay que ver qué curva domina para N no negativo.
El equilibrio continuo es unas 114583,33 peticiones/mes. En enteros y bajo estos supuestos exactos, local resulta más barato desde 114584. No significa que deba comprarse una máquina: falta viabilidad. El cálculo explicita la hipótesis de demanda. Con 100000 peticiones son 620 frente a 550 euros, favorable a nube; con 200000, 640 frente a 1050, favorable a local solo en el modelo de coste. La tabla conserva volúmenes mayores para mostrar cuándo la aritmética excede la viabilidad operativa.
| N/mes | Local (€) | Nube (€) | Local €/pet. | Nube €/pet. | N ≤ K (1/0) |
|---|---|---|---|---|---|
| 0 | 600.00 | 50.00 | — | — | 1 |
| 1000 | 600.20 | 55.00 | 0.600200 | 0.055000 | 1 |
| 10000 | 602.00 | 100.00 | 0.060200 | 0.010000 | 1 |
| 100000 | 620.00 | 550.00 | 0.006200 | 0.005500 | 1 |
| 200000 | 640.00 | 1050.00 | 0.003200 | 0.005250 | 1 |
| 1000000 | 800.00 | 5050.00 | 0.000800 | 0.005050 | 0 |
En la última columna, 1 solo indica que N no supera K nominal; 0 indica que lo supera. No juzga calidad del modelo ni cumplimiento de latencia.
Una máquina económica puede ser insuficiente
Añadimos capacidad local supuesta de 0,5 peticiones por segundo durante 160 horas mensuales. No afirmamos ese rendimiento de modelo o placa reales. Tasa por duración da capacidad nominal: 288000 peticiones. Es condición necesaria para procesar el mes, no garantía sobre colas, memoria o plazos. Un millón cuesta formalmente 800 euros en la recta local frente a 5050 en nube, pero supera capacidad local supuesta. No es un presupuesto válido para atender un millón: hay que recalcular una arquitectura capaz.
Incluso 200000 peticiones bajo el límite pueden llegar mal distribuidas. Si por la mañana llegan dos por segundo y se completan 0,5, la cola crece 1,5 por segundo durante ese tramo. La capacidad nocturna libre no responde antes al usuario matinal. Se puede aplazar trabajo no urgente, ampliar capacidad o usar vía híbrida; todo cambia costes y requisitos. No simulamos esta cola ni damos percentiles de latencia. El contraejemplo solo demuestra que la media mensual no certifica el servicio.
El histórico MLPerf Inference Benchmark de Reddi y colaboradores, preprint v1 de noviembre de 2019, distingue procesamiento offline y servicio con latencia acotada. Es contexto metodológico, no clasificación actual ni comparación local/nube de nuestra tarea. No reproducimos pruebas ni resultados.
¿Cuánto cambia la conclusión si estimamos mal?
El fijo local suele discutirse: el equipo existente parece gratis y un sistema con soporte puede exigir más trabajo. Manteniendo lo demás, F_L = 300 euros da equilibrio de unas 52083,33 peticiones; con 1200, 239583,33. No estimamos tres productos: aislamos un parámetro. Tal sensibilidad exige medir y justificar el coste antes de dar umbrales precisos. Más decimales no vuelven fiable una hipótesis incierta.
Las curvas izquierdas son cálculos, no ofertas. El tramo local sobre 288000 va discontinuo porque supera capacidad nominal del servicio supuesto; no es un precio disponible. El equilibrio ocurre antes, pero no certifica latencia ni calidad. Las tres barras derechas muestran cómo cambia el umbral con el fijo. Son preguntas distintas: dónde se cruzan curvas y cuánto depende esa posición de los supuestos.
Del coste por llamada al coste por trabajo utilizable
Si solo parte de las respuestas sirve, cambiar denominador. U es el número de trabajos aceptables tras verificación independiente; C/U es coste tecnológico por trabajo útil. Revisión y reparación deben añadirse al numerador si se contabilizan. No tomar puntuaciones del modelo como probabilidades de corrección: U debe observarse con criterios iguales. No damos U porque no evaluamos modelos. Esa evidencia ausente importa y no debe rellenarse con números plausibles.
Los límites del servicio deben coincidir. El precio de inferencia puede excluir recuperación documental, almacenamiento, transferencia, autenticación y mantenimiento de búsqueda. Local puede necesitar respaldo, monitorización, actualizaciones y recuperación. Nube puede tener cuotas, compromisos, transferencias o dependencias contractuales que revisar. No atribuimos costes a todos los proveedores: verificar la oferta concreta. Datos sensibles y accesos requieren analizar el recorrido entero: local no significa protegido automáticamente y nube no define todos los flujos o políticas.
Una comparación reproducible antes de decidir
Para convertir cálculo en evaluación, fijar tareas autorizadas y criterio de aceptación. Repetir casos en las alternativas, registrando versiones de modelo y runtime, contexto, concurrencia y configuración. Medir hasta primera salida visible y hasta final utilizable, separando red, cola y cálculo cuando sea posible. Registrar mediana, percentiles, errores, reintentos y corrección. Son instrucciones para pruebas futuras, no resultados obtenidos aquí. Conservar fallos y casos fuera de alcance, no solo éxitos rápidos.
Probar demanda más allá de la media: solicitudes cortas y largas, picos plausibles y periodos inactivos. No evaluar como exclusivo un equipo compartido con otros procesos. Si se requiere disponibilidad durante mantenimiento, declarar redundancia y reserva, recalculando F y v. Una vía mixta trata parte local y parte remota, pero tiene costes de selección, doble integración y fallos en ambas. Incluir un flujo sin IA si resuelve con calidad y trabajo comparables.
Qué demuestra el código y qué decisión permite
El programa usa Decimal para dinero, calcula seis volúmenes y repite equilibrio con tres fijos locales. Es determinista, sin semilla. Las aserciones verifican nube más barata a 100000 y local a 200000 dentro de las rectas supuestas, además de capacidad nominal 288000. La precisión aritmética no reduce incertidumbre de precios inventados. JSON y figuras permiten cambiar hipótesis y revisar cuentas, no inferir rendimiento de la máquina de portada. Es ilustrativa, no una instalación EL-AI.
La respuesta no necesita eslóganes: local compensa mayor fijo solo si demanda útil, diferencia variable y capacidad lo permiten; nube puede convenir a poco volumen sin ser mejor para todo requisito. El equilibrio cae entre 100000 y 200000 peticiones, pero la capacidad local supuesta no atiende un millón y faltan pruebas de picos. Elegir requiere costes reales, tareas equivalentes y pruebas de alternativas. No demostramos ahorro empresarial, retorno ni superioridad de producto: construimos cuentas auditables que explicitan condiciones necesarias.
Fuentes y materiales reproducibles
FinOps Foundation — Unit Economics; consulted 28 October 2026.
MLPerf Inference Benchmark — version-specific bibliographic record.
from decimal import Decimal as D
from pathlib import Path
import json,sys
# All costs and capacity are invented scenario inputs, not current vendor prices.
FL,FC=D('600'),D('50');VL,VC=D('.0002'),D('.005')
volumes=[0,1000,10000,100000,200000,1000000]
rows=[]
for n in volumes:
local=FL+VL*n;cloud=FC+VC*n
rows.append(dict(monthlyRequests=n,localEUR=str(local),cloudEUR=str(cloud),localEURPerRequest=str(local/n) if n else None,cloudEURPerRequest=str(cloud/n) if n else None))
break_even=(FL-FC)/(VC-VL)
assert FL+VL*100000>FC+VC*100000
assert FL+VL*200000<FC+VC*200000
assert FL+VL*114583>FC+VC*114583 and FL+VL*114584<FC+VC*114584
assert D('2')-D('.5')==D('1.5')
capacity=D('.5')*D('160')*3600
assert capacity==288000
sensitivity=[dict(localFixedEUR=str(f),breakEvenRequests=str((f-FC)/(VC-VL))) for f in [D('300'),D('600'),D('1200')]]
assert sensitivity[0]['breakEvenRequests'].startswith('52083.') and sensitivity[2]['breakEvenRequests'].startswith('239583.')
result=dict(sensitivity=sensitivity,python=sys.version.split()[0],seed=None,scope='Hypothetical equal-workload monthly cost arithmetic; no vendor quotation, hardware throughput, model quality or investment return measured',assumptions=dict(localFixedEUR=str(FL),cloudFixedEUR=str(FC),localVariableEURPerRequest=str(VL),cloudVariableEURPerRequest=str(VC),localAssumedRequestsPerSecond='.5',assumedHoursPerMonth='160'),breakEvenRequests=str(break_even),nominalMonthlyCapacityRequests=str(capacity),peakIncomingRequestsPerSecond='2',peakExceedsAssumedCapacity=True,rows=rows)
Path(__file__).with_name('results.json').write_text(json.dumps(result,indent=2),encoding='utf8')
print(json.dumps(result))
Código, datos e instrucciones · JSON. Cálculos didácticos ejecutados con Python 3.14.0; figuras con Matplotlib 3.11.2. Análisis asistido por IA, sin afirmar revisión por pares ni humana. Portada original ImageGen ilustrativa: no documenta personas, sedes ni instalaciones de EL-AI. Fuentes consultadas el 28 de octubre de 2026.