tk3.biz
ブログ一覧に戻る Back to Blog

Ryzen AI PCのローカルLLM環境を一度まっさらにする Wiping the Local LLM Setup on My Ryzen AI PC Clean

はじめに

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

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

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

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

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

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

対象マシン

項目内容
CPUAMD Ryzen AI 9 HX 370 (12コア / 24スレッド)
iGPUAMD Radeon 890M
NPUXDNA2
メモリ96 GB
OSWindows 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 GBunsloth/Qwen3.6-35B-A3B-MTP-GGUF
21.66 GBunsloth/Qwen3.6-35B-A3B-GGUF
9.47 GBunsloth/Qwen3.6-27B-MTP-GGUF
8.77 GBamd/Qwen3-8B-awq-quant-onnx-ryzenai-1.7-hybrid
5.56 GBunsloth/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

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

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

掃除前に残っていたもの。Lemonade Server 本体 0.01 GB だけがアンインストーラの守備範囲で、バックエンド 1.21 GB・モデル 67.58 GB・opencode の設定 0.05 GB の計 68.84 GB は手で消す必要がある。Ollama は痕跡なし

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

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

削除したもの合計68.84GBの内訳。Qwen3.6-35B-A3B-MTP-GGUF 22.12GB、Qwen3.6-35B-A3B-GGUF 21.66GB、Qwen3.6-27B-MTP-GGUF 9.47GB、Qwen3-8B(ONNX/NPU向け)8.77GB、gemma-4-E4B-it-GGUF 5.56GB、推論バックエンドと設定 1.26GB

上の 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",
               "$env:USERPROFILE\.config\opencode") {
  "{0,-60} {1}" -f $d, (Test-Path $d)
}
Get-Command lemonade, ollama -ErrorAction SilentlyContinue

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

C:\Users\<user>\.cache\lemonade                                False
C:\Users\<user>\.cache\huggingface                             False
C:\Users\<user>\AppData\Local\lemonade_server                  False
C:\Users\<user>\.ollama                                        False
C:\Users\<user>\.config\opencode                               False

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

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

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

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

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

C:の空き容量の推移。期待した動きは1277.4GBから1346.2GBへ増えるはずだったが、実測は削除直後から45分後まで下がり続け1125.9GBになった。裏でOneDriveが毎分約6GB書き込んでいた

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

まず 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.1GPU ドライバ本体。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 推論のままのほうが速いのか、 そのあたりを実際に測りながら決めていきます。

Introduction

A while ago, I tested whether a local LLM could run at a usable speed on an AMD Ryzen AI laptop, and built a setup with Lemonade Server and Qwen. And it did work.

But that was almost half a year ago. In the meantime, I ended up in the usual “piled-up” state:

  • I downloaded models every time I tried one, and never deleted them
  • The inference backend settings were still whatever I’d landed on through trial and error back then
  • Config files were left behind for tools I thought I had already uninstalled

Now that I’m rebuilding with a newer approach, there’s nothing to gain by stacking it on top of all this. I decided to wipe everything once and rebuild from scratch, and this post covers that cleanup.

I’m planning about five posts in this series. This one (part 1) is the cleanup; from the next one I’ll move on to designing and building the new setup.

The Machine

ItemDetails
CPUAMD Ryzen AI 9 HX 370 (12 cores / 24 threads)
iGPUAMD Radeon 890M
NPUXDNA2
Memory96 GB
OSWindows 11 Pro
DriverAMD Software 26.8.1

The 96 GB of memory is the key to this configuration: even without a discrete GPU, you can fit fairly large models entirely in memory.

Start with an Inventory

Before deleting anything, I checked what’s actually left. If you go deleting from memory alone, you usually either miss something or delete something you shouldn’t.

Finding Installed Software

$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

The only thing left was Lemonade Server 11.5.1.

Checking Running Processes and Ports

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

LemonadeServer.exe was running in the background, and it was even set to start automatically.

Then one thing tripped me up: the port. Requests to http://localhost:8000 got no response. Reading the config:

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

It was port: 13305. No wonder hitting 8000, as in my earlier post, didn’t connect.

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

Five models were registered.

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   ← 自分で作ったカスタム定義

(The last one is a custom definition I made myself.)

Finding What Eats Up the Space

This is the main part.

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
SizeRepository
22.12 GBunsloth/Qwen3.6-35B-A3B-MTP-GGUF
21.66 GBunsloth/Qwen3.6-35B-A3B-GGUF
9.47 GBunsloth/Qwen3.6-27B-MTP-GGUF
8.77 GBamd/Qwen3-8B-awq-quant-onnx-ryzenai-1.7-hybrid
5.56 GBunsloth/gemma-4-E4B-it-GGUF

