Kimi K2.7 vs Opus 4.8 : duel de code et coût

Dernière mise à jour: 2026-07-13 06:07:59

J’ai envoyé les mêmes tâches de codage à Kimi K2.7 Code et à Claude Opus 4.8 via une seule API, puis j’ai mesuré les résultats obtenus. En termes de justesse, ils étaient à égalité : tous deux ont détecté un piège de priorité SemVer et un bug caché de fusion d’intervalles. Mais Opus a répondu 3 à 9 fois plus vite avec un quart des tokens de sortie, tandis que Kimi coûtait environ 46 % de moins par tâche au prix catalogue. Le choix ne porte donc pas sur le modèle le plus « intelligent ». Si vous exécutez des tâches de codage sensibles au coût ou par lots, Kimi K2.7 l’emporte sur le prix. Si vous avez besoin d’une faible latence, d’un contexte d’1M tokens ou d’un modèle de relecture finale en lequel vous avez confiance, Opus 4.8 vaut le surcoût, et de nombreuses équipes finissent par répartir les requêtes entre les deux.

Pratique : j’ai exécuté les mêmes tâches de codage sur les deux

Comment j’ai testé : ID de modèle kimi-k2.7-code et claude-opus-4-8, appelés via un seul endpoint de passerelle compatible OpenAI le 2026-07-13, en exécution unique par tâche avec les paramètres par défaut et sans mise en cache des prompts. La latence est mesurée côté client en temps réel, elle inclut donc le réseau et le temps d’attente en file, pas seulement la génération. Avant la notation, j’ai demandé à chaque modèle de s’identifier comme vérification de cohérence (Kimi a répondu « made by Moonshot AI, » Opus a répondu Anthropic) ; c’est un contrôle d’acheminement, pas une preuve de version. Ceci est un échantillon de deux tâches, pas un benchmark. Il montre un comportement que l’on peut ressentir ; il ne peut pas mesurer les performances agentiques en multi-tour.

Tâche 1 demandait à chaque modèle d’implémenter une fonction compare_semver() conforme à la spécification SemVer 2.0.0, y compris la partie que la plupart des implémentations gèrent mal : la précédence des versions préliminaires, où 1.0.0-alpha.1 < 1.0.0-alpha.beta, les identifiants numériques sont classés en dessous des identifiants alphanumériques, et beta.11 > beta.2 numériquement plutôt que par ordre lexicographique. J’ai évalué chaque réponse à l’aide d’une matrice de 72 comparaisons construite à partir de l’ordre canonique de la spécification. Tâche 2 a fourni une fonction merge_intervals() boguée dont le véritable défaut était last[1] = cur[1] au lieu de max(...), une ligne qui avale silencieusement un intervalle entièrement contenu comme [1,10],[2,3] ; j’ai évalué sur 5 cas, y compris cet intervalle contenu.

Kimi K2.7 Code vs Claude Opus 4.8 first-hand coding duel results: latency, output tokens, correctness and cost

Métrique

Kimi K2.7 Code

Claude Opus 4.8

Exactitude de la tâche 1 (72 précédences + cas limites)

72/72

72/72

Exactitude de la tâche 2 (5 cas, y compris un intervalle contenu)

5/5

5/5

Latence de la tâche 1 (côté client)

49.1s

5.3s

Latence de la tâche 2 (côté client)

11.5s

7.6s

Jetons de la tâche 1 (entrée / sortie)

172 / 1,907

774 / 418

Coût de la tâche 1 (prix catalogue natif)

$0.0078

$0.0143

Le coût est calculé à partir des nombres de jetons ci-dessus aux tarifs catalogue natifs (Kimi 0,95 $/4 $ par million en entrée/sortie, Opus 5 $/25 $) : Kimi = 172×0,95/M + 1 907×4/M ≈ 0,0078 $ ; Opus = 774×5/M + 418×25/M ≈ 0,0143 $. Les nombres de jetons d’entrée diffèrent (172 contre 774) parce que le tokenizer de chaque modèle et la comptabilisation de la passerelle attribuent différemment le même prompt, et non parce que les tâches étaient différentes. Les deux modèles ont produit un code entièrement correct sur les deux tâches. L’écart résidait dans la manière d’y parvenir. Opus était concis et rapide, renvoyant 418 jetons en 5,3 secondes pour la tâche 1. Kimi a pris 49,1 secondes et a émis 1 907 jetons, dont une grande partie était une trace de raisonnement détaillée qu’il a renvoyée en même temps que le code. Pourtant, comme les jetons de Kimi sont environ 6× moins chers, l’exécution verbeuse a tout de même coûté moins cher.

Ce que le duel prouve et ne prouve pas

