La startup sud-coréenne Xcena bâtit MX1, une puce de compute near-memory qui se connecte à la DRAM via CXL (Compute Express Link) pis place des milliers de petits cores RISC-V à côté de la mémoire plutôt que de shuttler les données vers un CPU ou GPU. La thèse architecturale, c'est la partie qui vaut la lecture peu importe le titre de financement : la contrainte qui lie l'IA pour une grosse part du travail d'inférence, c'est la bande passante mémoire, pas le compute, pis la bonne réponse, c'est d'amener le compute aux données. MX1 vise spécifiquement la gestion du KV-cache (le store du contexte de conversation précédent), le preprocessing, pis le data caching — les opérations memory-bound qui roulent présentement sur des CPUs pis stallent le pipeline. Le statut honnête en avant : MX1 est un prototype, aucun silicium n'a shippé, le writeup donne zéro chiffre de bande passante ou benchmark, la production de masse est visée pour fin-2026 pis le revenu pour 2027. C'est un signal de direction architecturale, pas un produit que tu peux évaluer.

La forme technique, telle que divulguée : des milliers de cores RISC-V délibérément gardés petits pis efficaces, une hiérarchie mémoire interne custom, un bus d'interconnexion custom, pis un contrôleur DRAM custom — intégration verticale plutôt qu'assembler des parts off-the-shelf. La claim, c'est la consolidation d'infrastructure, « ce qui demandait 10 serveurs pourrait potentiellement rouler sur juste un », ce qui est le genre de chiffre qui veut rien dire sans une définition de charge pis devrait se lire comme une cible, pas un résultat. Le choix CXL, c'est le pari architectural load-bearing : CXL laisse l'accélérateur near-memory s'asseoir sur le bus mémoire comme device cohérent, donc le KV-cache peut vivre à côté des cores qui le gèrent au lieu d'être copié à travers PCIe vers un GPU. Si la latence CXL pis la maturité de l'écosystème rendent ça pratique à l'échelle inference-serving, c'est exactement la question ouverte que le prototype n'a pas répondue.

La lecture écosystème connecte au fil d'économie d'inférence qui se bâtit toute la semaine : le KV-cache est le hog de mémoire dans le serving long-context pis agentique, pis les moteurs qui gagnent cette charge (gains de décodage spéculatif, taux de hit de prefix-cache) combattent tous le même mur de mémoire du côté logiciel. Le pari de Xcena, c'est la version côté-hardware — désagréger la stack d'inférence pour que les parts memory-bound (KV-cache, preprocessing) roulent sur du silicium near-memory pas cher pendant que le GPU est réservé aux matmuls compute-bound. Si l'offload near-memory de KV-cache devient une vraie catégorie, ça change la structure de coût de l'inférence long-context plus qu'une autre génération de GPU. Le risque est triple : la latence CXL pourrait manger les gains, l'écosystème logiciel pour cibler les accélérateurs near-memory existe à peine, pis NVIDIA pourrait absorber la fonction dans sa propre hiérarchie mémoire avant qu'une startup ship.

Si tu architectes de l'infra d'inférence lundi matin : y'a rien à déployer ici avant deux ans, mais le split memory-bound-vs-compute-bound, c'est le framing à adopter maintenant — profile quelle fraction de ton coût d'inférence est KV-cache pis preprocessing versus du vrai matmul, parce que ce ratio détermine si le compute near-memory t'aiderait jamais. Si tu investis dans ou bâtis du hardware IA : le signal à tracker, c'est si quelqu'un ship de l'offload near-memory de KV-cache avec des vrais benchmarks, parce que la thèse est solide pis l'exécution est non prouvée. Watch pour du silicium shippé pis un tête-à-tête contre HBM-on-GPU avant de traiter ça comme plus qu'une direction.