Tencent HPC llega a SGLang y desafía a los kernels de inferencia predeterminados

Tencent HPC ha entrado en la rama principal de SGLang con tres rutas de operadores optimizadas y una reducción reportada de hasta el 48,8 % en la latencia por token de Hy3. La contribución incorpora implementaciones de Dynamic Attention, Router GEMM y Fused MoE de la biblioteca HPC-Ops de Tencent Hunyuan a un motor de inferencia de código abierto ampliamente utilizado.

La cifra principal merece un encuadre cuidadoso. TPOT, o tiempo por token de salida, mide la latencia media entre los tokens generados después de que aparece el primero. Tencent y SGLang informan mejoras de hasta el 48,8 % en configuraciones de Hy3 probadas, en lugar de una ganancia universal para todos los modelos, GPU y patrones de tráfico.

Aun así, esto es más que otra colección de benchmarks CUDA aislados. Los usuarios de SGLang pueden acceder a los kernels mediante un framework upstream, en vez de mantener un fork privado. Esto sitúa el trabajo de operadores de Tencent en competencia directa con rutas de inferencia consolidadas de SGLang, FlashInfer, CUTLASS, Triton y proveedores de hardware.

Tencent HPC pasa de una biblioteca de kernels a SGLang

El cambio importante es la distribución, no simplemente otro benchmark rápido.

HPC-Ops es una biblioteca de operadores de inferencia de código abierto desarrollada por el equipo de infraestructura de IA Hunyuan de Tencent. Su repositorio de operadores abarca operaciones de atención, GEMM, Mixture-of-Experts, muestreo, normalización y comunicaciones fusionadas.

Un operador es un bloque de computación de bajo nivel que ejecuta una tarea específica del modelo en la GPU. Frameworks como SGLang ensamblan estos bloques en la ruta de ejecución utilizada para atender solicitudes de modelos.

Antes de la integración upstream, los equipos interesados en HPC-Ops debían instalar y conectar sus componentes dentro de su propio entorno de serving. Ese trabajo implicaba pruebas de compatibilidad, selección de backend y adaptación continua cuando cualquiera de los proyectos cambiaba.

La integración en la rama principal de SGLang cambia esa relación. El framework puede reconocer y despachar operaciones Hy3 compatibles a los kernels de Tencent mediante rutas de backend mantenidas. Los usuarios ya no necesitan un fork de SGLang de larga duración solo para evaluar la implementación.

La contribución inicial se centra en tres áreas sensibles a la latencia:

• Dynamic Attention distribuye el trabajo de decodificación desigual entre las unidades de ejecución de la GPU.

• Router GEMM acelera una multiplicación de matrices sensible a la precisión que se utiliza para seleccionar expertos de MoE.

• Fused MoE combina varias etapas de procesamiento de expertos para reducir lanzamientos y tráfico de memoria.

Cada una apunta a una fuente distinta de retraso en la inferencia. En conjunto, abordan las cargas de trabajo irregulares creadas por contextos largos y modelos dispersos.

Hy3 es un caso de prueba útil porque combina ambos problemas. Tencent describe Hy3 como un modelo Mixture-of-Experts disperso diseñado para ejecución agéntica, programación y razonamiento extendido. Su arquitectura activa solo una parte del modelo para cada token, pero aun así requiere atención sobre un contexto creciente y enrutamiento entre muchos expertos.

Esa combinación genera latencia fuera de las grandes multiplicaciones de matrices que suelen dominar los benchmarks simplificados. La planificación, el movimiento de datos, la conversión de precisión, el enrutamiento y los pequeños lanzamientos de kernels pueden adquirir la misma importancia durante el serving en línea.

El resultado integral reportado es una reducción de TPOT de hasta el 48,8 % en cargas de trabajo Hy3 probadas. Esta cifra procede del entorno de benchmark de los autores del proyecto y no se ha reproducido de forma independiente en una amplia variedad de hardware.

La distinción importa porque “hasta” recoge el caso medido más favorable. No describe la mejora media para todos los patrones de solicitud. Un servidor con prompts cortos y uniformes puede obtener un resultado distinto al de otro que gestione sesiones agénticas de longitudes mixtas.

HPC-Ops también sigue siendo específico de hardware. Sus requisitos publicados identifican la arquitectura SM90 de NVIDIA, Python 3.8 o posterior y CUDA 12.8 o posterior. La biblioteca afirma que sus kernels están especialmente optimizados para las GPU NVIDIA H20.

