PróximamenteEl Entrenamiento de modelos estará disponible pronto en Scalata Enterprise. Enseñe a un modelo a responder como lo hace su equipo.Ver próximas novedades

Recursos/Entrenamiento de modelos/Prueba y despliegue de un modelo

Concepto

Serverless frente a dedicado

El servicio Serverless factura por token en capacidad compartida sin costo de inactividad; una implementación dedicada reserva GPU para su modelo y factura por cada hora que existe. Cuál resulta más económico depende de cuánto lo utilice.

Capítulo 94 min de lectura3 referencias

Qué es

Existen dos formas de ejecutar un modelo entrenado. Serverless (también llamado por token o bajo demanda) lo ejecuta en una capacidad que el proveedor comparte entre muchos clientes: usted envía solicitudes y paga por los tokens de entrada y salida, y cuando no envía nada, no paga nada. Una implementación dedicada reserva hardware exclusivamente para su modelo: siempre está cargado y listo, y usted paga por cada hora que exista.

ServerlessDedicado
Facturado porTokens de entrada y salidaHoras que existe la implementación
Costo de inactividadNingunoPrecio por hora completo
ArranqueGeneralmente inmediatoUn arranque en frío de varios minutos al crearse
CapacidadCompartida; sujeta a límites de tasaReservada; rendimiento predecible
DisponibilidadSolo para los modelos que el proveedor admite de esta formaLa mayoría de los modelos entrenados, incluidos los modelos abiertos

Comparativa de costes

el punto de equilibrio
serverless cost per day  = tokens per day × price per token
dedicated cost per day   = 24 × hourly price               (used or not)
break-even tokens/day    = 24 × hourly price ÷ price per token
uso (tokens por día)coste por díaPUNTO DE EQUILIBRIOSERVERLESS MÁS BARATODEDICADO MÁS BARATOdedicado: horas × precio por horaserverless: tokens × precio
El coste de serverless crece con cada token; una implementación dedicada cuesta lo mismo por hora, ya sea que responda a una pregunta o a un millón. Por debajo del punto de equilibrio, serverless es más barato; por encima, lo es la implementación dedicada — y una implementación dedicada inactiva se sitúa en el extremo izquierdo del gráfico, pagando la tarifa completa para nada.

La intuición: con una implementación dedicada, el coste por token es el precio por hora dividido por la cantidad de tokens que realmente procesa en esa hora. A plena carga, eso puede ser más barato que serverless. Con una carga baja, es mucho más caro, y una hora de inactividad tiene un coste infinito por token. Serverless tiene la forma opuesta: el precio por token es fijo, por lo que el coste se ajusta exactamente al uso.

¿Por qué no todo es serverless? El servicio compartido funciona manteniendo un modelo base cargado para muchos clientes. Algunos proveedores pueden conectar un pequeño adaptador con ajuste fino a ese modelo compartido por cada solicitud, lo que hace posible el servicio por token para modelos ajustados. Otros necesitan que todo el modelo ajustado esté cargado en su propio hardware —algo común en modelos abiertos y en ajustes finos completos— y entonces la implementación dedicada es la única opción. Algunos proveedores van más allá y exigen capacidad reservada para cualquier modelo personalizado.

Ejemplo práctico: precios ilustrativos, tres niveles de uso
  1. Supongamos (a modo ilustrativo, no son precios reales) un modelo serverless a $0,60 por millón de tokens y una implementación dedicada a $5 por hora, es decir, $120 al día.
  2. Punto de equilibrio: $120 ÷ $0,60 por millón = 200 millones de tokens al día.
  3. Un día de pruebas: 300 preguntas × 1.500 tokens = 450.000 tokens. Serverless: alrededor de $0,27. Dedicado: $120 por el día, o $10 si lo elimina después de dos horas.
  4. Un asistente interno con mucho tráfico: 50 millones de tokens al día. Serverless: $30. Dedicado: sigue siendo $120.
  5. Un producto de gran volumen: 500 millones de tokens al día. Serverless: $300. Dedicado: $120, si una sola implementación puede soportar la carga.

Cómo elegir

  • Utilice serverless cuando esté disponible y el uso sea bajo, incierto o en ráfagas — pruebas, evaluación, pilotos.
  • Utilice una implementación dedicada cuando el modelo solo se pueda servir de esa manera, cuando el tráfico constante esté por encima del punto de equilibrio, o cuando necesite capacidad y latencia garantizadas.
  • Establezca siempre una hora de finalización en una implementación dedicada que se utilice para pruebas, y elimínela cuando haya terminado. Los compromisos de semanas o meses pueden reducir el precio por hora, pero eliminan esa opción.

Errores comunes

  • Olvidar una implementación dedicada de prueba y pagar por días de horas de inactividad.
  • Comparar un precio por hora de una implementación dedicada con un precio por token de serverless sin realizar la conversión mediante el uso esperado.
  • Asumir que un modelo ajustado se puede servir por token porque su modelo base puede hacerlo.
  • Firmar un compromiso de capacidad a largo plazo para un modelo sobre el que todavía se está iterando.

Referencias y lecturas adicionales

Las fuentes externas se abren en una pestaña nueva.

  1. 01Increase model invocation capacity with Provisioned Throughput in Amazon BedrockAmazon Bedrock User Guide · docs.aws.amazon.comUn ejemplo real de capacidad reservada: se factura por horas hasta su eliminación, con compromisos opcionales.
  2. 02Inference EndpointsHugging Face docs · huggingface.coEndpoints dedicados para modelos abiertos, con escalado automático.
  3. 03Serverless computingWikipedia · en.wikipedia.orgEl modelo general de pago por uso y sus contrapartidas, como los arranques en frío.
ConceptoInferencia y despliegueLa inferencia consiste en utilizar un modelo para generar respuestas. Un modelo entrenado debe desplegarse primero —cargando sus pesos en el hardware detrás de un endpoint—, lo cual puede tardar minutos, y luego cuesta dinero por token o por hora.ConceptoPor qué los tokens determinan el costeCómo los recuentos de tokens se convierten en el precio de entrenamiento y de uso de un modelo, con números calculados, y qué factores reducen realmente la factura.ConceptoCuánto cuesta: cómo interpretar las cifrasEl trabajo de los modelos se factura de varias formas distintas, por lo que cada coste que muestra Scalata incluye un estado —Final, Estimado, Pendiente o No facturado— que indica en qué se basa la cifra.ConceptoCómo se factura el entrenamientoLa mayor parte del ajuste fino gestionado se factura por token procesado: los tokens del archivo de entrenamiento multiplicados por las épocas y por un precio. En cambio, los trabajos en GPU alquiladas se facturan por tiempo. El uso posterior del modelo supone un coste aparte.Mejor práctica¿Cabrá el modelo? Memoria para el entrenamientoEl entrenamiento necesita espacio para los pesos del modelo, sus gradientes y el estado del optimizador, además de la memoria de trabajo. Una regla general sencilla, de unos 2 GB por cada mil millones de parámetros para LoRA y 12 GB para el ajuste fino completo, le indica antes de empezar si un modelo cabrá en su máquina.MétodoLoRA y adaptadores (PEFT)LoRA congela el modelo base y entrena dos pequeñas matrices junto a las capas seleccionadas, cuyo producto se suma a los pesos congelados. Reduce drásticamente los pesos entrenables y la memoria y, si se configura bien, iguala al ajuste fino completo en conjuntos de datos de ajuste fino típicos.

Convierta semanas de trabajo experto en minutos

Vea cómo Scalata se adapta a su equipo, a sus datos y a sus Controles.

Contactar con ventas