En una aplicación de IA que lee mucho contexto antes de responder, el tiempo de procesamiento de entrada puede importar tanto como la velocidad de generación. Optimizar la solicitud completa puede cambiar qué configuración de inferencia ofrece la mejor experiencia.
En nuestro estudio de Kimi K3, ProsGrow aumentó el rendimiento de salida por solicitud completa un 50.1% frente a nuestra configuración ATOM existente, con el mismo hardware AMD. El resultado provino de cambios en el software de inferencia, con el mismo checkpoint original y tamaños de solicitud controlados. La configuración experimental cambia la precisión numérica en partes del entorno de ejecución; sigue siendo necesaria una validación de calidad más amplia.
El resultado: menos espera hasta recibir la respuesta completa
Nuestras mediciones del 22 de septiembre utilizaron Kimi K3 con ocho GPU AMD MI325X. Cada solicitud contenía exactamente 8,192 tokens de entrada y generaba 256 tokens de salida, con una solicitud en ejecución cada vez.
| Medida | Base ATOM local | Configuración experimental de ProsGrow | Cambio |
|---|---|---|---|
| Mediana del tiempo de solicitud completa | 9.57 s | 6.37 s | 33.4% menos |
| Rendimiento de salida por solicitud completa | 26.76 tokens/s | 40.17 tokens/s | 50.1% más |
El rendimiento por solicitud completa divide los tokens de salida entre el tiempo necesario para recibir la respuesta completa, incluidos el procesamiento de entrada y el transporte. Son mediciones del sistema completo, no tasas por GPU. Los dos porcentajes describen la misma mejora desde perspectivas distintas; no deben sumarse.
Para los equipos de IA privada, esto demuestra que merece la pena evaluar la configuración de inferencia junto con las especificaciones del hardware. Esperar menos por una respuesta de tamaño fijo puede importar en aplicaciones que combinan un contexto de entrada considerable con una salida breve.
Un resultado de 4.41× que muestra por qué importa la carga
También comparamos la configuración experimental con un adaptador local para el entorno Tutel de Microsoft, utilizando el mismo servidor, checkpoint original, casos de solicitud y cliente.
Para la carga de 8K tokens de entrada y 256 de salida, el adaptador Tutel entregó 9.10 tokens/s de salida por solicitud completa, frente a 40.17 de ATOM ajustado: 4.41× la tasa de solicitud completa. La mediana del tiempo de solicitud fue de 28.13 segundos con el adaptador y de 6.37 segundos con ATOM ajustado.
Tutel seguía generando tokens más rápido una vez iniciada la decodificación: 78.33 frente a 47.67 tokens/s. También completó antes nuestras solicitudes más cortas, con 512 tokens de entrada. Su mayor tiempo de procesamiento de prompts en el adaptador probado cambió el resultado con entradas de 8K.
La conclusión comercial es específica: elija una configuración según las longitudes de solicitud y los tamaños de respuesta que utiliza realmente su aplicación. Es una comparación local de entornos de ejecución, no una afirmación general de que uno es más rápido en todas las cargas.
De dónde vino la mejora
ProsGrow examinó cómo el software de inferencia utilizaba el hardware AMD durante el procesamiento de entrada y la generación, y después probó una configuración conjunta de ejecución. El trabajo se apoyó en los ecosistemas ATOM y AMD AITER.
Este enfoque vincula la optimización con la solicitud completa. También hace explícito el compromiso entre precisión y calidad: utilizar el mismo checkpoint original no significa que las distintas configuraciones realicen operaciones numéricas idénticas. En esta comparación difieren las políticas de precisión del entorno de ejecución y de la caché.
Qué validamos
Cada configuración utilizó dos solicitudes de calentamiento y cinco solicitudes medidas por longitud de entrada. La decodificación especulativa estaba desactivada. Se auditaron las respuestas guardadas para verificar los recuentos de tokens y los tiempos, y las tres configuraciones superaron las comprobaciones de aritmética y recuperación de marcadores.
Esas comprobaciones funcionales no acreditan una exactitud equivalente del modelo. La configuración experimental siguió siendo opcional y no sustituyó al servicio habitual. Estas mediciones son un resultado de desarrollo, sin intervalos de confianza ni garantía de nivel de servicio en producción.
Para los equipos que consideran alojamiento privado de Kimi, el siguiente paso es evaluar prompts, longitudes de respuesta, concurrencia y criterios de calidad representativos. ProsGrow puede ayudar a conectar esos requisitos con una configuración de despliegue medida.
Para hablar de un piloto de inferencia privada, escriba a contact@prosgrow.ai.