Moondream 3.1 9B A2B vs North Micro Vision Instruct：実際に数字を確認できるのは、どちらのベンダーか

4か月違いで登場した2つのオープンなビジョンモデルは、どのように評価されたいかという点でほとんど共通点がない。M​oondream 3.1 9B A2Bは2026年7月7日に、ベンチマーク表と、単一のH100 SXM5およびバッチサイズ16を記載した方法論フッター、そしてベンチマークは顧客が実際に必要とするものを測定していないという、同じ投稿を貫く主張とともにローンチした。North Micro Vision Instructは、Apache 2.0の下で2.4Bパラメータで、2026年8月12日にC​ohere Labsから登場し、そのリリース投稿は、トレーニングカリキュラムと評価設定——使用されたハーネス、そして数値が生成されたときの正確なサンプリングパラメータ——にその紙幅を費やしている。

それは種類の違いであり、どちらのモデルのパラメータ数よりも買い手にとって有用だ。一方のベンダーは、自社の表を再現する方法を教えている。もう一方は、表を信用するなと言っておきながら、表を公表している。我々が調べた限りでは、どちらも独立に評価されていない。したがって、どちらの数値群に頼るべきかを本当に決める問いは、どちらのベンダーがあなたに検証できるものをどれだけ与えたかである。

それぞれが何か

Moondream 3.1 9B A2B はスパースな Mixture-of-Experts 視覚言語モデルです。総パラメータ数は 9B、トークンあたり 2B がアクティブ、64 のエキスパートのうち 8 がアクティブで、マルチクロップ チャネル連結を備えた SigLIP 視覚エンコーダ、32K トークンのコンテキスト、SuperBPE トークナイザーを採用しています。その 4 つのスキル — クエリ、検出、ポインティング、キャプション — はプロンプトで与えられるのではなく学習によって獲得されており、検出とポインティングの経路は説明ではなく構造化されたジオメトリを返します。これはベンダーの推論エンジンである Photon 上で動作し、Ampere 以降の NVIDIA GPU と Apple Silicon をターゲットにしています。

North Micro Vision Instructは、3つの部分から構築された2.4Bのdenseモデルです。GoogleのSigLIP 2 SO400Mチェックポイントからさらに事前学習された400Mのネイティブ解像度ビジョンエンコーダ、複数のエンコーダ層からのパッチ埋め込みを言語モデルの初期層に注入するDeepStackパターンに従うプロジェクタ、そしてCohereのCommand A+アーキテクチャに従うNorth Micro LLMという2B言語モデルです。インターリーブされたテキストと画像（1枚または複数枚）を入力として受け取り、テキストを出力します。トークナイザの語彙数は262,144で、記載されている言語は11に「その他多数」を加えたものに及びます。

出力タイプの違いは、その後に続く内容を形作るため、はっきり述べておく価値がある。Moondreamはボックスと座標で答える知覚モデルであり、North Micro Visionは言語で答える理解モデルである。どちらのベンダーが公表するものも、これら2つの仕事のいずれかを測定したものであり、両者は同じ仕事ではない。

モデルのコンテキストウィンドウではない8Kという数字

まずはその罠から始めよう。というのも、それはNorth Micro Visionのモデルカードのど真ん中に居座っていて、うっかりするとアーキテクチャの意思決定に紛れ込んでしまう類いのものだからだ。

• North Micro Vision Instruct — 言語バックボーンのコンテキストウィンドウは128,000トークン。検証済みのマルチモーダル動作範囲は最大8,000トークン。カードには、より長いマルチモーダルコンテキストは外挿に依存する可能性があり、ベンチマークされていないと明記されている。

• {{1}}Moondream 3.1 9B A2B{{/1}} — {{2}}32,000トークン、数字は1つ、モダリティ別の内訳は公開されていない。{{/2}}

つまり、見出しの数字では North Micro Vision の方が4倍有利で、実際にあなたの画像ワークロードに当てはまる数字では M​oondream の方が4倍有利になります。スキャンした文書が1回の呼び出しで何ページ収まるかを見積もるなら、128K は間違った数字で、8K が正しい数字です。そして、ネイティブ解像度エンコーダーがピクセル面積に比例してトークンを出し始めると、画像とテキストが交互に並んだ8Kトークンは、多くのページにはなりません。ベンダーがこの注意書きを公開したことは評価に値します——ほとんどのカードならそうしないでしょう——しかし、その注意書きは仕様表の下に埋もれており、コピーされるのはその表なのです。

2社の報告方法を並べて比較

これが、モデルとは何の関係もなく、どちらを監査できるかという点にすべてがかかっている比較の部分です。

