Zamba2-VLとは｜Mamba2ハイブリッドで初回応答を速めた軽量オープンVLMの実力と制約（1.2B/2.7B/7B）

画像を読むモデルの「最初の1トークンまで」を縮める発想

画像や図表を入力として受け取り、その内容について答える視覚言語モデル（VLM、vision language model）は、ローカルでも実用域に入ってきた。請求書の項目を読み取る、グラフの数値を拾う、画面のUI要素を指し示す。こうした処理を手元のGPUで回せるローカルLLM系のモデルが増え、用途も広がっている。一方で、画像を扱うモデルには独特の重さがある。高解像度の画像は大量のパッチ（小片）に分割されてモデルへ渡るため、入力を読み込んで最初の1トークンを返すまでの時間、いわゆるプリフィル（prefill）の負荷が大きくなりやすい。

この「最初の応答までの待ち時間」をTTFT（time-to-first-token、初回トークンまでの時間）と呼ぶ。対話やバッチ処理で何度もモデルを呼ぶ使い方では、TTFTが体感とコストの両方に効いてくる。Transformerの注意機構（attention）は入力が長くなるほどプリフィルの計算量が二次的に増える性質があり、長い入力ほどここが効率の壁になる。

Zyphraが2026年6月に公開したZamba2-VLは、この壁の出方を変えにいったモデル群だ。言語側の土台をTransformer一辺倒ではなく、状態空間モデル（SSM、state space model）であるMamba2を主体にしたハイブリッド構成に置き換え、プリフィルの計算量を抑えることを狙っている。この記事では、Zamba2-VLが何をするモデルで、どんな仕組みで速さを得ているのか、精度は競合に対してどの位置にあるのか、そしてどこに制約があるのかを、公式情報と技術報告書を軸に整理する。確認できた数値と、Zyphra側の主張として読むべき数値は分けて扱う。

Zamba2-VLの概要：サイズ展開・ライセンス・できること

Zamba2-VLは、Zyphraが公開した視覚言語モデルのファミリーで、1.2B・2.7B・7Bの三系統がある。公開時期は、技術報告書（arXiv v1）が2026年5月29日、Zyphra公式ページでの紹介が6月2日付だ。いずれもApache 2.0ライセンスで重みが公開されており、商用利用を含めて扱いやすい配布形態になっている。注意したいのは、この1.2B/2.7B/7Bという呼称が言語バックボーン側のサイズだという点だ。視覚エンコーダを組み合わせた実体はもう少し大きく、Hugging FaceのModel size表記ではそれぞれおおむね2B・3B・8Bパラメータと出る（最も大きい構成はZamba2-7Bバックボーンに視覚エンコーダを足して約8B）。本稿ではモデル名に合わせて1.2B/2.7B/7Bと呼ぶ。

できることは、単一画像と複数画像の理解、そして画像内の対象を位置で指し示すグラウンディング（grounding）だ。文書や請求書のような文字の多い画像、グラフやチャートの読み取り、画像内の物体を数えるカウント系のタスクなどが対象になる。動画や画像を複数の観点で評価するマルチモーダル検品のような応用も、こうした画像理解モデルの上に成り立つ。NuExtract 3のような構造化抽出に特化したVLMとは違い、Zamba2-VLは特定タスク専用ではなく、画像理解の汎用モデルとして位置づけられている。

三つのサイズは役割が分かれる。7Bはベンチマークでの到達点を狙う本命、1.2Bと2.7Bは軽さと速さを優先する位置づけだ。後述するように、効率面（初回応答の速さ）の利点はサイズが小さいほど際立ちやすく、軽量帯の二つが設計の狙いをよく表している。

なぜ速いとされるのか：Mamba2ハイブリッドという土台

Zamba2-VLの速さの根拠は、言語側のアーキテクチャにある。標準的なVLMは言語モデル部分をTransformerで組むが、Zamba2はMamba2という状態空間モデルを backbone（背骨）に据え、そこへ少数の共有Transformerブロックを挟み込むハイブリッド構成をとる。挟み込まれたTransformerブロックは、挿入位置ごとにLoRAプロジェクタで軽く特化させてある。

