LLM auto hébergées · 9 November 2026

Kimi K3.1 Pro contre DeepSeek V4 Pro : ce qu’on peut vraiment faire tourner chez soi en 2026 (et sur quelle machine)

À l’automne 2026, deux familles de modèles chinois à poids ouverts monopolisent les discussions de r/LocalLLaMA. D’un côté Kimi, dont la lignée K3 vient de passer en K3.1 Pro avec un discours centré sur le code et l’agentique ; de l’autre DeepSeek V4 Pro, décliné en versions datées comme la 0813. Mais derrière les fiches marketing et les comparateurs de benchmarks, que peut-on réellement faire tourner sur une RTX 4090, un Strix Halo ou un Mac Studio ? Enquête sur un duel où les chiffres publics restent rares, mais où les choix d’architecture et de quantification changent tout.

Deux mastodontes open-weights à l’assaut de votre bureau

Il y a deux ans, faire tourner un modèle « de classe frontière » chez soi relevait du fantasme de forum. Aujourd’hui, la question n’est plus « est-ce possible ? » mais « lequel choisir, et sur quelle machine ? ». Le paysage du matériel local a basculé : les mini-PC à mémoire unifiée se sont multipliés — Strix Halo et ses 64 à 128 Go de LPDDR5X à 256 Go/s de bande passante, Gorgon Halo visant 192 Go pour des modèles jusqu’à 200B+, le Ryzen AI Halo à 3 999 $ avec 128 Go de mémoire unifiée et un support annoncé jusqu’à 120B+, sans oublier la famille Mac d’Apple et son architecture unifiée. Les GPU consumer, eux, stagnent autour de 24 Go de VRAM, mais la chute du coût du gigaoctet et l’explosion des moteurs d’inférence optimisés pour les MoE (llama.cpp, vLLM, llm-d, MLX) ont redistribué les cartes.

Dans ce contexte, deux noms reviennent en boucle : Kimi de Moonshot AI et DeepSeek V4 Pro de DeepSeek. Le premier est présenté comme le successeur de la famille Kimi K2, avec des specs revendiquées spectaculaires — 2,8 T de paramètres et un contexte d’un million de tokens pour K3, et une déclinaison K3.1 Pro désormais mise en avant sur le site officiel de Kimi comme une montée en gamme orientée « programmation et travail avec agents ». Le second, DeepSeek V4 Pro, apparaît dans les comparateurs publics sous une référence datée, DeepSeek-V4-Pro-0813, ce qui suggère une version figée au 13 août.

Mais voilà le problème, et il faut le poser d’emblée : la documentation technique vérifiable sur ces deux modèles reste mince. Les pages qui les présentent sont majoritairement promotionnelles. Aucune fiche technique officielle détaillée de Moonshot AI ou de DeepSeek n’apparaît dans les sources consultées, et les comparateurs se contentent d’afficher des benchmarks et des prix sans exposer l’architecture. Nous allons donc faire ce que tout bon journaliste technique doit faire : distinguer ce qui est revendiqué, ce qui est plausible, et ce qui est vérifiable — puis raisonner à partir de là.

Ce que vous allez trouver dans cet article : une dissection des architectures annoncées, une estimation honnête de l’empreinte mémoire réelle, un tour d’horizon des débits attendus sur le matériel grand public, une comparaison des qualités de raisonnement et d’agentique, l’état de l’écosystème, et un verdict par profil. Avec, à chaque fois, la même discipline : pas de chiffre inventé.

Kimi K3 et K3.1 Pro : le MoE géant de Moonshot AI et son pari sur le contexte massif

Commençons par ce que l’on sait de la généalogie. Kimi K2, le prédécesseur direct, est un modèle à mélange d’experts (MoE) développé par Moonshot AI, avec 1 000 milliards de paramètres totaux, 384 experts et 32 milliards de paramètres actifs par token, et un contexte étendu à 256K tokens dans ses versions récentes — notamment la déclinaison orientée code, Kimi K2.7 Code. Ces chiffres proviennent de sources tierces se présentant comme des hubs Kimi, cohérents avec la communication publique connue de Moonshot AI, mais non recoupés ici par une source primaire.

