Ryzen AI PCのローカルLLM環境を一度まっさらにする Ryzen AI PCのローカルLLM環境を一度まっさらにする

はじめに

少し前に、AMD の Ryzen AI 搭載ノートPCでもローカルLLMが実用速度で動くのか試して、 Lemonade Server と Qwen の組み合わせで環境を作りました。実際、動きました。

ただ、あれから半年近く経っています。その間に、

• モデルを試すたびにダウンロードして、消さずに置きっぱなし
• 推論バックエンドの設定が、当時の試行錯誤のまま
• すでにアンインストールしたはずのツールの設定ファイルだけが残っている

という、よくある「積み上がった状態」になりました。

新しい方法で組み直すにあたって、この上に重ねても良いことがありません。 一度まっさらにしてから作り直すことにして、今回はその掃除の回です。

このシリーズは全5回くらいを予定しています。 今回（第1回）は掃除、次回から新環境の設計と構築に入ります。

対象マシン

項目	内容
CPU	AMD Ryzen AI 9 HX 370 (12コア / 24スレッド)
iGPU	AMD Radeon 890M
NPU	XDNA2
メモリ	96 GB
OS	Windows 11 Pro
ドライバ	AMD Software 26.8.1

メモリ 96 GB というのがこの構成の肝で、 ディスクリートGPUが無くても大きめのモデルをまるごとメモリに載せられます。

まず棚卸しから

消す前に、何が残っているのかを確認します。 記憶だけで消しにいくと、だいたい消し残すか、消してはいけないものを消します。

インストール済みのソフトを探す

$paths = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -match 'lemonade|ollama|LM Studio|ROCm|Ryzen AI|llama' } |
  Select-Object DisplayName, DisplayVersion, UninstallString | Format-List

結果、残っていたのは Lemonade Server 11.5.1 だけでした。

動いているプロセスとポートを見る

Get-Process | Where-Object { $_.Name -match 'lemonade|ollama|llama|ryzenai' } |
  Select-Object Name, Id, Path

LemonadeServer.exe が常駐していました。しかも自動起動の設定付きです。

そして、ここで一つ引っかかったのがポートでした。 http://localhost:8000 を叩いても応答がありません。設定を読むと、

Get-Content "$env:USERPROFILE\.cache\lemonade\config.json" | ConvertFrom-Json |
  Select-Object port, host

port: 13305 でした。過去の記事のつもりで 8000 を叩いても繋がらないわけです。

(Invoke-RestMethod 'http://localhost:13305/api/v1/models').data | Select-Object id

登録されていたモデルは 5 つ。

Gemma-4-E4B-it-GGUF
Qwen3-8B-Hybrid
Qwen3.6-35B-A3B-GGUF
Qwen3.6-35B-A3B-MTP-GGUF
Qwen3.6-35B-A3B-MTP-ThinkingCoder   ← 自分で作ったカスタム定義

容量を食っているものを探す

ここが本題です。

Get-ChildItem "$env:USERPROFILE\.cache\huggingface\hub" -Directory | ForEach-Object {
  $sz = (Get-ChildItem $_.FullName -Recurse -File -EA SilentlyContinue |
         Measure-Object Length -Sum).Sum / 1GB
  "{0,10:N2} GB  {1}" -f $sz, $_.Name
} | Sort-Object -Descending

サイズ	リポジトリ
22.12 GB	unsloth/Qwen3.6-35B-A3B-MTP-GGUF
21.66 GB	unsloth/Qwen3.6-35B-A3B-GGUF
9.47 GB	unsloth/Qwen3.6-27B-MTP-GGUF
8.77 GB	amd/Qwen3-8B-awq-quant-onnx-ryzenai-1.7-hybrid
5.56 GB	unsloth/gemma-4-E4B-it-GGUF

合計 67.58 GB。 35B 系の GGUF が 2 リポジトリで 43 GB あり、ほぼ重複です。 「MTP 版とそうでない版、どっちが速いのか」を比べたときのものが、 比べたきり両方残っていました。

さらに、Lemonade が自分でダウンロードした推論バックエンドが別にあります。

Get-ChildItem "$env:USERPROFILE\.cache\lemonade\bin" | ForEach-Object {
  $sz = (Get-ChildItem $_.FullName -Recurse -File -EA SilentlyContinue |
         Measure-Object Length -Sum).Sum / 1MB
  "{0,8:N0} MB  {1}" -f $sz, $_.Name
}

   1079 MB  ryzenai-server
    156 MB  llamacpp

