Test d'acceptation runtime de K-EXAONE 2.0 : comment évaluer le service MoE à poids ouverts 750B-A37B avant la production

K-EXAONE 2.0 ne devrait pas être accepté comme une seule décision de déploiement. Il arrive sous forme d'une famille d'artefacts officiels et de routes de service, et ces routes peuvent diverger lorsque la quantification, le routage des experts actifs, le contexte long, la qualité multilingue, les queues de latence et le retour arrière entrent en jeu. Les chiffres de la fiche modèle sont utiles. Ils ne suffisent pas.

La question de production est plus étroite et moins séduisante. Quelle charge de travail peut être acceptée, sur quelle route, sous quelles limites, avec des preuves assez solides pour qu'un opérateur signe l'enregistrement de décision ? Voilà le niveau attendu. Cet article traite la version comme un test d'acceptation plutôt que comme un récapitulatif de lancement. Les affirmations de LG AI Research sur les benchmarks, la vitesse et les performances doivent être lues comme des affirmations de fournisseur tant qu'elles n'ont pas été reproduites sur votre matériel, votre runtime, votre mélange de prompts, vos longueurs de contexte et votre profil de concurrence. Ce sont des hypothèses de départ utiles, pas une preuve de production.

Si votre équipe a récemment examiné la vérification des artefacts Kimi K3, les builds TensorRT observables, les décisions de personnalisation d'IA locale ou le routage prix-performance, la même discipline s'applique ici. Figez d'abord l'artefact. Mesurez ensuite la route.

Pourquoi K-EXAONE 2.0 a besoin d'un test d'acceptation, pas d'un récapitulatif de lancement

K-EXAONE 2.0 750B-A37B est présenté par LG AI Research comme un modèle Mixture of Experts multilingue avec 750B paramètres au total et 37B paramètres actifs. La fiche modèle officielle indique une longueur de contexte de 262 144 tokens, 256 experts au total, 8 experts activés, une licence Apache-2.0 et dix langues prises en charge : coréen, anglais, espagnol, allemand, japonais, vietnamien, français, italien, polonais et portugais. La fiche modèle indique aussi une limite de connaissances au T2 2025.

Ces faits comptent. Ils ne répondent pas à eux seuls à la question du déploiement. Les paramètres actifs peuvent réduire le calcul par token par rapport à un modèle dense de même taille totale, tandis que la pile de service doit toujours stocker, partitionner, router et observer un inventaire d'experts beaucoup plus grand. L'écart entre l'attrait de la fiche modèle et la préparation à la production est l'endroit où se produisent beaucoup d'erreurs coûteuses.

Une équipe de production doit valider la révision du dépôt, le manifeste des fichiers, la configuration, le tokenizer, le chemin de service, l'enveloppe mémoire, le comportement de l'interconnexion, la stabilité en contexte long, la régression de qualité, les queues de latence et la route de retour arrière avant d'approuver toute charge de travail. C'est un processus exigeant parce que le service de grands MoE à poids ouverts a une vaste surface opérationnelle.

Le test d'acceptation runtime K-EXAONE d'Optijara est un cadre de décision par route. Il aide une équipe à décider si BF16, FP8, NVFP4, DSpark, un modèle plus petit ou une API hébergée est le bon chemin pour une charge de travail précise. Il ne suppose pas qu'une seule route gagne partout. Si une équipe ne peut pas financer une exécution de référence BF16 correcte, elle doit rester prudente avant de miser un flux de production sur la plus grande route.

Étape 1 : figez l'artefact avant de mesurer le modèle

Le premier seuil d'acceptation intervient avant que le modèle ne génère un token. Épinglez le dépôt Hugging Face exact, la révision, le manifeste de fichiers, la licence, la configuration, les fichiers du tokenizer et la ligne de commande de service. Capturez l'URL canonique de la fiche modèle, la page Files and versions, config.json, LICENSE, les fiches modèles officielles FP8, NVFP4 et DSpark, le dépôt GitHub, le blog officiel, le rapport technique et les consignes officielles de service utilisées pour l'exécution.

Réconciliez les affirmations entre la fiche modèle, le rapport technique, le dépôt GitHub, le fichier de configuration et les variantes quantifiées. Si une page décrit la prise en charge différemment d'une autre, traitez cela comme un point d'enquête. Ne supposez pas que la page qui semble la plus récente est correcte. La revue de licence appartient au même seuil. Apache-2.0 peut être favorable à l'usage commercial, mais les équipes doivent tout de même gérer les notices, la revue de redistribution, les règles de packaging interne et les contrôles de politiques en aval. L'accès hébergé, le fine-tuning, la redistribution du modèle et les images dérivées peuvent déclencher des parcours de revue interne différents.

