Kotonia Articles

1.58bit の 27B は何を忘れたか — 「FP16 比 95%」の死角を日本語で実測した

PrismML の Bonsai 27B(Qwen3.6-27B の ternary 1.71bit 圧縮)を発表翌日にローカル検証。英語の速度・品質クレームは本物(121.6 tok/s、重み 6.66GiB)だが、日本語は返答の52%に英単語が混入して壊れていた。素モデルとの対照実験で劣化の原因を変換工程に確定し、多言語プロダクト運用者向けのチェックリストにまとめた。

著者清水真二2026-07-146分で読める

#llm#quantization#ternary#localllm#gpu

他の言語英語中国語

TL;DR

PrismML が 2026-07-14 に公開した Bonsai 27B(Qwen3.6-27B の ternary 1.71bit / 1-bit 変換、Apache 2.0)を発表翌日にローカルで検証した。サイズと速度のクレームは本物で、RTX PRO 6000 Blackwell では公称の H100 値を上回る 121.6 tok/s(重み 6.66 GiB)が出た。英語の会話・コード・tool calling も実用品質で残っている
しかし日本語は壊れていた。50 プロンプトの音声チャット想定会話で、返答の 52% に英単語の混入(ラテン文字混入率 7.3%)。「三日坊主」を "three-day monk" と直訳して全文英語で返す、简体字「开」が紛れ込む、といった壊れ方をする
同一条件で素の Qwen3.6-27B(Q4_K_XL)を測ると混入率 0.27%・汚染返答 6%。ベースモデルの日本語は無傷であり、劣化は ternary 変換の工程で起きたと確定した
興味深いのは 1.71bit と 1.125bit で劣化がほぼ同じ(52% vs 56%)だったこと。つまりビット数を削るほど徐々に壊れるのではなく、変換時の学習データ分布が「何を残すか」を決めている。公式ベンチ 15 本が全て英語であることと、この結果は綺麗に整合する
結論: 「FP16 比 95%」は嘘ではない。ただしその 95% は英語ベンチが測れる範囲の 95% であり、多言語プロダクトにそのまま持ち込むと static なベンチには一切映らない形で壊れる。5 分で書ける機械的なカナリア指標(本文参照)を通してから採用判断すべき

Bonsai 27B とは何か、何がそんなに衝撃なのか

PrismML の発表を要約すると、Qwen3.6-27B を丸ごと ternary({-1, 0, +1}、実効 1.71 bits/weight) と binary({-1, +1}、実効 1.125 bits/weight) に変換したモデル、ということになる。重みは FP16 の 54GB から ternary 5.9GB / binary 3.9GB へ。iPhone 17 Pro Max で 11 tok/s、M5 Max で 44 tok/s、というのが公式の数字だ。

sub-2bit の LLM 自体は BitNet 系で前例がある。衝撃なのはそこではなく、次の 2 点だ。

既製の学習済みモデルを後から変換している。BitNet 系は最初から低ビット制約でフル事前学習する必要があり、既存モデル資産を全て捨てる前提だった(だから最大でも 2B 級で止まっていた)。Bonsai は「賢いモデルを作ってから圧縮する」方向で 27B に到達した
エスケープハッチがない。従来の「2bit 量子化」は embeddings や attention 周りを 4〜8bit で残すのが常識で、ラベルと実態が乖離していた(公式 whitepaper の計測では、いわゆる "2-bit" IQ2_XXS の実平均は 2.8 bits/weight)。Bonsai は embeddings から LM head まで一律に ternary/binary で、ラベル通りのビット数になっている

whitepaper の主張はこうだ: 15 ベンチ(全て thinking mode)の平均で FP16 85.07 に対し ternary 80.49(94.6%)、1-bit 76.11(89.5%)。同じ Qwen3.6-27B の IQ2_XXS(9.4GB)が 72.73 まで崩壊するのに対し、6 割のサイズ(5.9GB)で 8 点近く上回る。AIME26 では IQ2_XXS が 57.5 に崩れる一方 ternary は 87.5 を保つ。手法は Caltech の Hassibi 教授系の理論に基づく QAT(学習初期から ternary 制約を入れて変換学習)で、詳細は非公開の IP。