この構成が効くのはプリフィルの計算特性だ。Transformerの注意機構は入力長に対して計算量が二次で増えるのに対し、Mamba2のような状態空間モデルは入力長にほぼ比例する（near-linear）計算量で済み、過去の情報を小さくほぼ一定サイズの内部状態にまとめながら処理を進める。技術報告書はこの「near-linearなプリフィル計算量」と「小さくほぼ一定の再帰状態」を効率の源泉として挙げ、遅延やメモリが制約になる環境での運用に向くと説明している。長い入力を一気に読み込む場面ほど、この差が時間に現れる。

効くのはプリフィルだけではない。状態空間モデルは過去の文脈を、トークンを足すたびに膨らむキャッシュではなく、小さくほぼ一定サイズの内部状態に畳み込みながら処理を進める。Transformerが入力長に比例してKVキャッシュ（過去トークンの中間表現）を抱え込み、メモリを食っていくのに対し、Mamba2系はそこが膨らみにくい。同時に多数のリクエストをさばく、あるいは出力を長く続ける場面では、このメモリの平坦さが効いてくる。遅延だけでなく省メモリの両面で、軽量帯のサービングに向くと技術報告書が述べているのは、この性質を指している。

視覚側はTransformerを使う。視覚エンコーダにはQwenチームのQwen2.5-VLのVision Transformerが流用され、画像パッチに2次元の回転位置エンコーディング（2D RoPE）を当て、解像度に応じて動的に処理する作りになっている。エンコーダの出力は2層のMLPアダプタを通り、2×2のパッチ窓をひとつのベクトルにまとめてから言語モデル側の埋め込み空間へ射影される。トークナイザはMistral v0.1が使われている。視覚側にTransformerを残しつつ、計算とメモリの主因になりやすい言語側をMamba2主体に振った、という役割分担の構成だ。

学習は段階を分けて行われている。技術報告書によれば、約2.3億トークンのアライメント、約30Bトークンの事前学習、約20Bトークンの指示チューニングという三段構成で、データはオープンなWebデータセットから集められている。なお、学習データの総量はHugging Faceのモデルカードに100Bトークンとの記載もあり、技術報告書の三段の合計（約50B）とは数え方が異なる。ここでは段階別の内訳が示されている技術報告書の値に沿った。効率重視のアーキテクチャを採るという方向性は、MiniMax M3のMSA（スパース注意）のように、注意機構そのものを置き換える近年の流れと地続きにある。

「TTFTが約10分の1」をどう読むか

Zamba2-VLの宣伝文句として前面に出るのが、TTFTの大幅な短縮だ。Zyphraは、各サイズで「最も近いTransformerベースラインに対し、競争力のある精度を保ったまま、おおよそ一桁低いTTFT」を達成したとしている。ここは数字の出し方を踏まえて読む必要がある。

技術報告書によれば、このTTFTは言語バックボーン単体に対して、32kトークンのプリフィルで測られている。視覚処理を含むVLM全体ではなく言語モデル部分が測定対象だという点は、先に押さえておきたい。報告書は「推論計算の大半が費やされる」のがこのプリフィル部分だとして、そこを測定対象に選んだと説明する。つまり「一桁低い」という差は、長い入力を読み込む局面で、言語モデル部分に着目したときの値だ。GPUの機種やバッチサイズ、個別モデルとの一対一の比較条件までは報告書に明示されていない。

注意したいのは、後述するようにZamba2-VL自体の文脈長が4kトークンに制限されている点だ。32kプリフィルという測定条件は、モデルが実際に画像理解で扱える文脈長を超えた領域での、バックボーンのスケーリング特性を示すものと読むのが正確になる。したがって「日常的な短い入力でも常に10倍速い」とまでは言えず、長い入力ほど、また小さいサイズほど効いてくる性質だと捉えるのが実態に近い。報告書自身も、この優位性は1.2Bと2.7Bの小規模帯で最も顕著だとしている。速さは確かに設計の核だが、見出しの数字は測定条件込みで受け取るのが妥当だ。

精度の実力：競合と並べて読む

速さの裏で、精度はどの位置にあるのか。技術報告書のベンチマーク表（Table II）から代表的な指標を抜き出し、各指標で技報に並ぶ主な比較対象の値を併記する。ここで併記した比較対象はベンチマークごとに異なり、規模帯も揃っていない点には注意がいる。たとえばPixMoCountは1B級のInternVL3.5-1B、文書・図表系は8B級のQwen3-VL-8BやInternVL3.5-8Bを引いており、Zamba2-VLの三サイズすべてに対する同一条件の対戦表ではなく、各指標での代表的な相手として読むのが正確だ。

