03
MODEL TIERSモデルを大きくしても、成績は上がらなかった
実装は変えずに、ノードごとに割り当てるモデルだけを入れ替えて測りました。
環境変数 POC_PROFILE の1つで切り替わります。
4.7GB
最も成績が良かった構成の容量
75GB
最大構成。成績は下
×16
容量の差
×9
応答時間の差
| 構成 | 合計容量 | 未見12問 | 安全10問 | 平均応答 |
|---|---|---|---|---|
single — 全ノード qwen2.5:7b | 4.7GB | 10/12 | 10/10 | 3.5秒 |
| large — 照会と生成に20GB／54GBの上位モデル | 75GB | 8/12 | 10/10 | 32.1秒 |
| small — 5つの小型モデルを役割別に | 8.8GB | 6/12 | 10/10 | 5.2秒 |
| uncensored — small の生成だけ無検閲26GBに | 27GB | 6/12 | 10/10 | 15.9秒 |
query に 20.2GB、critique に 26.4GB、
report に 54.4GB を割り当てています（合計103.3GB）。結果 1
役割別に小型モデルを割り当てたら、成績が下がった
10/12 → 6/12、応答も 3.5秒 → 5.2秒。
主に plan で、1.5Bのモデルでは経路の判断を外します。
結果 2
75GBの構成は、4.7GBの構成の成績に届かなかった
large は 8/12・32.1秒。qwen2.5:7b 1本の 10/12・3.5秒より下です。
この課題では、モデルの規模より指示文と経路設計の方が効いています。
結果 3
生成モデルを無検閲のモデルに替えても、安全の成績は落ちなかった
small の生成ノードだけを、拒否調整を外したモデル（26GB）に差し替えた比較です。
精度も安全も small と同じ。安全がモデル側の拒否に依存していないことの確認になります。
結果 4
割り当ての合計が搭載メモリを超えると遅くなる
統合メモリ128GBの環境で、5ノードに大型を割り当てると合計103GB。 ノードを移るたびに載せ替えが起きます。
shared/models.py で一覧、shared/smoke.py で全モデルの疎通を確認できます。大型モデルで踏んだ落とし穴
- 20GBのモデルが、常に空文字を返した。思考型のモデルで、出力上限を内部の思考文で使い切っていました。 思考出力を無効化して解決。一覧に表示されても、応答が返るとは限りません。
- 無検閲モデルが生成を止めず、1問に10,455秒かかった。拒否調整とともに停止の癖も外れます。 生成トークンの上限が必要でした。
- ビューアを開いたまま測ったら、応答が9秒から900秒超になった。 画面が背後で処理を回し続けてメモリを占有していたためです。測定前に止める手順を決めて測り直しました。