Esto limita la portabilidad inmediata, pero no elimina la importancia de la disponibilidad upstream. SGLang se ha convertido en un punto de integración habitual para creadores de modelos, equipos de infraestructura y desarrolladores de kernels. Llegar allí expone el trabajo de Tencent a pruebas más realistas de las que suele recibir un repositorio independiente.

También sigue una integración similar en vLLM. En julio, los backends de atención y MoE de HPC-Ops entraron en la rama principal de vLLM como opciones de primera clase. Los benchmarks de vLLM que los acompañan informaron una menor latencia del primer token y de los tokens de salida en ocho GPU H20.

Por tanto, SGLang se convierte en el segundo gran ecosistema de serving donde Tencent puede comprobar si sus kernels orientados a producción funcionan más allá de la propia infraestructura de Tencent. Ese es el verdadero acontecimiento detrás del benchmark.

Por qué Tencent HPC importa para el serving de modelos en línea

El rendimiento de inferencia moderno depende de gestionar trabajo irregular, no solo de maximizar el rendimiento bruto de matrices.

Los benchmarks offline suelen utilizar longitudes de prompt fijas, lotes predecibles y formas de tensor estables. El tráfico de producción se comporta de otro modo. Las solicitudes llegan continuamente, los contextos crecen a ritmos distintos y los usuarios detienen la generación en momentos impredecibles.

Una solicitud puede llevar un contexto de 16.000 tokens, mientras que otra acaba de comenzar con 1.000 tokens. Una planificación de atención estática puede asignar mucho más trabajo a un bloque de GPU que a otro. La tarea más corta termina antes, mientras que la más larga determina cuándo se completa todo el lanzamiento.

Dynamic Attention intenta reducir ese desequilibrio. HPC-Ops divide el trabajo de la caché clave-valor en mosaicos más pequeños y los asigna según la carga de trabajo actual. La asignación se reconstruye a medida que las longitudes de las solicitudes cambian durante la decodificación.

Una caché clave-valor almacena estados de atención previos para que el modelo no recalcule todo su historial por cada token nuevo. Los historiales más largos requieren leer y procesar más datos de caché.

HPC-Ops describe un planificador que divide las solicitudes en mosaicos uniformes y los distribuye entre arreglos cooperativos de hilos. Un arreglo cooperativo de hilos, o CTA, es un grupo de hilos de GPU que ejecuta una unidad de trabajo planificada.

La biblioteca informa de un rendimiento de Dynamic Attention de hasta 2,88 veces el de su referencia static split-k en pruebas seleccionadas de longitud variable. Sus resultados de atención más amplios incluyen mejoras frente a FlashInfer, FlashAttention y TensorRT-LLM en configuraciones especificadas.

Esas cifras a nivel de operador no deben confundirse con mejoras integrales del servidor. Un kernel de atención más rápido afecta solo a la proporción de la latencia total que se dedica a esa operación. La planificación de solicitudes, las comunicaciones, la carga del modelo, el muestreo y otras capas siguen formando parte de la ruta.

Sin embargo, la atención adquiere cada vez más importancia a medida que crecen los contextos. Las aplicaciones agénticas añaden repetidamente resultados de herramientas, documentos recuperados y razonamiento intermedio a una sesión activa. Eso crea precisamente las longitudes desiguales de caché a las que apunta la planificación dinámica.

Un asistente de programación ofrece un ejemplo concreto. Una solicitud puede contener una función pequeña y una instrucción breve. Otra puede incluir un mapa del repositorio, varios archivos, registros de compilación y el historial completo de la conversación.

Colocar ambas solicitudes en un lote continuo mejora la utilización, pero crea trabajo de atención desigual. Una política de división estática deja algunas unidades de GPU inactivas o lanza fragmentos vacíos para solicitudes más cortas.

La planificación dinámica intenta hacer que esas solicitudes coexistan de forma más eficiente. El mayor beneficio debería aparecer cuando las longitudes de secuencia difieren de forma sustancial y el servidor cuenta con suficiente trabajo simultáneo para reequilibrar.

Por eso TPOT importa más que una sola cifra de rendimiento. El rendimiento mide la salida agregada de todas las solicitudes. TPOT refleja más directamente la rapidez con la que un usuario individual ve tokens sucesivos durante la generación.