Moondreamの3.1の投稿では、そのベースライン（Qwen3.5 9B、SAM 3、LocateAnything、Gemma 4 12B）、指標（検出におけるF1@0.5）、ハードウェア（H100 SXM5 1台）、バッチサイズ（16）、そして各モデルがそれぞれ独自のエンジンで提供されたことが述べられている — LocateAnything、Qwen3.5、Gemma 4にはvLLM、MoondreamにはPhoton、SAM 3にはHugging Face Transformers。また、モデルごとに最高精度および推論設定が選択され、LocateAnythingは精度を最大化するために低速モードで実行されたとも述べている。公開されている結果は、COCO valで81.46 F1@0.5、ODinW-13で93.94、LVISで67.4、Dense200で74.61、SKU-110Kで52.77、CrowdHumanで74.5、RefCOCO-Mで87.1、HumanRefで70.39、DOTA-v2で59.63、CountBenchで90.35、TallyQAで74.86、PixMo-Countで88.68、ChartQAで86.01、DocVQAで88.6であり、5つのベンチマークファミリーで最先端を主張している。

そのフッターに欠けているのは、結果を再現可能にするもの、つまりプロンプトだ。検出はオープンボキャブラリのタスクであり、あるものをどんなフレーズで問い合わせるかによって、返ってくるものが変わる。再実行する人が評価指標、ハードウェア、バッチサイズを手にしていても、各ボックスを生成したテキストが何かを知らなければ、その数値を再現することはできない。

Cohere Labsの投稿は別のアプローチを取っている。ハーネス（VLMEvalKit）を明記し、モデルは内部のvLLM実装で評価されたと述べ、各能力グループのベンチマーク構成を列挙している——General VQAはMMBench、MMStar、RealWorldQA、GQAの平均であり、チャート、ドキュメント、OCRグループはChartQA、DocVQA、InfoVQA、OCRBench、OCRBench v2、AI2Dをカバーし、グラウンディングとカウンティングはRefCOCO平均とCountBenchである——そして数値が生成されたときのサンプリングパラメータを公開している：temperature 0.7、top_p 0.8、top_k 20、min_p 0.0、presence_penalty 1.5、repetition_penalty 1.0。また、公開vLLMサポートは「coming soon」であると注記しており、これは再現を計画している人なら誰にとっても最も重要な正直な開示だ。つまり、モデルはフォーク上でテストされたのである。

あの投稿が公開していないのは、ベンチマークごとの表だ。その結果は能力グループ別の平均と相対的な主張である——Instructモードでは、35B-A3BはQwen3.6 35B-A3Bより短い推論時間で高いスコアを出し、1B版はスコアと効率の両方でQwen3.5 0.8Bを上回る——これはすぐには引用しにくく、チェリーピッキングに対してより頑健だ。どちらの文書も、他ベンダーの数値を再計算できるようにはしていない。どちらも、どれだけ隠しているかを見せてくれる。

アーキテクチャの違いが実践で現れる場面

ネイティブ解像度は、North Micro Vision において日々の業務を変える唯一の設計上の決定であり、ベンチマーク表を読む前に理解しておく価値があります。ほとんどの視覚エンコーダーは、与えられたものを固定の正方形にリサイズします。そのため、横長のスプレッドシートのスクリーンショットは、列が押しつぶされた状態で言語モデルに届きます。North Micro Vision のエンコーダーは、画像を本来の解像度とアスペクト比のまま取り込むように訓練されており、文書、表、グラフ、フォームの細かなディテールを保持します。公開されたカリキュラムは、1000万例による固定の384×384ステージから、1300万例以上による1024×1024ステージへと進みました。

Moondreamのエンコーダーは代わりにマルチクロップに基づいている。画像は、特徴が連結されるクロップの集合として扱われ、これは大きな入力でディテールを保持する方法でもあり、その検出ヘッドがボックスを生成する方法と結びついている。どちらも同じ問題に対する正当な答えであり、どちらのベンダーも同一解像度での直接比較を公表していない。したがって、このアーキテクチャの議論から得られる有用なものは、判定よりも狭い。もしあなたの作業が高密度な文書や横長のUIスクリーンショットを対象とするなら、テストすべき特性はネイティブ解像度であり、そのテストはベンチマークの1行ではなく、あなた自身のスクリーンショットで行うものだ。

もう一つの構造上の違いは、マルチ画像と動画です。North Micro Vision Instructはインターリーブされたマルチ画像入力に対応し、評価したグループの中にマルチ画像ベンチマークを挙げています。Moondream 3.1 9B A2Bは1回の呼び出しにつき1枚の画像に限定されています——動画の経路も、マルチ画像の経路もありません。これはその設計と一致しています。ライブ動画に関するMoondream自身のエンジニアリング記事は、問題はモデルの能力ではなく推論の配管にあると論じており、時間的なワークロードに対する同社の答えは、1枚を飲み込むチェックポイントではなく、ストリームに追随するエンジンです。それが128フレームを一度に受け取るモデルより優れた答えなのかは、正直なところ未解決の問いであり、両ベンダーは同じものを測っているわけではありません。

デプロイとライセンス、手短に。

• サイズ — 合計9B／アクティブ2B 対 2.4B dense。ストレージの観点では、その差はアクティブパラメータ比が示唆するよりも大きい。なぜなら、スパースモデルのフットプリントは総パラメータ数に連動するからだ。

