Fork Ninfer : correction du cache KV et du streaming d'outils, validée par quatre benchmarks

Déroulé structuré

Segment 1 — Fork Ninfer : deux correctifs validés par quatre benchmarks

Statut : Information première partie ; mesures auto-déclarées sur une machine unique.

• Deux bugs identifiés dans Ninfer en version d’origine : (1) perte silencieuse des entrées du KV cache sous pression de sessions parallèles, provoquant un re-traitement complet du contexte et une dégradation de latence estimée à 3–4× ; (2) les appels d’outils (écritures de fichiers) n’étaient pas streamés, laissant l’interface silencieuse pendant les longues générations.
• Le fork est publié sur github.com/co-l/ninfer. Le créateur le décrit comme déjà en retard sur le dépôt amont et difficile à maintenir en raison de l’ampleur des changements dans le moteur.
• Quatre benchmarks personnalisés ont été conçus pour valider les correctifs :
  • Pression cache : saturation du pool avec 65 contextes de 8K tokens, vérification des hits en sens inverse. Résultat fork : 57/65 contextes préservés (~456K sur 480K configurés, pool réel 460K). Résultat Ninfer d’origine : cache miss sur l’avant-dernier contexte créé.
  • Simulation agent : 4 sessions parallèles, chacune avec un agent principal et 2 sous-agents. Résultat fork : 100 % de cache hit. Résultat Ninfer d’origine : la phase des sous-agents n’est jamais atteinte (contextes principaux perdus).
  • Interruption : session de 40K tokens, génération puis abort, relance du prompt. Résultat fork : 96 % de cache réutilisé (99,8 % dans le framing du créateur). Résultat Ninfer d’origine : 0 %, re-traitement complet.
  • Needle-in-haystack : recherche à 50K, 100K, 200K, 300K et 450K tokens. Tests à 50K, 100K et 200K passés ; 300K et 450K échouent car la fenêtre contextuelle maximale est de 262K tokens.
• Le streaming d’outils est qualifié par le créateur d’amélioration d’expérience utilisateur plutôt que de gain de performance.
• Problème résiduel identifié : lorsque la VRAM est saturée et que des contextes doivent être re-transférés de la RAM vers la VRAM, le transfert prend environ une seconde par contexte ; le système n’est pas encore entièrement solide en contention extrême. Le créateur annonce continuer à travailler sur ce point.
• Développement : 5 jours / 62 heures au total (24 h de réflexion de l’agent IA « LIA » + 38 h 13 min d’outils). La session a été compactée 12 fois, chaque contexte faisant 500K tokens. Méthodologie : les benchmarks d’échec servent de critères d’acceptation ; le créateur ne fournit que leur design, l’agent itère seul jusqu’à leur passage.

Segment 2 — Configuration RTX 5090 / Qwen 3.8 27B

Statut : Information première partie ; configuration documentée dans un fichier start.sh.

• GPU : RTX 5090 d’occasion achetée 4 000 €, limitée à 400 W sur 600 W disponibles. Consommation totale machine : ~520–524 W.
• Mémoire : 32 Go DDR5, utilisée pour l’offload du KV cache au-delà de la VRAM.
• Modèle : Qwen 3.8 27B en quantification mixte — 52,6 % des poids en NVFP4 (format FP4 Nvidia), 41,8 % en FP8 (poids d’attention et de gestion du cache). Le créateur estime que le terme « Q6 » serait plus juste que « NVFP4 pur ».
• Moteur : Ninfer, dédié à la famille hardware 5090 + Qwen 3.6/3.8 (contrairement à llama.cpp, vLLM ou SGLang). Usage de VRAM nettement inférieur à vLLM. Format de poids spécifique publié par l’auteur du moteur sur Hugging Face. Linux uniquement.
• Capacité : 262 000 tokens de contexte par session ; 4 sessions simultanées en usage développeur (jusqu’à 10 en usage sporadique). KV cache : 460K tokens en VRAM, extensible à 600K+ via la RAM.
• Débits mesurés : 150+ tok/s en moyenne, 400 tok/s en pointe (~1 tok/s par watt à 400 W). En 3 sessions parallèles : 126, 133 et 110 tok/s par session, total approchant 400 tok/s. Moyenne sur sessions de 100K–150K tokens : 116–118 tok/s.
• Coût total de la configuration : ~5 000–5 500 €.
• Positionnement (opinion du créateur) : alternative viable aux abonnements cloud (ChatGPT, Claude, Gemini) pour les PME, avec argument de résidence des données et de conformité RGPD.
• OpenFox (github.com/co-l/openfox) : outil d’agents open source, gratuit, servant de couche frontend. Prend en charge les agents principaux et sous-agents, le mode « build and verify », l’isolation par workspace et le contrôle de langue de sortie.
• Configuration exacte publiée dans le fichier start.sh du dépôt du fork ; adaptation à la configuration matérielle individuelle nécessaire.