Para los agentes interactivos, una entrega lenta de tokens se acumula a lo largo de respuestas extensas y llamadas repetidas a herramientas. Un TPOT inferior puede acortar cada segmento de generación, lo que permite que el siguiente paso de herramienta o modelo comience antes.

La integración también presiona la selección de kernels predeterminados dentro de los frameworks de inferencia. SGLang ya ofrece varias implementaciones de atención y MoE, cada una optimizada para distintos modelos, precisiones y GPU. Un backend nuevo debe superar esas opciones sin crear reglas de configuración frágiles.

Esa competencia beneficia a los operadores solo cuando el despacho del framework sigue siendo comprensible. Un equipo de infraestructura necesita saber cuándo se activa HPC-Ops, qué formas admite y qué mecanismo de respaldo gestiona una solicitud no compatible.

También necesita evidencia de su propio tráfico. Los benchmarks públicos pueden identificar un backend prometedor, pero no pueden reproducir todas las combinaciones de longitud de secuencia, tamaño de lote, cuantización, paralelismo y objetivo de nivel de servicio.

Los equipos que evalúen la contribución deberían medir el TPOT mediano y de cola, el tiempo hasta el primer token, el rendimiento de solicitudes, el uso de memoria de GPU y la consistencia de salida. La latencia media por sí sola puede ocultar pausas que afectan a los usuarios más lentos.

La misma disciplina se aplica al conocimiento técnico que rodea una evaluación. Los equipos de ingeniería pueden conservar comandos de benchmark, notas de despliegue y análisis de fallos en una base de conocimiento con búsqueda, en lugar de depender de hilos de chat dispersos.

Tencent HPC importa porque ofrece a esos equipos otra ruta de ejecución mantenida que pueden probar. Su valor provendrá de mejoras repetibles en el serving, no de la cifra máxima de un gráfico de lanzamiento.

Dynamic Attention y Fused MoE atacan distintos cuellos de botella

La ganancia de Hy3 reportada procede de eliminar varios pequeños retrasos que se acumulan durante cada token generado.

Dynamic Attention apunta al desequilibrio de carga durante la atención. Fused MoE apunta a la fragmentación después de que el modelo enruta tokens a expertos seleccionados. Router GEMM se sitúa entre ambos y acelera la decisión que asigna esos expertos.

MoE, o Mixture-of-Experts, sustituye algunas capas neuronales densas por una colección más amplia de redes feed-forward especializadas. Un router selecciona un pequeño subconjunto de expertos para cada token, limitando el cálculo realizado por token.

Esa dispersión reduce el cálculo activo, pero introduce irregularidad. Diferentes expertos pueden recibir distintos recuentos de tokens. El servidor debe calcular puntuaciones de enrutamiento, organizar los tokens, ejecutar varias multiplicaciones de matrices más pequeñas y combinar salidas ponderadas.

Las implementaciones convencionales suelen separar esas acciones en múltiples kernels. Agrupan tokens en búferes específicos de cada experto, lanzan operaciones de matriz, aplican activaciones, cuantizan valores intermedios y reducen las salidas seleccionadas.

Cada separación puede producir otro lanzamiento y otro recorrido por la memoria de alto ancho de banda. Estos costes son pequeños de forma aislada, pero significativos durante la decodificación con lotes pequeños, donde cada operación de experto procesa relativamente pocos tokens.

HPC-Ops utiliza una ruta MoE FP8 fusionada. FP8 es un formato de coma flotante de ocho bits que reduce el tráfico de memoria y aumenta el rendimiento disponible de los tensor cores frente a formatos más amplios.

La ruta fusionada combina el preprocesamiento relacionado con el enrutamiento, la multiplicación de matrices de compuerta y expansión, la cuantización de activación, la proyección de vuelta al ancho del modelo y la reducción ponderada. Tencent afirma que la implementación lee los tokens originales mediante índices de enrutamiento, en lugar de copiarlos primero en búferes de expertos agrupados.

Ese diseño busca eliminar tanto el movimiento de memoria como las brechas entre lanzamientos de kernels. También cambia la forma en que la implementación oculta la latencia.

En lugar de depender en gran medida de la canalización de software dentro de un bloque de GPU, HPC-Ops aumenta el número de bloques residentes para formas de baja latencia. La planificación de hardware puede entonces alternar entre bloques mientras otras tareas esperan datos.