私は日本語音声ロールプレイのプラットフォーム(kotonia.ai)を一人で運用していて、prod の LLM は同じ Qwen3.6-27B 系の finetune(ThinkingCap-27B NVFP4、約 20GB)を RTX PRO 6000 Blackwell に常駐させている。同一ベースの 27B が 7GB になるなら GPU 配分が根底から変わる。発表翌日に検証する動機としては十分すぎる。

検証環境

GPU: RTX PRO 6000 Blackwell Max-Q(96GB)。音声系サービスは別 GPU に隔離してあるので、検証中も本番は無停止
ランタイム: PrismML の llama.cpp fork(独自量子化型 GGML_TYPE_Q2_0 + hybrid-attention 用 CUDA カーネル。mainline では動かない)を sm_120 向けにソースビルド
モデル 4 種を同一マシン・同一プロンプトで比較:
- Ternary Bonsai 27B(Q2_0、7.2GB)
- 1-bit Bonsai 27B(Q1_0、3.8GB)
- 素の Qwen3.6-27B(unsloth UD-Q4_K_XL、17.6GB)— whitepaper が FP16 代替の対照に使っているのと同一ファイル
- ThinkingCap-27B NVFP4(vLLM、prod 稼働中のもの)— 参考値

まず、本物だった部分

疑ってかかったが、インフラ系のクレームはことごとく実測で裏付けられた。むしろ上回った。

項目	公称	実測(RTX PRO 6000 BW)
重みサイズ (ternary)	~5.9GB(native 目標)/ 7.2GB(現行 GGUF)	6.66 GiB
推論 VRAM	4K ctx で 8.4GB	16K ctx で 8.9GB
生成速度 tg128	98 tok/s(H100)	121.6 tok/s
プロンプト処理 pp512	2,596 tok/s(H100)	3,210 tok/s

デコードは帯域律速なので、H100 より帯域あたりの素性がいいワークステーション GPU で公称超えが出るのは理屈通りではある。それでも「27B が 9GB 弱の VRAM で 121 tok/s」は、手元で見ると数字以上のインパクトがある。比較のために素の Qwen3.6-27B Q4_K_XL を同じ環境で回すと 65.7 tok/s。重みが 2.46 倍小さくなり、速度が 1.85 倍になる。帯域の数学がそのまま体感になる。

品質も、英語で使う限り本物に見えた。

英語の雑談・共感応答は自然で、破綻を見つけられなかった
コード生成は unit test 実行で機械判定し、区間マージ・ランレングス圧縮とも PASS
OpenAI 互換の tool calling は正しい構造の tool_calls を返した
数学は同一問題を 10 回投げて 10/10 正解(後述の分散問題はある)

同梱の投機デコード(DSpark、EAGLE 系の block-diffusion drafter)だけは公称と乖離した。H100 で 1.34 倍とされるが、うちの環境では 121.6 → 125.3 tok/s の +3% に留まった。draft の受理率を見ると英語エッセイで 73% と drafter 自体は機能しており、ベースの生成が速すぎて drafter の forward コストが利得を食い潰す構図だった。そして日本語では受理率が 10% まで落ちる。drafter も英語向けに訓練されている。この時点で嫌な予感はあった。

「ことね」が英語を話し始めた

うちの製品の音声ペルソナと同じ条件(話し言葉で 2〜3 文、thinking off)で日本語の雑談を投げると、様子がおかしい。

User: 資格の勉強始めたけど三日坊主になりそう。 Ternary Bonsai: Qualification study began but three-day monk?

「三日坊主」を three-day monk と直訳し、返答全体が英語になった。他にも:

User: 朝起きられないんだけど、何かいい方法ない? Ternary Bonsai: 朝起きられないのは、身体が休んで欲しいから maybe? 夜前にPhoneを遠くに置き、 morning light を受けられるようにカーテンを开けると、目覚め方が良いよ。

