Zyphra a publié TSP — Tensor + Sequence Parallelism — une stratégie de parallélisme qui replie ce qui était deux axes orthogonaux (TP shardant les poids, SP shardant les activations) sur un seul axe device-mesh. Le choix architectural qui compte : chaque GPU détient 1/D des poids du modèle *et* 1/D des tokens de séquence, où D est la taille de l'axe. La mémoire de paramètres et la mémoire d'activations chutent toutes les deux du même facteur 1/D sur le même hardware. La config validée : transformer décodeur dense 7B (h=4096, 32 couches, 32 têtes Q/KV, FFN×4, bf16) sur 1 024 GPU AMD MI300X à 128k longueur de séquence avec D=8. Débit rapporté : 173M tokens/sec versus 66,3M pour la baseline TP+SP appariée — une amélioration de 2,6×.

La stratégie de communication, c'est là que vit la substance ingénierie. Pour l'attention : les shards de poids broadcast itérativement, chaque GPU les applique à ses tokens locaux, puis les tenseurs K/V se font all-gather avec partition zigzag pour load balancing. Pour le MLP : schedule en anneau qui fait circuler les shards de poids par opérations point-to-point, *éliminant* l'all-reduce que le TP standard exige. Comparaison mémoire single-node à 128k tokens (8× MI300X) : 38,8 Go/GPU sous TSP versus 70,0 Go sous TP simple et 85-140 Go sous diverses variantes TP+SP. Cette marge mémoire, c'est ce qui débloque l'entraînement/inférence long-contexte à cette taille de modèle dense sur ce hardware. Papier sur arxiv.org/pdf/2604.26294; writeup technique sur zyphra.com/post/tsp.

Deux signaux écosystémiques. Premièrement, le résultat a été validé sur 1 024 MI300X — pas sur H100 — ce qui est cohérent avec l'histoire neocloud plus large : le silicium d'AMD apparaît dans des clusters de recherche classe production quand le stack logiciel est assez bon, et celui de Zyphra l'est apparemment. Deuxièmement, le choix architectural (sharder les poids et les activations sur le même axe plutôt que sur des axes orthogonaux) est le genre de simplification qui ouvre un nouvel espace de design pour le parallélisme. PTD-P (Megatron-LM) et FSDP sont les playbooks par défaut depuis des années; TSP ne les remplace pas, mais ça élargit l'ensemble des combinaisons hardware/modèle où le shardage plié peut battre le shardage orthogonal. Si tu fais rouler TP+SP à échelle de modèle petite-à-moyenne sur AMD ou NVIDIA, TSP vaut un benchmark sur ta config spécifique.

Pour les développeurs qui entraînent ou servent de gros modèles, le take-home est concret. Une marge mémoire de 38,8 Go versus 70-140 Go à 128k contexte veut dire que tu peux soit rouler des contextes plus longs sur le même hardware, soit faire entrer des modèles plus gros dans le même budget mémoire. Le claim 2,6× de débit est spécifique à la config (1 024 MI300X, dense 7B, D=8); à des échelles plus petites ou sur H100/H200, les chiffres seront différents — lis le papier, fais rouler sur ta shape. L'astuce MLP-sans-all-reduce est portable : même si tu n'adoptes pas TSP en entier, éliminer cet all-reduce dans ton setup TP existant est le genre de win qui vaut la peine d'être sorti comme optimisation standalone. Zyphra n'a pas livré de code à date de ce writeup; c'est la prochaine chose à surveiller.