Exécuter Kimi K3 localement sur CPU : le runtime 55 Go de K3Flight avec un modèle de 929 Go
K3Flight exécute le modèle Kimi K3 à 2,8 T de paramètres sur CPU avec seulement ~55 Go de RAM en diffusant les poids depuis le stockage via cPilot Runtime. Un serveur d'inférence Linux monofichier.
Kimi K3 est un modèle massif de 2,8 billions de paramètres de type Mixture-of-Experts. Son checkpoint complet Q2_K pèse 929 Go. L'exécuter localement semble impossible—jusqu'à ce que vous réalisiez que le modèle n'a pas besoin de tenir en mémoire. K3Flight, un nouveau projet open-source, le prouve : un serveur d'inférence Linux monofichier qui exécute Kimi K3 sur CPU avec une empreinte mémoire runtime mesurée d'environ 55 Go seulement.
Le secret n'est pas la compression ou la distillation. C'est une approche d'ingénierie système qui traite le stockage, la mémoire et le CPU comme un chemin d'exécution coordonné. Voici comment cela fonctionne et comment vous pouvez l'essayer vous-même.
Le problème : 929 Go de poids contre 64 Go de RAM
La plupart des inférences LLM locales supposent que le modèle entier doit résider en RAM. Pour un checkpoint de 929 Go, cela signifie une machine avec au moins 1 To de mémoire—bien au-delà de ce que la plupart des développeurs possèdent. Mais Kimi K3 est un modèle Mixture-of-Experts (MoE). Selon ses spécifications publiques, chaque token n'active que 16 des 896 experts. Le nombre total de paramètres décrit la capacité du modèle, pas l'ensemble de travail nécessaire pour une étape d'inférence unique.
K3Flight exploite cette parcimonie. Au lieu de tout charger, le runtime cPilot ne met en scène que les poids et l'état nécessaires pour le chemin d'exécution actuel. Le checkpoint complet reste sur le stockage, et les données sont diffusées vers le CPU selon les besoins.
Les chiffres : ce que montre l'exécution de référence
Les mainteneurs ont exécuté le checkpoint complet Kimi-K3-GGUF Q2_K sur une machine Linux x86-64 avec ces résultats :
- Paramètres totaux : 2,8 T
- Mémoire runtime : ~55 Go
- Backend : CPU uniquement
- Prefill : ~1 token/s
- Décodage : ~0,8 token/s
Ce sont des chiffres préliminaires d'une seule exécution de référence, pas une garantie. Le modèle exact de CPU et de SSD n'est pas divulgué. La bande passante de stockage, la capacité du CPU, la longueur du contexte et la version du runtime peuvent affecter considérablement les performances. Mais le but n'est pas la vitesse—c'est qu'un modèle complet de 2,8 T peut s'exécuter localement sans garder 929 Go en mémoire.
Comment fonctionne K3Flight
K3Flight ne réduit pas le modèle. Le checkpoint de 929 Go reste sur le disque. Au lieu de cela, le runtime cPilot gère un ensemble de travail vivant beaucoup plus petit pendant l'inférence. Il le fait en :
- Traitant le stockage, la mémoire hôte et le CPU comme un chemin d'exécution coordonné
- Mettant en scène les poids et l'état du runtime selon les besoins du modèle
- Orchestrant le mouvement des données et le calcul pour maintenir le chemin actif en mouvement
- Gardant le checkpoint Q2_K complet disponible sans résidence complète
Cela transforme un problème de taille de modèle en un problème de système. Le résultat est un serveur qui peut fonctionner sur une machine avec 64 Go de RAM et un SSD NVMe rapide.
Pour commencer : Aperçu de démarrage rapide
K3Flight est actuellement en v0.1.0-preview. Le premier binaire Linux est en cours de packaging, et les mainteneurs promettent une version reproductible bientôt. Voici comment vous préparer.
1. Téléchargez le binaire
Une fois la version publiée, récupérez l'archive Linux x86-64 depuis GitHub Releases :
curl -L -O https://github.com/onetoken-oss/K3Flight/releases/download/v0.1.0-preview/cpilot-server-v0.1.0-preview-linux-x86_64.tar.gz
tar -xzf cpilot-server-v0.1.0-preview-linux-x86_64.tar.gz
sha256sum -c cpilot-server-v0.1.0-preview-linux-x86_64.sha256
chmod +x cpilot-server-v0.1.0-preview-linux-x86_64
Assurez-vous de télécharger l'asset de version .tar.gz, pas l'archive du code source.
2. Téléchargez le modèle
Vous aurez besoin du checkpoint Kimi-K3-GGUF Q2_K depuis Hugging Face. Il pèse 929 Go, donc planifiez votre stockage en conséquence. Suivez les instructions dans MODEL.md pour le dépôt et la révision exacts.
3. Démarrez le serveur
Définissez votre répertoire de modèle et lancez le serveur :
export MODEL_DIR="$HOME/models/Kimi-K3-Q2_K"
./cpilot-server-v0.1.0-preview-linux-x86_64 \
--model "$MODEL_DIR/Kimi-K3-Q2_K-00001-of-00094.gguf" \
--host 127.0.0.1 \
--port 8080
Gardez la liaison en boucle locale sauf si vous comprenez les implications de sécurité d'exposer un serveur d'inférence à un réseau.
4. Envoyez une requête
Ouvrez http://127.0.0.1:8080 dans votre navigateur pour l'interface web, ou utilisez l'API compatible OpenAI :
curl http://127.0.0.1:8080/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "kimi-k3-q2_k",
"stream": true,
"messages": [
{"role": "user", "content": "Bonjour !"}
]
}'
Les journaux du serveur rapporteront le débit de préremplissage et de décodage.
Options du runtime
Exécutez ./cpilot-server-v0.1.0-preview-linux-x86_64 --help pour voir toutes les options. Les principales incluent :
-m, --model: Chemin vers le shard GGUF (requis)--host: Par défaut127.0.0.1--port: Par défaut8080-t: Threads CPU (par défaut 12)-c: Taille du contexte (par défaut 512)-b: Taille de lot logique (par défaut 64)-ub: Taille de lot physique (par défaut 64)--cpilot-memory: Niveau de réglage mémoire (0-?)
Exigences
L'aperçu cible une configuration étroite et vérifiable :
- Linux sur x86-64
- 64 Go+ de mémoire système recommandés
- Au moins 1 To d'espace de stockage local libre
- SSD NVMe local fortement recommandé
- Aucun GPU requis
Le support macOS est prévu ensuite.
FAQ : Questions courantes
Avez-vous compressé 929 Go en 55 Go ? Non. Les fichiers du modèle restent ~929 Go sur le stockage. ~55 Go est l'empreinte mémoire runtime observée.
Est-ce un modèle plus petit ou distillé ? Non. C'est le checkpoint complet Kimi-K3-GGUF Q2_K. Q2_K est une représentation quantifiée, donc elle n'est pas numériquement identique à l'original, mais c'est le modèle complet.
Pourquoi un modèle de 2,8 T peut-il fonctionner de cette façon ? Kimi K3 n'active que 16 des 896 experts par token. cPilot gère l'ensemble de travail vivant au lieu d'exiger une résidence complète.
~55 Go est-il le minimum de RAM ? Non. C'est un résultat mesuré préliminaire. 64 Go sont recommandés pour l'aperçu.
Pourquoi la génération est-elle lente ? Le chemin CPU échange la résidence contre le mouvement des données. Il est conçu pour prouver l'exécution locale, pas pour rivaliser avec la latence d'un centre de données.
Limitations connues
- Linux x86-64 uniquement ; macOS pas encore publié
- CPU uniquement, optimisé pour la faisabilité plutôt que pour la latence cloud
- Les performances varient avec le stockage et le CPU
- Pas de SLA de production ; ne pas exposer à des réseaux non fiables
Aidez à construire la carte matérielle
Les mainteneurs recherchent des résultats honnêtes, y compris des exécutions lentes et des échecs. Si vous essayez, partagez votre exécution avec des détails comme le CPU, la mémoire, le modèle de SSD et le débit. Les résultats négatifs contrôlés sont les bienvenus—ils aident à définir la frontière matérielle réelle.
Réflexions finales
K3Flight est une preuve de concept remarquable. Il remet en question l'hypothèse que les grands modèles nécessitent une grande mémoire. En exploitant la parcimonie MoE et une ingénierie système intelligente, il rend un modèle de 2,8 T exécutable sur une seule machine. Ce n'est pas rapide, mais c'est local, et cela ouvre des possibilités pour l'IA de périphérie, la confidentialité et l'expérimentation.
Si vous êtes intéressé par l'inférence LLM locale, cela vaut la peine d'être suivi. Mettez une étoile sur le dépôt, essayez l'aperçu quand il sort, et contribuez avec vos mesures. L'avenir de l'IA locale pourrait ne pas nécessiter un centre de données après tout.