皆さん、
これはアップデートです！数日前に、より大きなモデルを動かすためにSSDを使ったときのRaspberry Pi5の性能を示す投稿をしました。もっとも、当然のことながら、私が使っていたUSB3接続よりもPCIeの方が速いという指摘を何人かから受けたので、公式HATを購入しました。
結論（ネタバレ）：予想通りです。読み取り速度が2倍になり、スワップを使うモデルでの推論とテキスト生成のtokens/secが1.5倍〜2倍向上しました。
セットアップを改めて書きます：
- Raspberry Pi5（16GB RAM）
- 公式アクティブクーラー
- 公式M.2 HAT+ Standard
- HAT経由で接続した1TB SSD
- 標準のRaspberry Pi OS lite（Trixie）を使用
焦点はこの質問です：標準的な部品をいくつか買って、少しだけ工夫する程度で、どんな性能が期待できるのか？ より大きいファン/クーラーをサードパーティから買う、オーバークロックやオーバーボルトをする、Orange Piのようなニッチな機器を買うこともできますが、そういう方向性ではありませんでした。そこで、標準のPiを選び、いじるのは最小限にして、同じことが多くの人にできるようにしました。
デフォルトではPiはGen2規格のPCIeインターフェースを使います（そのため、HAT使用時にSSDから得られた読み取り速度は約418MB/secでした）。dtparam=pciex1_gen=3をファイル「/boot/firmware/config.txt」に追記し、再起動してGen3を使えるようにしました。
SSDの読み取り速度は、（USBでの）360.18MB/secから2.2倍になり、HATを使って他の人が達成したのと同じように見える最大値まで上がりました。
$ sudo hdparm -t --direct /dev/nvme0n1p2 /dev/nvme0n1p2: Timing O_DIRECT disk reads: 2398 MB in 3.00 seconds = 798.72 MB/sec
私のSSDは、半分をスワップ領域、半分をモデルの保存用パーティションにしています（ただし、これは他の場所でも構いません）。もちろん、RAMに収まるモデルならスワップは必要ありません。
私はこのコマンドで、すべてのモデルをベンチマークしました。プロンプト処理（pp512）とテキスト生成（tg128）を、0時点と（ほとんど全てで）32kコンテキスト時でテストしました：
$ llama.cpp/build/bin/llama-bench -r 2 --mmap 0 -d 0,32768 -m <all-models-as-GGUF> --progress | tee bench.txt
以下は、アルファベット順にフィルタした結果です（例としてGLM4.7-Flashが、下層のdeepseek2アーキテクチャとして言及されていたため、名前を調整しています）：
| model | size | pp512 | pp512 @ d32768 | tg128 | tg128 @ d32768 |
| Bonsai 8B Q1_0 | 1.07 GiB | 3.27 | - | 2.77 | - |
| gemma3 12B-it Q8_0 | 11.64 GiB | 12.88 | 3.34 | 1.00 | 0.66 |
| gemma4 E2B-it Q8_0 | 4.69 GiB | 41.76 | 12.64 | 4.52 | 2.50 |
| gemma4 E4B-it Q8_0 | 7.62 GiB | 22.16 | 9.44 | 2.28 | 1.53 |
| gemma4 26B-A4B-it Q8_0 | 25.00 GiB | 9.22 | 5.03 | 2.45 | 1.44 |
| GLM-4.7-Flash 30B.A3B Q8_0 | 29.65 GiB | 6.59 | 0.90 | 1.64 | 0.11 |
| gpt-oss 20B IQ4_XS | 11.39 GiB | 9.13 | 2.71 | 4.77 | 1.36 |
| gpt-oss 20B Q8_0 | 20.72 GiB | 4.80 | 2.19 | 2.70 | 1.13 |
| gpt-oss 120B Q8_0 | 59.02 GiB | 5.11 | 1.77 | 1.95 | 0.79 |
| kimi-linear 48B.A3B IQ1_M | 10.17 GiB | 8.67 | 2.78 | 4.24 | 0.58 |
| mistral3 14B Q4_K_M | 7.67 GiB | 5.83 | 1.27 | 1.49 | 0.42 |
| Qwen3-Coder 30B.A3B Q8_0 | 30.25 GiB | 10.79 | 1.42 | 2.28 | 0.47 |
| Qwen3.5 0.8B Q8_0 | 763.78 MiB | 127.70 | 28.43 | 11.51 | 5.52 |
| Qwen3.5 2B Q8_0 | 1.86 GiB | 75.92 | 24.50 | 5.57 | 3.62 |
| Qwen3.5 4B Q8_0 | 4.16 GiB | 31.02 | 9.44 | 2.42 | 1.51 |
| Qwen3.5 9B Q8_0 | 8.86 GiB | 18.20 | 7.62 | 1.36 | 1.01 |
| Qwen3.5 27B Q2_K_M | 9.42 GiB | 1.38 | - | 0.92 | - |
| Qwen3.5 35B.A3B Q8_0 | 34.36 GiB | 10.58 | 5.14 | 2.25 | 1.30 |
| Qwen3.5 122B.A10B Q2_K_M | 41.51 GiB | 2.46 | 1.57 | 1.05 | 0.59 |
| Qwen3.5 122B.A10B Q8_0 | 120.94 GiB | 2.65 | 1.23 | 0.38 | 0.27 |
build: 8c60b8a2b (8544) & b7ad48ebd (8661 because of gemma4 )
完全を期すために、llama-benchの出力結果全文をコメント欄に載せます。
このリストにはBonsai8Bが含まれています。私はllama.cppのフォークをビルドして、それでテストしました。何か間違っているのかもしれませんし、計算がARM CPU向けに本当に最適化されていないのかもしれませんが、そこまでは分かりません。このモデルをこれ以上掘り下げるつもりはありませんが、入れてほしいと言われたので入れました。
いくつかの観察と所見：
- CPU温度は、RAMに完全に収まる小型モデルではおよそ~75°Cでした
- CPU温度は、Qwen3.5-35B.A3B.Q8_0のようなスワップが必要なモデルではおよそ~65°Cで、負荷は50〜100%の間で跳ねました
- --> HATなしの以前のテストと比べて、RAMでは+5、スワップでは+15°Cです。これは、いまは風の通り道がより制限され、CPU負荷が高くなったためです
- もう一つ意外性のない点：アクティブなパラメータが多いほど遅くなります。密なモデルは特に速度が厳しく、たとえばQwen3.5 27Bのようなものです。