C'est aussi ici que les équipes doivent noter ce qu'elles ne testent pas. Par exemple, une évaluation qui couvre uniquement l'extraction en anglais à 8K de contexte ne doit pas être citée plus tard comme approbation pour la synthèse juridique en coréen près de la limite de 262K. La discipline de périmètre évite des débats plus tard.

La matrice de routes Optijara : BF16 contre FP8 contre NVFP4 contre DSpark

La matrice de routes Optijara note chaque route selon la maturité de l'artefact, l'adéquation matérielle, l'enveloppe mémoire, la pression d'interconnexion, le risque de régression de qualité, la prise en charge du service, la visibilité de débogage, le temps de démarrage à froid, la simplicité du retour arrière et le coût par charge de travail acceptée. L'objectif n'est pas de couronner un vainqueur. L'objectif est de sélectionner la route la plus légère qui passe les seuils de la charge de travail.

BF16 obtient généralement la position de référence parce qu'il donne la référence la plus propre pour la correction, la mise en forme, le comportement de refus, la qualité multilingue et le rappel en contexte long. FP8 ne doit être jugé qu'après la définition des seuils BF16. NVFP4 est une route plus agressive, elle mérite donc une revue plus stricte de la précision factuelle, de la mise en forme, du comportement dans les langues rares et des cas limites en contexte long. DSpark doit être traité comme une route opérationnelle, pas comme un raccourci. La fiche modèle officielle dit que K-EXAONE 2.0 prend en charge les méthodes de décodage spéculatif MTP et DSpark et affirme qu'elles peuvent accélérer la génération d'environ 3 à 5 fois. Ce chiffre doit être traité comme une affirmation de fournisseur tant qu'il n'a pas été reproduit sur le matériel et la charge de travail cibles.

{
  "framework": "Optijara Route Matrix",
  "model": "K-EXAONE-2.0-750B-A37B",
  "routes": ["BF16", "FP8", "NVFP4", "DSpark"],
  "required_gates": ["artifact_integrity", "quality_delta", "long_context", "multilingual_regression", "latency_tails", "cost_per_accepted_workload", "rollback"],
  "default_baseline": "BF16",
  "rollback_target": "BF16 or hosted API, depending on capacity and incident class"
}

Une route peut réussir techniquement et tout de même perdre commercialement. Ce n'est pas un échec du test. C'est le test qui fait son travail. Si FP8 réduit la pression mémoire mais augmente la revue manuelle, les appels de repli ou le risque d'incident, la charge de travail peut être moins chère sur BF16, un modèle plus petit ou une API hébergée.

Enveloppes de mémoire, de réseau et de parallélisme pour un MoE à 37B actifs

Un chiffre de 37B paramètres actifs ne doit pas être lu comme un budget mémoire de 37B. Pour K-EXAONE 2.0, la fiche officielle décrit 750B paramètres au total, 37B paramètres actifs, 256 experts au total et 8 experts activés. Le routage des experts actifs modifie le calcul par token, tandis que le système a toujours besoin de mémoire et de capacité d'interconnexion pour les poids, les poids quantifiés, les métadonnées de routage, le cache KV, les buffers de batch, les surcoûts du runtime et la marge de sécurité.

Le parallélisme expert, tensoriel et pipeline doit être testé comme une question de topologie. Faites varier la longueur de séquence, la taille de batch, les utilisateurs concurrents, les tokens générés et le mélange de prompts. Incluez des scénarios de déséquilibre des experts où des prompts similaires peuvent être routés de manière inégale. Surveillez les communications collectives, la mise en file, le chargement hôte vers appareil, les timeouts NCCL et les bulles de pipeline. La latence moyenne peut sembler acceptable tandis que le p99 se dégrade sous une forme précise de batch ou de contexte.

L'avertissement pratique est simple. N'utilisez pas le nombre de paramètres actifs comme raccourci d'achat. La route qui charge n'est pas automatiquement celle qui survit au trafic, au contexte long ou à la récupération après un déploiement raté.

Tests de fiabilité en contexte long et multilingue

La fiche modèle officielle indique une longueur de contexte de 262 144 tokens. Traitez cela comme une surface de fiabilité, pas comme une case à cocher. Testez des prompts courts, moyens, longs et proches de la limite. Utilisez des distracteurs de récupération, des entités répétées, le placement de réponse en fin de contexte, des instructions contradictoires, la compression de synthèse et l'extraction structurée. Suivez le temps de préremplissage, la croissance du cache KV, la latence du premier token, la stabilité de décodage, le comportement de troncation, les erreurs de fenêtre de contexte et la fidélité.

Une suite utile pour le contexte long comporte quatre niveaux : prompts de production normaux, prompts étendus avec distracteurs, prompts proches de la limite avec preuve de réponse près de la fin et prompts de mise en forme adversariale qui stressent JSON, les tables ou les citations. Chaque route doit être comparée à BF16 sur les mêmes entrées. Une route qui réussit sur des prompts courts peut quand même échouer près de la limite de contexte.