67.58 GB in total. The 35B GGUFs take up 43 GB across two repositories, and they’re nearly duplicates. They were from when I compared “which is faster, the MTP version or the regular one?”, and after the comparison I just left both.

On top of that, there are the inference backends Lemonade downloaded by itself.

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

The uninstaller doesn’t remove these. You have to delete them by hand.

Putting the inventory together, here’s what I found.

What was left before the cleanup. Only the Lemonade Server app itself (0.01 GB) is covered by the uninstaller; the backends (1.21 GB), models (67.58 GB) and opencode config (0.05 GB), 68.84 GB in total, have to be deleted by hand. No trace of Ollama

The uninstaller takes care of only the 0.01 GB at the top. The remaining 68.84 GB is up to me.

Let’s also look at the breakdown of the models.

Breakdown of the 68.84 GB deleted: Qwen3.6-35B-A3B-MTP-GGUF 22.12 GB, Qwen3.6-35B-A3B-GGUF 21.66 GB, Qwen3.6-27B-MTP-GGUF 9.47 GB, Qwen3-8B (ONNX, for the NPU) 8.77 GB, gemma-4-E4B-it-GGUF 5.56 GB, inference backends and config 1.26 GB

The top two are what really count. Both are the same Qwen3.6 35B, one MTP version and one regular. Together, 43.78 GB was effectively duplicated.

Three Things the Inventory Revealed

1. Ollama Was Already Gone

I thought I had installed Ollama last time, but there wasn’t a trace of it.

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

All False, and no command either. I had uninstalled it at some point. A good example of why not deleting from memory was the right call.

2. It Was Still Running Inference on the CPU

I noticed this while reading config.json.

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

Despite having a Radeon 890M and an NPU, I was running llama.cpp with the CPU backend. Thanks to the 96 GB of memory, 35B-class models ran anyway, so it had been left alone with a “well, it works” attitude.

This became the main motivation for building the new setup.

3. Dead Config Was Left Behind

~/.config/opencode/opencode.json was still pointing to an Ollama that no longer existed.

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

The only real harm is “it starts but can’t connect,” but this is on the cleanup list too.

Cleanup Steps

0. Back Up Before Deleting

I set aside only the settings I had tuned myself. In particular, user_models.json and recipe_options.json hold the sampling parameters I had dialed in, so it would be a shame to lose them.

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

1. Stop the Server

If it keeps running, it holds files open and the uninstall fails.

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

2. Uninstall Lemonade Server

It’s an MSI, so msiexec can remove it. The product code is in the UninstallString I looked up during the inventory.

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

(Replace {プロダクトコード} with the product code.) Going through Settings > Apps > Installed apps does the same thing.

3. Delete the Backends and Config

This is the 1.2 GB the uninstaller leaves behind.

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

4. Delete the Model Cache

This is the step that makes the biggest difference. 67.6 GB.

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

I hesitated over whether to delete everything, but I wiped it all. For two reasons:

  • The 35B GGUFs are effectively duplicates, so there’s no point deciding now which one to keep
  • The ONNX version targets ryzenai-1.7, and the supported version is likely to change in the new setup

If your connection is slow, you could keep just Qwen3.6-35B-A3B-MTP-GGUF (22 GB).

5. Remove Leftover Auto-Start Entries

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

…or so I braced myself, but this turned out to be unnecessary. The uninstaller in step 2 had already removed the shortcut, and when I checked, it already returned False.

Leaving the 1.2 GB of backends but deleting the shortcut is pretty hard-to-predict behavior. In the end, the only way to know what an uninstaller removes and what it leaves is to actually check.

6. Delete the Dead Config

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

7. Verify

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

Here’s the actual result.

C:\Users\<user>\.cache\lemonade                                False
C:\Users\<user>\.cache\huggingface                             False
C:\Users\<user>\AppData\Local\lemonade_server                  False
C:\Users\<user>\.ollama                                        False
C:\Users\<user>\.config\opencode                               False

The lemonade / ollama / llama-server commands returned nothing, and none of the ports 13305 / 11434 / 8000 were listening. Zero related processes, too. As far as cleanup goes, it’s done.

I Couldn’t Measure the Freed Space

Since it all went cleanly, I planned to finish with “this is how much space I freed.” But when I looked at the numbers:

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

(Before the cleanup: 1277.4 GB free; after: 1125.9 GB free.)

It had dropped by about 150 GB. I should have deleted 69 GB, but it went the other way.

Free space on C: over time. The expected behavior was to rise from 1277.4 GB to 1346.2 GB, but the measured value kept falling from right after the deletion to 45 minutes later, reaching 1125.9 GB. OneDrive was writing about 6 GB per minute in the background

The folders were definitely all gone. So what was this number? I looked into it.

