BitDelta : servir 14 modèles Zen depuis un seul cluster GPU

L'économie du service de variantes de modèles affinés est hostile par défaut.

Un modèle de 70B paramètres en BF16 exige 140GB de mémoire GPU. Si vous avez 14 variantes affinées de ce modèle — chacune pour un profil de capacité différent, une spécialisation de domaine ou un réglage comportemental — l'architecture de service naïve exige 14 chargements de modèle distincts : 1.96TB de mémoire GPU, 14 processus d'inférence distincts, 14x le coût d'infrastructure. Pour chaque variante au-delà de la première, vous payez le prix plein pour ce qui est presque entièrement du savoir de base dupliqué.

BitDelta (arXiv:2402.10193) rompt cette économie. L'idée est élégante et les mathématiques sont simples.

Le fondement mathématique

Soit W_base la matrice de poids du modèle de base et W_ft la matrice de poids correspondante dans une variante affinée. Le delta comportemental est :

Δ = W_ft - W_base

BitDelta compresse ce delta à une précision de 1 bit :

W_ft ≈ W_base + α · sign(Δ)

Où α est un facteur d'échelle par matrice, calculé comme la valeur absolue moyenne de Δ :

α = (1/n) · ||Δ||_1 = mean(|Δ_ij|)

L'opération signe réduit chaque delta scalaire à un seul bit, positif ou négatif. Le facteur d'échelle α restitue la magnitude. Ensemble, l'approximation capture l'information directionnelle de la mise à jour d'affinage pour 1/32 du coût de stockage d'un delta en pleine précision (1 bit contre 32 bits par élément de paramètre).

Pourquoi cela fonctionne-t-il ? L'affinage d'un grand modèle préentraîné produit des deltas qui, en espérance, sont petits relativement aux poids de base. Le modèle de base capture la structure dominante de la langue ; l'affinage capture des modifications comportementales par-dessus cette structure. Quand le delta est petit, le signe de chaque élément est la représentation la plus informative de cet élément : la magnitude est à peu près uniforme sur la matrice delta, donc α · sign(Δ) est un code efficace.

On peut le dire plus formellement. Si l'on modélise Δ_ij comme une variable aléatoire de Laplace de position 0 et d'échelle b :

Δ_ij ~ Laplace(0, b)
|E[sign(Δ) | |Δ|]| = 1 for all nonzero Δ

Le signe préserve parfaitement l'information directionnelle. La perte d'information est uniquement dans la variation de magnitude, que le seul facteur d'échelle α récupère en partie. Pour les deltas d'affinage où la variation de magnitude est faible (modification du comportement plutôt que transfert de connaissance), l'approximation est serrée.

Réduction de mémoire : pour un modèle de 70B en BF16, les poids de base occupent 140GB. Le delta de chaque variante affinée, en BF16 complet, ajouterait encore 140GB. Au format BitDelta, chaque delta occupe environ 8.75GB (70B bits = 8.75GB, plus les scalaires α, négligeables). Le cluster de 14 variantes passe de 14 × 140GB = 1.96TB à 140GB + 14 × 8.75GB ≈ 262GB, soit une réduction de 87%.

Architecture de service

┌─────────────────────────────────────────────────────────────────┐
│                    GPU CLUSTER (8x H100, 80GB each)             │
│                                                                  │
│  ┌──────────────────────────────────────────────────────────┐   │
│  │              BASE WEIGHTS (140GB, HBM resident)          │   │
│  │  W_base for zen4-70b: attention, FFN, embeddings, norms  │   │
│  └──────────────────────────────┬───────────────────────────┘   │
│                                 │ shared read                    │
│  ┌──────────────────────────────▼───────────────────────────┐   │
│  │           DELTA CACHE (≈8.75GB per variant)              │   │
│  │  zen4-coder:    α_coder,    sign(Δ_coder)    [8.75GB]    │   │
│  │  zen4-ultra:    α_ultra,    sign(Δ_ultra)    [8.75GB]    │   │
│  │  zen4-math:     α_math,     sign(Δ_math)     [8.75GB]    │   │
│  │  zen4-writer:   α_writer,   sign(Δ_writer)   [8.75GB]    │   │
│  │  zen4-legal:    α_legal,    sign(Δ_legal)    [8.75GB]    │   │
│  │  zen4-medical:  α_medical,  sign(Δ_medical)  [8.75GB]    │   │
│  │  ...14 total...                                           │   │
│  └──────────────────────────────┬───────────────────────────┘   │
│                                 │                                │
│  ┌──────────────────────────────▼───────────────────────────┐   │
│  │              REQUEST ROUTER                               │   │
│  │  model_id → delta_load → reconstruct W_ft → inference    │   │
│  └──────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

