Ce qui compte comme preuve en transfert KV cross-modèle

7 juil.
7 min de lecture

Trois articles récents revendiquent tous le transfert KV "cross-model". Chacun glisse une béquille qui rétrécit ce que le mot veut dire. Voici la barre à franchir qui rendrait le claim strict falsifiable.

Le transfert KV cross-modèle porte une affirmation précise et séduisante : un modèle de langage fait le prefill coûteux, un autre modèle décode à partir de l'état obtenu, et le second ne relit jamais le prompt. Si cela fonctionnait, le contexte cesserait d'être une séquence de tokens jetable pour devenir un artefact transportable. Le coût du prefill se détacherait du modèle qui exploite son output.

Le framework KV-First nomme cette frontière explicitement. Il définit un niveau de compatibilité cross-model (L2) — le cross-model strict — par un seul invariant : le récepteur décode seulement à partir d'un cache produit par un autre modèle, les modèles sont gelés, les architectures sont hétérogènes, et le transfert est runtime-only — le prefill propre du modèle cible n'est jamais dans le path candidat. Cet invariant est ce que "cross-model" doit vouloir dire pour que le claim soit un claim sur le transfert plutôt que sur quelque chose de plus facile. Le framework ne résout pas L2 ; il l'énonce.

L'idée est assez récente pour que la base de preuves soit encore en cours d'écriture, et le mot "cross-model" fait beaucoup de travail discret. Cette dernière année, trois systèmes — C2C, DroidSpeak et PrefillShare — ont chacun publié un résultat cadré comme du partage KV cross-model ou cross-LLM. Chacun reporte un résultat positif. Chacun aussi, à l'inspection, rétrécit la définition de "cross-model" avec une béquille qui relâche une des contraintes du cross-model strict et fait le travail difficile à sa place.

Ce n'est pas une accusation de malhonnêteté — chaque article énonce son périmètre. Le problème est que le domaine n'a pas de définition partagée assez stricte pour rendre un claim cross-model falsifiable, donc le même label peut vouloir dire un transfert entre deux fine-tunes d'un même base, ou un transfert avec le prefill propre du modèle cible encore dans le path, ou un transfert entre modèles co-entraînés pour être compatibles. Trois claims différents, un seul mot — et le cross-model strict est celui qu'aucun ne fait.

La question que pose cet essai est étroite : que devrait reporter un claim de cross-model strict pour compter comme preuve plutôt que comme proxy ? Y répondre demande de lire ce que chaque article claim réellement, de nommer la béquille sur laquelle chacun s'appuie, et d'énoncer la discipline d'évaluation que le cross-model strict exige et que la littérature n'a pas construite.

Trois claims, trois béquilles

C2C — cross-LLM, avec le prefill propre du récepteur conservé dans le path

C2C (Cache-to-Cache, Tsinghua, ICLR 2026) est le plus authentiquement cross-model des trois. Son claim au niveau du titre est la communication cross-LLM — projeter le KV cache d'un modèle dans l'espace d'un autre et laisser le second continuer — et il l'appuie avec une vraie paire cross-family (Llama-3.2 → Qwen3), un gain de précision reporté de +8,5–10,5 %, et sept fusers pré-entraînés publiés sur HuggingFace.

La béquille est dans le path, et la Table 8 de C2C la nomme. L'ablation labellise une configuration "Project" qui remplace directement le KV cache du récepteur par le cache projeté — le cas cross-model pur — et montre que retenir le cache propre du récepteur via une connexion résiduelle fait monter la précision de 24,18 %. Le gain de titre est mesuré sur un path qui conserve le prefill propre du modèle cible. Le fuser n'a pas à porter le prompt seul ; la lecture du prompt par le récepteur est encore là.

Donc C2C claim le transfert cross-LLM et démontre la projection cross-family. Mais le chiffre qui bouge est celui où le modèle cible lit aussi le prompt. Le cas de remplacement pur — celui qui satisferait l'invariant du cross-model strict sur l'absence de prefill cible — est l'ablation faible, pas le résultat de titre. C2C relâche la dernière contrainte du cross-model strict.

DroidSpeak — cross-LLM, entre fine-tunes d'un même base

DroidSpeak (Microsoft, NSDI 2026) s'intitule "KV Cache Sharing for Cross-LLM Communication", et son périmètre est énoncé honnêtement : il réutilise le KV cache entre des modèles fine-tunés à partir d'un même modèle base. Parce qu'ils sont seulement fine-tunés, ils partagent l'architecture, le tokenizer, le schéma positionnel et la plupart des poids du base. DroidSpeak est training-free et récupère la précision en recalculant les layers qui ont divergé pendant le fine-tuning.

La béquille est la définition de "cross-LLM" elle-même. Un modèle base et son fine-tune sont des checkpoints différents, mais ce ne sont pas des modèles hétérogènes — c'est la même architecture avec des poids différents. Le transfert est plus proche d'un cache warm-start que d'une traduction entre espaces internes distincts. Le geste le plus utile de DroidSpeak est de le dire explicitement : cross-model est un spectre, et DroidSpeak vit au bout facile. Il ne prétend pas, et ne teste pas, le bout difficile où les deux modèles diffèrent en architecture. DroidSpeak relâche la contrainte d'hétérogénéité du cross-model strict.

Donc DroidSpeak claim la communication cross-LLM et la délivre — pour la lecture la plus étroite de "cross-LLM", où les deux modèles sont des fine-tunes d'un seul base. Le label est gagné au bout facile de son propre spectre et non affirmé au-delà.