Kimi K3, lui, est annoncé sur ces mêmes pages comme le modèle phare de la génération précédente, avec des specs revendiquées de 2,8 T de paramètres totaux et un contexte de 1M de tokens, exposé via une API identifiée « kimi-k3 ». Depuis, le site officiel de Kimi met en avant K3.1 Pro, présenté comme une mise à niveau « programmation et agents » de la famille K3. C’est un point important pour qui suit l’actualité : la référence à retenir aujourd’hui n’est plus K3 seul, mais la lignée K3 / K3.1 Pro. Un point de calendrier : selon deux articles de presse, la publication des poids ouverts de K3 est intervenue le 27 juillet — avec une réserve notable, puisque VentureBeat évoquait un « open with a caveat », autrement dit une ouverture assortie de conditions. On ne connaît pas, dans les sources disponibles, la licence exacte retenue (MIT ? Apache 2.0 ? licence communautaire restrictive ?). C’est une lacune importante pour quiconque veut déployer en entreprise — et un rappel que « open weights » ne signifie pas « open source » au sens juridique, comme nous l’avons détaillé dans notre dossier sur les licences.

Sur l’architecture fine, il faut être clair : le nombre d’experts de K3, le nombre d’experts activés par token, le mécanisme de routage, le type d’attention (MLA, GQA, hybride), le tokenizer, la présence de têtes MTP pour le speculative decoding ou d’un module multimodal ne sont documentés nulle part dans nos sources. On sait seulement que K2 utilisait 384 experts avec 32B actifs, et que K3 multiplie l’échelle par près de trois sur le total. La logique MoE veut que le nombre d’experts actifs reste une fraction du total — c’est tout l’intérêt de l’architecture — mais sans chiffre sourcé, mieux vaut ne pas s’avancer.

Un élément d’écosystème mérite toutefois d’être signalé, car il concerne directement l’usage agentique : la famille Kimi K2.5/K3 est associée à un mode Agent Swarm capable de coordonner jusqu’à 300 sous-agents, plus de 4 000 appels d’outils par tâche, avec une accélération revendiquée de 4,5× par rapport à une exécution séquentielle. C’est le genre de fonctionnalité qui change l’usage réel — mais qui suppose des appels API ou une infrastructure serveur, pas un simple desktop.

Ce que cela implique concrètement : un modèle à 2,8 T de paramètres, même en MoE, c’est un monstre de mémoire morte. En Q4, on parle de l’ordre du téraoctet de poids — hors de portée de toute machine personnelle. Kimi K3 (et a fortiori K3.1 Pro) en local, sur du matériel grand public, n’est pas réaliste à pleine échelle. C’est un modèle pensé pour le cloud ou pour des clusters. Son intérêt pour l’utilisateur local réside davantage dans ses déclinaisons plus modestes de la famille, ou dans l’usage d’API. Il faut le dire sans détour : le « K3 chez soi » relève aujourd’hui du fantasme, sauf à disposer d’un data center.

DeepSeek V4 Pro : l’outsider dont on sait encore trop peu

Passons au second combattant — et là, la prudence est de mise. DeepSeek V4 Pro est présenté par la presse comme un modèle open-weights de DeepSeek, avec des benchmarks revendiqués supérieurs et un prix plus élevé que les versions précédentes. Les comparateurs publics le référencent sous l’identifiant DeepSeek-V4-Pro-0813, ce qui indique une version datée du 13 août, face à laquelle ils alignent Kimi K3 sur les benchmarks, les prix et un verdict « lequel est le meilleur ». C’est à peu près tout ce que les sources disponibles permettent d’affirmer avec certitude. Aucune architecture, aucun nombre de paramètres, aucun mécanisme d’attention, aucune taille de contexte, aucune licence ne sont documentés dans les extraits consultés.