Segment 3 — Variante Swift de Qwen 3.8 27B

Statut : Information rapportée ; évaluation qualitative sur une tâche unique.

• Variante réentraînée de Qwen 3.8 27B (« Swift ») : réduit les tokens de réflexion (moins de sur-réflexion) tout en conservant des résultats similaires et la capacité à réfléchir en profondeur quand nécessaire.
• Quantisation compatible Ninfer disponible (liens Hugging Face : ukisai/Swift-Qwen3.8-27b et Yuuyuuyuuyuu/Swift-Qwen3.8-27B-OrcaRouter-NVFP4-DFlash2-ninfer).
• Comparaison live : la même tâche de génération HTML prend 1 min 40 avec la variante Swift (184 tok/s, avec vérification par capture d’écran) contre 5 min 25 avec la quant de base (dont 4 min 40 de réflexion et 46 s d’outils).
• Test grandeur nature : 3 agents OpenFox en parallèle, mode build-and-verify, tâche de conception et test d’un petit jeu. Temps de réflexion IA : 19–25 minutes par agent (hors temps d’outils). Le créateur admet une erreur de configuration ayant fait travailler deux agents dans le même workspace. Évaluation de l’output de l’agent isolé : jeu jouable, esthétique cohérente, rien de fondamentalement cassé.
• Quantisations tierces (dont celles de « Bartoski ») potentiellement compatibles 16 Go VRAM mentionnées mais non testées par le créateur ; il propose un suivi en vidéo si la demande est suffisante.
• Méthodologie de réentraînement de la variante Swift non décrite dans la vidéo.

Points notables

• Le ratio 96 % contre 0 % de cache réutilisé après interruption est le chiffre le plus marquant : il illustre l’impact opérationnel direct d’un bug de gestion de cache sur le temps réel de génération.
• La méthode « benchmarks d’échec comme critères d’acceptation » est un pattern réutilisable au-delà de Ninfer : le créateur ne fournit que le design des benchmarks, l’agent IA itère seul. Il annonce un suivi sur un environnement cluster et les problèmes de cache de vLLM.
• La quantification mixte NVFP4/FP8 (plutôt que NVFP4 pur) est un détail technique souvent masqué par le nommage commercial : 41,8 % des poids (attention + gestion cache) restent en FP8.
• Le fork est explicitement décrit comme « déjà en retard » sur l’amont et difficile à maintenir : les correctifs pourraient être des patches temporaires à réappliquer ou supplantés.
• Le créateur compare Ninfer à llama.cpp, vLLM et SGLang en soulignant que la spécialisation hardware/modèle réduit nettement l’usage de VRAM — un argument de différenciation pour un moteur dédié 5090.

Limites & biais factuels

• Tous les résultats de performance (tok/s, pourcentages de cache, débits par session) sont auto-déclarés par l’auteur sur une configuration unique ; aucune validation indépendante n’est présentée.
• Le fork Ninfer est déjà en retard sur le dépôt amont ; les correctifs risquent d’être supplantés ou d’exiger des re-travaux, ce qui en limite la durabilité pratique.
• L’amélioration de la variante Swift (1 min 40 vs 5 min 25) repose sur une démonstration unique avec un prompt vague ; la généralisation à d’autres tâches n’est pas établie.
• L’argument RGPD (les États-Unis « n’ont pas de RGPD ») est une simplification de l’auteur ; les revendications techniques fonctionnent indépendamment de cet argument.
• La transcription corrompt certains termes anglais techniques (Ninfer, cache, VRAM, Qwen, vLLM, SGLang) ; les chiffres exacts doivent être recoupés avec la vidéo ou la documentation du fork.
• L’erreur de configuration workspace dans le test à 3 agents contamine partiellement la validité de ce test (deux agents ont travaillé dans le même workspace).