はじめに

ローカル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エージェントへ発展させてみます。