¡La latencia del primer Token se reduce un 32.4%! El gran movimiento de Shi Shi Tech en programación de clústeres, la inferencia nacional…

Yunzhong desde Aofeisi. Quantum Bit | Cuenta pública QbitAI

En un clúster de GPU, la cola de solicitudes y los recursos inactivos pueden ocurrir al mismo tiempo.

Durante el Congreso Académico Nacional de Computación de Alto Rendimiento CCF 2026, Shi Shi Tech lanzó un nuevo producto:el marco de programación distribuida TokenFleet, que centra su optimización en el enrutamiento de solicitudes, la coordinación de capacidad entre centros de datos y la gobernanza de cargas mixtas, intentando aumentar el rendimiento efectivo de la potencia de cómputo existente.

Si se considera el servicio de inferencia como una "fábrica nacional de optimización de Tokens", las GPU son los equipos de producción, las instancias de inferencia son los puestos de trabajo y las solicitudes de negocio son pedidos individuales. TokenFleet se encarga de emparejar los pedidos con la capacidad.

Con el mismo lote de equipos, distintas tareas y distintas formas de asignación producen tiempos de espera y rendimientos conformes diferentes. El servicio a gran escala requiere considerar todos estos arreglos de producción en conjunto.

TokenFleet se enfoca en el rendimiento efectivo del clúster

Después de desplegar el modelo, el clúster aún debe atender múltiples tipos de negocio simultáneamente.

Varios modelos comparten la potencia de cómputo, y diferentes inquilinos tienen sus propios requisitos de nivel de servicio. Las conversaciones cortas deben responderse con prontitud, el procesamiento de documentos largos requiere más cómputo y memoria de video, y las tareas por lotes sin conexión tienen plazos de finalización. Cuando el servicio se distribuye en varios centros de datos, también hay que considerar si las capacidades de cada lugar pueden coordinarse.

Una simple división del tráfico puede hacer que algunas instancias formen largas colas mientras la capacidad de otros lugares no se aprovecha a tiempo. La presión mutua entre solicitudes largas y tareas por lotes ralentiza la interacción en tiempo real; los tiempos de espera agotados, las cancelaciones y los cálculos repetidos consumen recursos sin generar entregas válidas.

Bajo la condición de que la calidad del modelo, los requisitos de servicio y el presupuesto de cómputo se mantengan consistentes, TokenFleet, medianteaumentar el rendimiento efectivo de Tokens, reducir el costo por unidad de rendimiento efectivo。

TokenPilot selecciona instancias dentro del mismo grupo de modelos, FleetMind se orienta a la coordinación de capacidad entre centros de datos, y SLOMax se encarga de la admisión de cargas mixtas, la gobernanza de colas y la asignación de capacidad; las tres tecnologías centrales tienen cada una su función.

A quién se asigna la solicitud, cuándo entra la tarea a la cola y cómo se coordina la capacidad de los centros de datos: todo regresa al mismo indicador: el rendimiento efectivo de Tokens completados con éxito y conforme a los requisitos de servicio.

TokenPilot calcula juntos el beneficio de la caché y el costo de la cola

Primero, la selección de destino de las solicitudes. ¿A qué instancia debe enviarse una solicitud?

Una pregunta corta y un documento largo, aunque ambos cuenten como una sola solicitud, pueden consumir cantidades de cómputo y memoria de video muy diferentes. Distribuir solo por número de solicitudes dificulta equilibrar la carga de trabajo real de cada instancia.

La caché añade una capa de compensación a este asunto. Las solicitudes con el mismo prefijo largo, si se envían a una instancia que conserva el KV caché correspondiente, tienen la oportunidad de reutilizar los resultados de cálculo previos, reduciendo el Prefill, es decir, el cálculo repetido al procesar el contenido de entrada.

Pero las instancias con alta tasa de acierto de caché también pueden tener colas largas. Si las solicitudes acuden todas al mismo lugar, el tiempo de cómputo ahorrado puede consumirse en la espera.

Al seleccionar el destino, TokenPilotestima simultáneamente el beneficio de reutilización de caché y el costo de la cola. Combina el tamaño de la entrada, el presupuesto de salida y los prefijos reutilizables para estimar la carga de trabajo, y luego, considerando la cola, los Tokens en tránsito, la presión del KV caché y la latencia prevista, filtra y puntúa las instancias candidatas. El presupuesto de salida es una restricción y no representa la longitud real de la salida.

