はじめに
ローカルLLMに興味はあるものの、
「実際、自宅PCでどこまで使えるのか？」
が気になり、Ubuntu PCでQwen3.8-27Bを動かしてみました。
今回は単にチャットできるかではなく、OpenCodeからコーディングエージェントとして利用し、Webアプリをゼロから実装・テストまで完遂できるかを検証します。
先に結論
RTX 4070 Ti SUPER 16GB + RAM 32GBのPCでも、Qwen3.8-27B Q4_K_Mは安定して動作しました。
OpenCodeからWebアプリ作成を任せた結果は、
- 16K：主要部分まで実装したものの、コンテキスト上限に達して未完
- 32K：実装・修正・テスト・README作成まで完遂
となりました。
実測結果を比較すると以下のとおりです。
| 項目 | 8K | 16K | 32K |
|---|---|---|---|
| Context | 8,192 | 16,384 | 32,768 |
| 生成速度 | 約10.19〜10.69 tok/s | 約7.8〜9.5 tok/s | 約6.66〜8.11 tok/s |
| Ollama CPU / GPU配置 | 24% / 76% | 約27% / 73% | 32% / 68% |
| VRAM使用量 | 約14.9GiB | 約14.9GiB | 約14.7〜14.8GiB |
| 最大Context使用 | ― | 16,383 | 約19,189 |
| 切り詰め | ― | あり | なし |
| OpenCodeコーディング課題 | 未実施 | 未完 | 完遂 |
8Kでは基本応答の性能を確認し、16K・32KでOpenCodeによるコーディング課題を実施しています。
コンテキストを増やすと生成速度は低下しましたが、今回の課題では32Kにすることで最後まで完遂できました。
検証環境
使用したPCです。
| 項目 | 環境 |
|---|---|
| OS | Ubuntu 24.04.2 LTS |
| CPU | AMD Ryzen 7 7800X3D |
| RAM | 32GB（Linux上では約30GiB） |
| GPU | NVIDIA GeForce RTX 4070 Ti SUPER |
| VRAM | 16GB（nvidia-smiでは16,376MiB） |
| NVIDIA Driver | 580.173.02 |
| Ollama | 0.32.13 |
CUDA Toolkitのnvccは未導入ですが、OllamaによるGPU推論には問題ありませんでした。
NVIDIAドライバやCUDAの変更・再インストールも行っていません。
使用したモデルはこちらです。
hf.co/unsloth/Qwen3.8-27B-GGUF:Q4_K_M
Ollamaで確認した情報は、
- パラメータ数：27.3B
- 量子化：Q4_K_M
- モデルサイズ：約18GB（Ollama登録サイズ）
- 対応機能：thinking / tools / vision
でした。正確な登録サイズは18,034,383,602 bytesです。
取得は以下です。
ollama pull hf.co/unsloth/Qwen3.8-27B-GGUF:Q4_K_M
約18GBのモデルを16GB VRAMで動かす
Q4_K_Mモデルは約18GBあります。
RTX 4070 Ti SUPERのVRAMは16GBなので、モデル全体をVRAMだけには載せられません。
今回の環境では、モデルの一部をGPU側のVRAM、一部をCPU側のRAMへロードして実行しています。
Qwen3.8-27B Q4_K_M
│
├─ GPU側 → VRAM → GPUで処理
│
└─ CPU側 → RAM → CPUで処理
ollama psで確認した配置は以下でした。
| Context | CPU / GPU配置 |
|---|---|
| 8K | 24% / 76% |
| 16K | 約27% / 73% |
| 32K | 32% / 68% |
ここでいう32% CPU / 68% GPUは、CPU使用率・GPU使用率ではありません。
Ollama上でモデルがCPU側とGPU側へどの程度分割配置されているかを示しています。
つまり、約18GBのモデルをVRAMとRAMへ分けてロードすることで、16GB VRAMのGPUでもQwen3.8-27Bを実行できています。
8Kで基本性能を確認
最初は8,192 tokensで日本語応答を確認しました。
例えば、
Linuxサーバーのディスク使用率が90%を超えました。
システム運用担当者として、最初に確認すべき項目を簡潔に説明してください。
と質問すると、正常に日本語で回答しました。
主な実測値です。
| 項目 | 結果 |
|---|---|
| 初回モデルロード | 31.05秒 |
| Warm時ロード | 0.24秒 |
| 初回生成速度 | 10.19 tok/s |
| 2回目生成速度 | 10.69 tok/s |
| CPU / GPU配置 | 24% / 76% |
| VRAM使用量 | 約14.9GiB |
| GPU温度 | 最大約52℃ |
短い応答では、おおむね10 tokens/sec前後でした。
OpenCodeからローカルQwenを使う
次に、OllamaのOpenAI互換API経由でOpenCodeからQwenを利用しました。
接続先は、
http://localhost:11434/v1
OpenCodeは以下で起動しています。
ollama launch opencode
ここから、単純なチャットではなくコーディングエージェントとしてどこまで自律的に作業できるかを確認します。
テスト課題：SRE Incident Viewerを作る
OpenCodeに、システム運用向けWebアプリ
「SRE Incident Viewer」
を空のディレクトリから作成させました。
主な要件は、
- Python / Flask
- サンプル監視ログ生成
- CPU / Memory / Disk / HTTP 500 / Service Down
- INFO / WARNING / CRITICAL
- ログ解析
- Severity別・ホスト別集計
- 最新イベント表示
- hostname / severity / keywordフィルター
/api/events/api/summary- pytest
- README
です。
外部DB、Docker、認証、外部AI APIは使わない条件にしました。
単にコードを書くだけではなく、
設計
↓
実装
↓
テスト
↓
エラー解析・修正
↓
README
↓
完了確認
まで一度に任せます。
16K：実装は進んだがコンテキスト不足で停止
まず16,384 tokensで実行しました。
最終状態は、
n_tokens = 16383
truncated = 1
となり、ほぼ上限まで使用しています。
それでも、
- ログ生成
- ログ解析
- Flaskアプリ
- HTML
- 自動テスト
までは実装しました。
途中では、HTTP 500を含むログ行が正規表現に一致しない問題も検出。
pytestを実行して原因を調べ、logparser.pyを修正して再テストまで進んでいます。
しかしコンテキストを使い切り、
- README未作成
- pytestの最終成功を確定できず
- 完了報告まで到達せず
という状態で終了しました。
実作業時間は約29分です。
実装やデバッグはできても、今回の課題を一度に完走するには16Kでは不足したという結果です。
32K：実装からREADMEまで完遂
次に32,768 tokensへ増やしました。
Modelfileは以下です。
FROM qwen3.8-27b-q4km-16k:latest
PARAMETER num_ctx 32768
ollama create qwen3.8-27b-q4km-32k \
-f Modelfile.qwen3.8-27b-q4km-32k
既存Layerが再利用されたため、約18GBのモデル本体を再ダウンロードする必要はありませんでした。
32Kで実際に使用した最大コンテキストは、
約19,189 / 32,768 tokens
でした。
すべての区間でtruncated=0です。
作成された主なファイルは、
app.py
loggen.py
templates/index.html
test_app.py
README.md
logs/sample.log
です。
実作業時間は約39分43秒でした。
最終的に、
- Webダッシュボード
- ログ生成・解析
- Severity分類・集計
- 最新イベント
- 3種類のフィルター
- JSON API
- 自動テスト
- README
まで実装されています。
テストとブラウザで動作確認
初回pytestでは3件失敗しましたが、その後OpenCodeがtest_app.pyを修正して再実行しています。
最後にpytestキャッシュを無効化して確認しました。
env PYTHONDONTWRITEBYTECODE=1 \
.venv/bin/python \
-m pytest -q -p no:cacheprovider
結果は、
................ [100%]
16 passed in 0.08s
全16件が成功しました。
ブラウザでも確認します。
.venv/bin/python app.py --port 5050
http://127.0.0.1:5050/
200件のイベントが表示され、
- INFO：72
- WARNING：57
- CRITICAL：71
と集計されました。
さらにhostname = web-01、severity = CRITICALで絞り込むと、18件のCriticalイベントだけが表示され、集計にも正しく反映されました。
ブラウザコンソールにもJavaScriptエラーや警告はありませんでした。
Qwen3.8-27B + OpenCodeがゼロから作成したSRE Incident Viewer
完走したが、そのまま完成品ではない
32Kでは一連の作業を最後まで完遂できましたが、課題もあります。
特に大きかったのがThinkingです。
最長の区間では、
Thinking：7,747 tokens
時間：約18分41秒
速度：6.91 tokens/sec
となり、約40分の総作業時間のうち、1回のThinkingだけで半分近くを使いました。
成果物にも、
- 200件を一括表示してページが長い
- ページングがない
- timestampがISO形式のまま
- Criticalの優先表示が弱い
といった改善点があります。
また、サンプルログには、
HTTP 200 ratio 100.9%
のような不自然な値も生成されました。
初回テスト失敗後にはテストコード自体も修正されているため、テスト変更の妥当性も含め、最終的な品質確認は人間が行う必要があります。
今回の評価としては、
動くものを自律的に作り、テスト・修正・文書化まで進められる。
ただし、完成品として扱うには人間のレビューが必要。
というところです。
約7 tokens/secをどう見るか
32Kでは主に約6.8〜7.3 tokens/secでした。
高速とは言えません。
対話しながら細かい修正を何度も繰り返す用途では、待ち時間が気になります。
一方、今回は約40分の間に、
設計 → 実装 → テスト → 修正 → README
まで自律的に進みました。
そのため今回の環境は、
「高速なチャットAI」より「時間を渡して仕事をさせるローカルエージェント」
として捉える方が合っていると感じました。
まとめ
RTX 4070 Ti SUPER 16GB + RAM 32GBで、
Qwen3.8-27B Q4_K_M + Ollama + OpenCode
を検証しました。
結果として、
- 約18GBの27BモデルをVRAMとRAMへ分割して実行できた
- 8Kでは約10 tokens/sec
- 16Kではコンテキスト上限に達して課題未完
- 32Kでは最大約19K tokensを使用して完遂
- 約40分でWebアプリの実装・修正・テスト・README作成まで進んだ
- 最終テスト16件成功
- ブラウザ表示・フィルター操作も成功
- OOMや異常終了は発生しなかった
ことを確認できました。
特に面白かったのは、
「自宅PCだけでも、数十分待てば27Bモデルにまとまった開発作業を任せられる」
ことです。
一方、Thinkingの長さや生成速度、成果物の品質確認にはまだ課題があります。
クラウドLLMをそのまま置き換えるというより、
ローカルで繰り返し動かせる、自分専用の作業エージェント
として考えると面白い選択肢だと感じました。
次は、このSRE Incident ViewerにQwen自身を組み込み、監視イベントから原因候補・確認項目・一次対応案を出すローカルSREエージェントへ発展させてみます。