TL;DR
- Le modèle Mixture-of-Experts Kimi K3 pèse 1,45 To — aucune mémoire vive (RAM) d'ordinateur portable ne peut le contenir. Le fork Deltafin stocke les experts sur des SSD NVMe et les streame couche par couche (layer streaming) vers la RAM.
- Mesures du 8 septembre 2026 : décodage à 1,00 token par seconde sur un MacBook Pro M5 Max avec 128 Go et quatre SSD — avec 6,3 minutes avant le premier token pour un prompt de 512 tokens.
- Le point essentiel à retenir est un test de budget de couches (Layer-Budget-Check) en trois étapes : il montre quelle classe de modèle peut tourner sur votre propre matériel et à quel point l'ajout de SSD accélère réellement le processus.
Le problème : Des modèles géants, une RAM limitée
Kimi K3 de Moonshot est un modèle Mixture-of-Experts (MoE) de 2,8 billions de paramètres. Les poids des experts représentent 1,45 To, soit environ onze fois plus de mémoire que ce qu'un MacBook Pro de 128 Go peut contenir.
Un processus de chargement classique échoue face à cette limite : le modèle ne rentre pas entièrement dans la mémoire vive. C'est précisément là qu'intervient le Layer-Streaming (streaming de couches), tel que l'implémente le fork argonautlabsai/deltafin.
La solution : Le streaming couche par couche depuis le NVMe
Le principe est simple : les couches "chaudes" (hot layers) restent dans la RAM, le reste est stocké sur un maximum de quatre SSD et chargé à la demande. Chaque token est néanmoins décidé par K3 lui-même — rien n'est tronqué, aucun expert n'est ignoré.
Les 16 experts par token sont tous utilisés, exactement comme Moonshot les a conçus. Un petit modèle brouillon (draft model) peut faire des prédictions, mais K3 vérifie chacune de ces propositions et valide chaque token. Le résultat : une qualité de modèle totale avec une empreinte RAM minimale.
La présentation des chiffres se veut particulièrement honnête : chaque valeur provient d'une seule exécution à froid (cold run) avec un prompt précis. Les journaux et les manifestes de placement sont accessibles publiquement dans le dépôt (repo).
Les mesures du 8 septembre 2026
| Métrique | Drafter désactivé | Drafter activé |
|---|---|---|
| Taux de décodage, réponse de 512 tokens (tok/s) | 0,92 | 1,00 |
| Taux de décodage, réponse de 128 tokens (tok/s) | 0,93 | 1,13 |
| Prompt public de 17 tokens, médiane sur 3 (tok/s) | — | 0,96 |
| Temps jusqu'au premier token (TTFT), prompt de 512 tokens | 6,3 min | 6,3 min |
À titre de comparaison : le dépôt en amont (upstream) rapporte 0,2901 tok/s sur un M1 Max — la configuration M5 Max avec quatre SSD est donc environ trois fois plus rapide. Le prompt public de 17 tokens, à 0,96 tok/s, était nettement supérieur aux 0,68 signalés en amont.
La mise à l'échelle des SSD : plus de disques, moins de linéarité
Les quatre SSD ne sont pas un gadget pour faire les gros titres, mais de la physique mesurable. L'échelonnage sur des prompts identiques donne ceci :
- 1 SSD : ≈ 52 % de la vitesse à quatre disques
- 2 SSD : ≈ 73 %
- 3 SSD : ≈ 90 %
- 4 SSD : 100 % (Référence)
La raison : pour chaque couche, 16 lectures s'exécutent en parallèle, et c'est l'ensemble le plus lent qui dicte le rythme. La bande passante totale n'est utile que si les accès individuels sont suffisamment rapides.
La vraie limite : Prefill et Time-to-First-Token
Le taux de décodage d'environ 1 tok/s n'est que la moitié de l'histoire. Un prompt de 512 tokens nécessite 6,3 minutes avant l'apparition du premier token (Time-to-First-Token, TTFT) — c'est la véritable limite architecturale.
L'équipe a identifié la cause : la phase de Prefill relit huit fois les experts de chaque couche. Un correctif est prévu, mais n'était pas encore implémenté au moment des mesures. En pratique, cela signifie que les prompts courts et précis offrent le meilleur ratio entre temps d'attente et réponse.
Le Layer-Budget-Check (Test de budget de couches) à reproduire
Ces trois étapes fonctionnent avec n'importe quel modèle MoE et n'importe quel matériel — sans même avoir besoin du dépôt :
- Noter le poids total des poids du modèle. Exemple avec K3 : 1 450 Go. Ce chiffre figure sur la Model Card ou se déduit de la taille des fichiers de poids.
- Calculer la part "chaude" (hot portion). RAM utilisable divisée par le poids total : 128 / 1450 ≈ 9 % des poids restent en permanence dans la RAM. C'est le socle à partir duquel le streaming s'effectue.
- Appliquer l'échelonnage SSD. À partir de 1,00 tok/s pour quatre disques : un disque ≈ 0,52, deux ≈ 0,73, trois ≈ 0,90 tok/s. Cela permet de prédire approximativement les performances de sa propre configuration.
Ce test est particulièrement utile pour comparer avec une API Cloud : à ~1 tok/s, une réponse de 100 tokens correspond à environ 100 secondes de temps d'exécution — c'est acceptable pour des tâches asynchrones par lots (batch), mais pas pour des interactions de chat avec plusieurs prompts par minute.
Qu'est-ce que cela signifie pour l'écosystème des agents (Agent-Stack) ?
- Les grands modèles MoE phares deviennent exécutables localement, sans avoir à compresser 1,45 To dans la mémoire vive. La qualité reste intacte avec l'utilisation de tous les experts.
- La latence est la nouvelle devise : Ceux qui n'anticipent pas le TTFT et le taux de décodage subiront un embouteillage de 6 minutes par prompt.
- Le contrôle budgétaire devient la règle de décision : Seules les catégories de 256 Go de RAM avec plusieurs disques sortent l'inférence locale de son marché de niche — précisément les configurations mises en avant dans l'article sur le matériel Apple de ce blog.
Conclusion
Deltafin démontre que le streaming de couches depuis le NVMe comble véritablement le fossé entre une RAM de 128 Go sur un ordinateur portable et un modèle de 1,45 To — avec des mesures propres et reproductibles plutôt que de simples promesses marketing. Le levier est le nombre de SSD, le frein est le Prefill. Pour les développeurs (builders), cela signifie que l'exécution locale de modèles MoE phares n'est plus une théorie, mais que leur vitesse doit être calculée pour chaque workflow, et non simplement lue sur le papier.
Foire aux questions (FAQ)
Combien de SSD Deltafin nécessite-t-il vraiment ? La mesure de référence est effectuée avec quatre disques NVMe et atteint 1,00 tok/s. Un seul disque fournit tout de même environ 52 % de cette vitesse, deux disques 73 % et trois 90 % — le passage de un à deux disques est donc le plus rentable. Si vous n'avez besoin que d'une tâche par minute, deux disques feront parfaitement l'affaire ; pour des réponses en parallèle, une configuration complète vaut l'investissement.
Pourquoi le premier token est-il si lent pour un prompt de 512 tokens ? La phase de Prefill lit les experts de chaque couche huit fois, et chacune de ces séries de lecture doit être terminée avant l'émission du premier token. Cela s'additionne pour atteindre les 6,3 minutes mesurées pour un prompt de 512 tokens. Un correctif est annoncé dans le dépôt, mais n'était pas encore implémenté au moment des mesures.
Est-ce que 128 Go de RAM valent le coup pour l'inférence locale ? Avec 128 Go, il est effectivement possible de faire tourner Kimi K3 via le layer streaming, la part "chaude" d'environ 9 % des poids soutenant l'opération. La catégorie des 256 Go repousse cette limite vers le haut et atténue les petites chaînes de Prefill. La réponse honnête dépend du cas d'usage : pour les longs prompts, le temps avant le premier token reste le goulot d'étranglement, pas la RAM.
Comment calculer le Layer-Budget-Check pour mon propre modèle ? Divisez votre RAM utilisable par le poids total des poids indiqués dans la description du modèle, et vous obtiendrez votre part "chaude". Multipliez ensuite le taux de décodage de référence par le ratio des SSD (0,52 / 0,73 / 0,90 / 1,00). Le résultat donne une prédiction approximative mais compréhensible — vous pouvez la vérifier avec les journaux ouverts dans le dossier k3-public-bench du dépôt.
Est-ce que cela remplace une API Cloud ? Pour des tâches asynchrones à un token par seconde, c'est tout à fait exploitable en local, par exemple pour la synthèse de notes ou les traitements par lots nocturnes. Cependant, pour des chaînes interactives de cinq prompts de 300 tokens chacun, le temps d'exécution se chiffre en plusieurs minutes. L'approche pragmatique reste mixte : un grand modèle en local comme ancrage, et le travail rapide de brouillon (draft) toujours dans le cloud.
Sources
- https://github.com/argonautlabsai/deltafin — Fork avec benchmarks, journaux de mesures et manifestes de placement de couches
- https://github.com/gavamedia/deltafin — Moteur en amont (Upstream-Engine) (MIT), original par gavamedia
- https://github.com/argonautlabsai/argodrive — Outils de mesure et de diagnostic (ARGODRIVE)
- https://news.ycombinator.com/ — Discussion sur l'exécution (run) avec 198 commentaires