アンインストーラはこれを消してくれません。 手で消す必要があります。

棚卸しの結果を整理すると、こうなりました。

アンインストーラが面倒を見てくれるのは、いちばん上の 0.01 GB だけです。 残り 68.84 GB は自分で消すことになります。

モデルの内訳も見ておきます。

上の 2 本が効いています。どちらも同じ Qwen3.6 35B で、MTP 版とそうでない版。 合わせて 43.78 GB が実質的な重複でした。

棚卸しでわかった3つのこと

1. Ollama はすでに消えていた

前回 Ollama を入れたつもりでいましたが、痕跡が一切ありませんでした。

foreach ($d in "$env:USERPROFILE\.ollama",
               "$env:LOCALAPPDATA\Programs\Ollama",
               "$env:APPDATA\Ollama") { "{0}: {1}" -f $d, (Test-Path $d) }
Get-Command ollama -ErrorAction SilentlyContinue

全部 False、コマンドも無し。どこかの時点でアンインストール済みでした。 記憶で消しにいかなくて正解だった例です。

2. CPU 推論のままだった

config.json を読んでいて気づいたのがこれです。

"llamacpp": {
  "backend": "cpu",
  ...
}

Radeon 890M も NPU も積んでいるのに、llama.cpp を CPU バックエンドで回していました。 96 GB のメモリのおかげで 35B クラスが動いてしまっていたので、 「動いてるからいいか」で放置されていたわけです。

新環境を作る一番の動機がこれになりました。

3. 死んだ設定が残っていた

~/.config/opencode/opencode.json が、もう存在しない Ollama を指したままでした。

{
  "provider": {
    "ollama": {
      "options": { "baseURL": "http://127.0.0.1:11434/v1" }
    }
  },
  "model": "ollama/qwen3.6:27b"
}

実害は「起動しても繋がらない」だけですが、これも掃除の対象です。

掃除の手順

0. 消す前にバックアップ

自分でチューニングした設定だけは退避します。 特に user_models.json と recipe_options.json は、 サンプリングパラメータを詰めた結果なので消すと惜しいです。

$backup = "$env:USERPROFILE\Desktop\llm-backup"
New-Item -ItemType Directory -Force -Path $backup | Out-Null
Copy-Item "$env:USERPROFILE\.cache\lemonade\*.json" $backup

1. サーバを停止する

常駐したままだとファイルを掴んでいて、アンインストールに失敗します。

Get-Process LemonadeServer -ErrorAction SilentlyContinue | Stop-Process -Force

2. Lemonade Server をアンインストールする

MSI なので msiexec で消せます。プロダクトコードは棚卸しで調べた UninstallString に入っています。

Start-Process msiexec.exe -ArgumentList '/X{プロダクトコード} /quiet /norestart' -Wait

「設定 > アプリ > インストールされているアプリ」からでも同じです。

3. バックエンドと設定を消す

アンインストーラが残していく 1.2 GB です。

Remove-Item "$env:USERPROFILE\.cache\lemonade" -Recurse -Force

4. モデルキャッシュを消す

今回いちばん効くところです。67.6 GB。

Remove-Item "$env:USERPROFILE\.cache\huggingface" -Recurse -Force

全部消すか迷いましたが、全消しにしました。理由は2つで、

• 35B の GGUF は実質重複していて、どちらを残すかを今決める意味がない
• ONNX 版は ryzenai-1.7 向け。新環境では対応バージョンが変わる可能性が高い

回線が細い環境なら、Qwen3.6-35B-A3B-MTP-GGUF（22 GB）だけ残す手はあります。

5. 自動起動の残骸を消す

$lnk = "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\Lemonade Server.lnk"
if (Test-Path $lnk) { Remove-Item $lnk -Force }

……と身構えていたのですが、これは不要でした。 手順2のアンインストーラがショートカットまで消してくれていて、 確認した時点ですでに False を返しました。

バックエンドの 1.2 GB は残すのにショートカットは消す、というのは なかなか読めない挙動です。結局のところ、 アンインストーラが何を消して何を残すかは実際に確認するしかないということでした。

6. 死んだ設定を消す

Remove-Item "$env:USERPROFILE\.config\opencode" -Recurse -Force

7. 確認する