Con base en esto, el programador compara el costo de procesamiento previsto de las distintas instancias y juzga si el cómputo ahorrado al reutilizar la caché puede compensar la espera adicional.

Según los datos de ajuste de GLM5.3 proporcionados por Shi Shi Tech, en las condiciones de clúster de tarjetas gráficas y carga probadas, tras adoptar el enrutamiento con latencia prevista,la latencia P95 del primer Token se redujo un 32.4%, y la latencia P50 del primer Token se redujo un 71.3%。

△Tabla 1 Resultados de ajuste de la latencia del primer Token de TokenPilot. Fuente de los datos: material de la presentación de Shi Shi Tech en el congreso. La tasa de mejora se calcula como (valor base − valor optimizado) ÷ valor base; la reducción de la latencia no equivale directamente a una reducción de costos.

P50 refleja el nivel mediano, y P95 refleja la espera de las solicitudes en la cola. Este conjunto de datos muestra la mejora de respuesta en las condiciones medidas; el costo-beneficio aún debe evaluarse en conjunto con el rendimiento y el consumo de recursos.

FleetMind también debe calcular la capacidad de servicio entre centros de datos

Al ampliar la perspectiva de un solo grupo de modelos a varios centros de datos, la programación añade una capa más de evaluación de capacidad.

Tener GPU libres no significa poder aceptar tareas de inmediato. Si el modelo objetivo está desplegado, si la versión coincide, si el punto de servicio está listo y cuánto tiempo tarda la transmisión por la red, todo ello afecta el efecto de la distribución de carga.

FleetMind se centra enla capacidad de servicio de modelos realmente disponible. En el diseño de TokenFleet, esta función reúne la disponibilidad de modelos, la capacidad en tiempo real y el estado de la red de cada centro de datos: primero selecciona el centro de datos de ejecución y, después, el motor de decisión local de ese centro elige la instancia de inferencia concreta.

Cuando un centro de datos congestionado empieza a formar cola, el sistema evalúa si otros centros de datos tienen puntos de servicio listos con la misma versión del modelo y si aún queda margen de servicio, y luego determina si puede aceptar nuevas solicitudes que permitan la ejecución entre regiones.

Si se puede desviar tráfico depende primero de cumplir las restricciones de permisos y de localización de datos. Si vale la pena desviarlo requiere además comparar de forma integral la latencia de retorno al origen, las colas, el cómputo, la caché y los costes de transmisión.

La coordinación de capacidad también tiene distintas escalas temporales: en ciclos cortos se ajusta el destino de las nuevas solicitudes, y en ciclos largos se ajustan las réplicas del modelo y las posiciones de precalentamiento, combinando reserva de capacidad, percepción de límites de carga y retroceso automático para reducir los desajustes de capacidad.

△Figura 3: Marco de ejecución entre centros de datos de FleetMind. Nota: la ubicación A es la entrada del negocio y no cuenta en el conjunto de capacidad GPU; la ubicación B es el clúster existente y las ubicaciones C y D son los centros de datos de expansión.

TokenPilot y SLOMax están orientados al clúster existente, mientras que FleetMind lo está a la expansión hacia los nuevos centros de datos de cómputo que se incorporen más adelante. El objetivo de la coordinación entre centros de datos es que la capacidad distribuida que cumpla las restricciones del negocio pueda absorber la demanda de picos, reduciendo los desajustes de capacidad y las reservas duplicadas.

SLOMax organiza la producción según los requisitos del servicio

Las solicitudes entran en el mismo clúster, pero sus requisitos de entrega son muy distintos.

El diálogo en tiempo real se preocupa por la respuesta del primer Token y la velocidad de generación continua; las tareas de contexto largo dependen más de la capacidad de procesamiento de entrada y de la capacidad KV; y las tareas por lotes fuera de línea se centran en los plazos de finalización y el rendimiento. Ponerlas en la misma cola facilita la lucha por los recursos.

Los Prefill largos, la presión sobre la capacidad KV y las cargas por lotes pueden aplastar las solicitudes interactivas. Los tiempos de espera agotados, las cancelaciones y las ejecuciones repetidas también hacen que parte del cómputo no se convierta en entregas válidas.

SLOMax identifica la carga de trabajo combinando la longitud de entrada, el presupuesto de salida, el tipo de tarea y los objetivos de servicio del inquilino, y luego aplica admisión por niveles, colas por grupos y coordinación de capacidad. Debe garantizar capacidad interactiva y controlar la concurrencia de solicitudes largas y cortas y su interferencia mutua.