La biblioteca informa que su operador Fused MoE es hasta 1,6 veces más rápido con paralelismo de tensores y 1,5 veces más rápido con paralelismo de expertos. Sus comparaciones publicadas incluyen implementaciones de SGLang, vLLM Triton y vLLM CUTLASS.

El paralelismo de tensores divide los cálculos del modelo entre varias GPU. El paralelismo de expertos sitúa distintos expertos de MoE en diferentes trabajadores, lo que exige que los tokens viajen a los trabajadores que alojan los expertos seleccionados.

La mejor elección depende de la forma del modelo, la velocidad de interconexión, la concurrencia de solicitudes y los límites de memoria. Un kernel local fusionado no puede eliminar la comunicación requerida por una arquitectura de expertos distribuida.

Router GEMM aborda una limitación más sutil. GEMM significa multiplicación de matrices de propósito general, la operación central detrás de muchas capas de redes neuronales.

Un router multiplica activaciones de menor precisión por pesos cuyas pequeñas diferencias numéricas pueden afectar la selección de expertos. Reducir esos pesos de forma demasiado agresiva puede cambiar la decisión de enrutamiento y, por tanto, alterar la salida del modelo.

Usar aritmética FP32 completa protege la precisión, pero los tensor cores actuales no ofrecen el mismo rendimiento FP32 que está disponible para formatos de menor precisión. Una implementación directa puede recurrir al cálculo más lento de los núcleos CUDA.

HPC-Ops descompone cada peso FP32 en dos componentes BF16. BF16 conserva el rango de exponentes de FP32 mientras utiliza menos bits de mantisa.

Un componente contiene la parte alta del peso. El segundo contiene un residual escalado; el proyecto documenta una escala de 1/256. El kernel realiza entonces dos multiplicaciones BF16 en tensor cores y combina los resultados.

Los dos cálculos permanecen dentro de un mismo kernel. Comparten el movimiento de entrada, mantienen los acumuladores intermedios en registros y escriben el resultado final una sola vez.

Tencent informa de un rendimiento de hasta 3,22 veces las referencias FP32 o TF32 de cuBLAS para determinadas formas de router y compresión de estado. La afirmación representa formas de operador probadas, no todas las cargas de trabajo GEMM.

El mecanismo importa porque intenta preservar el comportamiento de enrutamiento al tiempo que aprovecha el rendimiento del hardware de menor precisión. La velocidad sin una selección de expertos comparable sería un mal intercambio para la inferencia de producción.

Esta cuestión de precisión también explica por qué importan los detalles de validación de salida. Un benchmark debería comparar decisiones de enrutamiento o salidas finales del modelo, no solo el tiempo de ejecución.

La integración anterior con vLLM informó una calidad de salida equivalente en su comparación de MoE. La integración con SGLang ahora crea otra oportunidad para que mantenedores y usuarios prueben el comportamiento numérico entre implementaciones de frameworks.

En conjunto, los tres operadores forman una historia de ejecución coherente. Dynamic Attention distribuye el trabajo de contexto. Router GEMM decide adónde va el cálculo disperso. Fused MoE realiza ese cálculo con menos límites.

Por tanto, la mejora es una historia de mecanismos, no la afirmación de que un único kernel monolítico se volvió casi dos veces más rápido. Se redujeron varios cuellos de botella, y su valor combinado depende de cuánto aporte cada uno a una carga de trabajo concreta.

Lo que la afirmación de un 48,8 % de TPOT no demuestra

El benchmark más sólido es una base creíble para realizar pruebas, pero no es una garantía de rendimiento transferible.

La reducción informada se aplica a la evaluación Hy3 de Tencent y a las condiciones de hardware compatibles. Ni la cifra ni la documentación actual establecen el mismo resultado para todos los modelos de SGLang.

Hy3 combina un comportamiento de atención específico del modelo, enrutamiento disperso, ejecución FP8 y una estructura concreta de expertos. Un modelo denso sin capas MoE no puede beneficiarse de las rutas Fused MoE ni Router GEMM.

Un modelo que use embeddings rotatorios, orden de normalización, dimensiones de cabezas, escalas de cuantización o diseños de caché distintos puede requerir trabajo de integración. También podría activar solo una parte de HPC-Ops.

El hardware crea otro límite. Los requisitos de HPC-Ops se centran actualmente en GPU NVIDIA SM90 y CUDA 12.8 o posterior. Los resultados publicados más sólidos se concentran en H20.

