Etched Sohu et la course aux inférences ASIC : comment évaluer les puces spécialisées par rapport aux GPU

La question n’est pas de savoir si une puce a l’air rapide dans une démo. Pour une équipe d’IA de production, la question la plus difficile est de savoir si le matériel d’inférence spécialisé semble toujours bon une fois que la latence finale, les changements de modèle, la qualité de quantification, l’observabilité, le calendrier d’approvisionnement et le routage de secours sont pris en compte.

Etched Sohu est un cas de test utile. TechCrunch a rapporté qu'Etched avait atteint une valorisation de 5 milliards de dollars et revendiqué plus d'un milliard de dollars de ventes de puces, tandis qu'Etched décrit ses systèmes comme des clusters d'inférence de frontière conçus autour de puces, de racks, de logiciels et de méthodes de fabrication pour l'inférence de modèles de frontière. Cela rend l’entreprise difficile à ignorer pour les équipes d’infrastructure. Cela ne répond pas, en soi, à la question de l’opérateur : une charge de travail réelle doit-elle passer d’une capacité GPU flexible à un chemin d’inférence ASIC ?

Il ne s’agit pas d’un classement de fournisseurs, d’un récapitulatif de financement ou de conseils en investissement. Il s'agit d'un moyen pratique de comparer les racks ASIC de type Sohu avec les systèmes d'inférence basés sur GPU en termes d'ajustement de la charge de travail, de qualité des mesures, de maturité d'exécution et de planification de sortie.

La plupart des équipes ne devraient pas acheter de matériel d'inférence spécialisé tant que la base de référence du GPU n'est pas déjà bien réglée. Un batch faible, des p99 manquants, aucun test de régression de qualité et aucun exercice de restauration ne suivront l'équipe sur la nouvelle puce.

Pourquoi le silicium d'inférence spécialisé est de retour sur la table

Le passage de la rareté de la formation à l’économie d’inférence

De nombreuses équipes d’IA abandonnent les expériences occasionnelles sur modèles pour se tourner vers des charges de travail d’inférence récurrentes. Le fardeau ne réside pas seulement dans l’accès aux modèles. Il assure la latence, le temps d'attente, la fiabilité, la planification des capacités, la visibilité des coûts et le travail d'ingénierie nécessaire pour que les fonctionnalités d'IA destinées aux utilisateurs restent réactives.

Cela change la discussion sur le matériel. Le matériel de formation est souvent jugé en fonction des performances par lots, de l'échelle de la mémoire et du comportement de formation distribuée. L'inférence de production pose des questions sur le temps nécessaire à l'obtention du premier jeton, p95, p99, le temps d'attente, la stabilité du streaming et la restauration.

Le silicium d'inférence spécialisé devient intéressant lorsque la charge de travail se répète : même famille de modèles, formes d'invite similaires, fenêtres de contexte connues, longueurs de sortie connues et trafic pouvant être prévu avec une certaine confiance. Si la feuille de route du modèle change toutes les quelques semaines, la flexibilité matérielle peut valoir plus que tout gain d'efficacité revendiqué.

Ce que représente Etched Sohu sans le bruit du financement

Etched décrit son premier produit comme des clusters d'inférence frontaliers et affirme que son approche co-conçoit des puces, des racks, des logiciels et des méthodes de fabrication. Cela est important car les charges de travail basées sur des transformateurs et un mélange d'experts sont au centre de nombreux systèmes linguistiques, et l'inférence est le domaine où les produits d'IA de production peuvent supporter une pression de calcul continue.

La même concentration réduit le pari. Les acheteurs doivent croire que les futures charges de travail continueront de correspondre aux hypothèses matérielles. Cela peut être rationnel pour des produits stables et à volume élevé et risqué pour les équipes qui testent encore des familles de modèles, des longueurs de contexte, des entrées multimodales ou des frameworks de service.

Pourquoi les GPU restent le point de comparaison

Les GPU restent la référence par défaut car ils protègent les choix futurs. Le matériel d'architecture Blackwell de NVIDIA met l'accent sur une large accélération de l'IA, la mémoire, la mise en réseau, les fonctionnalités du Transformer Engine et l'intégration de la pile logicielle. TensorRT-LLM et vLLM montrent également à quel point l'optimisation réside encore dans la pile de diffusion.