英単語の混入(maybe、morning light)に加えて、「開ける」が简体字の「开ける」になっている。英語だけでなく中国語の表記体系まで滲んでいる。1-bit 版はさらに露骨で、日本語の愚痴に対して "Yeah, totally get that. Sometimes boss behavior can be really frustrating." と全文英語で返したり、カラオケの選曲相談に『Hello Sunshine』『Sugoi Nana』という実在しない曲を挙げたりした。

印象論で終わらせないために、これを機械的に測る。

定量化: ラテン文字混入率

判定用の LLM を使うと再現性の議論になるので、もっと原始的な指標にした。

日本語の雑談プロンプト 50 本(仕事・恋愛・食・健康・趣味…)を音声ペルソナの system prompt 付きで投げる
返答から空白を除き、ラテン文字([A-Za-z])の文字数比率と、2 文字以上のラテン文字連続を含む返答の割合を数える

自然な日本語の話し言葉なら外来語はカタカナになるので、この数字はほぼゼロになるはずだ。実際、対照群はそうなった。

モデル	bits/weight	ラテン文字混入率	英単語を含む返答
素の Qwen3.6-27B(Q4_K_XL)	5.2	0.27%	6%
ThinkingCap-27B(NVFP4、prod)	~4	0.56%	2%
Ternary Bonsai 27B	1.71	7.29%	52%
1-bit Bonsai 27B	1.125	7.83%	56%

返答の半分以上に英単語が混入する、というのは会話プロダクトでは全損に近い。中国語でも同じ傾向が出る(10 プロンプトの簡易プローブで、素モデルとprod は混入 0 に対し ternary 4.1% / 1-bit 5.3%)。英語以外が広く削られ、英語が濃縮されている。

なお公平のために書くと、whitepaper は 15 ベンチが全て英語であることを隠していないし、instruction following や agentic 系の低下(IFBench 68.0 → 58.5 など)は正直に開示している。多言語について何も主張していないのだから、嘘をつかれたわけではない。測っていないものは、見えない。それだけの話だ。

因果の切り分け: 犯人は変換工程

「そもそも Qwen3.6-27B の日本語が弱いのでは?」という反論が当然ありうる。だから対照に whitepaper 自身が使っているのと同一の GGUF(unsloth UD-Q4_K_XL)を置いた。結果は上の表の通り、混入率 0.27%・汚染返答 6%。素のベースモデルの日本語は完全に健全で、劣化は Bonsai の QAT 変換で注入されたと確定する。

もうひとつの発見は、ternary(1.71bit)と 1-bit(1.125bit)で劣化がほぼ飽和していることだ。ビット容量が 1.5 倍違うのに、日本語の壊れ方はほぼ同じ。もし「情報容量が足りなくて壊れる」なら 1-bit の方が明確に悪化するはずで、そうならなかった。

つまりこれは容量の問題ではなく、変換時に何を学習させたかの問題だ。QAT は「ternary 空間に最適化された表現を学び直す」工程であり、そこで流したデータの分布が、そのままモデルが保持する能力の分布になる。英語とコードを流せば英語とコードが残る。日本語の雑談を流さなければ、日本語の雑談は残らない。発表資料の「27B-class thinking, reasoning, and agentic capability を保持」という言葉は正しい。ただしその capability の定義域は、変換データとベンチが張った空間の内側に限られる。

これは批判というより、この技術の性質の理解として重要だと思う。sub-2bit への変換は「圧縮」というより「英語という部分空間への蒸留」に近い。そしてこの見方は、逆方向の希望も含んでいる。変換データに日本語を十分入れた Bonsai を誰かが焼けば、日本語も残る可能性が高い。壊れ方が容量律速ではないのだから。

おまけの発見: thinking 長の分散

whitepaper のベンチは全て thinking mode で取られている。実運用で効いてくるのは平均値ではなく分散で、同一の数学問題を 10 回投げたところ、全問正解ではあるものの thinking の長さが 2,339〜7,934 token(3.4 倍) ばらついた。別セッションでは同じ問題で 12,000 token を使い切っても答えに到達しない暴走も 1 回観測している。sub-2bit 特有かは未検証だが(素モデルでも thinking 分散はある)、レイテンシ SLA のあるプロダクトに thinking mode で組み込むなら token budget と timeout は必須になる。

