Etched Sohu y la carrera de inferencia ASIC: cómo evaluar chips especializados frente a GPU

La cuestión no es si un chip parece rápido en una demostración. Para un equipo de producción de IA, la pregunta más difícil es si el hardware de inferencia especializado todavía se ve bien después de que se tengan en cuenta la latencia de cola, los cambios de modelo, la calidad de la cuantificación, la observabilidad, el tiempo de adquisición y el enrutamiento alternativo.

Etched Sohu es un caso de prueba útil. TechCrunch informó que Etched alcanzó una valoración de 5 mil millones de dólares y reclamó más de mil millones de dólares en ventas de chips, mientras que Etched describe sus sistemas como grupos de inferencia de frontera diseñados en torno a chips, bastidores, software y métodos de fabricación para la inferencia de modelos de frontera. Eso hace que la empresa sea difícil de ignorar para los equipos de infraestructura. Por sí solo, no responde a la pregunta del operador: ¿debería una carga de trabajo real pasar de una capacidad de GPU flexible a una ruta de inferencia ASIC?

Esta no es una clasificación de proveedores, un resumen de financiación ni un consejo de inversión. Es una forma práctica de comparar racks ASIC tipo Sohu con sistemas de inferencia basados ​​en GPU mediante el ajuste de la carga de trabajo, la calidad de la medición, la madurez del tiempo de ejecución y la planificación de salida.

La mayoría de los equipos no deberían comprar hardware de inferencia especializado hasta que la línea base de la GPU ya esté bien ajustada. Los lotes débiles, los p99 faltantes, la ausencia de pruebas de regresión de calidad y ningún ejercicio de reversión seguirán al equipo hasta el nuevo chip.

Por qué el silicio de inferencia especializada vuelve a estar sobre la mesa

El paso de la escasez de formación a la economía de inferencia

Muchos equipos de IA están pasando de experimentos con modelos ocasionales a cargas de trabajo de inferencia recurrentes. La carga no es sólo el acceso a los modelos. Ofrece latencia, tiempo de cola, confiabilidad, planificación de capacidad, visibilidad de costos y el trabajo de ingeniería necesario para mantener la capacidad de respuesta de las funciones de IA orientadas al usuario.

Eso cambia la discusión sobre el hardware. El hardware de entrenamiento a menudo se juzga por el rendimiento por lotes, la escala de memoria y el comportamiento de entrenamiento distribuido. La inferencia de producción pregunta sobre el tiempo hasta el primer token, p95, p99, tiempo en cola, estabilidad de transmisión y reversión.

El silicio de inferencia especializado se vuelve interesante cuando la carga de trabajo se repite: la misma familia de modelos, formas de mensajes similares, ventanas de contexto conocidas, longitudes de salida conocidas y tráfico que se puede pronosticar con cierta confianza. Si la hoja de ruta del modelo cambia cada pocas semanas, la flexibilidad del hardware puede valer más que cualquier ganancia de eficiencia declarada.

Lo que representa Etched Sohu sin el ruido de la financiación

Etched describe su primer producto como grupos de inferencia de frontera y dice que su enfoque codiseña chips, bastidores, software y métodos de fabricación. Esto es importante porque las cargas de trabajo basadas en transformadores y en mezcla de expertos se encuentran en el centro de muchos sistemas lingüísticos, y la inferencia es donde la producción de productos de IA puede soportar una presión informática continua.

El mismo enfoque acota la apuesta. Los compradores deben creer que las cargas de trabajo futuras seguirán coincidiendo con los supuestos de hardware. Esto puede ser racional para productos estables y de gran volumen y riesgoso para los equipos que aún prueban familias de modelos, longitudes de contexto, entradas multimodales o marcos de servicio.

Por qué las GPU siguen siendo el punto de comparación

Las GPU siguen siendo la base predeterminada porque protegen las elecciones futuras. El material de arquitectura Blackwell de NVIDIA enfatiza una amplia aceleración de IA, memoria, redes, características de Transformer Engine y la integración de la pila de software. TensorRT-LLM y vLLM también muestran cuánta optimización aún existe en la pila de servicio.