Eso deja fuera del alcance demostrado a los sistemas NVIDIA Ampere, las configuraciones Blackwell, los aceleradores AMD y otro hardware. SGLang admite una gama más amplia de entornos que los que este backend pretende cubrir actualmente.

Incluso en H20, la forma del tráfico puede cambiar el resultado. Dynamic Attention ofrece su ventaja más clara cuando un lote contiene longitudes de secuencia desiguales. Las solicitudes cortas y uniformes dejan menos desequilibrio que el planificador pueda corregir.

Fused MoE también depende del tamaño del lote. El equipo de vLLM informó de sus mayores ganancias en lotes pequeños y medianos, donde los lanzamientos convencionales y los pasos de memoria consumen una mayor parte del tiempo total.

Con alta concurrencia, las operaciones matriciales más grandes pueden utilizar la GPU con suficiente eficiencia como para reducir la diferencia. La comunicación también puede dominar cuando el paralelismo de expertos abarca varios dispositivos o nodos.

Por tanto, la cifra del 48,8 % necesita el contexto de la matriz completa de benchmarks. Los lectores deberían buscar longitudes de prompt, longitudes de salida, concurrencia, tamaño del paralelismo de tensores, tamaño del paralelismo de expertos, precisión de caché, frecuencias de GPU y configuración de referencia.

La calidad de la referencia es especialmente importante. Un backend predeterminado puede ser una comparación razonable para usuarios nuevos, pero quizá no represente la mejor alternativa ajustada.

La arquitectura modular de paralelismo de expertos de SGLang permite kernels personalizados y backends especializados. FlashInfer, DeepGEMM, Triton, CUTLASS y los kernels nativos de SGLang siguen evolucionando, por lo que los resultados comparativos pueden cambiar rápidamente.

La fecha de integración también importa. El código de la rama principal recibe cambios rápidos antes de que una versión estable llegue a implementaciones más amplias. Un backend integrado aún puede necesitar empaquetado, documentación, pruebas de compatibilidad y salvaguardas operativas.

La precisión numérica sigue siendo otra área que requiere verificación independiente. Router GEMM aproxima el cálculo con pesos FP32 mediante dos componentes BF16. Ese diseño busca una precisión de nivel FP32, pero los usuarios posteriores deberían probar el comportamiento a nivel de modelo.

Las comprobaciones útiles incluyen concordancia de salida con decodificación determinista, solapamiento de índices de enrutamiento, perplejidad con datos representativos y evaluación a nivel de tarea. Una pequeña diferencia numérica puede ser inocua, o puede redirigir tokens a expertos distintos.

La fiabilidad en producción va más allá de la coincidencia numérica. Los kernels deben manejar formas límite, presión de memoria, cancelación, procesamiento continuo por lotes, caché de prefijos y longitudes de secuencia cambiantes sin fallos poco frecuentes.

La revisión de código abierto ayuda a identificar estos problemas, pero la visibilidad no equivale a madurez. Las versiones de SGLang muestran con qué frecuencia cambian la compatibilidad de modelos, los kernels, las rutas de cuantización y el comportamiento de planificación.

Tencent afirma que HPC-Ops ya admite inferencia a gran escala dentro de su propio entorno. Esa experiencia es significativa, aunque las implementaciones externas suelen revelar combinaciones que una flota interna de modelos nunca utiliza.

También existe una cuestión de mantenimiento. El código upstream reduce la carga de mantener un fork, pero el paquete externo de HPC-Ops y su matriz de compatibilidad aún necesitan una responsabilidad activa.

Los usuarios deberían observar con qué rapidez Tencent y SGLang responden a los informes de regresiones. También deberían comprobar si la integración continua cubre las combinaciones compatibles de GPU, precisión y modelos.

Ninguna de estas limitaciones invalida el resultado. Definen lo que realmente dice el resultado.

Tencent y SGLang han presentado un sólido benchmark específico de modelo para un backend upstream en hardware Hopper compatible. Las afirmaciones más amplias requieren una reproducción más amplia.

La respuesta correcta no es ni la adopción automática ni el descarte. Es una prueba controlada frente al mejor backend existente, bajo los propios objetivos de nivel de servicio de la organización.

Tres señales decidirán si Tencent HPC cambia la opción predeterminada