多言語プロダクト運用者としてのチェックリスト

同じ立場(英語圏外でユーザー向け LLM プロダクトを運用している人)への実務的な示唆をまとめる。

英語ベンチの平均点は、あなたのユーザーの言語について何も保証しない。これは Bonsai に限らず、蒸留・量子化・剪枝など「変換」を挟むモデル全般に言える。変換データの分布は普通開示されない
カナリア指標は 5 分で書ける。自分の製品のペルソナ prompt + 50 プロンプト + ラテン文字混入率(または対象言語の表記体系からの逸脱率)。判定 LLM 不要、完全に再現可能で、モデル更新のたびに CI で回せる
投機デコードの受理率も言語依存。drafter は本体より小さいぶん、学習データの偏りがより極端に出る。英語で測った speedup を多言語トラフィックに外挿しないこと
thinking mode を採用するなら p50 ではなく p99 の thinking 長で容量とタイムアウトを設計する

それでも、これは革命の入口だと思う

日本語が壊れているという結果を出しておいて矛盾するようだが、検証を終えた感想は「この方向は本物」だ。

27B ternary(80.49)は 8B FP16(79.3)を上回る。16.4GB の 8B を持つくらいなら 5.9GB の 27B ternary を持つ方が賢い、という逆転が既に起きている
変換ベースなので、フロンティアの進歩に追従できる。BitNet 路線が「低ビット専用に一から作り直せ」だったのに対し、こちらは「最新の賢いモデルが出たら変換すればいい」
壊れ方が容量律速ではない以上、多言語版は作れるはずだ。誰かが変換データに日本語を入れて焼けば、うちの GPU で最強クラスのローカルモデルが動く未来は普通にありうる

うちの製品は日本語×音声×リアルタイムの総合格闘技なので、prod は当面 ThinkingCap-27B のままだ。ただ、この検証で得たカナリア指標はモデル選定パイプラインに常設する。ベンチマークに映らない品質で殴り合うのが、多言語プロダクトの現場だから。

再現手順

検証は全て公開物で再現できる。

# 1. PrismML の llama.cpp fork をビルド (CUDA、Blackwell なら arch 120)
git clone https://github.com/PrismML-Eng/llama.cpp llama.cpp-bonsai
cd llama.cpp-bonsai
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=120 -DCMAKE_BUILD_TYPE=Release
cmake --build build -j --target llama-server llama-bench

# 2. モデル取得 (HF: prism-ml/Ternary-Bonsai-27B-gguf ほか)
#    Ternary-Bonsai-27B-Q2_0.gguf (7.2GB) / Bonsai-27B-Q1_0.gguf (3.8GB)
#    対照: unsloth/Qwen3.6-27B-GGUF の UD-Q4_K_XL (17.6GB)

# 3. 起動 (公式推奨サンプリング)
./build/bin/llama-server -m Ternary-Bonsai-27B-Q2_0.gguf \
  -ngl 999 -fa on -c 16384 --jinja \
  --temp 0.7 --top-p 0.95 --top-k 20 --min-p 0
# thinking を切る場合はリクエストに chat_template_kwargs {"enable_thinking": false}

# 4. 速度
./build/bin/llama-bench -m Ternary-Bonsai-27B-Q2_0.gguf -ngl 999 -fa 1

混入率の測定スクリプト(50 プロンプトと集計、100 行弱の Python)は素朴なものなので、記事内の定義から各自の言語向けに書き直すことをおすすめする。プロンプトセットは製品のペルソナに合わせるほど、カナリアとしての感度が上がる。

kotonia.ai は多言語 TTS とリップシンクアバターによる日本語音声ロールプレイのプラットフォームです。ローカル GPU 一枚で LLM・TTS・アバター生成を全部回している都合上、こういう検証が趣味と実益を兼ねています。