Entonces, la verdadera decisión no es ASIC o GPU en abstracto. Se trata de qué cargas de trabajo merecen especialización y cuáles aún necesitan espacio para moverse.## La compensación: eficiencia de ASIC versus flexibilidad de GPU

Un ASIC de inferencia de IA está diseñado en torno a un conjunto más limitado de patrones de cálculo que una GPU de uso general. En el mejor de los casos, ese enfoque puede mejorar el rendimiento, la densidad o la eficiencia energética de las cargas de trabajo compatibles. A modo de inferencia, el objetivo puede incluir arquitectura del modelo, patrones del núcleo, diseño de la memoria, formato de precisión y suposiciones de servicio.

Ese es el atractivo. Un sistema creado para un trabajo más limitado puede realizar ese trabajo muy bien.

Las GPU protegen a los equipos de la incertidumbre. Pueden ejecutar muchos tipos de modelos, admitir múltiples marcos, absorber cambios de arquitectura más fácilmente y beneficiarse de herramientas maduras cuando el tamaño del modelo, la estrategia de cuantificación, los patrones de recuperación o las características multimodales aún están en movimiento.

El costo oculto de la adopción de ASIC es el valor de la opción. Si un equipo se compromete con una ruta especializada, debe saber qué sucede cuando el modelo cambia, el tráfico aumenta, las ventanas de contexto se expanden o el tiempo de ejecución carece de una característica del producto.

El mapa de preparación de inferencia Optijara ASIC

El mapa de preparación de inferencia ASIC de Optijara es un marco de cinco ejes para decidir si un sistema similar a Sohu merece una prueba de concepto.

sirena diagrama de flujo TD A[Carga de trabajo de inferencia de producción] --> B[Estabilidad de la carga de trabajo] A --> C[Latencia y forma de rendimiento] A --> D [Exposición de la hoja de ruta del modelo] A --> E [Madurez de servicio y observabilidad] A --> F[arquitectura alternativa] B --> G{¿ASIC POC listo?} C --> GRAMO D --> GRAMO mi -> GRAMO F --> GRAMO

Eje 1: Estabilidad de la carga de trabajo

La preparación de ASIC comienza con la repetibilidad. Las buenas señales incluyen familias de modelos recurrentes, formas de mensajes predecibles, longitudes de contexto estables, longitudes de salida conocidas y tráfico que se puede pronosticar con cierta confianza.

Las señales débiles incluyen cambios frecuentes de modelos, funciones experimentales, comportamiento poco claro del usuario o una gran dependencia de las capacidades de los nuevos modelos que pueden no corresponderse claramente con el hardware actual.

Eje 2: Latencia y forma de rendimiento

No evalúe el hardware de inferencia con un tiempo de respuesta promedio. Mida el tiempo hasta el primer token, p50, p95, p99, tokens por segundo, tiempo en cola, latencia de precarga, latencia de decodificación, tasa de error, comportamiento de reintento y rendimiento con una simultaneidad realista.

Los ASIC pueden funcionar bien con una forma de lote y peor con otra. Las GPU pueden parecer costosas hasta que se ajusten el procesamiento por lotes, el almacenamiento en caché, TensorRT-LLM, vLLM y la programación. La comparación sólo significa algo cuando ambas partes se ponen a prueba seriamente.

Eje 3: Exposición de la hoja de ruta del modeloUn sistema especializado puede ser una buena opción para una carga de trabajo de transformador estable y una mala opción para una hoja de ruta cambiante. Los equipos deberían preguntarse si esperan nuevos patrones de atención, ventanas de contexto más largas, entradas multimodales, diferentes formatos de precisión o cambios de modelo impulsados ​​por el proveedor.

Si la hoja de ruta no está clara, las GPU pueden conservar más valor de opción. Si la hoja de ruta es estable y la carga de trabajo es lo suficientemente grande, las pruebas ASIC se vuelven más creíbles.

Eje 4: Madurez de servicio y observabilidad

El hardware no ejecuta el producto por sí solo. La capa de servicio necesita enrutamiento, escalado automático, seguimiento, registro, alertas, reversión, controles de implementación y respuesta a incidentes. Un chip rápido conectado a una ruta de servicio inmadura puede producir un sistema más débil que una pila de GPU más lenta y mejor operada.

