小さなPCで日本語のローカルLLMを動かした次の実験として、今回はサーバー側のProxmoxに専用LXCコンテナを作った。割り当ては10 vCPU、メモリ32 GiB。GPUは使わず、OllamaとQwen3 1.7B、Open WebUIでブラウザから会話できる環境にした。短い同条件の生成試験では約31.2トークン/秒を記録した。
モデルはそのまま、実行環境を広げる
今回のポイントは、モデルを大きくする前に実行環境を変えたことだ。前回の小型機でもQwen3 1.7Bを使い、メモリ4 GiBで日本語チャットを構築できた。今回は同じモデルを維持して、CPUとメモリに余裕のある環境へ配置した。32 GiBを割り当てたからといって、現在のモデルや回答品質が自動で変わるわけではない。
| 項目 | 前回の小型機 | 今回のサーバー |
|---|---|---|
| LXCのCPU割当 | 4 vCPU | 10 vCPU |
| LXCのメモリ | 4 GiB | 32 GiB |
| LXCのディスク | 24 GiB | 40 GiB |
| CPU | Core i7-7500U | Xeon E5-2630 v4 |
| モデル | Qwen3 1.7B | Qwen3 1.7B |
| 推論方式 | CPU、その後VRAM 2 GBのGPU併用を試験 | CPU専用 |
| チャット画面 | Open WebUI | Open WebUI、日本語表示 |
CPUの割当数は専有の予約ではない。ホスト上の他の負荷やメモリ帯域も影響するので、コア数だけで速度を予測せず、実際に生成して確認した。
構築は非特権LXCと二つのサービスで
Debian 12の非特権LXCを作成し、Ollamaを公式インストーラーから導入。Open WebUIはPython 3.11の仮想環境に入れ、両方をsystemdで自動起動させた。導入時のバージョンはOllama 0.35.1、Open WebUI 0.11.4。モデルファイルは約1.4 GBで、構築直後のディスク使用量は約7 GBだった。
手順の流れは、空きリソースとOSテンプレートを確認してLXCを作る、基本パッケージとOllamaを入れる、CPU版の依存パッケージとOpen WebUIを入れる、サービス設定を作る、モデルを取得する、ブラウザと再起動後の動作を確認する、という順序。以下はDebianコンテナ内での導入部分の例であり、自動起動設定やデータ保存設定は別途必要になる。
apt-get update
apt-get install -y --no-install-recommends curl ca-certificates python3-venv python3-pip zstd
curl -fsSL https://ollama.com/install.sh -o /var/tmp/ollama-install.sh
sh /var/tmp/ollama-install.sh
ollama pull qwen3:1.7b
python3 -m venv /opt/open-webui
/opt/open-webui/bin/pip install --upgrade pip
/opt/open-webui/bin/pip install --no-cache-dir torch --index-url https://download.pytorch.org/whl/cpu --extra-index-url https://pypi.org/simple
/opt/open-webui/bin/pip install --no-cache-dir open-webui版を指定していない導入コマンドは、実行時点によって結果が変わる。再構築時にはバージョンと依存パッケージの記録を残す。今回はテンプレート取得先への通信でつまずいたが、公式配布ファイルのハッシュを確認して解決し、証明書検証を無効にする対応はしていない。
余裕があっても、最初の設定は控えめに
Ollamaの既定コンテキストは2048、同時処理は1、ロードするモデルは1にした。CPU専用の設定を明示し、推論APIはコンテナ内のループバックで待ち受ける。LANからはOpen WebUIを利用する構成で、インターネットへ直接公開していない。サービスには会話データの保存先と、失敗時の再起動を設定した。
管理者登録後にOpen WebUIの言語を日本語へ変更し、メニューとチャット画面の表示を確認した。コンテナの再起動後もOllamaとOpen WebUIが自動起動し、日本語のAPI応答とWeb画面の配信を確認できた。今回はコンテナの再起動試験であり、サーバー本体の再起動試験とは区別している。
短い生成試験では約31.2トークン/秒
前回の記録と合わせるため、Qwen3 1.7B、think=false、stream=false、temperature=0、コンテキスト2048、出力上限64トークンを使用。日本語でローカルLLMの利点を3文で説明する同じプロンプトを使い、今回はCPU専用を明示して3回連続実行した。
| 条件 | 生成数 | 生成時間 | 生成速度 | 全体時間 |
|---|---|---|---|---|
| 前回の小型機・CPU（過去記録） | 64 | 5.41秒 | 11.83 tok/s | 11.82秒 |
| 前回の小型機・GPU併用、継続実行（過去記録） | 64 | 6.17秒 | 10.37 tok/s | 6.41秒 |
| 今回のサーバー・CPU、1回目 | 64 | 2.048秒 | 31.25 tok/s | 5.714秒 |
| 今回のサーバー・CPU、2回目 | 64 | 2.050秒 | 31.21 tok/s | 2.109秒 |
| 今回のサーバー・CPU、3回目 | 64 | 2.048秒 | 31.25 tok/s | 2.101秒 |
生成速度は生成トークン数を生成時間で割った値。全体時間にはモデルのロードやプロンプト処理なども含まれる。今回の中央値31.25 tok/sは前回CPU記録の約2.64倍だった。ただし、過去の少数試行との参考比較で、二つの環境を同時に繰り返し測定したものではない。
64トークンで打ち切る短い試験なので、長文の品質や長い会話での速度を評価した数字ではない。初回と継続時でも待ち時間は違う。また、think=falseはこのAPI試験で指定した条件であり、チャット画面の全会話で思考を無効化したわけではない。
極小モデルとの比較は、実測と設計案を分ける
これまでの極小構成の検討では、Qwen3 0.6Bを2 vCPU・メモリ2～4 GB程度で試す案があった。今回確認できた記録では設計案であり、0.6Bの実機速度や日本語品質を今回測り直してはいない。したがって、0.6Bより何倍速い、何倍賢いという結論にはしない。
実装済みの比較対象は、メモリ4 GiBのQwen3 1.7B環境だ。今回も同じ1.7Bなので、観察できた差は主に実行環境の違い。極小モデルは短い命令やJSON生成、今回の環境は会話や今後のモデル比較、と用途を分けて評価したい。
省電力との兼ね合いも、これから測る
サーバーは事前の省電力寄りのCPU設定を維持したまま試験した。ファン制御の設定は変えていない。消費電力は実測していないため、速くなったことを省エネと同一視しない。常時稼働のHOME.LABでは、応答速度だけでなく、待機時と生成中の電力、温度、騒音も一緒に記録する必要がある。
次はモデルの大きさと実用性を比べる
まず日本語の実際の質問を使い、初回と連続時の待ち時間を分けて測る。その後、0.6Bと1.7Bを同じ命令で比較し、日本語理解とJSONの正しさも見る。メモリに余裕があるので3B/4B/8B級の量子化モデルも候補になるが、収まることと快適に動くことは別。大きくする前に一つずつ測る。
Home Assistantやn8nとの連携、長時間の連続運転、同時利用、バックアップの復元試験は今回未実施。次の実験では、まず読み取りやJSON生成から連携を試し、運用を支えるバックアップも確認する。今回できたのは、同じ小型モデルをCPU専用の余裕あるLXCへ置き、日本語チャットとコンテナ再起動後の復帰まで確認した環境だ。
参考資料と前回の記事
- Ollama公式FAQ（環境変数、コンテキスト、CPU/GPU割当表示）
- Ollama公式モデルライブラリ：Qwen3 1.7B
- 前回：小さな構成で日本語ローカルLLMを動かす
- 前回：VRAM 2 GBのGPUを試した結果
記録日：2026年10月4日。内部IP、管理用ホスト名、コンテナ番号、利用者情報、内部文書のURLは公開記事に含めていない。