• ファインチューニングの規模 — 2.4Bの密なモデルは単一デバイスでファインチューニングできるほど小さく、9BのスパースモデルはLoRA以上のことをするなら本格的なトレーニング環境が必要になる。だからこそMoondream自身のチューニング手法はホスト型プロダクトを経由していた。

• ランタイム — North Micro Vision Instruct は Transformers 5.16.0 と accelerate、Pillow を要求します。コミュニティによる量子化版は MLX、LiteRT、および ONNX 系フォーマットで存在します。M​oondream 3.1 9B A2B は Photon 上で動作し、そのチェックポイントの初のサードパーティ製 GGUF パッケージングは 2026年10月15日に登場します。

• ライセンス — North Micro Vision Instruct は Apache 2.0 で、しきい値はなく、他者向けにホスティングするうえでの制限もありません。M​oondream 3.1 9B A2B には M​oondream Model License 1.0 が適用されます。商用利用、セルフホスティング、ファインチューニング、量子化、再配布はいずれも許可されていますが、禁止事項が 1 つあります — 汎用の M​oondream 推論またはファインチューニングをホスト型サービスとして提供してはなりません。

チャーン — North Micro Vision Instruct はリリース以来変化がなく、最近の注目すべき追加はサードパーティによる量子化です。Moondream の規約はこの2週間でその足元で変わりました。Prime Intellect は2026年10月13日に同社を買収し、Lens ファインチューニング製品を含む Moondream Cloud は2026年11月13日に終了します。重みと Photon は影響を受けませんが、ホスト型の経路は影響を受けます。

パイプラインの2番目のモデル、そしてそれをルーティングするのは誰か

これらのチェックポイントはいずれもOrcaRouterでは提供されていないので、これは統合に関する補足として読んでください。どちらも単一ステージのコンポーネントです。一方はボックスを返し、もう一方はテキストを返します。そして本番システムでは、その観測結果が何を意味するかを判断し、それを書き記すために、これらの背後にモデルが必要です。そのステージはテキストステージであり、通常はビジョンステージよりも1回あたりのコストが高く、より安価またはより優れた推論モデルが登場したときに真っ先に差し替えたくなるステージです。その差し替えを200を超えるモデルにまたがる単一のOpenAI互換エンドポイント — プロバイダーのリスト価格を0%のマークアップでそのまま反映し、上流が不調なときにはプロバイダー間で自動フェイルオーバーする — を通じて行えば、カメラを配線し直すのではなく、モデル識別子を変更するだけで済みます。1つの意見では足りない場合、モデルフュージョンが同じ入力に対してモデルのパネルを実行し、ルーティングDSLが複数のモデルを1回の呼び出しにまとめ上げます。

もう少し具体的に言える点が一つあり、それがどちらに転ぶかについては正直に話しておく価値がある。North Micro Vision Instruct は Apache 2.0 で、手持ちのハードウェアで動かせるほど小さい。つまり、ビジョンモデルをホスト型エンドポイント経由で回すときによく挙げられる論拠——自分ではホストできない——は当てはまらない。残る論拠はごく普通のものだ。ループに第二のモデルを入れ、同じキーを使い、請求は一つ、認証情報も一つで済む。

どちらを選ぶべきか、そして何が答えを変えるのか

文書、表、グラフ、画面を読む場合、1回の呼び出しで複数の画像が必要な場合、ほかの人たちのためにモデルをホストするつもりで Apache 2.0 が重要な場合、あるいは自分のデータでファインチューニングできる 2.4B チェックポイントが欲しい場合は、North Micro Vision Instruct を選んでください。C​ohere のモデルカードはファインチューニングを想定用途として示しており、ライセンスは妨げになるものではありません。

M​oondream 3.1 9B A2B は、出力がジオメトリ — ボックス、座標、インスタンスが紐づいたカウント — で、デプロイ環境が Photon を載せた CUDA マシンなら選びましょう。このモデルは特化型で、その速度の主張はまさにそのワークロードを狙っています。

両方にとって答えを変えるのは独立した評価であり、それは注視し続けるべきものだ。どちらのベンダーの数値もベンダー外部では再現されておらず、しかもそれぞれ、再現を必要以上に難しくする条件で公表している。一方はプロンプトを公開せず、もう一方は、公式サポートがまだ保留中のフレームワークの内部サービング実装上で実行した。第三者が同じ文書セットでどちらかのチェックポイントを走らせたとき、その接触を経ても表がそのまま残ったモデルこそ、信じるに値する——そしてそれまでは、どう測定したかを教えてくれたベンダーのほうが、議論しやすい。

このような結果は、このクラスのモデルの背後にあるAIインシデントやエージェントの失敗がすでに記録されているという事実を思い起こさせるものでもある。それらはOrcaRouter AI Incident Archiveにまとめられており、各項目には独自の情報源、重大度、信頼度評価、異議ありフラグが付されている。