Esto se conecta con un trabajo de observabilidad más amplio. Si su equipo aún no ha definido métricas de tiempo de ejecución de IA, comience con los conceptos básicos operativos de la observabilidad de la inferencia de IA antes de comprometerse con el hardware.

Eje 5: Arquitectura alternativa

Las implementaciones de ASIC más seguras suponen un respaldo desde el principio. Los modelos no compatibles, los picos de tráfico, las fallas en el tiempo de ejecución, las redes degradadas o las reversiones urgentes de modelos deberían tener una ruta de regreso a la GPU o la capacidad de la nube. Si el respaldo requiere reescribir el producto, la arquitectura no está lista.

Matriz de decisión: cuando los racks ASIC tipo Sohu merecen una prueba de concepto

Los racks ASIC tipo Sohu merecen atención cuando la carga de trabajo es de gran volumen, de nivel de producción, sensible a la latencia y lo suficientemente estable como para medirla. El equipo ya debería conocer las versiones del modelo, la duración de las secuencias, las distribuciones del tráfico, las longitudes de salida y los SLO objetivo.

Los productos dudosos con uso real pero con una estrategia de modelo no resuelta aún pueden ejecutar un POC de ASIC, pero solo como recopilación de evidencia, no como un atajo de adquisiciones.

Evite el silicio de inferencia especializado cuando la carga de trabajo sea de investigación intensa, de bajo volumen, muy puntiaguda o dependa de una amplia compatibilidad del marco. Tenga cuidado cuando la expansión multimodal esté cerca, el proveedor del modelo pueda cambiar o la telemetría de producción sea escasa.

Cómo probar sistemas de inferencia ASIC frente a GPU sin engañarte

Un punto de referencia válido comienza con entradas similares a las de producción: categorías de mensajes reales, longitudes de contexto realistas, longitudes de salida esperadas, comportamiento de transmisión, patrones de concurrencia, cargas útiles de recuperación y casos de error. Las indicaciones sintéticas pueden ayudar con la repetibilidad, pero no deberían reemplazar los seguimientos de la carga de trabajo.MLCommons Inference es un recordatorio útil de que la medición de la inferencia necesita escenarios definidos y métodos comparables. Las pruebas de carga de trabajo internas siguen siendo más importantes porque la forma del tráfico, la pila de servicios y la barra de calidad son específicos.

Divida la latencia en fases. Mida el tiempo de enrutamiento, el tiempo de cola, el llenado previo, el tiempo hasta el primer token, la decodificación, la cadencia de transmisión y el tiempo total de finalización. La latencia promedio oculta el comportamiento de la cola.

Ejecute pruebas independientes para mensajes breves, mensajes largos, resultados cortos, resultados largos, baja concurrencia, alta concurrencia y tráfico en ráfagas. No los colapses en una sola partitura. Los sistemas ASIC y GPU pueden responder de manera diferente según el tamaño del lote, la longitud del contexto y el cambio de simultaneidad.

Pruebe también las líneas base de GPU optimizadas. Antes de la prueba de concepto, ajuste el procesamiento por lotes, el almacenamiento en caché, la configuración del tiempo de ejecución, la ubicación del modelo y la configuración de servicio.

La cuantificación puede cambiar el rendimiento y la calidad de las tareas. No evalúe tokens por segundo sin verificar la confiabilidad de la salida, la factibilidad, el comportamiento de rechazo, la precisión de las llamadas a las herramientas, la calidad de la recuperación y el éxito de la tarea. Un sistema más rápido que degrada silenciosamente los resultados críticos para el negocio no es más barato en la práctica.

Un POC serio también incluye simulacros de falla.

La hoja de ruta del modelo corre el riesgo de que la mayoría de los equipos subestimen el precio

El rendimiento de ASIC puede depender de suposiciones sobre variantes de transformadores, mecanismos de atención, diseño de memoria, longitud de secuencia, precisión y soporte del kernel. Si los modelos futuros se alejan de esos supuestos, la ruta del hardware puede volverse menos útil.