Elle prouve que, sur des problèmes de codage bornés et bien spécifiés, Kimi K2.7 Code atteint la même réponse correcte qu’un modèle de pointe. Elle ne prouve pas que Kimi égale Opus lors de longues sessions agentiques en plusieurs étapes, que deux tâches en un seul tir ne peuvent pas mettre à l’épreuve. La revendication la plus forte de Kimi porte précisément sur ce territoire agentique, que les benchmarks ci-dessous abordent directement.

Benchmarks : qu'est-ce qui relève de tiers par rapport au propre tableau de Moonshot

Voici le détail, avec chaque chiffre étiqueté par source. Le tableau auto-déclaré de Moonshot est l’endroit où Kimi semble le plus fort ; l’évaluation indépendante est plus limitée, car le modèle est récent, et lorsqu’aucun chiffre K2.7 d’un tiers n’existe encore, la valeur publiée la plus proche est celle de K2.6 (indiquée ci-dessous).

Benchmark

Kimi K2.7 Code

Claude Opus 4.8

Source

MCPMark Verified (utilisation d’outils)

81.1

76.4

Moonshot, auto-déclaré

SWE-bench Verified

60.4%

non publié dans le même format

Moonshot, auto-déclaré

Indice d’intelligence

35 (proxy K2.6)

56

Artificial Analysis, tiers

Vitesse de sortie

~45 tok/s (proxy K2.6)

59 tok/s

Artificial Analysis, tiers

Le seul chiffre sur lequel repose la comparaison, MCPMark Verified 81.1 contre 76.4, provient du propre tableau de Moonshot, et non d’un laboratoire indépendant. Ce n’est pas une raison de l’écarter, puisque l’utilisation d’outils de type MCP est précisément ce sur quoi Kimi a été ajusté. Mais il faut lire le titre « Kimi bat Opus » comme une affirmation du fournisseur sur un benchmark optimisé par le fournisseur. Sur le seul face-à-face mesuré par une partie externe, Artificial Analysis place Opus 4.8 nettement devant sur son Intelligence Index (56 contre 35), bien que cette ligne utilise K2.6 comme proxy, car K2.7 n’avait pas encore été évalué indépendamment au moment de la rédaction.

Les benchmarks cachent l’écart de la fenêtre de contexte

Opus 4.8 dispose d’une fenêtre de contexte de 1M tokens ; Kimi K2.7 est plafonné à 256K. Les scores des benchmarks le montrent rarement, mais cela décide du travail réel. Une fenêtre de 256K peut confortablement contenir un dépôt de taille moyenne et une longue trace d’agent, et c’est suffisant pour la grande majorité des sessions de codage. Vous atteignez la limite lorsque vous alimentez une invite unique avec un monorepo volumineux entier, de longs ensembles de documents ou des transcriptions d’agent de plusieurs heures. Là, la fenêtre 4× plus grande d’Opus fait la différence en pratique, pas un point sur un graphique.

Tarification : l’écart de 5 à 6× et le levier du cache

Aux tarifs de liste de l'API native, Kimi K2.7 Code coûte 0,95 $ par million de tokens d'entrée et 4,00 $ par million de sortie ; Claude Opus 4.8 coûte 5 $ et 25 $. C'est un écart de 5 à 6 fois sur la sortie, et c'est la principale raison pour laquelle les équipes évaluent Kimi tout court.

Le levier que la plupart des tableaux de prix négligent est la mise en cache. Kimi facture 0,19 $ par million de tokens lors d’un cache hit, soit une remise de 80 % sur l’entrée que vous avez déjà envoyée. Dans une boucle agentique qui relit la même base de code à chaque étape, l’entrée mise en cache domine la facture, de sorte que le coût effectif chute bien en dessous de l’écart affiché. Philip Kiely de Baseten a signalé environ 82 % d’économies sur une charge de travail d’exemple après être passé d’Opus 4.8 à Kimi 2.7 Code, le type de tâche gourmande en cache et en entrée où la tarification de Kimi s’accumule. Votre chiffre variera selon votre ratio entrée-sortie, mais la tendance reste la même : plus vous relisez le contexte par rapport à ce que vous générez, plus Kimi prend l’avantage sur le coût.

Opus rentabilise son prix du côté des sorties. Il a généré un quart des tokens que Kimi a produits sur ma Task 1, donc sur les tâches fortement axées sur la génération, comme l’écriture de gros fichiers ou des refactorings verbeux, l’écart par token se réduit en dépense réelle, et la vitesse d’Opus réduit le temps d’attente facturé pendant lequel vous payez un ingénieur à patienter.

La promesse des poids ouverts face à la réalité des 577 Go

Kimi K2.7 est proposé en open weights sous une licence MIT modifiée, vous pouvez donc l’héberger vous-même et le fine-tuner. Opus 4.8 est uniquement disponible via API ; votre code et vos traces de raisonnement sont envoyés à Anthropic. Sur le papier, cela confère à Kimi un avantage décisif en matière de confidentialité et de verrouillage propriétaire. En pratique, vérifiez d’abord la facture matérielle.

