Dimensiona GPUs de inferencia por tokens por segundo por dólar, no por tamaño de modelo
Elige la GPU más barata que mantenga la latencia, el margen de memoria y el costo por token dentro de tu perfil real de longitud de tokens y aciertos de caché.
La compensación es simple: cuando la capacidad excede lo que una carga de trabajo necesita, la utilización disminuye y el costo por token aumenta.
Trata el dimensionamiento de GPU como la asociación del caso de uso a una huella de GPU basada en el comportamiento real de la carga de trabajo, no en conjeturas. La elección del dispositivo sigue esa distribución, no al revés. La huella debe compararse con el perfil real de longitud de tokens y aciertos de caché que la carga de trabajo utiliza realmente.
Costos
Una mayor tasa de aciertos de caché puede reducir TTFT, el costo por solicitud y la capacidad de GPU necesaria para el mismo tráfico. Esto mantiene la decisión de capacidad como una decisión de costo, no como conjetura.
Comienza con la hoja de cálculo de cinco números. Las entradas son tokens de entrada/salida, tasa de aciertos de caché, tamaño de lote, nivel de cuantización y costo propio o alquilado. Si tu tráfico reutiliza prompts de sistema repetidos, prefijos de documentos o contexto de varios turnos, incluye la tasa de aciertos de caché en la hoja de cálculo antes de elegir una GPU, no después del primer incidente de latencia. Las salidas son tokens por segundo por GPU, dólares por token, margen de memoria y utilización de punto de equilibrio. El margen de memoria es la diferencia entre la memoria disponible y la estimación de memoria. Mantén la hoja de cálculo en las mismas unidades que tu sistema de facturación, porque el número que importa a finanzas no es el throughput bruto; es el costo de inferencia de un token visible para el usuario. Calcula los tokens por segundo por GPU a partir de la forma real de tu lote. Una forma útil es el tamaño de lote multiplicado por los tokens de salida por solicitud, dividido por el tiempo para completar ese lote. No uses una sola solicitud a la vez si en producción se agruparán solicitudes. No uses un prompt sintético si los prompts de producción son más largos. Longitudes más largas de tokens de entrada y salida aumentan la demanda de memoria y cómputo de GPU. Los dólares por token son el costo de GPU por hora dividido por los tokens por hora de GPU. Si alquilas, usa la tarifa horaria de la clase de instancia exacta. Si es propia, usa el costo propio del dispositivo. La hoja de cálculo debe mostrar el punto de quiebre donde la capacidad reservada o propia supera a la bajo demanda, y el nivel de utilización donde la capacidad adicional empieza a pagarse a sí misma. La utilización de punto de equilibrio es la proporción de capacidad que debe estar ocupada para que el costo propio o reservado supere a una huella más pequeña o bajo demanda. Una vez que esas fórmulas estén en su lugar, la GPU de inferencia correcta es el dispositivo más barato que mantiene la latencia, el margen de memoria y el costo por token dentro de tu perfil de longitud de tokens y aciertos de caché. Eso mantiene la elección del dispositivo vinculada a la aritmética, no al tamaño del modelo. La hoja de cálculo debe volver a ejecutarse cuando cambie el perfil de longitud de tokens y aciertos de caché, y la utilización de punto de equilibrio debe volver a verificarse.
Modelos
La elección del modelo es una palanca de costo, no solo una palanca de calidad. La cuantización, la poda y la destilación pueden mejorar el rendimiento al reducir TCO. La compensación merece considerarse cuando los efectos de rendimiento y costo son favorables. Si el modelo más pequeño cumple el requisito del producto, un modelo destilado puede ser suficiente. Si la pérdida de calidad es inaceptable, la compensación no vale la pena.
No dimensiones la GPU a partir del número de parámetros del modelo. Incluye pesos, caché KV, activaciones y sobrecarga de lote en la estimación de memoria. El contexto largo y la alta concurrencia pueden cambiar la estimación de memoria lo suficiente como para invertir la elección del dispositivo. La hoja de cálculo te obliga a comparar el estado real de servicio, no la ficha del modelo.
La cuantización también cambia la aritmética de memoria. Si estás eligiendo entre un modelo de mayor precisión y un modelo de menor precisión, pasa ambos por el mismo perfil de longitud de tokens y aciertos de caché. El ganador es el que mantiene la latencia y el margen de memoria dentro del requisito del producto con los dólares por token más bajos.
Servicio
Para tráfico en estado estacionario, la regla de capacidad es aburrida y correcta. Establece una línea base de capacidad local o de GPU en la nube reservada para cargas de trabajo en estado estacionario. Eso puede ayudar a alinear la capacidad con las cargas de trabajo en estado estacionario. Si tu tráfico tiene picos, no compres el pico como una línea base permanente. La línea base debe estar vinculada al perfil real de longitud de tokens y aciertos de caché, y el objetivo de utilización debe volver a verificarse.
La utilización es el número que te dice si el diseño de servicio es honesto. Si la GPU está mayormente inactiva, el costo por token se infla por el costo fijo del dispositivo. Si la GPU está al límite, la latencia se degradará antes de que notes el problema de costo. El objetivo no es la utilización máxima. El objetivo es la utilización que mantiene la latencia dentro del requisito del producto mientras deja suficiente margen de memoria para el crecimiento de caché y lote.
Ejecuta la hoja de cálculo en tres estados: normal, pico y degradado. Normal es el tráfico que esperas la mayor parte del tiempo. Pico es el tráfico que debes soportar sin perder calidad. Degradado es el estado donde la capacidad disponible se reduce o el rendimiento del modelo es más lento. La salida debe ser un rango, no un solo SKU. Si el rango es amplio, tu carga de trabajo no es lo suficientemente estable para una huella fija, y necesitas una política de servicio que pueda mover solicitudes entre clases de dispositivos.
La verificación final es simple: la salida de la hoja de cálculo es la regla de decisión. Si la hoja de cálculo no puede atender el perfil real de longitud de tokens y aciertos de caché con la latencia objetivo y suficiente margen para absorber el crecimiento, la GPU es demasiado pequeña y mostrará problemas de latencia y margen de memoria. Si la hoja de cálculo muestra que estás pagando por capacidad que la carga de trabajo no usa, la GPU es demasiado grande y mostrará silicio inactivo y un costo por token más alto. El tamaño correcto es aquel en el que la hoja de cálculo indica que puedes atender el perfil real de longitud de tokens y aciertos de caché con la latencia objetivo, con suficiente margen para absorber el crecimiento, y sin pagar por capacidad que la carga de trabajo no usa.