Zen : architecture MoE à 1T+ paramètres

Zen est la famille de modèles de langue phare de Hanzo. Le plus grand modèle, zen4-ultra, est une architecture Mixture of Experts (MoE) de 1.04T paramètres qui active 140B paramètres à chaque passage avant. C'est l'aboutissement de trois ans de développement de modèles, de zen-nano (600M) à la famille zen4 actuelle.

Cet article décrit l'architecture, la méthode d'entraînement et le système de vérification sur la chaîne qui rend les modèles Zen auditables.

Architecture

Zen4-ultra utilise une architecture Mixture of Experts creuse. Le dessin de cœur :

Paramètres totaux : 1.04T
Paramètres actifs par token : ~140B (taux d'activation de 13.5%)
Experts : 128 experts par couche MoE, routage top-8
Couches : 96 couches transformer, une couche sur deux est MoE (48 couches MoE, 48 denses)
Fenêtre de contexte : 256K tokens (interpolation positionnelle YaRN)
Vocabulaire : 152K tokens (BPE multilingue)

Le routage MoE utilise un réseau de porte appris, avec une perte auxiliaire d'équilibrage de charge pour empêcher l'effondrement des experts. Chaque expert est une FFN standard (réseau feed-forward) avec activation SwiGLU. Le routeur choisit 8 experts sur 128 par token — assez de diversité pour saisir des motifs de raisonnement complexes, tout en gardant le calcul tractable.

Pourquoi le MoE

Les modèles denses passent à l'échelle de façon linéaire : 2x paramètres = 2x de calcul par token. Le MoE casse cette relation. Zen4-ultra a 7.4x les paramètres totaux d'un modèle dense de 140B, pour le même coût d'inférence par token. Les paramètres en plus donnent de la capacité — le modèle stocke plus de connaissance et traite des tâches plus diverses — sans hausse proportionnelle du calcul.

Le compromis, c'est la mémoire. Il faut charger les 1.04T paramètres, même si seuls 140B sont actifs. Cela demande une inférence distribuée sur plusieurs nœuds, et c'est là que le réseau ACI devient indispensable.

La famille Zen4

Modèle	Paramètres totaux	Paramètres actifs	Architecture
zen4-mini	4B	4B	Dense
zen4-base	8B	8B	Dense
zen4-pro	14B	14B	Dense
zen4-max	30B	8B	MoE (32 experts, top-2)
zen4-coder	80B	20B	MoE (64 experts, top-4)
zen4-ultra	1.04T	140B	MoE (128 experts, top-8)

Chaque modèle de la famille partage le même tokenizer, la même implémentation d'attention et le même pipeline de données d'entraînement. Les modèles denses (de mini à pro) sont distillés depuis ultra, pas entraînés à part. Cela assure une cohérence de comportement dans toute la famille.

Fusion de modèles

Les modèles Zen ne sont pas entraînés depuis zéro sur une initialisation aléatoire. Ils sont fusionnés à partir de modèles à poids ouverts parmi les plus performants, selon une méthode que nous appelons transfert de connaissance structuré.

L'architecture de base est Qwen3. Chaque modèle Zen part d'un checkpoint Qwen3 — c'est une contrainte de gouvernance dure sous la politique de la Zoo Foundation (Qwen3+ seulement). Le processus de fusion :

Alignement d'architecture : on projette les architectures des modèles sources sur l'architecture cible Zen. Pour les modèles MoE, cela comprend l'initialisation des experts à partir de couches d'un modèle dense, avec la technique d'upcycling DROP (décrite dans notre texte Drop-Upcycling : construire des modèles MoE de qualité 13B à 1/4 du coût).
Distillation de connaissance : on entraîne le modèle Zen sur un mélange de (a) données brutes de pré-entraînement et (b) sorties d'enseignants tirées des modèles sources. L'ensemble d'enseignants comprend des checkpoints Qwen3, DeepSeek et Mistral choisis selon leurs résultats sur les capacités visées.
Spécialisation des experts : après la fusion initiale, chaque expert est affiné sur des données d'un domaine — mathématiques, code, raisonnement scientifique, texte multilingue — pour pousser la spécialisation. Le routeur apprend à envoyer les tokens d'un domaine vers les experts de ce domaine.
Alignement comportemental : les entrées d'expérience DSO (optimisation sémantique décentralisée) du grand livre de la Zoo Foundation servent au réglage comportemental final. C'est la couche de gouvernance de la communauté — les comportements que Zen montre sont fixés par les entrées que la communauté a votées dans le grand livre.

Entraînement distribué

L'entraînement de zen4-ultra tourne sur les clusters de calcul de Hanzo Network — des nœuds bare-metal avec 8x H100 chacun, reliés par InfiniBand. L'infrastructure d'entraînement :

Cadre : PyTorch avec FSDP (parallélisme de données entièrement fragmenté) pour les couches denses, et un partitionnement propre en parallèle d'experts pour les couches MoE
Nœuds : 512 nœuds (4096 GPU H100) pour la campagne complète d'ultra
Durée d'entraînement : 14 jours pour la phase finale de fusion et de spécialisation
Données : 15T tokens, dédupliqués, filtrés par qualité, multilingues (97 langues)
Checkpoints : tous les 1000 pas, versés dans Hanzo Storage avec un hachage adressé par le contenu

La stratégie de parallélisme d'experts place chaque expert sur un seul GPU et utilise une communication all-to-all pour router les tokens. C'est plus bavard que le parallélisme de données, mais cela évite le surcoût mémoire de répliquer tous les experts sur chaque GPU.

Attestation du modèle sur la chaîne

Chaque checkpoint d'un modèle Zen a une attestation sur la chaîne, sur Hanzo Network. L'attestation comprend :

Hash du modèle : SHA-256 du tenseur de poids complet, calculé de façon déterministe à partir de la sérialisation canonique safetensors
Hash de la configuration d'entraînement : SHA-256 de la configuration complète (hyperparamètres, mélange de données, allocation de calcul)
Résultats de benchmark : scores standardisés (MMLU, HumanEval, MATH, etc.) calculés par des évaluateurs indépendants du comité d'évaluation de la Zoo Foundation
Attestation TEE : attestation Intel TDX ou AMD SEV des nœuds d'entraînement, prouvant que l'entraînement a tourné sur le matériel déclaré et avec le code déclaré

Le contrat d'attestation est déployé sur Hanzo Network à une adresse connue. N'importe qui peut vérifier qu'un jeu de poids correspond au hash attesté, et que les résultats de benchmark viennent du comité d'évaluation plutôt que d'une autodéclaration.

Cela n'empêche pas toutes les formes de jeu — la contamination des benchmarks dans les données d'entraînement reste difficile à détecter —, mais cela donne une chaîne vérifiable, du matériel d'entraînement aux poids publiés et à la performance annoncée. Si le hash ne correspond pas, les poids ont été modifiés. Si l'attestation TEE est invalide, l'environnement d'entraînement n'était pas celui qui était déclaré.

Inférence sur ACI

Zen4-ultra demande environ 2TB de mémoire pour charger tous les paramètres en FP16. Aucun nœud n'a autant de mémoire GPU. L'inférence est distribuée sur les nœuds de calcul ACI par parallélisme de tenseurs :

Parallélisme de tenseurs à 8 voies sur des GPU H100 d'un seul nœud pour les couches denses
Parallélisme d'experts entre nœuds pour les couches MoE — chaque nœud détient un sous-ensemble d'experts
Décodage spéculatif avec zen4-mini comme modèle brouillon, pour un gain de débit de 3.2x sur la génération longue

Latence de bout en bout pour une génération de 256 tokens : 1.8 secondes jusqu'au premier token, puis 45 tokens/seconde. Concurrentiel avec les modèles denses au même nombre de paramètres actifs, malgré le surcoût de la distribution.

Poids ouverts

Tous les modèles Zen sont publiés sous Apache 2.0 sur HuggingFace et dans le dépôt hanzoai/zen. Poids, tokenizer, configurations d'entraînement et scripts d'évaluation sont inclus. Le mandat de poids ouverts est une exigence structurelle de la gouvernance de la Zoo Foundation — il est écrit dans la charte de l'organisation, ce n'est pas une politique discrétionnaire.

Liens

Modèles : huggingface.co/zenlm
Source : github.com/hanzoai/zen
Attestations : explore.hanzo.network — registres d'attestation du modèle sur la chaîne
Benchmarks : zenlm.org/benchmarks

Hanzo AI est Techstars '17. Modèles Zen : zenlm.org. Hanzo : hanzo.ai.