Ce que l’on peut reconstituer par analogie : DeepSeek a bâti sa réputation sur des MoE efficaces (la lignée V3/R1), avec une attention de type MLA (Multi-head Latent Attention) qui compresse le KV cache — un avantage décisif en local, puisqu’il réduit drastiquement la mémoire nécessaire au contexte long. Si V4 Pro prolonge cette philosophie, il devrait être plus économe en mémoire que Kimi K3 à contexte équivalent, et probablement plus adapté à un déploiement sur GPU consumer ou mini-PC. Mais c’est une inférence, pas un fait sourcé. À prendre comme telle.

Un autre élément circule : DeepSeek aurait annoncé un modèle baptisé « Flash », qui surpasserait Kimi K3 sur des benchmarks cyber et coding. Là encore, information non vérifiée, issue d’un article de presse. Et une rumeur amusante circule selon laquelle combiner Kimi K3 et DeepSeek V4 Pro permettrait d’obtenir « 5x les limites d’API » — une affirmation marketing à prendre avec des pincettes.

Le point honnête à retenir : DeepSeek V4 Pro est un outsider dont on connaît la réputation, pas les specs. Toute personne qui vous vend un comparatif chiffré précis K3 vs V4 Pro aujourd’hui travaille soit sur des données qu’elle ne partage pas, soit sur des extrapolations. Nous ferons donc le pari de la méthode : raisonner sur les ordres de grandeur de la famille DeepSeek et sur la logique des architectures MoE, en signalant systématiquement l’incertitude.

Poids lourds, mémoire légère : combien de VRAM et de RAM pour chaque modèle ?

C’est la question qui fâche. Et la réponse honnête commence par un constat : aucune donnée d’empreinte mémoire réelle pour Kimi K3/K3.1 Pro ou DeepSeek V4 Pro n’est disponible dans nos sources. Nous pouvons néanmoins poser le cadre de calcul, qui reste valable pour tout MoE.

La mémoire nécessaire se décompose en deux blocs : les poids (paramètres × bits par paramètre / 8) et le KV cache (qui dépend du contexte, du nombre de couches, de têtes et de la dimension d’attention). Pour un modèle à 2,8 T de paramètres, même en Q4_K_M (environ 4,5 bits effectifs par poids), on dépasse le téraoctet de poids seuls. Aucun matériel grand public ne s’en approche. À l’inverse, un modèle de la classe 100-200B en Q4 tient dans 60 à 120 Go — c’est précisément la cible des mini-PC à mémoire unifiée actuels, dont le Strix Halo (64-128 Go), le Gorgon Halo (192 Go, jusqu’à 200B+) et le Ryzen AI Halo (128 Go, jusqu’à 120B+ supportés) sont les représentants.

Voici un tableau de cadrage, à lire comme un ordre de grandeur par classe de taille, pas comme des specs K3/V4 Pro (non précisées) :

Le KV cache est le second piège. Sur un modèle à contexte long (256K, 1M), il peut dépasser la taille des poids si l’attention n’est pas compressée. C’est là que les mécanismes type MLA changent tout : ils réduisent la mémoire du cache de plusieurs ordres de grandeur par rapport à une attention classique. Si DeepSeek V4 Pro hérite du MLA de sa lignée, il aura un avantage structurel majeur pour le contexte long en local. Si Kimi K3 s’appuie sur une attention moins compressée, son 1M de contexte deviendra un gouffre mémoire dès qu’on le sollicitera.

Recommandation pratique : pour du matériel grand public, visez Q4_K_M ou Q5_K_M. Le Q8_0 double presque la mémoire pour un gain de qualité souvent marginal — sauf sur les tâches de code ou de raisonnement fin, où l’écart se resserre. Et surveillez l’offloading CPU : dès que les couches débordent de la VRAM, le débit s’effondre.

Tokens par seconde : ce que vous obtenez vraiment sur RTX 4090, Strix Halo et Mac Studio

Ici encore, aucun benchmark de débit spécifique à Kimi K3/K3.1 Pro ou DeepSeek V4 Pro n’est disponible. Mais nous avons des repères solides sur le matériel et les moteurs d’inférence.