First I measured the free space every 10 seconds, and it kept going down steadily.

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

About 6 GB per minute. Something unrelated to the cleanup kept writing.

I ruled out the candidates one by one.

  • Recycle Bin → 0.09 GB. Naturally, since Remove-Item doesn’t go through the Recycle Bin
  • Windows Update staging (SoftwareDistribution\Download) → 0 GB
  • Docker’s docker_data.vhdx → 45.54 GB, but it hadn’t grown when I measured again

That left processes. I took the difference in bytes written.

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

(The comment means: take the difference in IOWriteBytesPersec and look at the top entries.)

The culprit was explorer.exe, about 900 MB in 15 seconds. It was OneDrive’s sync engine, endlessly writing files back in the background.

So the answer was that the 69 GB the cleanup freed was buried under even more OneDrive writes. I can’t show it as a before / after number.

If I wanted the change in disk space to be a number in a post, I should have stopped OneDrive, Docker and Windows Update before measuring. Noting down the sizes of the folders before deleting them was the right move: in the end, the only way to show “how many GB I deleted” is to add those up (67.58 + 1.21 + 0.05 GB).

What Not to Delete

These are things that easily get caught up in a cleanup, so I explicitly decided to keep them.

KeepReason
AMD Software 26.8.1The GPU driver itself. The NPU driver is included here too
NPU Compute Accelerator DeviceThe device itself. Don’t disable it in Device Manager
Docker DesktopI use it for other things
Microsoft Store PythonNot something I installed for local LLMs

AMD Software in particular: if you go to remove it “while I’m at it, reinstalling the ROCm bits,” you take your display down with it. Keep the driver as a prerequisite for the new setup, and you’re fine.

Summary

Here’s what I learned this time:

  • Take inventory first. Ollama was already gone, and the port wasn’t what I remembered
  • You can’t predict what an uninstaller leaves behind. It left 1.2 GB of backends but removed the startup shortcut
  • Read config files before deleting them. That’s where I found I was still on CPU inference, the main reason for building the next setup
  • Note the sizes before deleting. The before / after free space was buried under OneDrive syncing and was useless
  • I deleted 68.8 GB in total (models 67.58 + backends 1.21 + config 0.05)

Next time, starting from this empty state, I’ll begin by considering which inference backend and model to choose. How should I split work between the iGPU (Vulkan / ROCm) and the NPU? And with 96 GB of memory, is staying on CPU inference actually faster? I’ll decide those while actually measuring.

関連記事 Related Posts

Ryzen AI PCのローカルLLMを7倍速くした話(llama.cpp + Vulkan + Qwen) How I Made the Local LLM on My Ryzen AI PC 7 Times Faster (llama.cpp + Vulkan + Qwen)

まっさらにしたRyzen AI 9 HX 370機に、llama.cppとVulkanでローカルLLM環境を作り直しました。CPU推論から約7倍。最新モデルを選んで失敗した話と、ファイルが大きいほうが速いという実測結果をまとめます。 I rebuilt the local LLM setup on my freshly wiped Ryzen AI 9 HX 370 machine with llama.cpp and Vulkan: about 7 times faster than CPU inference. Here's how picking the newest model backfired, and measurements showing the bigger file was faster.

Ryzen AI の NPU を使わなかった理由 Why I Didn't Use the Ryzen AI NPU

50 TOPS の NPU を積んだ機体でローカルLLMを動かしてきましたが、一度も NPU を使っていません。使えるのか調べたら、動く保証がなく、動いても iGPU より遅く、最大の利点が自分の使い方では効かないと分かりました。インストーラを落としたところで止めた記録です。 I've been running local LLMs on a machine with a 50 TOPS NPU, but I've never used the NPU. When I looked into whether I could, I found there's no guarantee it runs, it's slower than the iGPU even if it does, and its biggest advantage doesn't apply to how I use it. A record of stopping right after downloading the installer.

ローカルLLMにメモリは何GB必要か: 96GB積んだミニPCで実測した How Much Memory Does a Local LLM Need? Measured on a Mini PC with 96GB

Ryzen AI ミニPCに96GBのメモリを積んでローカルLLMを動かし、実際に何GB使っているかを測りました。35BのMoEモデルで24GiB、コンテキストを上限の256Kまで伸ばしても28GiB程度です。32GB・64GB・96GBでそれぞれ何ができそうかを、実測と推定を分けて整理します。 I ran a local LLM on a Ryzen AI mini PC with 96GB of memory and measured how many GB it actually uses. A 35B MoE model takes 24GiB, and even with the context stretched to its 256K limit, it stays around 28GiB. I sort out what 32GB, 64GB and 96GB are each likely to handle, keeping measurements and estimates apart.