Bonsai 2の2B・4B・9Bが登場。Macで日本語を試すと、作業メモに欠落が出た

ふくふくでは、2BのMac向けMLX版をApple M2 UltraのMacで動かし、架空の日本語メモ3件を試しました。日本語で応答しましたが、2人分の作業から1人分を落とす結果も出ました。軽さ、導入条件、実際の欠落をまとめ、どの仕事から試すと判断しやすいかを考えます。

新しい3モデルはQwen3.5を基にしており、重みを−1・0・+1の3値で表す方式を採ります。モデルを表す数値を小さく持つことが狙いです。提供元が示すフットプリントは2Bが0.43GB、4Bが0.95GB、9Bが2GB。重みはApache 2.0で公開されています。発表ページでは同日から利用可能としていますが、正確な発表時刻は確認できませんでした。発表と提供条件

ここでBはパラメータ規模の目安です。「9Bならどの仕事でも2Bより正確」とまでは言えません。どのサイズを選ぶかは、手元の入力で失敗を減らせるか、そのために増えるメモリと待ち時間を受け入れられるかで決めます。

2Bの公式MLXモデルカードは、保存形式の付随情報と画像処理部分を説明しています。モデルファイルが入る空き容量だけを見て導入を決めず、実行時の余裕も確保します。長い文書や画像を渡した場合の消費量は、今回の短文試用とは異なります。

今回はApple Silicon向けのMLXパックを、mlx-vlm 0.7.8で読み込みました。公式カードでは同版以降のネイティブ対応を案内しています。確認時点のmlx-lm 0.32.0は、このパックのモデル種別を読み込めません。mlx-vlmとmlx-lmは名前が似ていますが、起動方法を入れ替えないことが大切です。小型モデル専用手順

公式デモはMacのほかLinux・Windows向けの経路も案内していますが、バックエンドと重み形式の組み合わせに条件があります。GGUFのPQ2_0・PTQ1_0にはPrismML側のllama.cppが必要で、Q2_0もモデル対応を含む新しい実装が前提です。「GGUFだから、手持ちのどのアプリでも開ける」とは考えないほうがよいです。対応表

日本語の既存記事にも、27BをMacで起動する際にランタイムやメモリでつまずいた検証記録があります。ただし、旧サイズ・以前の環境の結果を、新しい2B・4B・9Bの結果として扱うことはできません。今回の小型モデル向け手順を読み直す価値があります。

公式デモを使う場合、何も指定しない初期値は27Bです。小さいモデルを試すつもりなら、モデル指定を省かないようにします。以下は公式の小型モデル向け手順に沿う例です。インストーラー一式を今回そのまま実行したわけではなく、本記事の実測は後述の分離したPython環境で行いました。公式デモ

短い分類・抽出では、まずthinkingをオフにして試すのが観察しやすい入口です。これは今回の試行方針であり、thinkingを使う価値がないという意味ではありません。公式手順ではモードごとにサンプリング設定が異なり、APIではモードを変えるだけで全設定が切り替わるわけではないと説明しています。

手元で再現する場合は、Apple Silicon用のPythonかも確かめてください。今回、最初に選ばれたPythonはx86_64用で、対応するMLXパッケージが見つからず導入に失敗しました。arm64版Python 3.12.13を別の仮想環境へ用意すると導入できました。既存の仕事用Pythonを上書きする必要はありません。

2026年10月16日、Apple M2 Ultra・メモリ192GiB・macOS 27.0で、2BのMLX版を試しました。Python 3.12.13、mlx 0.32.4、mlx-vlm 0.7.8を使用。モデルの固定版は 1c6cbae21f8c38830ce337972b46fdae7b18eaaa です。モデルを事前に取得し、推論では外部APIを呼ばず、架空のテキストだけを入力しました。画像・音声・ツール実行は試していません。

設定はthinkingオフ、最大出力384トークン、temperature 0.7、top-p 0.8、top-k 20、min-p 0、presence penalty 1.5、履歴幅64、repetition penalty 1.0、乱数seed 42です。各入力は1回ずつで、正解率を推定できる件数ではありません。以下は入力と実際の出力を照合した判定です。

抽出テストの全文は次の通りです。入力にない期限を作らないことに加え、入力にある人物や作業を落とさないことも確かめる必要がありました。

期待した内容は、佐藤さんの見積書確認と、期限を「不明」とした鈴木さんの請求先確認の両方です。出力されたJSONの文法が正しくても、仕事の情報が揃っているとは限りません。今回は指示を修正して再試験していないため、「配列で2件出す」と追加すれば直るとも断定しません。

3件の生成呼び出しにかかった時間は順に約3.91秒・0.26秒・0.12秒でした。モデルのダウンロードとロード時間は含まず、最初の呼び出しには初回処理の影響があり得ます。出力の長さも異なるので、この数字を一般的な速度比較には使いません。4B・9Bや元モデルとの比較、16GBなどのMacでの検証は未実施です。

導入候補として考えやすいのは、短い問い合わせの仮分類、作業メモの下整理、定型文の言い換えなどです。これは今回の結果から考える試行案です。自動送信・確定処理を最初から任せず、入力と結果を並べて人が見直せる画面を出口にします。

本格導入の前には、モデルを小さくする効果と、修正にかかる時間を一緒に記録します。2Bで失敗した同じ入力を4B・9Bでも試し、欠落が減るかを比較すると、容量を増やす理由を説明しやすくなります。高いベンチマークの数字だけで、社内文書の精度を代用しないことが重要です。

今回のような少数試行を記録できる空の検証表CSVを用意しました。モデル・実行環境・入力・期待する事実・欠落・追加された事実を分けて残します。社外へ公開する表に実際の顧客情報を入れる必要はありません。

ローカル推論では従量API料金を使わずに動かせますが、端末・保存容量・電力・保守の負担は残ります。クラウドの入口に置いて情報を減らす設計も考えられるものの、今回の欠落結果を見る限り、匿名化や重要情報の除去を無確認で任せる用途には慎重な検証が必要です。

ローカルAIの利用条件を読む視点はGoogle Foresightの導入と検証にも通じます。小さく動くことを入口にし、必要な情報を保てることを採用条件にする。その順番でBonsai 2を試すと、軽量化が実際の仕事に役立つかを判断できます。