Kimi K3 face à GPT-5.6-SOL : test réel sur des exercices difficiles en maths, physique et programmation

Cette fois, pas de questions-réponses triviales : j’ai fixé trois problèmes qui exigent un raisonnement en chaîne — un problème de probabilité avec recouvrement de motifs et second moment, un problème de physique avec inertie du poulie et bascule vers un câble détendu, et un problème Python qui dépend de fermetures de dépendances, d’une capacité sur plusieurs jours et d’un tie-break en trois niveaux. Les deux modèles ont été interrogés via la même interface, avec le même prompt et des plafonds de sortie proches, sans outils ni accès réseau.

D’abord, la conclusion :

• gpt-5.6-sol a produit une réponse visible complète sur les trois exercices, avec des résultats de référence corrects en maths et en physique.
• kimi-k3 a atteint finish_reason=length sur les maths et la physique dès la première passe avec une limite de 6500 tokens ; aucune réponse visible n’a été produite. En maths, même après avoir porté la limite à 10000, la sortie a encore été tronquée. Sur le problème de programmation, la requête a expiré en lecture après environ 245 secondes.
• L’implémentation de programmation de GPT-5.6-SOL a passé des vérifications indépendantes supplémentaires sur la fermeture des dépendances, la capacité, le tie-break, les dépendances invalides et les dépendances cycliques, mais sa première assertion d’exemple intégrée contenait une valeur attendue erronée. Cela montre bien qu’il faut valider séparément « le corps du code est correct » et « tous les tests d’exemple passent ».

La latence indiquée ici est l’observation de cette requête précise, pas une SLA fixe. Lors des requêtes parallèles initiales, les requêtes mathématiques et physiques de GPT ont reçu un HTTP 408, puis ont été relancées séquentiellement ; la vitesse ne sert donc ici qu’à observer l’expérience d’appel, pas à revendiquer un classement absolu.

Configuration de test

Les tests ont été exécutés entre le 2026-07-17 et le 2026-07-18 (heure de Pékin), avec l’API suivante :

POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2

La première passe utilisait uniformément : maths et physique max_tokens=6500, programmation max_tokens=7500. Chaque problème demandait au modèle de fournir un raisonnement vérifiable ou du code exécutable, et l’on a enregistré finish_reason, les tokens de completion/reasoning, la latence de requête, la justesse numérique, ainsi que la capacité du code à s’exécuter de façon autonome sous Python 3.11.

Tableau récapitulatif des résultats

Tâche	kimi-k3	gpt-5.6-sol	Verdict
Maths : espérance et variance de HHTH	length, 186.98 s, 6500 tokens ; contenu visible vide	relance séquentielle stop, 236.07 s, 6872 tokens	GPT a répondu complètement ; Kimi n’a pas produit de réponse au premier tour
Physique : poulie, contact au sol, ressort	length, 202.05 s, 6500 tokens ; contenu visible vide	relance séquentielle stop, 156.29 s, 4501 tokens	GPT complet et numériquement correct
Programmation : sac à dos avec clôture de dépendances	TimeoutError après 245.54 s	stop, 87.96 s, 4514 tokens	Le code GPT s’exécute ; Kimi n’a pas renvoyé de code complet
Re-test maths de Kimi	length, 286.99 s, 10000 tokens	—	L’augmentation du budget n’a toujours pas permis de terminer

Dans les requêtes maths et physique de Kimi, le nombre de reasoning tokens rapporté par l’API était proche de 6497 dans les deux cas ; pour le re-test maths, il était proche de 9997. Cela ne veut pas dire que Kimi est incapable de raisonner, mais simplement que, pour ces prompts et avec ce routage, le budget de raisonnement est très facilement consommé, ce qui empêche le client d’obtenir la réponse finale.

Problème de maths : le chevauchement des motifs affecte non seulement l’espérance, mais aussi la variance

L’énoncé est le suivant : à chaque lancer, la probabilité de face vaut p=3/5 et celle de pile q=2/5. On lance jusqu’à ce que HHTH apparaisse pour la première fois, en autorisant les recouvrements de motif. On demande E[T] et Var(T).

L’automate des préfixes correct est S0=préfixe vide, S1=H, S2=HH, S3=HHT, S4=HHTH (état absorbant). La transition clé est S2 --H--> S2 : après HH, un nouveau H laisse encore comme plus long suffixe pertinent HH, il ne faut donc pas retomber à tort dans l’état vide.

Les équations du premier moment établies par GPT-5.6-SOL sont :

M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0

En poursuivant avec les équations du second moment, on obtient :

E[T]   = 715/54       ≈ 13.2407407407
E[T²]  = 195335/729   ≈ 267.9492455418
Var(T) = 270115/2916  ≈ 92.6320301783

L’espérance peut aussi être vérifiée indépendamment par une formule de bord. HHTH n’a comme bord propre non vide que le caractère H, donc E[T] = 1/p + 1/(p³q) = 715/54. La réponse complète de GPT couvre à la fois les transitions d’état, le développement du second moment et un contrôle de cohérence. Kimi n’ayant produit aucun raisonnement visible sous les plafonds 6500 et 10000, il est impossible d’évaluer sa justesse mathématique sur cette passe ; on ne peut que noter qu’elle n’a pas été menée à terme dans le budget.

Problème de physique : après l’impact au sol, la contrainte se rompt, on ne peut plus réutiliser le même bilan énergétique