Sur Strix Halo (256 Go/s de bande passante), les mesures communautaires donnent environ 40-60 tok/s sur Llama 3 8B Q4 en Vulkan, et 5-10 tok/s sur Mixtral 8x7B Q4_K_M — un MoE nettement plus gros. C’est instructif : un MoE de taille moyenne tourne, mais lentement. Pour un modèle de classe 100B+, attendez-vous à des débits de l’ordre de quelques tokens par seconde en decode, avec un prefill correct mais pas miraculeux. Sur un GPU intégré plus modeste comme le Radeon 780M, on tombe à ~10-12 tok/s sur Llama 3 8B Q4 en Vulkan, ~8-11 tok/s sur Mistral 7B Q4_K_M et ~10-12 tok/s sur Qwen 2.5 7B, ce qui donne l’échelle. Bonne nouvelle côté réglages : sur ce même 780M, l’activation de Vulkan apporte environ +50 % et le réglage MMVQ environ +12,9 % — des gains gratuits qu’il serait dommage d’ignorer.

Sur RTX 4090 (24 Go), un modèle qui tient entièrement en VRAM bénéficie de la bande passante GDDR6X (plus de 1 To/s), soit un ordre de grandeur au-dessus du Strix Halo. Mais dès qu’on dépasse 24 Go, l’offloading CPU casse tout : le débit chute à celui de la RAM système. C’est le piège classique : un modèle 70B en Q4 (~40 Go) ne tiendra jamais confortablement sur une 4090 seule ; il faudra un 2×3090 ou accepter la lenteur. À l’inverse, les moteurs « overfit » comme Strata montrent qu’avec un offloading hiérarchisé et une gestion fine du KV-cache et des experts à la demande, on peut faire tourner un MoE de 125B sur une RTX 5070 de 12 Go à des débits étonnants — au prix d’une optimisation taillée pour une paire modèle-machine précise, pas d’un usage générique.

Le choix du runtime compte énormément. llama.cpp reste la référence pour le CPU/GPU hybride et les quants GGUF — sa version v0.5.0 a consolidé le backend, les modèles et le serveur, avec vérification GPU et llama-server. vLLM et SGLang brillent pour le serving à haut débit sur GPU, avec du batching continu — mais nécessitent de la VRAM. MLX est le choix naturel sur Mac Apple Silicon. Et côté production, llm-d 1.0, annoncé le 20 octobre 2026 à la PyTorch Conference, pousse la désagrégation prefill/decode et le routage prefix-aware à l’échelle d’un cluster — avec un chiffre d’IBM Research de 0,11 $ par million de tokens, soit environ 11,5× moins cher que les API commerciales. C’est du self-hosting industriel, pas du desktop, mais cela fixe l’étalon du coût auquel le local doit se comparer.

Côté réglages : le batch size et la taille de contexte sont les deux leviers principaux. Augmenter le batch améliore le débit global mais consomme de la mémoire KV. Réduire le contexte libère de la VRAM au prix de la mémoire de conversation. Pour le sampling, les valeurs par défaut (temperature ~0.6-0.7, top_p ~0.9) conviennent à la plupart des usages, mais les modèles de raisonnement bénéficient souvent d’une temperature plus basse.

Raisonnement et agentique : ce que les benchmarks ne disent pas

C’est le terrain où les deux familles se livrent la bataille la plus visible — et le plus trompeur. Les comparateurs publics alignent Kimi K3 et DeepSeek-V4-Pro-0813 sur des scores de benchmarks et des prix, mais sans exposer la méthodologie : quelles tâches, quel harnais, quel budget de tokens, quel nombre de tentatives ? Or, comme nous l’avons montré dans notre dossier sur les modèles de décision, ce que mesurent vraiment BFCL, τ-bench ou AgentBench dépend étroitement du protocole. Un score « supérieur » sur une capture d’écran ne dit rien de votre usage.

