こんにちは、パレイド技術部の夏目です。
前回 Phi-4-mini（3.8B）を測ったとき、128K のコンテキストを開くと KV キャッシュ（過去のトークンを保持する作業領域）が本体 2.5GB の 6 倍以上に膨らみ、常駐 19GB を要求しました。長い文脈のコストはパラメータ数ではなく構造で決まる、という結論です。Qwen3.8-27B は、その構造を作り替えたモデルとして 8/14 に公開されました。64 層のうち 48 層を線形 attention（Gated DeltaNet）に置き換え、フル attention は 16 層だけ。KV キャッシュが長さに比例して膨らむのはフル attention の層だけなので、262K を開いても暴れないという触れ込みです。32GB の MacBook Air M5 で、この触れ込みが成立するかを測りました。
本記事はローカル LLM による自動執筆パイプラインで生成されました。現段階ではクラウド AI（Claude 等）の補助や人間の編集が介在していますが、pareido.jp では最終的に AI が自律的にコンテンツを制作できる仕組みの構築を目指しています。
Ollama が 412 を返す、バージョンの罠
| 項目 | 内容 |
|---|---|
| 検証機 | MacBook Air (M5 / 10 コア) |
| メモリ | 32GB ユニファイドメモリ |
| OS | macOS 26.4.1 |
| 推論エンジン | Ollama 0.32.13 |
| 対象モデル | qwen3.8:27b (Q4_K_M / 17GB) |
| 比較対象 | phi4-mini (Q4_K_M / 2.5GB、前回計測値) |
| 計測時の load average | 2〜4（1 分平均） |
最初の一手で止まりました。手元に入っていた Ollama 0.32.3 で pull を叩くと、ダウンロードが始まる前に弾かれます。
# manifest の取得段階で 412 が返る
ollama pull qwen3.8:27b
# Error: pull model manifest: 412:
# The model you are attempting to pull requires a newer version of Ollama.ollama show の requires 行が 0.32.12 でした。新しいアーキテクチャのモデルは、量子化ファイルを読む側の対応版が揃うまで手元に降りてきません。GUI 版を上書きするのは避けたかったので、公式リリース v0.32.13 の standalone バイナリ（ollama-darwin.tgz / 147MB）を展開し、別ポートで並走させて取得しました。17GB を 715 秒、約 24MB/s です。
# インストール済みの Ollama.app には触らず、別ポートで立てる
OLLAMA_HOST=127.0.0.1:11500 ./ollama serve &
OLLAMA_HOST=127.0.0.1:11500 ./ollama pull qwen3.8:27bなお検証を終える頃には、インストール済みの Ollama.app 自身が 0.32.13 へ自動更新されていました。急いで手を動かさなければ、待つだけで解決した類の罠です。とはいえ公開直後のモデルに触るなら、requires 行を先に見る癖はつけておいて損はありません。
ollama show が返した素性は、architecture が qwen35、parameters 27.3B、context length 262144、quantization Q4_K_M。capabilities には completion のほか vision / tools / thinking が並び、460.73M の clip projector も同梱されています。27B クラスとしては装備が手厚く、ライセンスは Apache 2.0 です。
触れ込みの構造は GGUF のメタデータで裏付けが取れました。block_count 65、full_attention_interval 4、つまり 4 層に 1 層だけがフル attention。残りは ssm.state_size 128 / ssm.conv_kernel 4 といった状態空間モデル系のキーで埋まっています。フル attention 層の KV ヘッドは 4、key と value がそれぞれ 256 次元でした。
5 タスクは全部自力で止まった
前回と同一条件（/api/chat、num_ctx 4096 / temperature 0.2 / seed 42 / num_predict 1024）で 5 タスクを投げました。
| タスク | 生成トークン | 生成 tok/s | 所要秒 | 判定 |
|---|---|---|---|---|
| 挨拶 | 44 | 4.94 | 26.43 | ○ |
| 事実質問 | 7 | 6.51 | 2.51 | ○ |
| コード生成 | 92 | 7.75 | 13.32 | ○ |
| 日本語要約 | 90 | 4.81 | 21.34 | ○ |
| 英語要約 | 65 | 4.83 | 15.44 | ○ |
挨拶行の所要秒にはモデル読み込みの 15.98 秒を含みます。5 タスクすべてが done_reason: stop、つまり自力で終端しました。Phi-4-mini が日本語要約で上限まで反復し、「ノートパソコン」を「ノートパソン」に崩しながら止まれなかった場所を、こちらは 90 トークンで指示どおり 3 行に畳んでいます。
エッジコンピューティングは、遅延やプライバシーの懸念からデータ発生地付近で処理を行う方式であり、需要が高まっています。 生成AI分野でも、小型化・量子化されたモデルを端末内で動かす試みが進められています。 現状は複雑な処理をクラウドに任せる分担が現実的ですが、性能向上により1年程度で日常タスクの端末内完結が期待されます。
代償は速度です。4.8〜7.8 tok/s で、Phi-4-mini の 43〜50 tok/s のおよそ 7 分の 1。パラメータ数の比（27.3B / 3.8B = 7.2 倍）とほぼ一致します。dense なので活性パラメータが総パラメータと等しく、MoE のように「総量は大きいが計算量は小さい」という抜け道がありません。速度に関しては、構造がそのまま素直に出ます。
thinking も試しました。「消えた 1 ドル」のパズルを OFF / ON で投げると、どちらも正解します。OFF は 671 トークンを 98.7 秒、ON は英語で 1308 字ぶん考えてから日本語で表つきの回答を返し、847 トークンを 161.4 秒。回答の整理は ON のほうが明確ですが、5 tok/s では思考中の沈黙が 2 分近く続きます。応答が返らない時間をどう扱うかは、組み込む側の設計課題になります。
KV キャッシュは暴れない。詰まったのは本体
num_ctx を変えながら ollama ps の常駐サイズと CPU/GPU 配分を追い、同じ条件で生成速度も測りました。
| num_ctx | 常駐サイズ | 配分 | 生成 tok/s | 判定 |
|---|---|---|---|---|
| 4,096 | 17 GB | 100% GPU | 6.46 | ○ |
| 16,384 | 18 GB | 100% GPU | — | ○ |
| 32,768 | 17 GB | 100% GPU | 6.03 | ○ |
| 131,072 | 19 GB | 24%/76% CPU/GPU | 0.22 | × |
| 262,144 | 27 GB | 57%/43% CPU/GPU | 0.076 | × |
触れ込みは成立しています。コンテキストを 4K から 128K へ 32 倍に広げて、常駐は 17GB から 19GB、増えたのは 2GB だけです。構造から計算しても合います。フル attention 1 層あたり 1 トークンで 4 ヘッド ×（key 256 + value 256）× 2 バイト = 4KB、それが 16 層で 64KB/トークン。64 層すべてがフル attention なら 4 倍を積む計算なので、線形 attention への置き換えが KV キャッシュを 4 分の 1 に抑えた形です。
同じ 19GB でも、Phi-4-mini とは中身が逆でした。前回のモデルは本体 2.5GB に KV が 16.5GB。今回は本体 17GB に KV が 2GB。長い文脈のボトルネックは、KV キャッシュから本体の重みへ移動しています。
そして、成立しても救われませんでした。32GB のユニファイドメモリでは 17GB の本体だけで Metal 側の予算をほぼ使い切るため、128K を開いた時点で層が CPU へこぼれます。生成速度は 6.03 tok/s から 0.22 tok/s へ、27 倍遅くなりました。262K では 20 トークンの生成に 264.6 秒、1 トークンあたり 13 秒です。KV キャッシュを節約した設計の恩恵を受け取る手前で、本体の大きさが先に効きます。
読み取りの精度は落ちません。文書の中央に「検証機の内部識別番号は QX-7731」を埋め、末尾でその記号だけを訊きました。
| モデル | num_ctx | 入力トークン | プロンプト処理 tok/s | 読み込み秒 | 正答 |
|---|---|---|---|---|---|
| qwen3.8:27b | 16,384 | 13,394 | 64.0 | 209.3 | ○ |
| qwen3.8:27b | 40,960 | 33,522 | 46.0 | 729.2 | ○ |
| phi4-mini（前回） | 16,384 | 9,805 | 556.7 | 17.6 | ○ |
| phi4-mini（前回） | 40,960 | 36,596 | 161.2 | 227.0 | ○ |
33K トークンでも記号を正確に拾います。効かなくなるのは、やはり速度でした。プロンプト処理は同じ 16K で Phi-4-mini の 8.7 分の 1、40K でも 3.5 分の 1 で、40K の読み込みだけで 12 分かかります。答えが返り始めるまでの待ち時間として、対話では成立しない領域です。
トークナイザ（文章をモデルが扱う単位へ切り分ける機構）は日本語寄りでした。
| テキスト | qwen3.8:27b | phi4-mini | 比 |
|---|---|---|---|
| 日本語の短文 | 62 | 76 | 0.82 |
| 英語の短文 | 48 | 37 | 1.30 |
日本語では 2 割少なく、英語では 3 割多くなります。Phi-4-mini とちょうど裏返しで、この 262K は日本語基準では額面以上に使える計算です。埋め切る速度があれば、の話ですが。
まとめ
- ハイブリッド attention は宣伝どおり効いた。4K → 128K でコンテキスト 32 倍に対し、常駐は +2GB
- 32GB Mac の実用上限は 32K 前後。そこまでは 100% GPU で 6 tok/s、17GB を保つ
- 128K からは CPU へこぼれて 0.22 tok/s、262K で 0.076 tok/s。KV を節約しても、dense 27.3B の本体 17GB が先に GPU 予算を食い切る
- 日本語は安定。5 タスクすべて自力で停止し、Phi-4-mini の無限反復は再現しなかった
- 速度は Phi-4-mini の約 7 分の 1。dense なので活性パラメータの抜け道がない
- Apache 2.0 に vision / tools / thinking という装備は 27B クラスとして手厚い
- 新アーキテクチャは推論エンジンのバージョンを選ぶ。0.32.3 では pull すらできない
用途で切るなら、短い入力に時間をかけて品質を取るバッチ処理が 27B の居場所です。対話の応答速度が要る場面、長文を実際に流し込む場面は、このマシンでは小型モデルに譲ることになります。
262K という数字は、モデル側ではなく GPU 予算の側が受け取れていません。Ollama には 27b-mlx タグも用意されているので、バックエンドを MLX に替えたときに 6 tok/s と 19GB がどこまで動くか、次はそこに挑みます。前回 Ternary Bonsai で計測したときは、エンジンを移すだけで速度が倍、メモリが 4 分の 1 になりました。同じ幅が出るなら、128K の壁は位置が変わります。