English · Español

04 — Matemática del $/token: auto-alojado vs servido por API; el presupuesto (budget) de RPS de §A13¶

🇪🇸 ¿Cuánto cuesta una corrección del tutor §A13? Depende: si lo auto-alojamos en el i5-8250U el coste es electricidad + amortización, no por-token. Si lo serviésemos por una API comercial (no lo haremos — anti-objetivo §10), el coste por token sería real y medible. Esta página hace ambas cuentas y deriva el RPS estable que el portal §A14 espera.

Dos modelos de coste, ambos útiles¶

Modelo A — auto-alojado (lo que realmente hacemos)¶

El tutor de gramática §A13 se ejecuta en el portátil de Borja. El coste marginal por petición es electricidad + desgaste de la máquina, no "tokens de salida × $precio". Números (i5-8250U, a plena carga):

TDP bajo carga del tutor: ~25 W de media (el modelo es pequeño; no estamos saturando la CPU).
Potencia de pared incluyendo pérdidas de la PSU, pantalla, periféricos: ~45 W.
Tarifa eléctrica (residencial ES, 2026): ~0,16 €/kWh.
Coste por hora a plena carga: $0.045 \cdot 0.16 = 0.0072$ €/hora ≈ 0,7 céntimos/hora.

Si el tutor está inactivo la mayor parte del día y dispara al 100 % durante 1 hora de tutoría (un aprendiz), el coste marginal diario es < 1 céntimo. El coste de capital amortizado (portátil / 5 años) es la línea dominante — y es un coste hundido que Borja ya pagó. A esta escala, el auto-alojamiento es efectivamente gratis.

Modelo B — servicio por API hipotético (no hacemos esto)¶

Si estuviéramos alquilando inferencia de clase GPT-4 en lugar de auto-alojar, la matemática es más familiar. A mediados de 2026, una API de clase GPT-4-mini cotiza ~$0,15 por 1M tokens de entrada, ~$0,60 por 1M tokens de salida. Para una petición típica del tutor:

Entrada: prompt de sistema (≈ 200 tokens) + frase del usuario (≈ 24 tokens) = 224 tokens.
Salida: corrección (≈ 16 tokens) + glosa en español (≈ 8 tokens) = 24 tokens.
Coste por petición: $224 \cdot 0.15 \cdot 10^{-6} + 24 \cdot 0.60 \cdot 10^{-6} = 4.8 \cdot 10^{-5}$ USD ≈ 0,005 céntimos.

El auto-alojamiento gana en $/petición por un orden de magnitud solo porque el modelo §A13 es microscópico y corre en hardware ya pagado. Para un modelo de clase 7B en GPU, el cálculo se invierte — pagar el H100 amortizado de otro es más barato que comprar el tuyo propio hasta que lo saturas. El punto de equilibrio es la matriz de decisión MLOps estándar (la Fase 38 cubre esto).

La razón por la que auto-alojamos el tutor §A13: es parte del contrato pedagógico del currículo (CLAUDE.md §0.4, "construir antes de abstraer"). Podríamos ser más baratos alquilando; deliberadamente no lo hacemos.

El $/token no cuenta toda la historia¶

Tres costes que el precio por token oculta:

Egress / ancho de banda. Hacer streaming de 24 tokens de salida a ~6 bytes cada uno = 144 bytes. Despreciable en el cable; ~0,0001 céntimos a tarifas típicas de cloud. Pero multiplica por 10k aprendices × 100 peticiones/día y estás en 144 GB/día, que ya no es gratis.
Inactividad / reserva. Auto-alojado = pagas 24/7 incluso si está inactivo. API = pagas por llamada. El cruce para una carga de trabajo a escala del tutor §A13 es aproximadamente 1 petición/minuto: por encima, gana el auto-alojamiento; por debajo, gana la API en $.
Auditabilidad. Las respuestas de la API son los logs de otro. Para los requisitos de logging de auditoría de la Fase 37 / Fase 41, el auto-alojamiento nos da procedencia gratis; el servicio por API requiere que registremos cada request/response, lo cual es su propia línea de coste.

El presupuesto (budget) de RPS para el tutor de gramática §A13¶

Según LYNX_CORTEX_ADDENDUM.md §A14, el portal de la Fase 41 es el consumidor funcional del tutor. Carga esperada:

Cohorte multi-aprendiz: asumimos 30 aprendices concurrentes como objetivo de diseño (1 clase activa).
Tiempo de sesión activa por aprendiz: ~20 minutos/día de media.
Envíos por sesión: ~12 (ítems de quiz + reintentos de texto libre).
Envíos por día por aprendiz: ~12.
Envíos por día, cohorte: $30 \cdot 12 = 360$.
Dentro de la ventana de 20 min, tasa pico de ráfaga: $12 / (20 \cdot 60) = 0.01$ envíos/aprendiz-segundo.
RPS pico de cohorte (todos hacen clic a la vez — peor caso): $30 \cdot 1$ = 30 RPS durante ~1 segundo, luego vuelta a ~0,3 RPS.

Estado estable realista durante una clase: 0,3 - 1 RPS, picos de 5-10 RPS durante transiciones de quiz. Con el batching de la Fase 33 (lab 03), el servidor maneja ~30 RPS cómodamente en el presupuesto (budget) de latencia calculado en teoría 05. Margen de capacidad: ~3-10×.

Leyendo esto en la otra dirección: el presupuesto da el coste. Si quisiéramos dimensionar para una cohorte de 100 aprendices (3,3× el objetivo de diseño), tocaríamos el techo del batching en el pico y necesitaríamos (a) un MAX_INFLIGHT mayor (más memoria por réplica) o (b) una segunda réplica (la práctica blue/green / horizontal-scale de la Fase 38).

La métrica $/pregunta-de-quiz (a nivel de portal)¶

El portal expone un botón "explicar" por pregunta que llama al tutor. Coste en el peor caso por sesión de quiz:

12 explicaciones × ~150 ms de tiempo de pared = 1,8 segundos de cómputo.
En el Modelo A auto-alojado: ~$3.6 \cdot 10^{-6}$ en electricidad. Esencialmente cero.
En el Modelo B API hipotética: ~$5.8 \cdot 10^{-4}$ ≈ 0,06 céntimos por sesión.

Incluso con 10k sesiones/mes, el Modelo B es < $6/mes. El coste de ejecutar el tutor queda eclipsado por el coste de construirlo. Esa proporción solo se invierte a muy gran escala, lo cual la Fase 41 no apunta explícitamente.

Datos de observabilidad (observability) de los que dependen los números de coste¶

Para que lo anterior no sea ficción, la instrumentación de la Fase 34 debe exportar:

tutor_requests_total{outcome="success|error"} — counter.
tutor_input_tokens_total / tutor_output_tokens_total — counters (para la matemática de servicio por API que no usamos, pero queremos mantener honesta).
tutor_latency_seconds{quantile} — summary o histogram.
tutor_compute_seconds_total — counter para la matemática de coste (integra al tiempo de pared de CPU).
tutor_concurrent_inflight — gauge para el chequeo de margen derivado de la ley de Little.

El lab 03 (docs/phase-34-observability-cost/lab/03-cost-and-loadtest.md) cablea (1)-(4); (5) es el puente a la señal de backpressure /readyz de la Fase 33.

Reglas de ingeniería empíricas¶

Decisión	El auto-alojamiento gana cuando	La API gana cuando
Tamaño del modelo	< ~1B params (cabe en CPU/portátil)	≥ 7B (necesitarías un H100 igualmente)
Tasa de peticiones	> ~1 RPS sostenido	< ~1 RPS / con picos
Auditoría / soberanía de datos requerida	Sí	(solo proveedores con garantías de auditoría)
SLO de latencia < 100 ms intra-región	Auto-alojar cerca del usuario	A menudo pierde por impuesto de arranque en frío
Quieres aprender cómo funciona	Siempre	Nunca

El tutor de gramática §A13 satisface las cinco filas a favor del auto-alojamiento. Eso no es casualidad — el tema fue elegido (§A13) en parte porque sería una demostración limpia de auto-alojamiento.

Lo que este capítulo NO cubre¶

Modelos de coste de clúster — Fase 35 / X4 / X1 para la matemática del clúster.
Arbitraje regional de $/hr de GPU — Fase 38.
Estrategia de precios spot vs on-demand — Fase 38.
Atribución de coste por tenant en un portal multi-tenant — responsabilidad de la Fase 41; cross-ref docs/phase-41-learner-portal/theory/02-data-model.md.

Referencia¶

Ouyang et al., "Training language models to follow instructions with human feedback" (NeurIPS 2022) — paper de InstructGPT. Incluye la discusión de coste por token que se convirtió en la plantilla de precios de API.
Patterson et al., "Carbon Emissions and Large Neural Network Training" (2021). La cadena energía → $ → CO₂.

Siguiente: ../lab/03-cost-and-loadtest.md.