La vraie décision n’est donc pas ASIC ou GPU dans l’abstrait. Il s’agit de savoir quelles charges de travail méritent une spécialisation et quelles charges de travail ont encore besoin d’espace pour se déplacer.## Le compromis : efficacité ASIC contre flexibilité GPU

Un ASIC d’inférence IA est conçu autour d’un ensemble plus restreint de modèles de calcul qu’un GPU à usage général. Dans le meilleur des cas, cette concentration peut améliorer les performances, la densité ou l’efficacité énergétique des charges de travail prises en charge. À des fins d'inférence, la cible peut inclure l'architecture du modèle, les modèles de noyau, la disposition de la mémoire, le format de précision et les hypothèses de service.

C'est l'appel. Un système conçu pour un travail plus restreint peut très bien faire ce travail.

Les GPU protègent les équipes de l'incertitude. Ils peuvent exécuter de nombreux types de modèles, prendre en charge plusieurs frameworks, absorber plus facilement les changements d'architecture et bénéficier d'outils matures lorsque la taille du modèle, la stratégie de quantification, les modèles de récupération ou les fonctionnalités multimodales sont encore en mouvement.

Le coût caché de l’adoption des ASIC est la valeur de l’option. Si une équipe s'engage sur un chemin spécialisé, elle doit savoir ce qui se passe lorsque le modèle change, que le trafic augmente, que les fenêtres de contexte s'agrandissent ou que le runtime ne dispose pas d'une fonctionnalité de produit.

La carte de préparation à l'inférence Optijara ASIC

La carte de préparation à l'inférence ASIC Optijara est un cadre à cinq axes permettant de décider si un système de type Sohu mérite une preuve de concept.

sirène organigramme TD A[Charge de travail d'inférence de production] --> B[Stabilité de la charge de travail] A --> C[Latence et forme du débit] A --> D[Exposition de la feuille de route du modèle] A --> E[Maturité de service et d'observabilité] A --> F[Architecture de secours] B --> G{ASIC POC prêt ?} C --> G D --> G E --> G F --> G

Axe 1 : Stabilité de la charge de travail

La préparation aux ASIC commence par la répétabilité. Les bons signaux incluent des familles de modèles récurrents, des formes d'invite prévisibles, des longueurs de contexte stables, des longueurs de sortie connues et un trafic qui peut être prévu avec une certaine confiance.

Les signaux faibles incluent des échanges de modèles fréquents, des fonctionnalités expérimentales, un comportement utilisateur peu clair ou une forte dépendance à l'égard de nouvelles fonctionnalités de modèle qui peuvent ne pas correspondre correctement au matériel actuel.

Axe 2 : Latence et forme du débit

N'évaluez pas le matériel d'inférence avec un temps de réponse moyen. Mesurez le temps jusqu'au premier jeton, p50, p95, p99, les jetons par seconde, le temps d'attente, la latence de pré-remplissage, la latence de décodage, le taux d'erreur, le comportement des nouvelles tentatives et le débit avec une concurrence réaliste.

Les ASIC peuvent fonctionner correctement sous une forme de lot et moins bien sous une autre. Les GPU peuvent sembler coûteux jusqu'à ce que le traitement par lots, la mise en cache, TensorRT-LLM, vLLM et la planification soient réglés. La comparaison n’a de sens que lorsque les deux côtés sont sérieusement mis à l’épreuve.

Axe 3 : Exposition de la feuille de route du modèleUn système spécialisé peut être parfaitement adapté à une charge de travail de transformateur stable et peu adapté à une feuille de route changeante. Les équipes doivent se demander si elles s’attendent à de nouveaux modèles d’attention, à des fenêtres contextuelles plus longues, à des entrées multimodales, à des formats de précision différents ou à des changements de modèle pilotés par les fournisseurs.

Si la feuille de route n’est pas claire, les GPU peuvent conserver davantage de valeur d’option. Si la feuille de route est stable et la charge de travail suffisamment importante, les tests ASIC deviennent plus crédibles.