foreach ($d in "$env:USERPROFILE\.cache\lemonade",
               "$env:USERPROFILE\.cache\huggingface",
               "$env:LOCALAPPDATA\lemonade_server",
               "$env:USERPROFILE\.ollama") {
  "{0,-60} {1}" -f $d, (Test-Path $d)
}
Get-Command lemonade, ollama -ErrorAction SilentlyContinue

実際の結果はこうなりました。

C:\Users\Pearl19\.cache\lemonade                               False
C:\Users\Pearl19\.cache\huggingface                            False
C:\Users\Pearl19\AppData\Local\lemonade_server                 False
C:\Users\Pearl19\.ollama                                       False
C:\Users\Pearl19\.config\opencode                              False

lemonade / ollama / llama-server のコマンドも返らず、 13305 / 11434 / 8000 のどのポートも待ち受けなし。関連プロセスもゼロ。 掃除としては完了です。

空き容量が測れなかった話

きれいに終わったので、最後に「これだけ空きました」と書くつもりでした。 ところが数字を見ると、

掃除前: 1277.4 GB 空き
掃除後: 1125.9 GB 空き

約 150 GB 減っています。 69 GB 消したはずなのに、逆方向です。

フォルダは間違いなく全部消えている。ではこの数字は何なのか、と調べました。

まず 10 秒おきに空き容量を測ると、きれいに減り続けていました。

11:02:57  空き 1,134.2 GB
11:03:09  空き 1,133.2 GB
11:03:21  空き 1,131.9 GB
11:03:34  空き 1,130.5 GB

毎分およそ 6 GB。 掃除とは無関係に、何かが書き込み続けています。

候補を順に潰していきます。

• ごみ箱 → 0.09 GB。Remove-Item はごみ箱を経由しないので当然
• Windows Update のステージング（SoftwareDistribution\Download）→ 0 GB
• Docker の docker_data.vhdx → 45.54 GB あるが、測り直しても増えていない

残ったのはプロセスです。書き込みバイト数の差分を取ります。

$s1 = Get-CimInstance Win32_PerfRawData_PerfProc_Process
Start-Sleep -Seconds 15
$s2 = Get-CimInstance Win32_PerfRawData_PerfProc_Process
# IOWriteBytesPersec の差分を取って上位を見る

犯人は explorer.exe、15 秒で約 900 MB。 OneDrive の同期エンジンです。裏で延々とファイルを書き戻していました。

つまり、掃除で解放した 69 GB は、それを上回る OneDrive の書き込みに埋もれた というのが答えでした。before / after の数字としては出せません。

容量の増減を記事の数字にするつもりなら、 OneDrive・Docker・Windows Update を止めてから測るべきでした。 削除したフォルダのサイズを事前に控えておいたのは正解で、 結局「何 GB 消したか」はそちらの積み上げ（67.58 + 1.21 + 0.05 GB）で示すしかありません。

消してはいけないもの

掃除のときに巻き込みがちなので、明示的に残すと決めたものです。

残すもの	理由
AMD Software 26.8.1	GPU ドライバ本体。NPU ドライバもここに含まれる
NPU Compute Accelerator Device	デバイスそのもの。デバイスマネージャーで無効化しない
Docker Desktop	別用途で使っている
Microsoft Store 版 Python	ローカルLLM用に入れたものではない

特に AMD Software は、 「ROCm まわりを入れ直すついでに」と消しにかかると画面ごと巻き込みます。 ドライバは新環境の前提として残す、で問題ありません。

まとめ

今回わかったことを整理すると、

• 棚卸しを先にやる。 Ollama はすでに消えていたし、ポートも記憶と違っていた
• アンインストーラが何を残すかは読めない。 バックエンド 1.2 GB は残したのに、スタートアップのショートカットは消していた
• 設定ファイルは消す前に読む。 CPU 推論のままだったという、 次の環境を作る一番の理由がここから出てきた
• 消す前にサイズを控えておく。 空き容量の before / after は OneDrive の同期に埋もれて使い物にならなかった
• 削除したのは合計 68.8 GB（モデル 67.58 + バックエンド 1.21 + 設定 0.05）

次回は、この空っぽになった状態から どの推論バックエンドとモデルを選ぶかを検討するところから始めます。 iGPU（Vulkan / ROCm）と NPU をどう使い分けるのか、 そもそも 96 GB のメモリでは CPU 推論のままのほうが速いのか、 そのあたりを実際に測りながら決めていきます。