Upload RESULTS.md with huggingface_hub
Browse files- RESULTS.md +50 -0
RESULTS.md
CHANGED
|
@@ -344,3 +344,53 @@ par des chemins différents : la spéculation pour Qwen, la concurrence pour Kim
|
|
| 344 |
| Claude Code, un utilisateur | **Qwen3-Coder-30B** | 575 tok/s en édition de code, cache de préfixe 16×, 0,21 $/1M |
|
| 345 |
| contexte au-delà de 262k | **Kimi-Linear-48B** | 1 048 576 tokens sur une carte, prefill à froid 1,7× meilleur |
|
| 346 |
| service multi-utilisateurs | Qwen sans spéculation | 1 166 tok/s à 32 flux, 0,105 $/1M |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| 344 |
| Claude Code, un utilisateur | **Qwen3-Coder-30B** | 575 tok/s en édition de code, cache de préfixe 16×, 0,21 $/1M |
|
| 345 |
| contexte au-delà de 262k | **Kimi-Linear-48B** | 1 048 576 tokens sur une carte, prefill à froid 1,7× meilleur |
|
| 346 |
| service multi-utilisateurs | Qwen sans spéculation | 1 166 tok/s à 32 flux, 0,105 $/1M |
|
| 347 |
+
|
| 348 |
+
---
|
| 349 |
+
|
| 350 |
+
# Endurance agentique — 553 tours de codage en boucle
|
| 351 |
+
|
| 352 |
+
Un pic à 575 tok/s sur 900 tokens ne dit rien de la tenue sur une session. Test
|
| 353 |
+
simulant le régime réel de Claude Code : prompt système volumineux, tours
|
| 354 |
+
successifs avec résultats d'outils réinjectés, sorties de code, contexte qui
|
| 355 |
+
gonfle puis se compacte.
|
| 356 |
+
|
| 357 |
+
```
|
| 358 |
+
553 tours 387 100 tokens emis contexte 2 484 -> 35 352
|
| 359 |
+
|
| 360 |
+
debit soutenu 268,2 tok/s 0,456 $ / 1M
|
| 361 |
+
par tour min 108 mediane 330 max 453
|
| 362 |
+
premier tiers 301,0 tok/s
|
| 363 |
+
dernier tiers 304,6 tok/s <- aucune derive
|
| 364 |
+
```
|
| 365 |
+
|
| 366 |
+
**Le débit ne se dégrade pas sur la durée.** La variation par tour suit le cycle
|
| 367 |
+
du cache de préfixe, pas une fatigue du serveur.
|
| 368 |
+
|
| 369 |
+
## Le compactage de l'historique décide de la moitié du débit
|
| 370 |
+
|
| 371 |
+
Première version du test : retirer les deux plus anciens messages **à chaque
|
| 372 |
+
tour** dès que l'historique dépasse une taille. Le préfixe change donc à chaque
|
| 373 |
+
requête, le cache est invalidé en permanence :
|
| 374 |
+
|
| 375 |
+
```
|
| 376 |
+
elagage tour par tour 173,8 tok/s soutenus
|
| 377 |
+
compactage par blocs 268,2 tok/s soutenus +54 %
|
| 378 |
+
```
|
| 379 |
+
|
| 380 |
+
Visible dans le journal au tour 127 : le compactage retire 32 messages, le
|
| 381 |
+
contexte retombe de 35k à 19k, le tour suivant tombe à 165 tok/s le temps que
|
| 382 |
+
le cache se reconstruise, puis remonte immédiatement à 360-410.
|
| 383 |
+
|
| 384 |
+
**Un compactage rare et massif coûte un tour. Un élagage permanent coûte la
|
| 385 |
+
moitié du débit.** Cela vaut pour tout client agent qui gère une fenêtre.
|
| 386 |
+
|
| 387 |
+
## Les trois régimes, à ne pas confondre
|
| 388 |
+
|
| 389 |
+
```
|
| 390 |
+
pic, 900 tokens, contexte court 575 tok/s 0,21 $/1M
|
| 391 |
+
tour isole a 20k de contexte 421 tok/s
|
| 392 |
+
session soutenue, compactage compris 268 tok/s 0,46 $/1M
|
| 393 |
+
```
|
| 394 |
+
|
| 395 |
+
Le troisième est celui qui décrit un usage réel. C'est lui qu'il faut citer
|
| 396 |
+
pour dimensionner, et non le premier.
|