表から読み取れる構図は素直だ。7BのZamba2-VLは、文書理解（DocVQA 92.9対96.1）、画像内文字（TextVQA 81.0対83.2）、一般質問応答（VQAv2 82.8対86.1）、総合理解（MMMU 43.8対47.7）といった指標で、同規模帯の強い競合に数ポイント届かない。精度の絶対値で先頭を取りにいくモデルではなく、競合と肩を並べる水準を保ちながら速度と効率で差をつける、というのが立ち位置になる。

得意が出るのはカウント系、とくにPixMoCountだ。ここでは1.2Bですら62.5と、同規模のInternVL3.5-1Bの32.8を大きく上回り、2.7B・7Bでも高い。ただしカウント全般で一律に強いわけではない。もうひとつのカウント指標CountBenchQAは、2.7B（87.5）・7B（90.6）では競合と競り合う水準だが、1.2B（56.9）はPerceptionLM-1BやQwen3-VL-2Bなどに届かず、小型版では弱い。「PixMoCountでは特に強く、CountBenchQAは中型以上で競争的」という濃淡で捉えるのが正確だ。

サイズと強みの関係も整理しておきたい。効率（初回応答の速さ）の優位は、1.2B・2.7Bの小型帯で特に出やすい。一方で精度の相対位置はベンチマークごとに差が大きく、小さいサイズだから競合に近づく、という単純な傾向にはない。7Bは7〜8B級の強い競合と競争的な水準に入り、Zyphraも相対的な位置づけはスケールとともに改善すると説明している。速さと competitive な精度の両立という強みは、用途と指標とサイズの組み合わせで出方が変わる。

文脈長4kという制約

運用前に押さえておきたいのが文脈長の上限だ。Zamba2-VLの最大文脈長は4,096トークンで、技術報告書はこれを「Zamba2のベースモデルが事前学習された文脈長を引き継いだもの」と明記し、制約として認めている。報告書の言葉を借りれば、標準的な4k文脈のZamba2ベースモデル上で学習したことが、一度の文脈に収まる解像度と画像枚数の上限を決めている。

これが実務で何を意味するかは、画像をどれだけのトークンに展開するか次第だ。Hugging Faceの推論例では1枚あたりの画像トークン数を3,400に設定しており、高解像度のまま1枚読ませるだけで4kの枠の大半を使うこともある。解像度や1枚あたりのトークン数を抑えれば（OmniParserのように視覚トークンの負荷を前処理で削る手もある）、文書1ページや数枚の画像理解は4kの中で扱えるが、超高解像度を細かいパッチで大量に流し込む、多数の画像を一度にまとめて横断比較する、長大なPDFを丸ごと、といった使い方では枠に収まらない。前節のTTFTの測定が32kプリフィルだったことと合わせると、バックボーンの素性としての長文処理能力と、VLMとして実際に使える文脈長は別物だと理解しておくのが安全だ。

動かすには：必要なものと現状のハードル

重みはHugging FaceのZyphraコレクションで、推論コードはGitHubのZyphra/transformersリポジトリのzamba2-vlブランチで公開されている。ただし、現時点では一般的な実行環境にそのまま載るわけではない点に注意がいる。

Hugging Faceのモデルカードによれば、動かすにはZyphraが用意したtransformersのフォーク（transformers @ git+https://github.com/Zyphra/transformers.git@zamba2-vl、v4.57.1ベース）が必要で、加えてqwen-vl-utilsとflash_attnを入れる構成になっている。さらに高速なMamba2カーネルを使うには、causal-conv1dとmamba-ssmをZyphra側のフォークから導入する必要がある。これは、標準のtransformersやOllama・llama.cpp・LM Studio・vLLMといった一般的な推論エンジンに、公開直後の段階ですぐ載るわけではないことを意味する。Mamba2系のカスタムカーネルを伴うモデルは、量子化やGGUF化、各種ランタイムへの対応が出そろうまでに時間がかかりやすく、導入のハードルは平易とは言いにくい。量子化して動かす段になれば、フォーマットごとの精度とサイズの兼ね合いも判断材料になる。手元で試す場合は、公式リポジトリのREADMEで要求される依存とブランチを確認し、指定どおりの環境を作るところから始めることになる。