△Figura 4: Marco de colas clasificadas y retroalimentación de capacidad de SLOMax. Nota: la retroalimentación de efectos se usa para ajustar la capacidad y la admisión; el marco no presupone capacidad de desalojo de tareas en ejecución.

Para medir el efecto de esta programación, TokenFleet toma como objetivo de optimización la producción que cumple los requisitos.

Goodput, es decir, el rendimiento de salida que cumple los requisitos, calcula: el volumen total de Tokens de salida generados por las solicitudes completadas con éxito y que cumplen los requisitos de servicio pactados, durante todo el periodo de prueba, dividido por la duración de la prueba. Las distintas categorías de tareas requieren umbrales de cumplimiento definidos por separado y la presentación de resultados separados.

El sistema retroalimenta a la política de programación el rendimiento válido, los fallos, las cancelaciones y las ejecuciones repetidas, ajustando continuamente la admisión y las proporciones de capacidad. Lo ocupadas que estén las GPU y lo alto que sea el rendimiento total deben verse junto con la entrega válida final.

En el ejemplo de estimación de beneficios de GLM5.3 presentado por Metastone, tras adoptar la programación coordinada con control de flujo, el rendimiento total de salida aumentó alrededor de 1,5%,el rendimiento de salida válido mejoró alrededor de 29,4%, y la proporción de cumplimiento pasó de aproximadamente 67% a aproximadamente 86%.

△Tabla 2: Ejemplo de estimación de beneficio de rendimiento de Tokens válidos de SLOMax. Fuente de datos: materiales de la ponencia en el congreso de Metastone. Esta tabla es un ejemplo de estimación de beneficios; la proporción de cumplimiento usa los valores redondeados del texto original, con un cambio de aproximadamente 19 puntos porcentuales.

Estos valores pertenecen a una estimación de beneficios que muestra la estructura de producción que la programación aspira a mejorar. Los beneficios reales aún deben verificarse según cargas concretas y umbrales de servicio específicos.

Con el mismo volumen total de producción, si se reducen los tiempos de espera agotados, las cancelaciones y los cálculos repetidos, existe la oportunidad de entregar más Tokens válidos. SLOMax incorpora estos resultados en la retroalimentación para ajustar la asignación posterior de recursos.

La eficiencia de la fábrica nacional de optimización de Tokens también depende de la programación

TokenFleet lleva la optimización de los servicios de inferencia al nivel de clúster. Cómo se asigna el rendimiento de las instancias a las distintas solicitudes y cómo participa la capacidad de varios centros de datos en el servicio son cuestiones que requieren que la programación conecte los recursos con los requisitos del negocio.

Metastone (是石科技) es unoperador independiente de terceros de cómputo de pila completaque no está vinculado a ningún fabricante específico de grandes modelos y que ofrece a sus clientes unservicio de entrega de cómputo de pila completa en una sola parada que abarca hardware, redes, programación, optimización y operación。

. Con la amplia experiencia proveniente de centros nacionales de cálculo, el SLA de operación de sus clústeres de cómputo supera el 99,95%. Actualmente, Metastone ya gestiona más de 20000P+ de recursos de cómputo y opera más de 10 súper centros de cómputo inteligente, entre ellos 2 centros nacionales de supercómputo; los miembros de su equipo han ganado 3 veces el premio Gordon Bell y acumulado experiencia en servicios técnicos de pila completa para clústeres de ultra gran escala.

En torno a la fábrica nacional de optimización de Tokens, Metastone pule continuamente sus capacidades de software mediante el desarrollo y uso propios, con la esperanza de hacer más económicos los servicios de inferencia generales y de alta frecuencia, y de que el cómputo nacional despliegue más capacidades.

El motor de inferencia eficiente Meta-Infer, presentado anteriormente, se centraba en mejorar la eficiencia de ejecución de cada instancia de inferencia. Esta vez, TokenFleet pone el énfasis en laprogramación de clústeres, organizando el servicio a gran escala mediante la asignación de solicitudes, la coordinación de capacidad y la gobernanza de cargas mixtas.

Para que más negocios puedan permitirse y aprovechar bien los Tokens, se necesita que el hardware proporcione potencia de cómputo, pero también que el software organice la producción.

TokenFleet ha centrado su dirección de optimización adicional en cómo se asigna cada solicitud y cómo se utiliza cada porción de capacidad.

*Este artículo es publicado por QbitAI con autorización; las opiniones pertenecen únicamente al autor original.