Axe 4 : Maturité du service et de l'observabilité

Le matériel ne fait pas fonctionner le produit à lui seul. La couche de service a besoin de routage, de mise à l'échelle automatique, de traçage, de journalisation, d'alertes, de restauration, de contrôles de déploiement et de réponse aux incidents. Une puce rapide attachée à un chemin de service immature peut produire un système plus faible qu'une pile GPU plus lente et mieux exploitée.

Cela est lié à un travail d’observabilité plus large. Si votre équipe n'a pas encore défini de métriques d'exécution de l'IA, commencez par les bases opérationnelles de l'observabilité de l'inférence de l'IA avant de prendre un engagement matériel.

Axe 5 : Architecture de repli

Les déploiements ASIC les plus sûrs supposent un repli dès le départ. Les modèles non pris en charge, les pics de trafic, les échecs d'exécution, la dégradation du réseau ou les restaurations urgentes de modèles doivent pouvoir revenir à la capacité du GPU ou du cloud. Si le repli nécessite de réécrire le produit, l’architecture n’est pas prête.

Matrice de décision : quand les racks ASIC de type Sohu méritent une preuve de concept

Les racks ASIC de type Sohu méritent l'attention lorsque la charge de travail est importante, de qualité production, sensible à la latence et suffisamment stable pour être mesurée. L'équipe doit déjà connaître les versions du modèle, les longueurs de séquence, les répartitions du trafic, les longueurs de sortie et les SLO cibles.

Les produits limites avec une utilisation réelle mais une stratégie de modèle non définie peuvent toujours exécuter un ASIC POC, mais uniquement à titre de collecte de preuves, et non comme raccourci d'approvisionnement.

Évitez le silicium d'inférence spécialisé lorsque la charge de travail est lourde de recherche, de faible volume, très pointue ou dépend d'une large compatibilité de framework. Soyez prudent lorsque l'expansion multimodale est proche, que le fournisseur de modèle peut changer ou que la télémétrie de production est mince.

Comment tester les systèmes d'inférence ASIC par rapport aux GPU sans vous tromper

Un benchmark valide commence par des entrées de type production : catégories d'invites réelles, longueurs de contexte réalistes, longueurs de sortie attendues, comportement de streaming, modèles de concurrence, charges utiles de récupération et cas d'erreur. Les invites synthétiques peuvent contribuer à la répétabilité, mais elles ne doivent pas remplacer les traces de charge de travail.MLCommons Inference est un rappel utile que la mesure d'inférence nécessite des scénarios définis et des méthodes comparables. Les tests de charge de travail internes sont encore plus importants car la forme de votre trafic, votre pile de services et votre barre de qualité sont spécifiques.

Divisez la latence en phases. Mesurez le temps de routage, le temps d'attente, le pré-remplissage, le temps jusqu'au premier jeton, le décodage, la cadence de diffusion et le temps d'achèvement total. La latence moyenne masque le comportement de la queue.

Exécutez des tests distincts pour les invites courtes, les invites longues, les sorties courtes, les sorties longues, la faible simultanéité, la simultanéité élevée et le trafic en rafale. Ne les regroupez pas en une seule partition. Les systèmes ASIC et GPU peuvent réagir différemment en termes de taille de lot, de longueur de contexte et de changement de concurrence.

Testez également les références GPU optimisées. Avant le POC, ajustez le traitement par lots, la mise en cache, les paramètres d'exécution, le placement du modèle et la configuration du service.

La quantification peut modifier les performances et la qualité des tâches. N'évaluez pas les jetons par seconde sans vérifier la fiabilité de la sortie, la factualité, le comportement de refus, la précision des appels d'outils, la qualité de la récupération et la réussite des tâches. Un système plus rapide qui dégrade discrètement les résultats critiques pour l’entreprise n’est pas moins cher en pratique.

Un POC sérieux comprend également des exercices d’échec.

La feuille de route du modèle risque de sous-évaluer la plupart des équipes

Les performances des ASIC peuvent dépendre d'hypothèses concernant les variantes de transformateur, les mécanismes d'attention, la disposition de la mémoire, la longueur de la séquence, la précision et la prise en charge du noyau. Si les futurs modèles s’éloignent de ces hypothèses, la voie matérielle pourrait devenir moins utile.