À l'inférence, le pipeline de service est le suivant :

1. La requête arrive avec model: "zen4-coder"
2. Le routeur identifie l'entrée du cache de deltas pour zen4-coder
3. Le poids effectif est reconstruit à la volée : W_eff = W_base + α_coder · sign(Δ_coder)
4. La passe avant s'exécute avec les poids reconstruits
5. La réponse est renvoyée

L'étape 3 est le chemin critique. La reconstruction est un noyau CUDA fusionné qui lit en même temps les poids de base et les bits du delta, et reconstruit le poids effectif dans les registres ou la mémoire partagée sans matérialiser le W_eff complet en HBM. La reconstruction et la multiplication matricielle peuvent être fusionnées en une seule passe du noyau : le poids reconstruit n'existe jamais entièrement comme tenseur indépendant.

# Simplified reconstruction kernel (conceptual)
def fused_bitdelta_linear(
    x: torch.Tensor,          # input activations [batch, seq, d_in]
    w_base: torch.Tensor,     # base weight [d_out, d_in] in HBM
    delta_sign: torch.Tensor, # 1-bit delta [d_out, d_in] packed as int8
    alpha: torch.Tensor,      # scale factor [d_out] or scalar
) -> torch.Tensor:
    # In practice: single CUDA kernel, no intermediate w_eff allocation
    # Conceptually equivalent to:
    delta_unpacked = unpack_bits(delta_sign).to(w_base.dtype)  # {-1, +1}
    w_eff = w_base + alpha.unsqueeze(1) * delta_unpacked
    return torch.nn.functional.linear(x, w_eff)

L'approche du noyau fusionné maintient la consommation de pointe de bande passante HBM à environ 1.5x les poids du modèle de base, et non à 2x, parce que le delta est lu au format binaire compacté et décompacté dans la SRAM rapide pendant l'opération fusionnée.

Profil de latence

En pratique, sur le cluster de service Zen à 14 variantes :

Variante	P50 TTFT	P99 TTFT	face à la base
zen4 (base)	18ms	42ms	1.0x
zen4-coder	21ms	48ms	1.17x
zen4-ultra	22ms	51ms	1.22x
zen4-math	21ms	47ms	1.17x
zen4-writer	20ms	45ms	1.11x

Le surcoût de temps jusqu'au premier token dû à la reconstruction BitDelta est de 2-4ms, négligeable devant le coût de préremplissage pour des longueurs de prompt usuelles. Le noyau de reconstruction est borné par le calcul, pas par la mémoire, donc il passe bien à l'échelle avec la génération sur GPU.

Le débit de génération (tokens/seconde) est identique entre le modèle de base et toute variante BitDelta, puisque la reconstruction n'a lieu que pendant la phase de préremplissage. Une fois le cache KV rempli, l'étape de génération autorégressive emprunte les chemins matmul standard.

Qualité : ce qui se perd dans la compression à 1 bit

La réponse honnête : une petite quantité, soigneusement bornée.

La dégradation de qualité de BitDelta dépend de la tâche. Sur les tâches bien représentées dans les données d'affinage, le delta comportemental est fort : le signe capture de façon fiable la direction dominante du gradient. Sur les tâches à la périphérie de la distribution d'affinage, le delta est plus faible : l'approximation introduit plus de bruit relativement au signal.

Empiriquement, sur les modèles Zen évalués sur leurs suites de tâches cibles :

Modèle	Pleine précision	BitDelta	Delta
zen4-coder (HumanEval)	72.4%	71.1%	-1.3%
zen4-math (MATH-500)	68.9%	67.8%	-1.1%
zen4-writer (WritingBench)	84.2%	83.7%	-0.5%
zen4-legal (LegalBench)	61.3%	60.1%	-1.2%

La dégradation de 1-1.3% sur les suites de tâches principales est le prix d'une réduction de mémoire de 87%. Pour toutes les variantes Zen, ce compromis est acceptable : l'écart de qualité reste sous le seuil d'un changement de comportement perceptible par l'utilisateur dans les cas d'usage usuels.

MonoSoup : complément SVD d'un seul point de contrôle

MonoSoup (arXiv:2602.09689) traite un problème complémentaire : lorsque plusieurs points de contrôle affinés du même modèle de base existent, comment les fusionner en un seul point de contrôle sans les charger tous en même temps ?

MonoSoup applique une SVD au vecteur de tâche (Δ = W_ft - W_base) pour identifier les composantes de bas rang qui capturent le plus d'information comportementale, puis les agrège entre les points de contrôle :