Kimi K2.7 est un modèle Mixture-of-Experts de 1 trillion de paramètres (32B actifs par token, 384 experts). Des évaluateurs indépendants estiment un déploiement INT4 complet à environ 577 Go de VRAM une fois les poids, le cache KV et les surcharges d’exécution pris en compte, ce qui place la configuration minimale pratique autour de 8× H100 80 Go ou d’une machine de classe DGX Spark. Une seule RTX 4090 (24 Go) ne peut pas exécuter le modèle complet avec des réglages utilisables. Pour tous sauf une poignée d’équipes bien financées, « open weights » signifie la liberté d’acheminer vers un fournisseur d’hébergement ou de fine-tuner sur des GPU loués, et non un modèle que vous déployez en interne. Si votre raison de choisir Kimi est le contrôle des données sur site, chiffrer le cluster avant de vous engager ; pour la plupart des équipes, l’auto-hébergement reste théorique.

Lequel devriez-vous choisir

Adaptez le modèle à la charge de travail plutôt que de couronner un vainqueur :

  • Choisissez Kimi K2.7 Code pour les cas sensibles au coût, à fort volume, ou pour le codage agentique, lorsque vous relisez à plusieurs reprises une base de code, que la latence n’est pas critique et qu’un contexte de 256K suffit. La remise sur le cache se cumule en votre faveur.

  • Choisissez Claude Opus 4.8 lorsque vous avez besoin d’une faible latence, d’un contexte de 1M tokens pour de grands dépôts ou de longues sessions, d’une sortie plus concise, ou d’un modèle de revue finale auquel faire confiance pour des changements à fort enjeu, où son avance sur les scores de raisonnement indépendant compte le plus.

La stratégie hybride : brouillons générés par un modèle peu coûteux, finalisation par un modèle de pointe

Le schéma le plus courant parmi les équipes qui utilisent les deux n’est pas d’en choisir un, mais de faire du routage. Laissez Kimi K2.7 gérer la majeure partie de la génération et des itérations à moindre coût, puis confiez le résultat à Opus 4.8 pour la revue finale ou les parties qui exigent un jugement de pointe. Kimi parle nativement le format OpenAI tandis qu’Opus utilise l’API propre à Anthropic, donc la manière pratique d’acheminer les requêtes entre eux consiste à passer par une passerelle qui expose les deux derrière un seul endpoint compatible OpenAI ; sur une plateforme comme AIReiter, par exemple, les deux se trouvent sous une seule clé, ce qui fait d’un passage de Kimi à Opus un simple changement de chaîne de modèle plutôt qu’une nouvelle intégration. Les économies de 82 % mentionnées ci-dessus provenaient exactement de ce type de routage, et non de l’abandon complet d’Opus.

FAQ

Kimi K2.7 est-il meilleur que Claude Opus 4.8 pour le codage ?

Sur des tâches bornées et bien spécifiées, ils sont à égalité ; dans mon test, les deux ont renvoyé un code entièrement correct. L’avantage de Kimi réside dans l’utilisation d’outils agentiques (MCPMark 81.1 contre 76.4, selon les chiffres communiqués par Moonshot) ; Opus est en tête pour le raisonnement général, la vitesse et le travail sur long contexte.

À quel point Kimi K2.7 est-il moins cher qu’Opus 4.8 ?

Environ 5 à 6 fois moins cher au prix catalogue ($0.95/$4 par million contre $5/$25). Avec des cache hits ($0.19/M input) sur des charges de travail répétitives, les économies réelles peuvent atteindre 80 % ou plus.

Quelle est la fenêtre de contexte de Kimi K2.7 par rapport à Opus 4.8 ?

Kimi K2.7 gère 256K tokens ; Opus 4.8 gère 1M, soit quatre fois plus.

Puis-je exécuter Kimi K2.7 localement ?

Uniquement avec du matériel sérieux. Un déploiement INT4 complet nécessiterait environ 577 Go de VRAM (environ 8× H100 ou un DGX Spark). Une seule GPU grand public comme une RTX 4090 ne peut pas exécuter le modèle complet.

Kimi K2.7 est-il open source ?

Il est fourni avec des poids ouverts sous une licence MIT modifiée, vous pouvez donc l’héberger vous-même et le fine-tuner. Opus 4.8 est fermé et accessible uniquement via API.

En résumé

Si votre goulot d’étranglement est le budget, optez par défaut pour Kimi K2.7 Code et laissez le cache faire le reste. S’il s’agit de la latence, de la longueur du contexte, ou d’un changement que vous ne pouvez pas vous permettre de rater, payez pour Opus 4.8. Considérez la licence open-weights comme un bonus que vous n’encaissez que si vous possédez les GPU. Et si vous n’êtes pas sûr, mettez les deux en place et acheminez selon la tâche plutôt que de miser le workflow sur un seul pari que vous devrez défaire plus tard.

Lectures connexes