Cela ne rend pas automatiquement le verrouillage mauvais. Cela signifie que le verrouillage doit être tarifé. Si une charge de travail est stable et précieuse, la spécialisation peut être rationnelle. Si le produit dépend d’un changement rapide de modèle, le verrouillage peut devenir coûteux.

Les équipes doivent cartographier la manière dont le runtime ASIC s'adapte à vLLM, TensorRT-LLM, Kubernetes, au packaging de modèles, à la surveillance, aux secrets, au CI/CD et à la restauration. Même si certains outils sont orientés GPU, les attentes opérationnelles restent les mêmes : déployer en toute sécurité, observer les comportements et récupérer rapidement.

Les décisions concernant le matériel comportent également un risque de timing. Les délais de livraison, les réservations de capacité, les contrats de support, la préparation du centre de données, l'alimentation électrique, la mise en réseau et les travaux d'intégration peuvent durer plus longtemps que le plan modèle actuel. Les acheteurs dépendent également de la prise en charge du runtime du fournisseur, de la maturité du compilateur, de la compatibilité des modèles et de la future feuille de route des puces. Si un nouveau modèle nécessite d'attendre le support du fournisseur, incluez ce délai dans la décision.

Liste de contrôle d'implémentation pour une preuve de concept d'inférence ASIC

Pendant le POC

Exécutez un trafic représentatif, comparez-le aux références GPU optimisées, enregistrez les métriques de service complètes, évaluez la régression de la qualité, vérifiez l'observabilité, testez les hypothèses de mise à l'échelle automatique et exécutez des exercices de basculement. Le POC devrait produire des preuves comparables, et non un dossier de captures d’écran.

Après la décision du POC

Rédigez un mémo de mise en œuvre/non-démarrage qui couvre l'adéquation de la charge de travail, les hypothèses économiques, les lacunes opérationnelles, le coût de migration, le risque de la feuille de route du modèle, le risque d'approvisionnement et l'architecture de secours. Si le mémo ne peut pas expliquer comment le chemin ASIC échoue en toute sécurité, la décision n'est pas prête.

json { "asicReadinessProfile": {

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

"observabilityCoverage": ["logs", "traces", "metrics", "alerts"],

} }

Erreurs courantes lors de la comparaison des puces d'inférence ASIC avec les GPU

La première erreur consiste à comparer avec une référence GPU non optimisée. Ajustez d'abord le chemin du GPU, y compris les paramètres du logiciel de service, du traitement par lots, de la mise en cache et de l'exécution.

La seconde consiste à faire confiance au débit global sans distribution de latence. Mesurez p95, p99, le comportement en rafale et le temps d'attente, et pas seulement le temps d'exécution du modèle.

La troisième consiste à ignorer les régressions de qualité issues de la quantification. Une précision inférieure peut améliorer les performances, mais elle peut nuire à la fiabilité de la sortie. Associez les tests de performances aux contrôles de qualité au niveau des tâches.

Un autre échec courant est l’oubli de la couche de service. Le matériel ne peut pas compenser un mauvais routage, des traces manquantes, une restauration faible ou une propriété d'incident peu claire.

Enfin, ne considérez pas les achats comme une simple décision financière. L'achat de matériel façonne le choix du modèle, le flux de travail de déploiement, la planification de la fiabilité et la flexibilité future.

Mises en garde, limites et plan de mesure pratique

Les réclamations des fournisseurs publics peuvent ne pas correspondre à votre charge de travail. La disponibilité et les prix varient. Le comportement du modèle change. Le support logiciel est important. L'obsolescence du cache peut fausser les résultats des tests de référence. Le coût de mise en œuvre peut effacer les économies théoriques. Un système qui semble efficace isolément peut paraître moins attrayant une fois la migration, le support, le repli et le risque opérationnel inclus.

Le silicium d'inférence spécialisé mérite d'être évalué lorsque l'adéquation à la charge de travail est claire et que les preuves opérationnelles sont solides. Les GPU restent précieux là où la portabilité, la variété des modèles et la flexibilité de la feuille de route sont les plus importantes.