Comment partager du savoir entre IA sans gaspiller ton GPU ?

TROIS IA, UN MÊME TEXTE : LE PROBLÈME INVISIBLE

Imagine trois agents IA enchaînés comme dans un jeu de rôle : le premier lit un document technique, le deuxième analyse les sections pertinentes, le troisième rédige un rapport final. Problème ? Chaque agent relance son tokenizer (l'outil qui découpe le texte en morceaux compréhensibles pour l'IA) sur le même texte, plusieurs fois de suite. Comme si tu faisais recalculer la même recette de cuisine par trois cuisiniers différents alors qu’un seul suffit. Le tokenizer est rapide, mais pourquoi refaire le même travail trois fois ?

C’est exactement ce qui se passe dans les pipelines multi-agents quand on utilise des modèles de la même famille. Par exemple, avec trois Qwen2.5-Coder (7 milliards, 3 milliards et 1,5 milliard de paramètres) : chaque agent relance le tokenizer sur le texte produit par l’agent précédent. Résultat ? Du temps CPU gaspillé, des latences inutiles et une consommation électrique excessive. Le pire ? L’IA génère des réponses cohérentes mais fausses, car chaque tokenizer recrée des jetons différents à partir des mêmes mots.

LE FORMAT OKF : UN CADRE POUR ÉCHANGER DES DONNÉES ENTRE IA

Google a créé l’Open Knowledge Format (OKF) : un squelette en Markdown avec une section YAML en en-tête. À l’origine, ce format sert à partager des connaissances entre humains et IA. Mais ici, on l’utilise différemment : pour faire transiter des tableaux de jetons pré-calculés entre trois IA de la même famille.

Le fichier OKF ressemble à ceci :

---
blockid: block004routingandsignalingintegration_points
sourceagent: agent1_architect
stage: 1
title: Routing and Signaling Integration Points
tags:
- routing
- signaling
- security
- deployment
tokenpointer: /dev/shm/qwentokens/block004routingandsignalingintegrationpoints.npy
token_count: 3437
tokenizermodelid: Qwen/Qwen2.5-Coder-7B-Instruct
created_at: '2026-08-04T12:41:39.249368+00:00'
---

Le champ token_pointer est la clé : il pointe vers un fichier .npy stocké dans la mémoire partagée /dev/shm/qwen_tokens/. Ce fichier contient les jetons numériques déjà calculés par le premier agent. Plus besoin de relancer le tokenizer .

COMMENT ÇA MARCHE : PARTAGER DES JETONS AU LIEU DE TEXTES

Le premier agent (7B) lit le document, découpe le texte en jetons avec son tokenizer, puis sauvegarde le résultat dans /dev/shm/qwen_tokens/ sous forme de tableau NumPy. Les agents suivants (3B et 1,5B) chargent directement ce tableau et l’utilisent comme entrée pour leur propre Génération de texte. Plus de tokenizer relancé, plus de temps perdu.

Le code pour sauvegarder les jetons est simple :

def savetokenarray(tokenids: torch.Tensor, blockname: str) -> Path:
    tokenidsasnumpyint64 = tokenids.detach().cpu().numpy().astype(TOKENARRAY_DTYPE)
    destinationpath = QWENTOKENSSHMDIR / f"{block_name}.npy"
    np.save(destinationpath, tokenidsasnumpyint64, allowpickle=False)
    return destination_path

Et pour les charger :

def loadtokenarray(pointer_path: Path) -> torch.Tensor:
    tokenidsasnumpyint64 = np.load(pointerpath, allowpickle=False)
    if tokenidsasnumpyint64.dtype .= TOKENARRAYDTYPE:
        raise TypeError(.)
    return torch.fromnumpy(tokenidsasnumpy_int64)

TOKENARRAYDTYPE est np.int64, ce qui évite les conversions inutiles. /dev/shm/qwen_tokens/ est un dossier en mémoire vive (tmpfs), donc ultra-rapide. Le fichier .npy est lisible par n’importe quel agent du pipeline, tant qu’il utilise la même famille de modèles.

28 À 38% DE TEMPS EN MOINS : LES CHIFFRES QUI PARLENT

Les benchmarks montrent des gains spectaculaires. Pour le modèle de 3 milliards de paramètres :

Pour le modèle de 1,5 milliard :

Le pipeline complet (trois agents) met 41,3 secondes au total : 3,9 s pour le premier agent, 18,7 s pour le deuxième et 15,7 s pour le troisième. Chaque essai a été répété 7 fois pour garantir la fiabilité des résultats.

Mais attention : ces gains ne sont possibles que si les jetons partagés sont compatibles entre tous les modèles. Sinon, l’IA produira des réponses cohérentes… mais fausses.

LE PIÈGE : VÉRIFIER QUE LES JETONS SONT COMPATIBLES

Le plus grand danger ? Que deux modèles de la même famille n’utilisent pas exactement le même vocabulaire. Par exemple, le jeton « 1234 » pourrait correspondre au mot « route » pour le modèle 7B, mais au mot « signal » pour le modèle 3B. Résultat : l’IA génère un rapport parfaitement structuré… mais complètement faux.

Pour éviter ça, le pipeline vérifie trois choses avant de faire confiance aux jetons :

1. La taille du vocabulaire : tous les modèles doivent avoir le même nombre de jetons.
2. La correspondance jeton → mot : chaque jeton numérique doit correspondre au même mot pour tous les modèles.
3. Les jetons spéciaux (comme <start> ou <end>) doivent être identiques.

