Skip to content

English · Español

Lab 03 — Tabla FinOps: coste por unidad de calidad para el tutor de gramática

Objetivo: calcular docs/COSTS.md — una fila por modelo registrado del tutor de gramática con precisión de conjugación, cost-per-1k-tokens y CpQU.

Tiempo estimado: 2–3 horas.

Prerequisito: lab 00 hecho (registry tiene ≥ 3 entradas); lab 01 hecho (existen datos de latencia); el harness de evaluación de la Fase 20 puede puntuar cada entrada contra la tabla canónica de conjugación.

Lo que produces

experiments/38-finops/ conteniendo:

  • compute.py — driver que lee el registry, corre evaluación, calcula costes.
  • cost_inputs.json — inputs de hardware-rate y timing registrados manualmente.
  • cpqu.json — los números por entrada.
  • manifest.json.

Además, fuera del directorio del experimento:

  • docs/COSTS.md — la tabla FinOps. Commiteada al sitio de docs.

TODOs

Bloque A — recolecta inputs de coste

Para cada SHA canónico de modelo registrado (el lab 00 produjo ≥ 3):

  • Tarifa hardware-hora. Sobre el i5-8250U local de Borja (CPU-only): usa $0.05/hr como tarifa amortizada de electricidad + hardware (coincide con la tarifa nocional de la Fase 34). Registra en cost_inputs.json con un comentario.
  • Tokens-por-segundo por modelo. Desde los benchmarks de servicio de la Fase 33, o corriendo un test de throughput de 60 segundos sobre cada variante de modelo contra un sub-set fijo de 200 frases de la Fase 20. Registra en cost_inputs.json.
  • Precisión de conjugación. Corre el eval set de la Fase 20 contra cada modelo; captura el conjugation_accuracy agregado más los desgloses por bucket (por tiempo, por persona, por verbo). Guarda el reporte de evaluación completo en cost_inputs.json bajo cada SHA.

Bloque B — calcula cost-per-1k-tokens

Para cada SHA canónico \(s\):

\[\text{cost\_per\_1k}_s = \frac{\text{rate}_\$\text{/hr}}{\text{tps}_s \cdot 3.6}\]

(3.6 porque tokens/sec × 3600 sec/hr / 1000 tokens-per-k = ratio 3.6.)

  • Calcula y guarda en cpqu.json indexado por SHA canónico.

Bloque C — calcula CpQU

Para cada SHA:

\[\text{CpQU}_s = \frac{\text{cost\_per\_1k}_s}{\text{conjugation\_accuracy}_s}\]
  • Añade a cpqu.json. Más bajo es mejor.
  • Guarda: si conjugation_accuracy < 0.30, marca CpQU como "not-deployment-ready" y omite la división — el resultado sería un número engañosamente grande conducido por un denominador cercano a cero.

Bloque D — emite docs/COSTS.md

  • Crea o actualiza docs/COSTS.md con una fila por SHA canónico registrado:
| SHA (8) | Semver | Conjugation accuracy | $/1k tokens | CpQU | Notes |
|---|---|---|---|---|---|
| `a1b2c3d4` | v0.1.0 | 0.752 | 0.0098 | 0.0130 | FP32 baseline (Phase 18), no grammar-tutor specialization |
| `e5f6a7b8` | v0.2.0 | 0.748 | 0.0042 | 0.0056 | INT8 (Phase 26), 0.4pp drop |
| `c9d0e1f2` | v0.3.0 | 0.781 | 0.0114 | 0.0146 | LoRA grammar tutor (Phase 28) |

(Los números son ilustrativos — los números reales de Borja vienen de sus mediciones.)

  • Debajo de la tabla, escribe 2–3 párrafos sobre:
  • Qué entrada tiene el mejor CpQU. Usualmente INT8 — precisión similar, cómputo más barato. Indica si tus datos confirman.
  • Qué entrada tiene la mejor precisión cruda de conjugación. Usualmente el tutor de gramática LoRA (el punto entero de la Fase 28), pero a mayor CpQU.
  • Caveat por bucket. La precisión agregada esconde diferencias por tiempo y por verbo. Anota cualquier bucket donde el modelo "mejor" no sea el LoRA — esas son áreas que el LoRA empeoró.
  • Recomendación operacional. Dadas las restricciones de deployment de Borja (el capstone de la Fase 39 corre sobre una instancia CPU pequeña, quizás una sola GPU cloud como máximo), cuál sería el modelo de servicio default y cuál sería el modelo tier premium.

Bloque E — cerrar el bucle con el lab 01

  • Revisita experiments/38-shadow-ab/report.md y rellena la recomendación operacional anteriormente placeholder, usando los números CpQU de este lab más los desgloses por bucket de conjugación.

Bloque F — manifest + Justfile

  • manifest.json registra: lista de SHAs canónicos del registry usados; tarifa hardware; hash DVC del eval set de la Fase 20; metodología de tokens-por-segundo.
  • Añade just cpqu al Justfile — invoca scripts/mlops/cpqu.py que lee el registry, corre la evaluación, regenera docs/COSTS.md. Idempotente.

Restricciones

  • Un único eval set. Todas las filas CpQU comparten el mismo eval set de la Fase 20 (verificado vía hash DVC). Si cambias el eval set, cambia el denominador y las filas son incomparables. Documenta el hash DVC del eval set en el manifest.
  • Sin API de cloud cost. Los costes se registran a mano. La integración con billing de AWS/GCP está fuera de scope (ver PHASE_38_PLAN.md open question f).
  • Sin latencia en CpQU. CpQU es coste vs calidad. La latencia vive en el reporte del lab 01. No los mezcles.
  • Sin nuevo src/<module>/. cpqu.py vive en scripts/mlops/.

Condiciones de parada

Hecho cuando:

  1. docs/COSTS.md existe y tiene ≥ 3 filas.
  2. El reporte del lab 01 tiene su recomendación operacional rellenada.
  3. cpqu.json está commiteado y coincide con la tabla.
  4. just cpqu regenera docs/COSTS.md determinísticamente.

Pitfalls

  • CpQU engañoso cuando la precisión es cercana a cero. Añade el guard del Bloque C — si la precisión < 0.30, reporta "not deployment-ready", no un número CpQU.
  • Comparar CpQU entre eval sets distintos. No lo hagas. Bloquea el eval set per docs/COSTS.md; si cambia, recalcula todas las filas.
  • Inflación de la tarifa de hardware. Si migras de la tarifa nocional del laptop a una tarifa cloud real en la Fase 39, los números absolutos de CpQU se desplazan uniformemente. El ranking se preserva, pero sé explícito sobre qué tarifa se usó.
  • Por bucket vs agregado. Un modelo que gana el CpQU agregado podría ser 10pp peor en conjugaciones de participio pasado — un problema si la cohorte real de aprendices se enfoca en participios pasados. Siempre lee la evaluación por bucket antes que la tabla.
  • Tokens-por-segundo sobre una máquina ruidosa. Los procesos en background sobre el laptop de Borja perturbarán tps. Corre el test de throughput con nice -n 19 y 3–5 repeticiones; registra la mediana.

Cuándo consultar solutions/

Tras los seis bloques. solutions/03-finops-ref.md (apertura de fase) revisa la formulación CpQU, el comentario por bucket y el layout de docs/COSTS.md para claridad.

Siguiente lab: lab/04-ci-deploy-gate.md.