はじめに
「総パラメータ7.9B、実際に動くのはたった1.3Bだけ」——そんな触れ込みのモデル、Ling-3.0-tiny(InclusionAI/Ant Group)がnoteの記事で紹介されているのを見かけた。本番で動かしているOrnith-1.0-9B(9B dense、詳細は前回記事参照)よりずっと軽いのに、Apple Silicon Macで秒間86〜90トークンという速度が出ると聞けば、気になるのが人情というものだ。
「パラメータ数が少ない=賢さも劣る」と決めつけるのは早計、というのは前回記事でOrnith-9BがQwen3.6-27Bを打ち負かした実例で身をもって学んだ。今回はその再現があるか、実際に同じ質問をぶつけて確かめた記録である。
結論を先に言うと、今回は再現しなかった。ただし「なぜ負けたのか」「どこまでなら救えたのか」を丁寧に切り分けたところ、reasoning系モデルを評価するときに初心者が引っかかりやすい罠がいくつも見えてきたので、それも含めて書く。
環境: WSL2 Ubuntu, RTX 5070 ×2 (12GB×2)、Ornith-9BはSonar(Aphrodite Engine)本番環境を直接使用。Ling-3.0-tinyはAphroditeが対応する新アーキテクチャ(後述)をまだ持っていないため、OpenRouterの無料枠経由(提供元: Novita)で検証した。
そもそも何と何を比べるのか(初心者向け)
| Ornith-1.0-9B | Ling-3.0-tiny | |
|---|---|---|
| アーキテクチャ | Dense(全パラメータが常に働く) | MoE(専門家の一部だけが働く) |
| 総パラメータ | 9B | 7.9B |
| 実際に計算に使うパラメータ | 9B(Denseなので全部) | 1.3B(512人の専門家のうち8人+共有1人だけ選んで使う) |
| コンテキスト長 | 262,144トークン | 256,000トークン |
| 公開時期 | (既存モデル、EXL3量子化6bpwで運用中) | 2026年8月6日(検証時点でリリース6日) |
MoE(Mixture of Experts)というのは、「専門家集団を大量に用意しておいて、質問ごとに得意そうな専門家だけを選んで答えさせる」という仕組みだ。Ling-3.0-tinyで言えば、512人の専門家のうち実際に呼ばれるのはたった8人+全問共通の1人だけ。だから「総パラメータ7.9B」という数字よりずっと軽く、速く動く……はずだった。
検証方法(最初にやらかした話も含めて)
最初、Ling-3.0-tinyにシステムプロンプトなしで質問を投げて、Ornith-9Bの実運用結果と比べようとした。これは典型的なフェアでない比較だった。Ornith-9B側は本番投入までに言語ルールや推奨サンプリングパラメータを何ヶ月もかけてチューニング済みなのに、Ling-3.0-tinyは素のままだったからだ。
条件を揃え直した。最終的な検証条件:
- システムプロンプト: 両モデルに同じ言語ルール(「日本語と英語のみ使用可、中国語は厳格禁止」という趣旨の文言。詳細は後述)を投入
-
サンプリングパラメータ: それぞれの公式モデルカードが推奨する値を採用
- Ornith-9B:
temperature=0.6, top_p=0.95, top_k=20 - Ling-3.0-tiny:
temperature=1.0, top_p=0.95, top_k=20
- Ornith-9B:
- 同一の質問文をそのまま両方に投げる
対決結果
4種類の難問(論理パズル・デバッグ・日本語の歴史知識・制約付きコーディング)を同条件でぶつけた。
| テスト | Ornith-9B | Ling-3.0-tiny |
|---|---|---|
| 論理パズル(確率の罠問題) | ✅ 42.5秒、正しい手順で完答 | ❌ 手元のトークン予算をすべて「思考」に使い切り、回答本文が一度も出ないまま打ち切り |
| デバッグ(移動平均のバグ) | ✅ 15.0秒、原因の表を作って説明、正しい修正コード | ⚠️ 条件によっては正答するが、条件次第で同じく思考だけで打ち切られることもある |
| 日本語の歴史知識(大政奉還/王政復古) | ✅ 時系列(1867年9月→1868年1月)も概ね正確 | ❌ 完全な捏造(下記参照) |
| 制約付きコーディング(HTTPS POST、特定ライブラリ禁止) | ✅ 指定通り禁止ライブラリを避けて実装 | ❌ 禁止したライブラリを2回とも普通に使用 |
一番驚いた実例: 歴史的事実の捏造
「大政奉還と王政復古の大号令、それぞれ誰が主導したか」と聞いたときのLing-3.0-tinyの回答(思考の中身)がこれだ。
- 大政奉還：1868年（明治元年）の戊辰戦争を経て、鶴間藩と京都の支持を得た明治維新の指導者たち（井上馨、木戸嘉才、岡本正邦など）によって主導されました。
- 王政復古：1930年代から1940年代にかけて、右翼政治系の勢力（石田琢磨、昭和制憲会など）によって主導されました。
大政奉還は1867年、王政復古の大号令はその4ヶ月後の1868年、どちらも明治維新の出来事だ。それを一方は江戸幕末、もう一方はまるまる70年後の昭和初期の右翼運動として説明してしまっている。人物名も実在しないか無関係な人物ばかりだった。単なる誤字レベルの話ではなく、**時代ごと丸ごと取り違えた幻覚(ハルシネーション)**だった。
対するOrnith-9Bの同じ質問への回答:
| 事件 | 主導者 | 時期 |
|---|---|---|
| 大政奉還 | 大久保利通・木戸孝允が中心 | 1867年9月13日 |
| 王政復古の大号令 | 大久保利通・西郷隆盛・大木喬任・木戸孝允ら | 1868年1月3日 |
多少の粒度の粗さ(実際の主導者は徳川慶喜自身であり薩長は後押しした側、という細かい解釈の余地はある)はあるものの、時代・人物とも実在の範囲に収まっている。
制約を無視する問題
「requestsもurllib.requestもhttp.clientも使わずにHTTPS POSTを送るコードを書いて」という、あえて意地悪な制約付き問題も出した。Ling-3.0-tinyは2回とも、禁止したはずのhttp.clientを堂々と使ったコードを返してきた。Ornith-9Bはsocket+ssl+urllib.parse(パース専用なので許容範囲)という、指定通りの低レベル実装で応えた。
なぜここまで差がついたのか
罠その1: 「思考」も回答の一部としてトークン予算を消費する
reasoning系モデル(思考してから答えるタイプのモデル)は、ユーザーに見える最終回答を出す前に、頭の中で長々と考える。この「思考」も裏側では普通にトークンを生成しており、max_tokens(1回の応答で生成できるトークン数の上限)を消費する。
Ling-3.0-tinyは、難しい問題に当たるとこの思考だけで予算を使い切り、最終回答を一度も出力しないまま打ち切られることが何度もあった。1500トークンで打ち切られたときはもちろん、6000トークンに増やしても、4000トークンに増やしても、問題によっては同じことが起きた。予算を増やせば直る「単に冗長なだけ」の問題ではなく、考え始めると結論に辿り着けずに発散してしまうという、もっと根深い不安定さだった。
Ornith-9Bも実は過去に全く同じ問題を踏んでいる。前回記事で書いた通り、本番投入直後に「複雑なプロンプト3問中2問が6000トークンいっぱいまで思考し続けて回答を一度も出力できない」という不具合が見つかり、thinking_token_budget=4000(思考にトークンレベルで強制的に上限をかける、Aphrodite/vLLMの既存機能)を安全網として本番導入した経緯がある。Ling-3.0-tinyには、この種の安全網がまだ何も入っていない、素の状態だったわけだ。
罠その2: システムプロンプトを揃えても直らないものがある
検証の後半で、Ornith-9B本番で使っている言語ルール(後述)をLing-3.0-tinyにも投入してみた。
あなたは優秀な日本人の秘書です。言葉遣いはとても丁寧です。
あなたはバイリンガルアシスタントです。使用できる言語は「日本語」と「英語」のみです。
ただし英語は my, me のような基本的な単語のみ使用してください。
中国語を含む日本語・英語以外の言語での出力は厳格に禁止されています。
このプロンプトを入れると、「回答が丸ごと中国語になる」現象は完全に消えた。効果てきめんだった。一方で、「思考が発散して回答に辿り着けない」問題と「歴史的事実の捏造」は、このプロンプトを入れても入れなくても変わらなかった。
ここから学べるのは、「プロンプトや後処理で直せる不具合」と「モデル自体の地力が原因で直せない不具合」は別物だ、ということ。今回で言えば:
- 言語の混入 → プロンプトや後処理(次章)で軽減できる
- 思考の発散・事実の捏造 → モデル自体の課題で、外側からの工夫では埋められない
Ornith-9B側の不具合、どうやって見つけて直したか(初心者向け解説)
ここからは「なぜOrnith-9Bはこの手の不具合に強いのか」の答え合わせとして、本番投入後に実際に踏んだバグとその直し方を、初心者にもわかるように振り返る(詳細な調査過程は前回記事に詳しい)。
バグA: 漢字が中国語の字体に化ける
Qwen系のモデルによくある現象で、日本語で正しく文章を書いているのに、時々1文字だけ中国語の簡体字(画数を省略した字体)が混じる。たとえば「郷」と書くべきところが「乡」になる、といった具合だ。実測では9Bクラスのモデルで0.4〜1.7%程度の確率で起きる、業界的にもよく知られた癖らしい。
直し方: サンプリング設定やプロンプトでは消せなかったので、生成された文章を後から機械的に直す方式を採用した。「簡体字を、対応する日本語の正しい漢字に変換する辞書」を用意し、出力の最後に必ず通す。今回の検証でこの仕組みを実際に「西乡隆盛」という誤字に対して試したところ、綺麗に「西郷隆盛」へ直った。ただし、これはあくまで1文字単位の字体の入れ替えにすぎない。今回Ling-3.0-tinyで見つかった「文章が丸ごと中国語になる」現象に同じ仕組みを試したところ、「错误」→「錯誤」のように字体だけは直っても、中国語の文法や助詞(「的」「了」など)はそのまま残ってしまい、日本語としては全く成立しない文章になった。単発の誤字を直す道具であって、言語そのものが入れ替わる不具合には無力、ということが今回の検証で改めて確認できた。
バグB: 考えすぎて答えが出せなくなる
前述の通り、思考が発散して最終回答が一度も出ないまま打ち切られる現象。直し方は単純で、「思考に使えるトークン数」自体に上限を設ける(thinking_token_budget)。これにより、思考が長引きすぎたら強制的に打ち切って、残りのトークンを本来の回答に回させる。根本的に「発散しない賢いモデルにする」わけではなく、あくまで「発散しても実害を最小限にする」という対症療法だが、実運用上はこれで十分効果があった。
バグC: 「禁止すればするほど悪化する」プロンプトの罠
これは前回記事で一番面白かった発見なので改めて紹介したい。Ornith-9Bの思考の中に、時々中国語の語彙(「也不需要」「即可」など)が混ざる不具合があった。素直に「中国語は禁止」という文言を強めていったところ、発生率はむしろ悪化した(2.5%→5.0%)。
種明かしはこうだ。何も指示しないと、このモデルは思考を英語で行う癖がある。「日本語だけを使え」と禁止を強めるほど、モデルは「日本語でも英語でもない、微妙な状態」に追い込まれ、逃げ場を失って中国語に転げ落ちやすくなる。逆に「日本語+ちょっとだけ英語もOK(my, meのような基本語のみ)」という逃げ道を用意してあげると、発生率が0.4〜1.7%まで下がった。1,440回超の試行で確かめた結果なので、まぐれではない。
「厳しく縛れば縛るほど良い」という直感は、AIの挙動に関しては必ずしも正しくない。今回Ling-3.0-tinyの検証でこの知見(逃げ道ありの言語ルール)をそのまま使い回せたのも、この過去の泥沼のおかげだった。
量子化について、正直に書いておくこと
今回Ling-3.0-tinyはOpenRouterの無料枠(提供元Novita)経由で検証した。この枠がどの精度(量子化レベル)でモデルを動かしているかは、OpenRouterのAPI上でも "quantization": "unknown" としか出てこず、確認できなかった。無料提供という都合上、何らかの軽量化がかかっている可能性はある。
ただし今回の検証の目的は「今すぐ実際に使えるかどうか」であり、その観点では「無料枠経由で確認できる実力がこれ」という結果自体には意味がある。逆に言えば、もし将来フル精度版で再検証して結果が変わるようなら、それはそれで追記したい。
AphroditeへBailingMoE V3(Ling-3.0系アーキ)を移植する話は?
実はLing-3.0-tinyが使う新しいアーキテクチャ(BailingMoeV3、KDA:MLA混合注意機構)は、vLLM本家にはすでにマージ済みだが、今のPCで使っているAphrodite-engine(vLLMのフォーク)にはまだ来ていない。ソースコードを突き合わせたところ、必要な低レベル部品(線形アテンションのtritonカーネル等)はAphrodite側に既にベンダリング済みで、新規CUDAカーネルを書く必要はなく、Pythonファイルの移植だけで済みそう(importの94%がそのまま名前空間変換だけで通った)ということまで確認できた。
技術的には「週末プロジェクト」レベルで実現できそうだったが、今回の検証結果を見て、移植の労力に見合う価値は今のところ無いと判断し見送った。技術的可能性と採用の判断は別、という当たり前の話だが、手を動かす前に検証しておいて良かったと思う。
まとめ
- 「総パラメータ7.9B、実働1.3B」という軽さの触れ込みだけで判断せず、実際に難しい問題を投げて確かめたら、Ornith-9Bに全項目で負けた
- reasoning系モデルは「思考」もトークン予算を食うため、難問で思考が発散すると最終回答が一度も出ないまま打ち切られることがある。パラメータ数が少なくても、この罠には普通に嵌まる
- システムプロンプトで直せる不具合(言語の混入)と、直せない不具合(思考の発散・事実の捏造)がある。プロンプトを整えて再検証したことで、この切り分けができた
- Ornith-9B側が過去に踏んだのと同種の不具合(簡体字混入・思考発散・言語混入)を比較対象として持っていたおかげで、「何が対策可能で何が対策不可能か」を素早く判断できた。過去の泥沼調査が今回の検証の物差しになった
- 後処理(簡体字→正しい字体への変換)は「1文字単位の字体の誤り」には効くが、「文章が丸ごと別言語になる」不具合には無力。不具合の種類によって効く対策とそうでない対策がある
- 「禁止を強めるほど悪化する」という過去の知見(逃げ道のある言語ルールの方が効く)は、モデルが変わっても再利用できた
- 技術的に移植可能(週末プロジェクト級)と分かっても、実力検証の結果次第では見送るのが妥当。可能性と価値は別軸で判断する必要がある