Zyphra a sorti Zamba2-VL, une famille de vision-language models ouverts en trois tailles, 1,2B, 2,7B et 7B paramètres, sous Apache 2.0 avec les poids, le code et un papier tous publics. Côté perception, c'est conventionnel : un encodeur vision-transformer Qwen2.5-VL pré-entraîné transforme les patches d'image en features, un adaptateur MLP à deux couches les projette dans l'espace du modèle de langage, et le modèle de langage traite les tokens vision et texte entrelacés avec du grounding single- et multi-image. La partie non-conventionnelle, c'est le backbone de langage, et le claim de Zyphra à son sujet est le titre : c'est la première famille de VLM ouverte bâtie sur un modèle hybride state-space-plus-transformer entièrement ouvert.

L'architecture divise le travail exprès. Le backbone Zamba2 alterne des couches state-space Mamba2, qui portent le gros de la computation à bas prix et scalent quasi-linéairement avec la longueur de séquence, avec des blocs d'attention transformer partagés, chacun doté de son propre adaptateur LoRA, qui préservent le retrieval in-context que les modèles SSM-purs ont tendance à abandonner. La raison pour laquelle ça compte, c'est la latence sur les longs inputs, et la vision rend les inputs longs vite : une seule image haute-résolution peut ajouter de l'ordre de 3400 tokens visuels, donc quelques images ou un document multi-pages dépassent le point où le coût quadratique de l'attention et son KV cache qui grossit dominent le prefill. Zamba2 garde un état récurrent de taille fixe à la place, et sur un prefill de 32k tokens Zyphra rapporte environ un ordre de grandeur de moins en time-to-first-token que la baseline Transformer la plus proche. Les modèles ont été entraînés sur 100 milliards de tokens de données vision-texte et texte avec le tokenizer Mistral v0.1.

Les benchmarks racontent une histoire à deux côtés, et la lecture honnête est dans le deuxième côté. À 2,7B, Zamba2-VL est fort là où le travail c'est la perception : il poste 90,9 sur DocVQA pour la compréhension de documents et 82,5 sur PixMoCount pour le comptage visuel, ce dernier bien au-dessus des baselines Transformer de même taille, avec une perception générale compétitive. Il est derrière là où le travail c'est la connaissance et le raisonnement : 37,7 sur MMMU et 51,0 sur MathVista traînent derrière les VLM Transformer de même taille, et l'OCR traîne aussi. Donc le gain de latence d'un ordre de grandeur n'est pas gratuit. Tu échanges du raisonnement et de la qualité OCR contre un premier token beaucoup plus rapide sur du long contexte visuel, et les use cases que Zyphra nomme s'alignent exactement avec cette forme : extraction de documents et de formulaires, comptage et inventaire retail, PDF multi-pages, et assistants on-device, où le modèle 1,2B edge-tuné et le bas time-to-first-token comptent plus que le raisonnement maximal.

Pour le fil de diversité d'architecture qu'on track, l'accumulation lente de preuves que l'attention est pas la seule façon de bâtir un modèle capable, c'est un data point propre et vérifiable : un VLM hybride SSM-transformer ouvert avec un vrai avantage de latence mesuré et un coût de qualité honnêtement borné, code et poids ouverts. Les caveats sont énoncés clairement : ça a besoin d'un GPU CUDA pour les kernels optimisés, avec des chemins CPU lents ; y'a pas d'API gérée, donc tu self-host ; et ça ship comme un artefact de recherche, pas un service de production. Mais la forme est le point. À mesure que les inputs multimodaux continuent de s'allonger, plus de pages, des images plus haute-résolution, plus de frames vidéo, le coût quadratique de l'attention sur le prefill est exactement là où un backbone state-space quasi-linéaire gagne sa croûte, et Zamba2-VL est la première famille ouverte qui laisse les builders mesurer ce tradeoff sur leurs propres workloads visuels long-contexte au lieu de le prendre sur la foi.