Le problème est défini ainsi : m_A=4.0 kg est sur un plan incliné rugueux à 25°, avec μ_k=0.18 ; m_B=3.0 kg est suspendue ; la poulie a M_p=1.2 kg, R=0.10 m ; après une descente de 1.50 m, B touche le sol et la corde se détend immédiatement ; A continue à monter de 0.10 m avant d’entrer en contact avec un ressort de k=250 N/m ; g=9.8 m/s².

Avant que B touche le sol, la corde est tendue et il n’y a pas de glissement ; la masse inertielle équivalente de la poulie vaut I/R²=(1/2)M_p=0.60 kg. En écrivant les équations couplées des deux masses et de la rotation de la poulie, on obtient :

a  ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x  ≈ 0.0835 m = 8.35 cm

Après l’impact au sol, la vitesse de B est modifiée par la collision avec le sol, A conserve encore une vitesse vers le haut du plan incliné, et la poulie peut continuer à tourner ; l’énoncé précise en plus que la corde se détend immédiatement, donc on ne peut plus imposer v_A=v_B=Rω. La suite doit donc être analysée uniquement pour A :

v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x

GPT-5.6-SOL a également vérifié les dimensions, la distance d’arrêt sans ressort, ainsi que la cohérence entre l’énergie du ressort et la somme des pertes par frottement et gravité ; les valeurs sont auto-cohérentes. Kimi n’ayant pas produit de réponse visible lors de la première passe, il est impossible de comparer la qualité de son modélisation intermédiaire.

Problème de programmation : le cœur de l’algorithme passe les vérifications indépendantes, mais l’exemple du modèle contient un bug

Le problème demandait d’implémenter optimize_release_plan(items, capacity_by_day, dependencies), en gérant la capacité journalière, une capacité par défaut de 0 pour les dates non configurées, la fermeture transitive des dépendances directes et indirectes, la détection des dépendances invalides et des cycles, ainsi qu’un tie-break en trois niveaux value → risk → liste d’identifiants triée. Comme items <= 18, une exploration exhaustive par bitmask est une base raisonnable.

GPT-5.6-SOL a utilisé un cache de fermeture des dépendances et une énumération des sous-ensembles en 2^n. Nous avons extrait le code et l’avons vérifié indépendamment sous Python 3.11 : fermeture des dépendances, exemple de capacité multi-jour, tie-break en trois niveaux valeur/risque/id, capacité des dates non configurées, absence de dépendance et dépendance cyclique — les 6 groupes de vérifications ont tous passé.

En revanche, la première assertion ajoutée à la fin du code par le modèle échoue : elle écrit A -> B -> C, tout en introduisant un X de valeur 11. Avec la capacité donnée, la valeur totale de B + C + X est 13, donc supérieure à celle de A + B + C, qui est 12 ; la fonction doit donc renvoyer ['B', 'C', 'X']. L’assertion attendant ['A', 'B', 'C'] est incorrecte, c’est un bug dans le harnais de test.

C’est un point très parlant : pour un exercice de code, il ne faut pas se contenter du corps de la fonction, et il ne faut pas non plus considérer qu’« il y a 8 assertions, donc les tests sont forcément fiables ». Les données de test générées par le modèle doivent, elles aussi, être relues par un humain ou par une implémentation de référence. La requête de programmation de Kimi K3 a expiré en lecture après environ 245 secondes, sans code complet récupérable.

Bilan global

Dimension	kimi-k3	gpt-5.6-sol
Complétude en maths	les tokens 6500/10000 ont tous été tronqués, impossible à valider	espérance, second moment, variance et check de cohérence complets
Modélisation physique	troncature dès la première passe	traitement correct de l’inertie de la poulie, de la détente de la corde et de la phase ressort
Livraison du code	timeout sur cette passe	corps du code validé indépendamment, mais une assertion interne est fausse
Stabilité de sortie	forte consommation de reasoning, réponse visible souvent absente	sur les trois problèmes, les relances séquentielles sont toutes revenues en stop
Vitesse de réponse	environ 187–246 s, avec troncature/timeout	requêtes réussies d’environ 88–236 s ; 408 sur la première passe concurrente

La conclusion la plus juste n’est pas « tel modèle est objectivement plus intelligent », mais plutôt :

1. Avec ce routage et ce budget, GPT-5.6-SOL parvient plus facilement à condenser un raisonnement complexe en réponse finale ; c’est plus adapté à un workflow où il faut obtenir tout de suite une démonstration ou du code lisible.
2. Le principal problème de Kimi K3 est l’efficacité de conversion entre budget de raisonnement et sortie visible ; même en portant les maths à 10000 tokens, la génération n’aboutit toujours pas.
3. On ne peut pas faire une confiance aveugle au code de GPT-5.6-SOL. La logique de la fonction passe les vérifications indépendantes, mais le jeu de tests fourni contient une erreur de calcul de valeur.
4. Pour un choix en production, il faut enregistrer à la fois finish_reason, les reasoning tokens, la latence et les résultats des tests locaux ; il ne faut pas s’arrêter à la dernière phrase du type « la réponse est correcte ».

Reproduire l’expérience

Les scripts de test et les résultats de relance séquentielle de cette passe sont conservés ici (le résumé de la première passe concurrente a aussi été écrit dans la sortie du script) :

.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json

Pour refaire l’expérience, il est conseillé de figer les IDs de modèle, le prompt, temperature, max_tokens et le degré de concurrence, puis d’enregistrer chaque sortie dans un fichier séparé. La charge du canal amont, les hits de cache et l’état du rate limiting influencent tous la latence ; ici, les HTTP 408, length et les timeouts en lecture ont été conservés comme résultats de test à part entière, sans être masqués.