El segundo riesgo es el que de verdad muerde a quien está aprendiendo. Un endpoint desplegado para una prueba de media tarde sigue facturando en septiembre si nadie lo borra, y no manda ningún aviso: no hay error, no hay log, solo una línea en la factura. Por eso los pasos de limpieza de la guía llevan la advertencia en mayúsculas.
// borra el endpoint al terminar: es la única parte del tutorial que cuesta dineroLas dos curvas se cruzan, y la forma del argumento es lo que hay que retener: una tarifa plana se amortiza con volumen y una por uso no. A poco tráfico, pagar por token es casi gratis y mantener una instancia encendida es absurdo; a mucho tráfico, la tarifa plana se reparte entre tantas peticiones que el coste unitario se desploma.
La guía ilustra el cruce con un clasificador de tickets y estas cifras, que presenta sin mostrar la aritmética ni la fecha:
| Enfoque | Coste mensual declarado (10.000 tickets) | Lo que la tabla no dice |
|---|---|---|
| Modelo propio en un endpoint | ~$50 | Es el mismo $50 con 10 tickets que con 10.000 |
| Pasarela, modelo económico | ~$15 | Escala en línea recta: 100.000 tickets son ~$150 |
| Pasarela + fine-tuning | ~$20 + coste de ajuste | El «coste de ajuste» no se cuantifica |
Su conclusión —poco volumen, pasarela; mucho volumen, modelo propio— se sostiene. Las cifras concretas no se pueden usar: no hay fecha, no hay desglose y los precios de ambas columnas cambian varias veces al año. Lo reutilizable es el método: estima tokens por petición, multiplica por peticiones al mes, y compáralo con el precio por hora de la instancia más pequeña que aguante tu latencia.
| Partida | A quién afecta | Por qué se olvida |
|---|---|---|
| Etiquetar los datos | Solo al modelo propio | Es trabajo de personas, no una línea de factura |
| Entrenar y reentrenar | Solo al modelo propio | Se paga a saltos, no todos los meses |
| Almacenamiento de datos y artefactos | Sobre todo al modelo propio | Es barato por unidad y se acumula en silencio |
| Tiempo de ingeniería para mantenerlo | Al modelo propio, mucho más | No aparece en ninguna calculadora de la nube |
| El endpoint de pruebas olvidado | A cualquiera | Nadie lo planifica: por eso pasa |
Sumadas, estas partidas desplazan el punto de cruce bastante más arriba de lo que sugiere una comparación de precios de cómputo. La propia guía reconoce «necesitas datos etiquetados» como desventaja del modelo propio y no le pone precio — y suele ser la partida más cara de todas.
# Eliminar endpoint (IMPORTANTE - cuesta dinero si queda activo) — que contradice la
tabla dos páginas antes sin señalarlo. Antes de creerte la etiqueta, haz la pregunta que la
resuelve: si no llega ni una petición en todo el mes, ¿cuánto cuesta esto? Si la respuesta no
es cero, es un servidor con otro nombre.
Coge un caso tuyo y haz dos números. Uno: tokens de entrada y salida por petición (mídelos, no los estimes) por el precio actual del modelo que usarías, por peticiones al mes. Dos: el precio por hora de la instancia más pequeña que aguante tu latencia, por 730 horas.
Divide el segundo entre el coste por petición del primero y tendrás el volumen mensual al que se cruzan. Compáralo con tu tráfico real. Si estás un orden de magnitud por debajo del cruce —y casi siempre lo estás— la decisión está tomada, y todo el trabajo de entrenar un modelo propio habría sido para ahorrar dinero que no estabas gastando.