Ce que l’on peut affirmer avec prudence : la communication de Kimi s’est déplacée vers l’agentique et le code avec K3.1 Pro, ce qui suggère que Moonshot considère ces tâches comme différenciantes. Côté DeepSeek, la réputation de la lignée V3/R1 repose sur un raisonnement solide et un coût contenu. Pour un usage local, la vraie question n’est pas « lequel est le meilleur » mais « lequel tient sur ma machine avec un contexte utile ». Un modèle excellent mais qui ne tient qu’en Q2 sur votre matériel sera moins utile qu’un modèle un peu moins fort qui tourne en Q4 avec un contexte confortable.

Un point de méthode, enfin : la qualité perçue dépend énormément du harnais — le scaffolding qui entoure le modèle (outils, grammaires contraintes, validateurs, boucles de vérification). Depuis le printemps 2026, la communauté locale l’a intégré : le harnais compte souvent plus que la taille du modèle. C’est particulièrement vrai pour l’agentique, où un petit modèle bien outillé peut surpasser un géant mal piloté.

L’écosystème 2026 : ce qui a vraiment changé pour le local

Trois évolutions structurelles méritent d’être soulignées, car elles conditionnent tout le reste.

Premièrement, la mémoire unifiée a démocratisé le « gros modèle ». Là où il fallait hier un cluster de GPU, un mini-PC à 128 Go (Ryzen AI Halo à 3 999 $) ou 192 Go (Gorgon Halo) fait tourner des modèles de classe 100-200B en Q4. C’est le vrai basculement de 2026 : le facteur limitant n’est plus la VRAM du GPU dédié mais la bande passante mémoire du système.

Deuxièmement, les moteurs d’inférence se sont spécialisés. llama.cpp pour l’universel, vLLM/SGLang pour le débit GPU, MLX pour Apple, llm-d pour le distribué, et des moteurs « overfit » comme Strata pour des cas précis. Le corollaire : le choix du moteur pèse autant que le choix du modèle.

Troisièmement, l’écosystème Windows a rattrapé son retard. Depuis octobre 2026, Windows ML ajoute un support expérimental de llama.cpp pour les modèles GGUF, une API locale compatible OpenAI, la génération de texte ONNX et de nouveaux outils runtime. Concrètement, monter un serveur LLM local sur Windows devient nettement moins artisanal — un point non négligeable pour qui veut éviter le double boot Linux.

À cela s’ajoute une donnée économique : héberger son propre LLM pour réduire la facture dépend de deux paramètres — le volume d’usage et le coût du matériel amorti. En dessous d’un certain seuil, l’API reste plus rentable ; au-delà, le local s’impose. Le calcul mérite d’être posé froidement avant d’acheter.

Verdict par profil : qui doit faire quoi ?

Assez de théorie. Voici des recommandations concrètes, avec leurs limites assumées.

Vous avez une RTX 4090 (24 Go) et un budget serré. Oubliez Kimi K3 et DeepSeek V4 Pro à pleine échelle. Visez des modèles de classe 7-30B en Q4_K_M/Q5_K_M, ou des MoE légers. Si vous voulez goûter à la famille Kimi ou DeepSeek, passez par l’API pour les gros modèles et gardez le local pour les tâches courantes. Le piège à éviter : l’offloading massif qui transforme un 70B en tortue.

Vous avez un mini-PC à mémoire unifiée (Strix Halo 128 Go, Ryzen AI Halo, Gorgon Halo 192 Go). C’est le sweet spot 2026 pour la classe 100-200B en Q4. Attendez-vous à quelques tokens par seconde en decode sur les plus gros, avec un prefill correct. Privilégiez les quants Q4_K_M, surveillez le KV cache si vous poussez le contexte, et testez plusieurs runtimes (llama.cpp en Vulkan/ROCm, éventuellement un moteur spécialisé MoE).

Vous avez un Mac Studio / Apple Silicon. MLX est votre ami. La mémoire unifiée d’Apple reste excellente pour les modèles de taille moyenne ; pour les très gros MoE, la bande passante vous rattrapera.

