En el evento del otoño de 2026 organizado por D1net, el峰会 del que es anfitrión, sobre CIOs de empresas estatales y altos ejecutivos de empresas tecnológicas (19ª edición), Tang Anbo, director de soluciones de flujo basado en silicio, asistió al峰会 y realizó una presentación temática: “De ‘capacidad de cálculo’ a ‘productividad de tokens’: infraestructura de razonamiento y prácticas de ROI para la implementación a gran escala de modelos grandes en empresas estatales”. A continuación, se presenta el esqueleto del contenido de la presentación.
En este momento, las aplicaciones de IA se encuentran en una fase inicial de crecimiento explosivo, y el consumo de tokens aumenta de manera exponencial. Detrás de esto, la arquitectura de los modelos evoluciona continuamente, con un ritmo rápido de actualizaciones; al mismo tiempo, la arquitectura de potencia computacional también está en constante desarrollo. Entre los modelos y la potencia computacional, existe un proceso iterativo que se impulsa mutuamente. Para las empresas, por un lado, es necesario adaptarse a estos cambios, y por otro lado, ofrecer servicios de modelos diversificados para sus escenarios de negocio, además de controlar los costos dentro de un rango razonable.
Lo que hace el flujo de silicio es conectar la capa de transformación entre la capacidad de cálculo y los tokens: gestionar de manera unificada la capacidad de cálculo; a través del motor de razonamiento desarrollado internamente, hacer que los modelos funcionen más rápido y mejor. Nosotros construimos fábricas de tokens en la nube pública, y también ayudamos a las empresas estatales y gubernamentales a crear sus propias fábricas de tokens internas.
En resumen, a través de un proceso de razonamiento sistemático, se logra una adaptación adecuada entre los modelos y la capacidad de cálculo. Basándose en esto, el flujo de silicio propone la fórmula central de productividad de tokens: Productividad de tokens = Capacidad de producción × Tasa de utilización × Calidad del entrega. En este caso, la capacidad de producción está determinada por la capacidad de hardware del chip y el nivel de optimización del modelo; la tasa de utilización se logra mediante la gestión del tráfico y el ajuste inteligente de la capacidad de cálculo; la calidad del entrega incluye la precisión de la inferencia del modelo, el éxito en la ejecución de tareas como llamadas a herramientas, así como la estabilidad del servicio SLA necesario en el entorno de producción.
De una gestión unificada a la operación basada en modelos, lograr realmente una alta tasa de utilización de potencia computacional
Desde la perspectiva de los negocios y el tráfico, diseñamos una arquitectura de desacoplamiento en cuatro capas. Conecta la operación del modelo, el mantenimiento del modelo, la ejecución de inferencias y la agrupación de capacidad computacional, cubriendo todos los aspectos de la vida completa de un modelo, desde la implementación, la aceleración hasta la agrupación de servicios. El diseño de la arquitectura de desacoplamiento en capas también tiene como objetivo adaptarse a la situación de construcción de plataformas existentes de las empresas estatales y gubernamentales, evitando la construcción repetida; si la empresa ya cuenta con capacidades de desarrollo propio, se puede integrar con los sistemas existentes sin tener que empezar desde cero, es decir, se pueden completar directamente las capacidades necesarias mediante una “combinación de capacidades”.
Portal del modelo: no es solo una entrada, sino también una plataforma para la operación del modelo.
Esta capa está directamente en contacto con los usuarios de los servicios de modelos, como las compañías de tecnología molecular y los grupos subordinados. Todas las llamadas a los grandes modelos se realizan a través de esta capa para llevar a cabo tareas básicas como la medición, la facturación y el reconocimiento. Lo más importante es que también ofrece una amplia variedad de estrategias de programación y enrutamiento: por ejemplo, se puede enrutar las solicitudes a los servicios de modelos correspondientes según los requisitos de tiempo de respuesta en diferentes escenarios de negocio, lo que permite que los diferentes negocios no interfieran entre sí y garantiza que todas las partes cumplan con el SLA deseado; además, es compatible con un programación flexible basada en objetivos como la prioridad al rendimiento o a los costos.
Plataforma de servicio de modelos: entrega las mejores prácticas de despliegue y operación al negocio.
Esta capa gestiona principalmente desde el punto de vista de operaciones y mantenimiento las capacidades como el despliegue de modelos y el repositorio de modelos. Incluiremos las buenas prácticas para el despliegue de modelos, permitiendo que las empresas puedan activar los modelos con un solo clic, en lugar de tener que realizar ajustes cada vez. Ya hemos adaptado cerca de cien modelos, y los nuevos modelos principales se sigan adaptando continuamente, con el objetivo de que el equipo de negocios pueda utilizarlos de inmediato.
Marco de razonamiento de alto rendimiento: optimización iterativa orientada a modelos y hardware específicos.
Colaboramos en profundidad con diferentes fabricantes de potencia de cálculo, y en torno a modelos y potencia de cálculo específicos, desarrollamos nuestras propias bibliotecas de operadores y bibliotecas de comunicación, con el fin de liberar al máximo el rendimiento del modelo en el hardware correspondiente. Por ejemplo, en colaboración con Huawei Cloud, se lanzó por primera vez en el sector un servicio DeepSeek R1/V3 Token basado en chips nacionales, y se desarrollaron y optimizaron soluciones de inferencia para el clúster de super nodos CloudMatrix. En DeepSeek-R1, el rendimiento de decodificación por tarjeta única superó los 1,920 tokens/s; se lanzó globalmente el servicio comercializado del gran modelo de lenguaje Kimi-K2 basado en el clúster C550 de MuXi Cloud; y con el chip MTT S5000 de MooreThread, se implementó DeepSeek-V3, logrando un rendimiento de prefill por tarjeta única de más de 4000 tokens/s y un rendimiento de decodificación de más de 1000 tokens/s.
Al mismo tiempo, nuestra tecnología de razonamiento también está evolucionando continuamente: a medida que el contexto de las tareas de procesamiento del modelo crece y la concurrencia aumenta, es necesario optimizar constantemente los marcos de razonamiento, como la optimización de operadores, la optimización de comunicación y la cuantificación del modelo. Además, se combinan técnicas como la separación PD y el descargado jerárquico del caché KV para mejorar significativamente el rendimiento general y la capacidad de consumo del procesamiento del modelo.
Distribución de potencia de cálculo: Gestión flexible de los recursos de potencia de cálculo.
La programación flexible de la capacidad de cálculo es un elemento clave para reducir los costos de inferencia y mejorar la eficiencia en el uso de la capacidad de cálculo. Sin embargo, la planificación de la capacidad de cálculo a menudo se enfrenta a una dificultad: si es demasiado conservadora, podría llegar rápidamente al límite y incluso sobrecargarse; si se configura completamente según el pico diurno, se generará desperdicio de recursos en otros horarios. Por lo tanto, se necesita tanto una estrategia de ampliación y reducción flexible como medidas de operación adecuadas.
Por ejemplo, cuando las empresas estatales del gobierno central ofrecen servicios de modelos a sus filiales, se puede utilizar un precio diferenciado en el cálculo interno: durante el día se aplica el precio habitual, y por la noche se otorga un descuento, lo que permite que algunas operaciones funcionen durante la noche. Cada operación podría utilizar modelos diferentes, lo que exige que la plataforma pueda ajustar dinámicamente los ejemplos de modelo basándose en indicadores multidimensionales como la cola de solicitudes y el rendimiento.
Ejemplo de empresa estatal de China: pasar de “alquilar máquinas” a “llamar a servicios de modelos”
Servimos a un grupo de empresas estatales y gubernamentales, que originalmente tenía aproximadamente 50 máquinas, las cuales proporcionaban servicios a las compañías filiales. La forma de servicio en aquel entonces era muy directa: las compañías filiales solicitaban las máquinas y implementaban los modelos que necesitaban. En otras palabras, se trataba de “alquilar máquinas”.
De esta manera, se crearon cuarenta o cincuenta ejemplos de modelo, pero el uso general de la capacidad de cálculo es muy bajo. Algunas unidades ocupan la máquina y solo despliegan un modelo; otras se usan durante el día y no durante la noche; y otras solo se usan unos días a la semana. La máquina está ocupada, pero no genera carga efectiva de forma continua.
Colaboramos en profundidad con los clientes para reconstruir la situación actual: unificación de modelos y de capacidades computacionales. Se reducen los modelos repetitivos a unos diez; el método de asignación de recursos por máquina se cambia a servicios de modelo Serverless, todos llaman al API de forma unificada, sin preocuparse por dónde se implementa específicamente el modelo ni qué máquina lo ocupa.
Así, con aproximadamente 50 máquinas, se pueden hacer más tareas. Por ejemplo, después de utilizar algunas máquinas para soportar los modelos pequeños existentes, se pueden liberar más máquinas para desplegar nuevos modelos de parámetros grandes, como GLM-5.2, DeepSeek-V4-Flash-0731, etc. En el pasado, este tipo de modelos no podían ejecutarse dentro del grupo. Pero en realidad, los nuevos modelos de parámetros grandes son muy importantes para la exploración de negocios, ya que el límite superior de la inteligencia del modelo también determina el límite superior de la innovación en las aplicaciones. A través de la convergencia del modelo y la gestión intensiva de la capacidad de cálculo, hemos desplegado estos modelos, y combinándolos con la optimización del rendimiento, hemos convertido más escenarios de “incapacitados” en “disponibles”, y de “potencialmente explorables” en “pueden ser ampliados”.
Originalmente, la mayor preocupación del lado de negocios era: hacer exploraciones y crear un agente no es un problema, pero ¿puede ser lanzado a gran escala? ¿Puede manejar más llamadas? Todos tenían dudas en sus corazones. Después de que el nuevo modelo se lanzara, en los tests de desde una única concurrencia hasta muchas concurrencias, la velocidad de salida, en total, se mantenía por encima de 30 tokens/s. Por ejemplo, en el ámbito de programación, superar a 30TPS es un requisito básico para obtener una buena experiencia de uso. En los tests comparativos del mismo modelo, logramos una mejora en el rendimiento del 40% al 100%. Por supuesto, depende de los diferentes tamaños de entrada y salida, y los beneficios específicos no son los mismos.
En general, primero, la capacidad de consumo del modelo ha mejorado; segundo, la tasa de utilización de la potencia computacional ha aumentado. Al combinar ambos factores, esto se refleja en el costo por millón de tokens, que es un indicador que muchas empresas usan para medir la eficiencia de los servicios de razonamiento. En este caso, el costo por millón de tokens de un modelo Qwen inicialmente era de más de cien yuanes, pero después del ajuste, se redujo a menos de diez yuanes. La reducción de costos es notable, pero lo más importante es que se han abierto más escenarios de negocio que antes eran difíciles de implementar.
Mejorar aún más el ROI, optimizando conjuntamente aplicaciones e infraestructura
A medida que el agente se implementa de forma escalable, hemos observado un problema: existe una cierta desconexión entre la capa de aplicaciones y la capa de infraestructura. En el pasado, al desarrollar aplicaciones, incluso si se trataba principalmente de la parte frontend, los desarrolladores generalmente tenían algún conocimiento sobre los índices de la base de datos y la optimización de SQL. Ahora, la separación entre las aplicaciones de grandes modelos y la infraestructura es más evidente; la parte de aplicaciones no necesariamente comprende completamente los mecanismos de razonamiento subyacentes y caché, y esto afecta directamente la eficiencia.
Por ejemplo, en el área de Coding, estamos explorando conjuntamente con los clientes la optimización en este aspecto. En el diseño de software de las empresas estatales y gubernamentales, no se trata de escribir una App hoy y realizar otra demostración mañana, sino de realizar iteraciones continuas a lo largo de muchos años. El repositorio de código se actualizará constantemente; enviar código y llevar a cabo la construcción cada día son parte del proyecto a largo plazo. La forma en que este código se convierte en el Contexto del modelo es muy importante.
Si la construcción del Contexto no está bien diseñada, cada solicitud no puede alcanzar el caché, y la entrada de decenas de miles de Token consume una gran cantidad de potencia de computación. Pero si está bien diseñada, aproximadamente el 90% del contenido podría alcanzar el caché, y así se manifiesta la diferencia en eficiencia. Por ejemplo, cuando no hay alcanzamiento del caché, el sistema puede soportar 100 concurrencias; después de mejorar el alcanzamiento del caché, podría soportar 200 concurrencias. Este aumento no implica un incremento en hardware, sino que reduce el cálculo repetido. Por lo tanto, la construcción del Contexto en sí mismo necesita ser optimizada para la inferencia.
En otra dirección, es combinar DevOps para la optimización. El uso de la capacidad de cálculo tiene picos y valles; durante el día, todos utilizan la capacidad de cálculo, y la entrada en escenarios de codificación es muy larga. Si todo el código se procesa solo cuando se realizan solicitudes durante el día y luego se genera un caché, se utilizará una gran cantidad de capacidad de cálculo en los horarios de pico. Entonces, ¿sería posible, durante el proceso diario de construcción por la noche, mediante métodos de ingeniería, que el modelo preprocese el repositorio de código y guarde los resultados correspondientes en el KV Cache de antemano? De esta manera, no será necesario calcular de nuevo durante el día. Todas estas formas tienen la oportunidad de mejorar aún más la tasa de uso de la capacidad de cálculo. Pero esta capacidad también depende de que exploremos juntos con la parte responsable del escenario.
La esperanza de flujo base de silicio quiere, junto con las empresas estatales centrales, explorar más escenarios de implementación de IA, y liberar la verdadera capacidad de cálculo y producción.
Reifeng Net (publico: Reifeng Net) Reifeng Net