Le code de vérification est implacable :

def verifytokenizerequivalence(modelids: tuple[str, .] = PIPELINEMODEL_IDS) -> None:
    loaded_tokenizers = {
        modelid: AutoTokenizer.frompretrained(modelid) for modelid in model_ids
    }

    referencemodelid = model_ids[0]
    referencetokenizer = loadedtokenizers[referencemodelid]
    referencevocabsize = referencetokenizer.vocabsize

    referencevocab = referencetokenizer.get_vocab()

    for candidatemodelid in model_ids[1:]:
        candidatetokenizer = loadedtokenizers[candidatemodelid]

        if candidatetokenizer.vocabsize .= referencevocabsize:
            raise RuntimeError(
                f"Tokenizer vocabsize mismatch: {referencemodel_id} has "
                f"vocabsize={referencevocabsize}, but {candidatemodel_id} "
                f"has vocabsize={candidatetokenizer.vocab_size}. Token IDs "
                "produced by one are not safe to feed into the other's "
                "embedding layer."
            )

        if candidatetokenizer.getvocab() .= reference_vocab:
            raise RuntimeError(
                f"Tokenizer vocabulary mismatch between {referencemodelid} "
                f"and {candidatemodelid}: at least one token string maps "
                "to a different integer id between the two. Direct token "
                "injection across these models would silently corrupt "
                "downstream generations."
            )

        if candidatetokenizer.specialtokensmap .= referencetokenizer.specialtokensmap:
            raise RuntimeError(
                f"Special-tokens map mismatch between {referencemodelid} "
                f"({referencetokenizer.specialtokens_map}) and "
                f"{candidatemodelid} ({candidatetokenizer.specialtokens_map})."
            )

Cette vérification est cruciale : sans elle, le pipeline produirait des réponses fluides mais erronées, un bug difficile à détecter car l’IA semble « fonctionner ».

POURQUOI ÇA NE MARCHE PAS TOUJOURS : LES LIMITES À CONNAÎTRE

Cette méthode a des contraintes strictes :

• Même famille de modèles : seuls les Qwen2.5-Coder (7B, 3B, 1,5B) fonctionnent ici. Impossible d’utiliser des modèles comme Llama ou Mistral sans vérifier leur compatibilité.
• Blocs courts uniquement : cette optimisation est conçue pour des morceaux de texte de quelques centaines de jetons. Pour des documents longs, d’autres méthodes (comme le partage de cache KV) sont nécessaires.
• Pas de CUDA custom : cette solution repose sur l’API standard model.generate(input_ids=.) de Transformers. Aucune optimisation matérielle spécifique n’est requise.

De plus, la vérification du vocabulaire ne s’applique qu’aux trois modèles testés ici. Rien ne garantit que tous les Qwen2.5-Coder du monde utiliseront exactement le même vocabulaire.

UN CAS CONCRET : COMMENT ÇA S’APPLIQUE EN TÉLÉCOMS

Prenons un exemple réel : un réseau mobile 5G. Une entreprise veut automatiser l’analyse d’une nouvelle fonctionnalité de contrôle de plan. Le pipeline se compose de :

1. Agent Architecte (7B) : structure le document technique et identifie les sections pertinentes.
2. Agent Ingénieur Protocole (3B) : évalue les sections identifiées et génère des recommandations.
3. Agent Analyste Edge (1,5B) : produit des conseils de déploiement prêts à l’emploi, suffisamment légers pour tourner sur un site distant.

Sans optimisation, chaque agent relancerait le tokenizer sur le texte produit par le précédent. Avec l’OKF et le partage de jetons :

• L’agent 1 tokenize une fois et sauvegarde les jetons en mémoire partagée.
• L’agent 2 charge directement ces jetons et génère sa réponse 28% plus vite.
• L’agent 3 fait de même, avec un gain de 38%.

Résultat : un pipeline plus rapide, moins gourmand en ressources, et surtout… fiable.

COMMENT REPRODUIRE L’EXPÉRIENCE ?

Pour tester cette méthode, il suffit de :

1. Installer les trois modèles Qwen2.5-Coder (7B, 3B, 1,5B) depuis Hugging Face.
2. Cloner le dépôt inter-llm-tokf.
3. Exécuter le script de benchmark : python scripts/benchmark.py.
4. Lancer le pipeline complet : python src/run_pipeline.py.

Le dépôt contient tout le code nécessaire : gestion des jetons, vérification du vocabulaire, et orchestration des agents. Pas besoin de modifier le code des modèles ou d’écrire des kernels CUDA custom.

EN RÉSUMÉ : CE QUE TU RETIENS

Cette méthode permet de réduire les latences dans les pipelines multi-agents de 28 à 38%, à condition de respecter trois règles :

1. Utiliser des modèles de la même famille (ex : Qwen2.5-Coder).
2. Vérifier que leurs vocabulaires sont strictement identiques avant de partager des jetons.
3. Stocker les jetons dans /dev/shm/ pour un accès ultra-rapide.

Le plus important ? Cette optimisation ne coûte rien en complexité : elle repose sur des outils existants (OKF, NumPy, PyTorch) et une vérification de sécurité indispensable. Sans elle, ton pipeline produirait des réponses fluides… mais potentiellement catastrophiques.