Eso no hace que el encierro sea automáticamente malo. Significa que el bloqueo debe tener un precio. Si una carga de trabajo es estable y valiosa, la especialización puede ser racional. Si el producto depende de un cambio rápido de modelo, el bloqueo puede resultar costoso.

Los equipos deben mapear cómo encaja el tiempo de ejecución de ASIC con vLLM, TensorRT-LLM, Kubernetes, empaquetado de modelos, monitoreo, secretos, CI/CD y reversión. Incluso si algunas herramientas están orientadas a GPU, las expectativas operativas siguen siendo las mismas: implementar de forma segura, observar el comportamiento y recuperarse rápidamente.

Las decisiones sobre hardware también conllevan riesgos de sincronización. Los plazos de entrega, las reservas de capacidad, los contratos de soporte, la preparación del centro de datos, la energía, las redes y el trabajo de integración pueden durar más que el plan modelo actual. Los compradores también dependen del soporte de tiempo de ejecución del proveedor, la madurez del compilador, la compatibilidad del modelo y la hoja de ruta futura del chip. Si un nuevo modelo requiere esperar el soporte del proveedor, incluya ese retraso en la decisión.

Lista de verificación de implementación para una prueba de concepto de inferencia ASIC

Durante el POC

Ejecute tráfico representativo, compare con líneas base de GPU optimizadas, registre métricas de servicio completo, evalúe la regresión de calidad, verifique la observabilidad, pruebe supuestos de escalado automático y ejecute simulacros de conmutación por error. El POC debería presentar pruebas comparables, no una carpeta de capturas de pantalla.

Después de la decisión del POC

Escriba un memorando de aprobación o no que cubra el ajuste de la carga de trabajo, los supuestos económicos, las brechas operativas, el costo de la migración, el riesgo de la hoja de ruta del modelo, el riesgo de adquisiciones y la arquitectura alternativa. Si el memorándum no puede explicar cómo la ruta ASIC falla de manera segura, la decisión no está lista.

json { "asicReadinessProfile": {

"latencyTargets": ["timeToFirstToken", "p95", "p99", "tokensPerSecond"],

"observabilityCoverage": ["registros", "rastros", "métricas", "alertas"],

} }

Errores comunes al comparar chips de inferencia ASIC con GPU

El primer error es comparar con una base de GPU no optimizada. Primero ajuste la ruta de la GPU, incluido el software de servicio, el procesamiento por lotes, el almacenamiento en caché y la configuración de tiempo de ejecución.

El segundo es confiar en el rendimiento de los titulares sin distribución de latencia. Mida p95, p99, el comportamiento de ráfaga y el tiempo de cola, no solo el tiempo de ejecución del modelo.

El tercero es ignorar las regresiones de calidad derivadas de la cuantificación. Una precisión más baja puede mejorar el rendimiento, pero puede perjudicar la confiabilidad de la salida. Combine las pruebas de rendimiento con controles de calidad a nivel de tareas.

Otro error común es olvidar la capa para servir. El hardware no puede compensar un enrutamiento deficiente, rastros faltantes, reversiones débiles o propiedad de incidentes poco clara.

Por último, no trate las adquisiciones como una decisión puramente financiera. La compra de hardware determina la elección del modelo, el flujo de trabajo de implementación, la planificación de la confiabilidad y la flexibilidad futura.

Advertencias, limitaciones y un plan de medición práctico

Es posible que los reclamos de proveedores públicos no coincidan con su carga de trabajo. La disponibilidad y los precios varían. El comportamiento del modelo cambia. El soporte de software es importante. La obsolescencia de la caché puede distorsionar los resultados de las pruebas comparativas. El costo de implementación puede borrar los ahorros teóricos. Un sistema que parece eficiente de forma aislada puede parecer menos atractivo después de incluir la migración, el soporte, el respaldo y el riesgo operativo.

Vale la pena evaluar el silicio de inferencia especializado cuando el ajuste de la carga de trabajo es claro y la evidencia operativa es sólida. Las GPU siguen siendo valiosas cuando la portabilidad, la variedad de modelos y la flexibilidad de la hoja de ruta son más importantes.