ライセンスはApache 2.0で、これは重みについてもZyphraが公式に明示している。商用・改変・再配布を広く許す条件で、研究にも製品にも組み込みやすい。ローカルで動かすこと自体は、データを外部のAPIへ送らずに画像処理を完結させられる可能性を開くが、実際にどこまでオフラインで完結するかは、組み込む側のアプリやパイプラインの設計次第で変わる点は一般のローカルモデルと同じだ。

手元で確かめるなら、どこを見るか

このモデルの利点は条件依存なので、導入を検討するなら公開された数値をそのまま自分の環境に当てはめず、いくつかの点を実地で確かめるのが堅実だ。第一に、TTFTは自分が実際に使う入力長で測る。公式の「約一桁低い」は32kプリフィルでの値であり、文書1ページ程度の短い入力では差はそこまで開かない。普段の入力サイズで、競合のTransformer系VLMと並べて初回応答までの時間を比べると、効果の実寸がつかめる。

第二に、精度は扱うドメインの画像で見る。ベンチマークは汎用指標であって、請求書なら請求書、図面なら図面と、現場のデータでカウントや読み取りの正答を確かめないと、数ポイントの差が用途にとって致命的かどうかは判断できない。第三に、導入そのものが通るかだ。ZyphraのフォークやMamba2系カーネルを含む環境がGPUとドライバの組み合わせでビルドできるか、量子化なしのBF16でVRAMに収まるかを、小さい1.2Bから順に確認していくと躓きが少ない。速さと精度のトレードオフが自分の条件で割に合うかは、最終的にこの三点を手元で測って初めて見える。

どんな用途・誰に向くか

ここまでの素性を踏まえると、向き・不向きは比較的はっきりしている。

精度で先頭を取りたい、あるいは長い文脈や高解像度をたっぷり扱いたいなら、Qwen3-VLやMolmo2、InternVL3.5といったTransformer系の競合のほうが素直に合う。逆に、限られた計算資源で軽量VLMを回数多く動かす、初回応答の速さが効くサービングに組み込む、カウントや位置把握が主役、といった条件では、小型帯のZamba2-VLが選択肢に入る。大型のマルチモーダルを正面から使う発想とは対照的だ。Qwen3.6-35B-A3Bのように、総パラメータ容量とMoE構成（35B総量・3B active級）で性能を出しにいく大きめのモデルが「容量で押す」側だとすれば、Zamba2-VLは「小ささと初回応答の速さで効かせる」側に振った設計だといえる。

よくある質問

Zamba2-VLは日本語の画像も読めるのか。 学習データはオープンなWebデータセットとされ、トークナイザはMistral v0.1だ。日本語を含む文書や画像での精度は公式のベンチマークに個別の指標として示されておらず、実際の用途では手元のデータで試して確かめる必要がある。多言語性能を断定できる材料は公開情報からは取れない。

GGUF化してllama.cppやLM Studioで動かせるのか。 公開直後の時点では、ZyphraのtransformersフォークとMamba2系のカスタムカーネルを前提とした構成だ。GGUFや一般的な推論エンジンへの対応は、コミュニティや本家の対応が出そろうかどうかにかかる。現状で確実に動かすには、公式が案内する環境を使うのが前提になる。

7Bと1.2B、どちらを選ぶべきか。 精度の到達点を重視するなら7B、軽さ・速さ・省メモリを重視するなら1.2Bや2.7Bだ。効率の優位は小型帯ほど出やすいので、用途が許すなら小さいサイズから試し、精度が足りなければ上げる進め方が無駄が少ない。

まとめ

Zamba2-VLは、視覚言語モデルの言語側をMamba2主体のハイブリッドに置き換え、長いプリフィルでのTTFTを抑えることに焦点を当てた、Apache 2.0の軽量VLMファミリーだ。精度は同規模の強い競合に数ポイント届かない指標が多いものの、カウント（とくにPixMoCount）では強みを見せ、何より速さと効率で差をつける。「TTFTが約一桁低い」という主張は32kプリフィル・バックボーン単体という条件込みで読むべきで、文脈長が4kに制限される点、導入に専用環境が要る点と合わせて、得意と不得意がはっきりしたモデルだといえる。限られた資源で軽量VLMを多数回回す、初回応答の速さが効く、といった条件に当てはまるなら、特に1.2B・2.7Bの小型帯が検討に値する。

参考資料

• Hugging Face — Zyphra/Zamba2-VL-7B（仕様・依存環境・ライセンス・ベンチマーク）
• Hugging Face — Zyphra/Zamba2-VL-2.7B（小型帯の仕様）