【実測】1.74GB の小モデルに、自分の非公開コードを読ませてみた ―― VibeThinker-3B にできること・できないこと
1.74GBのVibeThinker-3Bを自分の非公開コードで実測。解答エンジンとしては本物、だがエージェントではない。
1.74GB のモデルが「AIME 94.3、LiveCodeBench 80.2」と謳っています。
桁違いに大きいフラッグシップと張り合う、という触れ込みです。
本当でしょうか。
私は、数字を引用するだけでは信じませんでした。
手元の Apple M5 で、暗記できないはずの問題と、私自身の非公開コードを食わせて、自分で確かめました。
結論を先に言います。
解くこと・コードを読むことは、本当に強い。でもこれは「解答エンジン」であって「エージェント」ではありません。 タスクが深く長くなると、崩れます。
これは何か
VibeThinker-3B（WeiboAI）です。
作ったのは、Sina Weibo の AI チームです。聞き慣れないかもしれません。
狙いは一点に絞られています。「小さなモデルで、検証可能な推論をどこまで伸ばせるか」。
論文のタイトルが、そのまま主張です ―― Exploring the Frontier of Verifiable Reasoning in Small Language Models。
ふつう、3B クラスの小モデルは「そこそこ何でもこなす汎用アシスタント」を目指します。
VibeThinker は逆でした。数学とコードという、答え合わせができる領域に全振りしています。
その結果が、冒頭の数字です。3B でありながら、桁違いに大きい DeepSeek V3.2 や GLM-5、Gemini 3 Pro と張り合うスコアを出し、「3B でそんなはずがない」とベンチマーク界隈で議論を呼びました。
そして、重みも訓練コードも公開されています。だからこそ、こうして手元に落として確かめられます。
ベースは Qwen2.5-Coder-3B → Qwen2.5-3B。つまりコード系ベースの推論特化モデルです。
4bit 量子化で 1.74GB。手元の M5 で 約45〜63 tok/s、完全にローカル・無料・オフラインで動きます。
from mlx_lm import load, generate
model, tok = load("mlx-community/VibeThinker-3B-4bit") # 1.74GB
ハードについて一言だけ。
M5 は GPU の各コアに Neural Accelerator を積んでいて、MLX はその GPU（Metal） を使います。
16コアの Neural Engine（ANE）は、Core ML 用で、Transformer の LLM 推論には使われません。
だから「M5 で速い」のは GPU の力です。そして 3-4B/4bit は、そもそも端末を選びません。
まず、他人が測った数字
汚染対策済みのベンチだけ見ます。
- LiveCodeBench v6：80.2（コード。モデルの学習打ち切り後に公開された新問題だけを使う＝暗記不能）
- AIME26：94.3（数学）
- 未公開 LeetCode（2026年）：96.1%
3B がこの数字を出すのは、確かに目を引きます。
でも、これは他人が測った数字です。だから私は次に、自分で確かめました。
vs 通用モデル（Google Gemma 4）
ここで一つ、比較しておきます。
同じ ~3-4B クラスの、Google の汎用小モデル Gemma 4 E4B と並べると、こうです。
| VibeThinker-3B | Gemma 4 E4B | |
|---|---|---|
| AIME26（数学） | 94.3 | 約42.5 |
| LiveCodeBench v6（コード） | 80.2 | 約52.0 |
推論とコードに限れば、1.74GB の専門特化が、Google の小モデルを2倍近く突き放しています。
ただし、ここで正直に線を引きます。
私が比べたのは、推論とコードのベンチの数字だけです。
Gemma の汎用性能（画像・日本語・指示追従）は、私自身ではまだ測っていません。 だから「汎用なら Gemma が上」とは、ここでは言いません。それは未検証の決めつけになります。
言えるのは、設計上の位置づけと、VibeThinker 側で実際に見たことだけです。
- 設計：Gemma 4 は多モーダル・多言語の汎用モデル（画像も入力できる）。VibeThinker は推論/コードの特化モデルで、画像は扱えません。
- 観測：VibeThinker の「特化ゆえの弱さ」は、私が直接見ました。日本語で常識を問うと別の問題（微分）を解き始め、JSON で出せと頼んでも出さず、長い追跡では崩れました。
つまり、「数学・コードを解かせる」なら VibeThinker は強い。一方で汎用用途は VibeThinker の弱点であり、そこを Gemma 等の汎用モデルが担うのが自然――ただし「汎用で Gemma がどれだけ強いか」は、私が別途測るべき宿題です。
（VibeThinker のベンチは公式論文、Gemma の数字は二次情報で、Google 公式の裏取りは継続中です。）
コード：暗記できない自作問題を、実行して確かめた
定番の LeetCode 問題は使いませんでした。
ネットに転がっている問題は、モデルが暗記している可能性があるからです。
そこで、私がその場で作った、世の中に存在しないオリジナル問題を 5 題出しました。ルールも独自です。
各問題、私の参照実装＋ランダム・境界ケースで、生成コードを実際に実行して採点しました。
例えば、私が勝手に決めたこのルール。
encode(s): 同じ文字の連続が3個以上なら「文字＋個数」に、
1〜2個ならそのまま。'aaabbc' -> 'a3bbc'
結果は、ロジック 5/5 正解でした。
| 自作問題 | 結果 |
|---|---|
| encode（自作RLE≥3） | ✓ 13/13 |
| fib_index_sum（フィボナッチ番目の和） | ✓ 10/10 |
| expand（自作展開） | ✓ 10/10 |
| longest_alt（最長の正負交互部分列） | ✓ 12/12 |
| score（母音は2倍で採点） | ✓ ロジック正解 |
「最長の正負交互部分列」のような、少し頭を使う問題も、全ケース通しました。
暗記ではありません。見たことのない問題を、本当に解いています。
LiveCodeBench 80.2 という数字が、手元で腑に落ちました。
私の非公開コードを、読ませてみた
ここが、今回いちばん確かめたかったことです。
私は yuewei という個人の情報システムを運用しています。
そのコードは公開していません。モデルが学習している可能性は、ゼロです。
まず、assess_article_signal という実際の関数を 1 つ渡し、制御フローを問いました。
「どの条件で『高シグナルなし』と判定するか」「ある記事ではどの kind と confidence になるか」「分岐の優先順位は」。
3問とも正解でした。「いったん industry_dynamic に落ちてから、karpathy と anthropic の条件で上書きされ 0.96 になる」という、込み入った流れまで追い切りました。
次に、負荷を上げます。
モジュール全体（signals.py、約4000トークン、キーワード辞書も全部込み）を渡し、具体的な記事3件について出力を予測させました。
答え合わせは、実際にそのコードを走らせた結果と照合しました。
3件とも完全正解。
しかも、account_name が特定の集合に入ると confidence が 0.92 になる、という地味な罠まで当てました。
集中した実コードであれば、読んで、追って、具体的な入力に正しく当てはめられる。これは見ていて、素直にすごいと思いました。
どこで壊れるか
ここからが、正直な話です。
さらに負荷を上げ、3ファイル（signals + screener + analyzer、約18000トークン）を渡し、ファイルをまたぐ追跡をさせました。
崩れました。
「その箇所を探そう…その箇所には…でも読まないと…」という繰り返しループに陥り、9000トークンを使い切って、答えを出しませんでした。
公式推奨の temp=0.6 でも、です。
原因を切り分けました。
| 条件 | 結果 |
|---|---|
| 大コンテキスト(18K) ＋ 簡単な質問 | ✅ 平然と正解 |
| 小コンテキスト(6.8K) ＋ 深い多段追跡 | ❌ 崩壊 |
つまり、犯人はコンテキストの「量」ではありません。
18K 入れても、聞くことが簡単なら平気でした。
6.8K でも、推論チェーンが長く複雑だと崩れました。
犯人は「推論の長さ・複雑さ」です。 窓が128Kあっても、安定して使える作業記憶は、ずっと小さい。
もう一つ、エージェント的に致命的な弱点があります。
JSON で出せと頼んでも、延々と推論して出しません。
関数名を score と指定したのに、calculate_score と名付けます。
指示やフォーマットを、素直に守らない。
（補足：greedy デコードは偽の崩壊＝復読を誘発しました。推奨の temp=0.6 で多くは直りますが、最も重い負荷では依然崩れます。評価の設定で結論が変わる、という教訓でした。）
では、ローカルで何に使えるのか
適材適所で言います。
向いていること：
- 自己完結した問題を解くローカルエンジン（アルゴリズム・数学・コード）。
- 集中したコード片の説明・レビュー・トレース（1関数、1モジュールなら正確）。
- パイプラインの「解答部品」。外側が小さく明確な部分問題を渡し、出力を検証する使い方。
オフライン・無料・秘匿が要る場面で、特に効きます。
向いていないこと：
- 自律エージェント / ツール呼び出しの司令塔（フォーマットを守らず、脱線し、長丁場で崩れる）。
- リポジトリ丸ごと / 大規模なファイル横断改修。
- 日常の汎用チャット（これは解答脳であって、アシスタントではありません）。
これは、ローカルAIコーディングを実測した Vicki Boykis の見立て――ローカルは「部品」、オーケストレーションやツールは外側――と、そのまま地続きです。
一文でまとめます。
VibeThinker-3B は、強いローカルの「解答脳」です。切って、正確に渡せば強い。大局や、膨らんでいくコンテキストを丸投げすると、崩れます。
正直な限界
- 自作問題は数題、私の手元実測です。公開ベンチの代わりにはなりません。能力の「数字」は LiveCodeBench / AIME を見るべきです。
- 4bit 量子化版での結果です。
- 崩壊は temp=0.6 単発の観測も含みます。サンプリングには揺れがあります。
- Gemma の比較値は二次情報で、公式裏取りは継続中です。
それでも、方向ははっきりしました。
「賢い」と「エージェントになれる」は、別の話です。 1.74GB のこのモデルは、前者では本物でした。後者は、まだ別の道具の仕事です。
検証環境：Apple M5 / MLX / mlx-community VibeThinker-3B-4bit。コード採点は生成コードを実行し、私の参照実装と照合。コード理解は私の非公開リポジトリ yuewei の実コードを使用。
―― AI未来編集室「AIウォッチ」
← 一覧へ