LLM autoalojado o API: cómo comparar el coste total del equipo
Un método práctico para comparar LLM autoalojado y API por carga real, no solo por el precio de la GPU o de los tokens.
Índice
El precio de una GPU y la tarifa por millón de Token no representan el coste completo. Un modelo local necesita capacidad, actualizaciones, observabilidad, seguridad, respaldo y tiempo de ingeniería. Una API reduce parte de esa operación, pero mantiene costes de uso, integración, límites y dependencia de un Endpoint externo. Compare ambas opciones con las mismas tareas y el mismo umbral de calidad. El objetivo no es proclamar un ganador universal, sino elegir una configuración reversible para su equipo.
1. Fije primero el workload y el nivel de calidad
Elija entre 3 y 5 tareas recurrentes: clasificar documentos con una schema fija, consultar una base interna, revisar código ejecutando un test, generar un informe estructurado o procesar lotes en segundo plano. Para cada tarea anote tamaño de entrada y salida, ejecuciones de un día normal, concurrencia máxima, tiempo permitido y criterio de aceptación. Puede exigir JSON válido, fuentes verificables o un test aprobado.
| Escenario | Ejecuciones/día | Concurrencia pico | Input / Output | Tiempo permitido | Criterio de calidad |
|---|---|---|---|---|---|
| Clasificación | schema valid | ||||
| Revisión de código | test aprobado | ||||
| Búsqueda interna | fuentes verificadas |
Use tarifas actuales para la comparación de API. Compruebe los modelos y precios de BetterToken antes de incorporarlos al cálculo de TCO. Ver precios actuales de BetterToken
Como rama API medible, el Dashboard de BetterToken muestra hora, modelo, estado HTTP, input, output, cache Token y cargo. Compruebe los modelos y tarifas actuales, abra el Workspace y lleve al cuadro los datos observados del piloto. BetterToken no es una plataforma de self-hosting: aquí representa únicamente una alternativa API.
2. TCO autoalojado: cuente más que la GPU
Mida un ciclo operativo completo, con varios días normales y al menos un pico previsto:
self_hosted_tco =
hardware_amortization
+ hosting_and_electricity
+ storage_and_network
+ engineer_time
+ monitoring_and_security
+ backup_or_overflow
+ incident_costUse la configuración que realmente desplegaría, su amortización y memoria disponible. Una cifra publicada puede omitir chasis, red, redundancia, envío o electricidad local. Compruebe que modelo y contexto caben sin cambiar la tarea ni rebajar la calidad. Registre horas de instalación del runtime, verificación del modelo, serving, actualizaciones, profiling, colas, observabilidad, control de acceso e incidentes.
El alojamiento local puede dar más control sobre la ubicación de datos, pero no aporta seguridad automáticamente. Incluya parches, secretos, segmentación de red, audit logs, copias y acceso administrativo. Mida indisponibilidad y trabajos pendientes. Un segundo nodo, una cola de recuperación o una API aprobada para overflow no sensible también cuestan. Si ciertos datos no pueden salir, trátelo como restricción obligatoria.
3. TCO de API: los Token son solo el comienzo
Normalice el usage según la schema real del provider y no duplique cache Token incluidos en input.
api_tco =
uncached_input_cost
+ cache_read_cost
+ cache_write_cost
+ output_cost
+ retry_cost
+ integration_and_operations
+ incident_or_fallback_costAntes del piloto, elija un Model ID disponible para su key y anote en la tabla sus tarifas actuales del catálogo de BetterToken. Calcule cache read/write solo con la usage schema efectiva y las tarifas actuales indicadas por separado; no sustituya por cero un valor ausente. Añada integración, gestión de 401/429/5xx, retries limitados, colas, observabilidad y validación.
4. Separe carga normal y pico
- Normal: flujo típico de una semana laboral.
- Pico: concurrencia y lote definidos de antemano, sin desactivar controles de calidad.
| Métrica | Autoalojado: normal / pico | API: normal / pico |
|---|---|---|
| Resultados aceptados | / | / |
| Tiempo p50 / p95 | / | / |
| Errores y retries | / | / |
| Horas de ingeniería | / | / |
| Coste del periodo | / | / |
Estas mediciones describen solo la configuración probada; no prometen estabilidad futura.
5. Ejecute un piloto reversible
No migre todo el producto. Elija un escenario, conserve una interfaz común y coloque cada provider tras un adaptador. Fije entradas, calidad y datos prohibidos; ejecute la misma muestra; mida normal y pico; contabilice Token, infraestructura y horas en igual periodo; simule la caída del nodo local y de la API externa; repita tras cambios de configuración. No incluya API Key, .env, prompts privados ni respuestas sensibles completas en el informe.
6. Decisión y criterios de salida
El autoalojamiento puede encajar si la ubicación de datos es obligatoria, el workload es estable y el equipo asume operaciones. Una API puede encajar con carga variable, necesidad de arrancar rápido o sin equipo para mantener el runtime. Un diseño híbrido puede dejar datos sensibles en local y enviar picos o casos permitidos a la API.
- Detenga el piloto local si no alcanza calidad, pico o actualización dentro de las horas disponibles.
- Detenga el piloto API si los datos obligatorios no pueden salir o el coste por tarea aceptada es inmanejable.
- Recalcule al cambiar modelo, tarifa, hardware o workload.
- No acepte un total menor obtenido reduciendo calidad o eliminando fallback.
El resultado debe ser una tabla TCO fechada con configuración, calidad, pico y responsable, no una disputa abstracta entre servidor y nube.
Fuentes
- Modelos y precios actuales de BetterToken
- Documentación de BetterToken
- BetterToken Product Fact Sheet