PrefillShare — cross-model, entre modèles co-entraînés pour partager un prefill

PrefillShare (2026) claim "cross-model prefill and KV-cache sharing" à travers des "heterogeneous models", et le claim est réel dans son setup. Il découpe chaque modèle en un module de prefill partagé et des modules de decode spécifiques aux tâches, gèle le module de prefill, et fine-tune seulement les decodeurs via cache-conditioned fine-tuning. Les modèles qui partagent le module de prefill gelé peuvent réutiliser le KV cache les uns des autres à l'inférence.

La béquille est structurelle et c'est tout le mécanisme. Les modèles sont rendus compatibles cross-model par construction : ils sont entraînés à partager un prefill, puis ils le partagent. "Heterogeneous" se rapporte au côté decode fine-tuné ; le côté prefill — la partie dont le KV cache est partagé — est identique par design. C'est une solution training-time qui retire le problème runtime en exigeant l'accès au training et en changeant ce que sont les modèles. PrefillShare relâche les contraintes frozen-and-runtime du cross-model strict.

Donc PrefillShare claim le partage KV cross-model et l'atteint — mais sur des modèles qu'il avait le droit de remodeler, pas sur des modèles gelés qu'il devait projeter entre eux. Il concède le cas frozen-models, runtime-only en résolvant un autre cas.

La barre à franchir

Chaque article fait un claim légitime, plus petit, sous son propre nom. Aucun ne fait le claim de cross-model strict — le cas strict n'est pas contesté par ces articles ; il est non-revendiqué. Une frontière non-revendiquée n'a aucune discipline d'évaluation attachée, et sans cette discipline, un claim qui arriverait ne pourrait pas être vérifié.

Le cross-model strict est l'invariant ; la barre à franchir énonce ce qu'un claim qui y tient devrait reporter. La première condition est l'invariant lui-même, restaté comme quelque chose contre lequel évaluer. Les trois autres sont la discipline d'évaluation que la littérature n'a pas construite.

Pas de prefill cible dans le path candidat. Le récepteur décode seulement à partir du cache transformé. Le prefill propre du modèle cible peut apparaître comme teacher ou comme oracle d'évaluation ; il ne peut jamais apparaître dans le path dont la précision est le claim. C'est le test unique qui sépare le transfert strict de la béquille résiduelle — et la Table 8 de C2C est l'ablation honnête qui montre ce qui se passe quand on la retire.
Delta contre la baseline native, sur plusieurs familles de tâches. Le claim est `score(récepteur sur cache transformé) − score(récepteur sur prefill natif)`, reporté par famille, en décodage déterministe. Au moins trois familles qui sollicitent des capacités différentes — raisonnement en génération libre, QA à choix multiples, connaissance élargie — pour qu'une méthode ne puisse survivre que là où l'évaluation est clémente. Le delta est l'unité de vérité ; les scores absolus sont de l'orientation. Un fuser qui monte un récepteur faible de 20 % à 26 % n'est pas une victoire si la baseline native du récepteur est 40 %.
Split held-out disjoint. Reporter le score du candidat sur des prompts que le fuser n'a jamais vus pendant l'entraînement, à côté du score sur la surface d'entraînement. Un résultat qui tient sur le train et s'effondre sur le held-out est data-starved, pas une map. C'est la différence entre "le fuser marche" et "le fuser a été entraîné sur assez de la distribution pour avoir l'air de marcher". Ce point mord le plus dur sur la branche du projecteur appris — C2C et ses successeurs — qui est la branche susceptible d'atteindre le cross-model strict.
Séparation d'avec les controls perturbés. Le cache transformé réel doit battre un cache du mauvais prompt, un cache mélangé, un cache poolé, et un cache mis à zéro. S'il ne sépare pas de ceux-ci, le fuser a appris un raccourci, pas le prompt. Le control est le mécanisme de falsification : c'est ce qui rend le protocole capable de dire non.

Un résultat qui reporte les quatre et montre quand même un delta non négatif a franchi la barre que la littérature actuelle n'a pas définie, et encore moins passée.

Pourquoi cette barre est la contribution

Nommer la barre à franchir est la contribution, parce qu'elle sépare trois choses que le label "cross-model" confond actuellement. Un résultat avec le prefill cible dans le path est un résultat de fusion résiduelle, pas un résultat de transfert cross-model. Un résultat entre fine-tunes d'un seul base est un résultat de réutilisation same-architecture, pas un résultat de transfert hétérogène. Un résultat sur des modèles co-entraînés est un résultat de compatibilité training-time, pas un résultat de projection runtime. Chacun mérite d'être publié sous son propre nom. Aucun n'est le cross-model strict.

L2 est la frontière que KV-First nomme mais ne résout pas : la compatibilité same-model est réglée, la compatibilité cross-model est ouverte, et l'ouvert est défini par l'invariant énoncé plus haut. Une frontière n'est pas une feature réglée. Dire ce qui la règlerait — cette barre à franchir en quatre points ci-dessus — est le travail, parce que ça dit à la prochaine expérience exactement ce qu'elle doit reporter et ce qu'elle doit réfuter. Le framework fournit la définition ; cette barre fournit la falsifiabilité.

La barre à franchir n'est pas haute pour être prudent. Elle est haute parce que toute barre plus basse a déjà été franchie par un résultat qui gardait une béquille dans le path et l'appelait cross-model.