La siguiente etapa trata sobre adopción, reproducibilidad y expansión más allá de un modelo y una familia de GPU.

La primera señal es un benchmarking independiente de Hy3 dentro de SGLang. Los operadores externos deberían reproducir la mejora de TPOT informada con comandos publicados y detalles completos de configuración.

Una reproducción útil incluiría TPOT mediano y P99, tiempo hasta el primer token, rendimiento de salida, uso de memoria y fallos de solicitudes. Debería probar tanto cargas de trabajo de longitudes mixtas como uniformes.

Una confirmación cercana al rango informado reforzaría la afirmación de Tencent de que la optimización combinada de operadores cambia materialmente la latencia de decodificación visible para el usuario. Ganancias mucho menores sugerirían que el resultado máximo depende en gran medida de una forma concreta de carga de trabajo.

La segunda señal es la compatibilidad más allá de Hy3 y H20. HPC-Ops ya publica cobertura de benchmarks para DeepSeek-V3, modelos Hunyuan y Qwen3-235B a nivel de operador.

La integración a nivel de framework es más difícil. Cada modelo puede diferir en diseño de atención, orden de normalización, cuantización, enrutamiento de expertos y ejecución distribuida.

La compatibilidad con otro modelo MoE ampliamente implementado demostraría que el backend proporciona infraestructura reutilizable, en lugar de una ruta Hy3 ajustada de forma estrecha. La compatibilidad con Blackwell también pondría a prueba si el proyecto puede adaptarse más allá de su objetivo Hopper original.

La hoja de ruta del proyecto enumera cuantización más amplia, hardware futuro, megakernels y comunicación de baja precisión. Un megakernel combina varias operaciones consecutivas para reducir la sobrecarga de lanzamiento y el tráfico de memoria intermedio.

Si estos elementos llegan con integración en SGLang y benchmarks públicos, Tencent HPC se convertirá en un competidor más amplio entre los backends de inferencia. Si el avance permanece limitado a unas pocas configuraciones H20, seguirá siendo valioso, pero especializado.

La tercera señal es si los usuarios de SGLang seleccionan el backend en implementaciones reales. Las estrellas de repositorio y los microbenchmarks aislados ofrecen evidencia limitada de adopción operativa.

Señales más útiles incluyen recetas de implementación, documentación del framework, informes de errores de flotas externas, pruebas de compatibilidad y actividad sostenida de los mantenedores. La inclusión en versiones estables importa más que la mera presencia en la rama principal.

La adopción presionaría a los kernels competidores para mejorar la planificación de longitudes mixtas, la precisión del router y la fusión de MoE. Los mantenedores de SGLang se enfrentarían entonces a un reto productivo: seleccionar el backend más rápido sin crear valores predeterminados confusos o frágiles.

Los informes de fallos serían igualmente informativos. Revelarían formas no compatibles, casos límite numéricos, fricción de empaquetado o restricciones operativas ocultas por benchmarks controlados.

Para los desarrolladores, la pregunta inmediata es práctica. ¿Reduce el nuevo backend la latencia para el modelo, la GPU y el patrón de tráfico exactos que operan?

Para los compradores de infraestructura, la cuestión es económica sin requerir una comparación pública de precios. Un TPOT menor puede aumentar la capacidad utilizable y mejorar la velocidad de respuesta interactiva, pero solo si la fiabilidad y la calidad de salida se mantienen estables.

Para los equipos de producto de IA, el efecto puede ir más allá de un panel de benchmarks. Una entrega de tokens más rápida acorta las sesiones de programación, los bucles de agentes, el análisis de documentos y otros flujos de trabajo que realizan varias llamadas al modelo por tarea.

Tencent HPC se ha ganado una evaluación seria porque sus operadores ahora están dentro de la ruta upstream de SGLang. La integración elimina una barrera entre un resultado de investigación optimizado y una prueba de producción.

La cifra del 48,8 % debería iniciar esa prueba, no terminarla. Los equipos que ejecutan Hy3 en hardware Hopper compatible pueden comparar el backend con su configuración actual de SGLang ahora mismo.

Todos los demás deberían vigilar las tres señales: reproducción independiente, compatibilidad más amplia de modelos y hardware, y evidencia de implementación sostenida. Juntas, determinarán si Tencent HPC se convierte en una opción de inferencia común o sigue siendo una ventaja especializada de Hy3.