For checkpoints {W_1, W_2, ..., W_k}:
  Δ_i = W_i - W_base
  [U_i, S_i, Vh_i] = truncated_SVD(Δ_i, rank=r)
  τ_i = U_i · diag(S_i) · Vh_i  # rank-r approximation

MonoSoup merge:
  W_merged = W_base + (1/k) · Σ τ_i

La troncature SVD au rang r agit comme une étape de débruitage : l'affinage tend à modifier un modèle le long d'un petit nombre de directions à forte variance dans l'espace des poids. Capturer ces directions par SVD tronquée et les fusionner capture l'essence comportementale de chaque point de contrôle, sans le bruit des directions de plus faibles valeurs singulières.

Nous utilisons MonoSoup pendant les entraînements Zen comme étape de moyennage de points de contrôle : tous les 1000 pas de gradient, nous fusionnons le point de contrôle courant avec le meilleur précédent via MonoSoup plutôt que par un moyennage naïf. Cela réduit le bruit d'entraînement et produit des courbes de perte plus lisses, avec une meilleure qualité finale.

K-Merge : gestion en ligne d'adaptateurs LoRA pour la périphérie

K-Merge (arXiv:2510.13537) résout une autre variante du problème de service : à la périphérie, où le stockage est contraint à un budget fixe de B gigaoctets, comment servir K adaptateurs LoRA efficacement ?

K-Merge maintient un pool d'adaptateurs fusionnés sous la contrainte que le stockage total ne dépasse jamais B. Lorsqu'un nouvel adaptateur est demandé et qu'il n'est pas dans le pool :

1. On calcule la similarité par paires entre le nouvel adaptateur et tous les membres existants du pool (similarité cosinus sur les vecteurs de tâche)
2. On identifie l'adaptateur existant le plus similaire
3. On fusionne le nouvel adaptateur dans le plus similaire existant via OPCM (fusion par projection orthogonale)
4. Si la qualité de l'adaptateur fusionné sur les deux tâches dépasse le seuil, on évince l'original et on stocke la version fusionnée

La politique garantit que le pool contient au plus K adaptateurs consommant le budget B, tout en maximisant la couverture de tous les adaptateurs demandés par une fusion raisonnée.

Pour le déploiement de Zen en périphérie (Hanzo Desktop, mobile), K-Merge permet des familles de modèles servies localement qui dépasseraient sinon les limites de stockage de l'appareil. Un appareil avec 16GB de stockage de modèle disponible peut servir 8 profils comportementaux distincts en maintenant un pool K-Merge qui fusionne à la demande les adaptateurs similaires.

Détails d'infrastructure

Format de stockage du delta : matrices de signe en 1 bit, stockées comme tenseurs int8 compactés (8 bits par octet, de sorte qu'une couche de 70B paramètres avec un poids 4096×4096 se compacte en 4096×512 int8). Les facteurs d'échelle α sont stockés en float32, un par dimension de sortie, soit environ 0.1% du stockage du delta.

Comportement de démarrage à froid : lorsque le delta d'une variante n'est pas en cache dans la SRAM du GPU (par exemple, la variante n'a pas été demandée depuis 10 minutes), la première requête paie une pénalité de latence de chargement du delta d'environ 200ms pour un modèle de 70B, le temps de transférer 8.75GB de la NVMe vers la HBM aux débits de lecture séquentielle NVMe. Après la première requête, le delta reste dans le cache de deltas de la SRAM du GPU jusqu'à éviction par la politique LRU.

Politique d'éviction du cache : LRU pondérée par le taux de requêtes. Les variantes à fort taux de requêtes sont épinglées ; les variantes à faible trafic peuvent être évincées. En pratique, les 6 variantes de tête par volume de trafic résident toujours en cache ; les 8 restantes partagent l'espace de cache restant avec une éviction LRU.

Routage des requêtes : le routeur de service suit les requêtes en cours par variante et empêche le blocage de tête de ligne : si le delta de zen4-coder est en cours de chargement, les requêtes zen4-coder entrantes font la queue au lieu que chacune déclenche un chargement indépendant.

Le résultat : 14 variantes de modèles Zen servies depuis des nœuds 8x H100 qui auraient auparavant exigé des nœuds 112x H100 pour une capacité équivalente. La baisse du coût d'infrastructure n'est pas incrémentale. BitDelta rend la famille de modèles multi-locataires économiquement viable.

---

Les modèles Zen sont disponibles sur zenlm.org. Accès à l'API sur hanzo.ai.