La régression multilingue doit couvrir les dix langues documentées : coréen, anglais, espagnol, allemand, japonais, vietnamien, français, italien, polonais et portugais. Utilisez des tâches appariées pour l'extraction, la synthèse, le raisonnement, le comportement de refus, la préservation de la terminologie et la mise en forme. Les vérifications automatisées peuvent détecter les échecs de schéma, les champs manquants, les fuites de langue ou la troncation. La revue humaine reste importante pour la nuance, le ton et la terminologie du domaine.

Un modèle qui répond bien à des prompts de benchmark en anglais peut quand même mal traiter la terminologie polonaise, laisser fuiter de l'anglais dans une sortie vietnamienne ou perdre une preuve tardive dans un long document japonais. La suite d'acceptation doit rendre ces échecs visibles avant qu'un utilisateur ne les trouve.

Latence, débit et coût par charge de travail acceptée

L'acceptation en production doit mesurer le temps de démarrage à froid, le temps de chargement du modèle, la latence chaude du premier token, les latences p50, p95 et p99 du premier token, la latence de décodage, les tokens par seconde, les requêtes acceptées par seconde, le délai de file d'attente, le taux de timeout, le taux de retry et l'utilisation GPU. Gardez la vitesse synthétique des tokens séparée du débit de charge de travail acceptée. Une requête ne doit compter que si elle respecte les seuils de qualité, de mise en forme, de sécurité, de latence et de coût.

Le coût par charge de travail acceptée est plus honnête que le coût brut par token pour cette classe de déploiement. La quantification peut réduire la pression mémoire, mais si elle cause plus de retries, de revue manuelle, d'appels de repli ou de complexité de retour arrière, le coût de charge de travail acceptée peut ne pas s'améliorer. De même, une API hébergée ou un modèle plus petit peut être le meilleur choix lorsque le volume, les besoins de confidentialité, les objectifs de latence, les gains de qualité ou la maturité opérationnelle ne justifient pas le service d'un grand MoE.

Définissez les seuils avant le début du test. Si l'équipe continue de déplacer le seuil après avoir vu les résultats, l'évaluation s'est transformée en plaidoyer.

Playbook d'acceptation production : du manifeste au retour arrière

Utilisez ce playbook comme ordre d'exécution pour une évaluation K-EXAONE.

L'injection de défaillance doit inclure un shard manquant, un fichier corrompu, une incompatibilité de tokenizer, un OOM, un timeout NCCL, un déséquilibre d'experts, un timeout en contexte long, une sortie malformée, un échec de sécurité, un pic de trafic et l'activation du repli. La posture de retour arrière diffère selon la route. BF16 peut être la référence de correction, mais peut nécessiter un repli hébergé si la capacité est contrainte. FP8 et NVFP4 doivent revenir à BF16 ou au service hébergé. DSpark doit revenir au chemin de service standard si le comportement d'accélération devient opaque ou instable.

L'enregistrement de décision doit être banal et précis : route acceptée, routes rejetées, liens de preuves, seuils passés, limites connues, propriétaire, cible de retour arrière, date de retest et charges de travail approuvées. Toute version plus vague devient difficile à reconstruire après le premier incident.

Les erreurs fréquentes des équipes avec le déploiement de grands MoE à poids ouverts

Les équipes benchmarkent souvent une révision non épinglée, font confiance aux affirmations de vitesse du fournisseur sans reproduction, mesurent uniquement la latence moyenne, ignorent le cache KV en contexte long, supposent que les paramètres actifs égalent l'empreinte mémoire, sautent la régression multilingue, traitent la quantification comme un gain gratuit, manquent la revue de licence ou lancent un canary avant que le retour arrière existe. Chaque erreur crée un mode de défaillance différent, de la dérive silencieuse de qualité aux boucles de retry coûteuses.

Les réserves sont pratiques. Le coût d'implémentation compte. La disponibilité matérielle compte. La maturité du runtime compte. Les exigences de confidentialité, l'obsolescence du cache, la qualité du jeu d'évaluation, les régressions propres aux routes et les compromis opérationnels peuvent changer la bonne réponse. Une API hébergée ou un modèle plus petit peut battre l'auto-hébergement lorsque la charge de travail n'a pas besoin de la plus grande route, que le cas de confidentialité est faible ou que l'équipe d'exploitation ne peut pas assumer les modes de défaillance.

Si votre équipe veut de l'aide pour transformer des artefacts de version en suite d'évaluation épinglée, matrice de sélection de routes, plan de test de service et décision de déploiement prête au retour arrière, Optijara peut aider. L'important est de prendre la décision de production à partir de preuves, pas à partir du titre du lancement.