Vous voulez du « frontière » sans data center. La réponse honnête : API ou self-hosting distribué (llm-d 1.0), pas un desktop. Kimi K3.1 Pro et DeepSeek V4 Pro, dans leurs versions phares, sont des modèles de serveur.

Vous voulez de l’agentique. Le modèle compte moins que le harnais. Un modèle de taille moyenne bien outillé (outils, grammaires, validateurs) surpassera souvent un géant mal piloté — et tiendra sur votre machine.

Ce qu’il faut retenir (et ce qu’on ne sait toujours pas)

Résumons sans détour. Kimi K3, et sa déclinaison K3.1 Pro, est un MoE géant (2,8 T de paramètres revendiqués, contexte 1M) hors de portée du matériel grand public à pleine échelle ; son intérêt local passe par des déclinaisons plus modestes ou par l’API. DeepSeek V4 Pro (référencé 0813) reste un outsider dont on connaît la réputation — efficacité, probable héritage MLA — mais pas les specs publiques. Aucun benchmark de débit ni d’empreinte mémoire spécifique à ces deux modèles n’est disponible dans nos sources : tout comparatif chiffré précis relève aujourd’hui de l’extrapolation.

Ce qui est solide, en revanche : le cadre de calcul mémoire (poids + KV cache), les ordres de grandeur par classe de taille, les repères de débit sur 780M, Strix Halo et RTX 4090, et la maturité des runtimes (llama.cpp v0.5.0, vLLM, MLX, llm-d 1.0, Windows ML). C’est avec cela — et non avec des fiches marketing — que vous déciderez.

Deux réserves à garder en tête. D’abord, la licence exacte de K3 n’est pas établie dans nos sources : « open weights » ne veut pas dire « open source », et un déploiement en entreprise exige de vérifier les conditions. Ensuite, la méthodologie des benchmarks publics manque : sans protocole, pas de comparaison fiable. La discipline reste la même qu’il y a deux ans : mesurer sur votre machine, avec votre usage, plutôt que de croire un tableau.

Sources

• Kimi AI, site officiel — mise en avant de K3.1 Pro (programmation et agents) : kimi.com, kimi.ai/fr, platform.kimi.ai
• Comparateur Kimi K3 vs DeepSeek-V4-Pro-0813 (benchmarks, prix) : llm-stats.com
• Wikipédia, entrée « Kimi (AI) » : en.wikipedia.org
• llm-d 1.0 — annonce du 20 octobre 2026 (PR Newswire) : prnewswire.com ; couverture IBM/Red Hat/Google Cloud/CoreWeave/NVIDIA : finance.yahoo.com ; chiffre 11,5× et 0,11 $/M tokens (IBM Research) : techtimes.com
• TorchTPU, backend PyTorch natif pour TPU (Google/Meta), 20 octobre 2026 : pytorch.org
• Windows ML — support expérimental llama.cpp/GGUF, API locale compatible OpenAI (octobre 2026) : techgenyz.com, devblogs.microsoft.com
• llama.cpp v0.5.0 — guide pratique (backend, GGUF, llama-server), 27 septembre 2026 : gyanaangan.in
• Héberger son propre LLM pour réduire la facture IA : faire le calcul, 14 octobre 2026 : journaldunet.com
• Mistral Large 4 / « Le Chonk » (1 000 milliards de paramètres, poids ouverts annoncés le 27 octobre 2026) : clubic.com, presse-citron.net, numerama.com
• Strata — MoE 125B sur RTX 5070 12 Go, offloading hiérarchisé et KV-cache : dossier du magazine et ai-stat.ru
• Dossiers internes du magazine : « Open weights, open source, open data » (licences, OSAID 1.0, EU AI Act) ; « Optimiser l’inférence LLM locale en 2026 » (quantification, PagedAttention, speculative decoding) ; « Faire tourner des LLM open source chez soi sans se ruiner » (iGPU, mémoire unifiée, benchmarks 780M/Strix Halo) ; « Modèles de décision » (BFCL, τ-bench, AgentBench, harnais)

Article recherché et rédigé automatiquement · Magazine Electrosens