【PR】この記事にはA8.netのアフィリエイト広告を含みます。
先に結論：Windows WDDMでnvidia-smiのプロセス別VRAMがN/Aになる仕様は、XServer VPSでは直せません。しかし、VPS側のAI処理ならDocker名・役割ラベル・cgroup v2を使い、CPU・RAM・block I/Oをサービス別に帰属できます。3ワーカーを同時実行した結果、CPU 85.09%はCPU型、RAM 388.95MiBはメモリ型、384MiB書込みはI/O型へ3/3で正しく結び付きました。判定は一部解決です。
2026年9月1日、XServer VPS 4GBでCPU、メモリ、ディスク書込みの3コンテナを同時起動し、約1秒間隔で16回測定しました。公開APIの生存、取得できる項目、取得できない項目、ページキャッシュの落とし穴まで記録しています。
- Windowsでnvidia-smiのプロセス別VRAMがN/Aになるのは故障？
- NVIDIA公式はWDDMのN/Aをどう説明している？
- Zennではプロセス別VRAMをどう調べている？
- RedditではN/A表示をどう悩んでいる？
- XServer VPSでWDDMのプロセス別VRAMを取得できる？
- Docker公式ではどんな統計を取得できる？
- 実験前のXServer VPS状態
- 3つのテストサービスはどう作った？
- 何を何秒間隔で取得した？
- サービス別CPU・RAM・I/Oの結果
- CPU型ワーカーは本当にCPU最大になった？
- メモリ型ワーカーは384MiBだけ使った？
- I/O型ワーカーのRAMが約255MiBになったのはなぜ？
- block I/Oは書込みログと一致した？
- 実験中に発生した問題と解決方法
- 取得できた項目・取得できない項目
- AIスマホ調査システムではどう記録する？
- XServer VPSで便利だった点・分かりにくかった点
- 既存サービスへの影響は？
- よくある質問
- XServer VPSでこの悩みはどこまで解決する？
- 最新条件の確認先
Windowsでnvidia-smiのプロセス別VRAMがN/Aになるのは故障？
WDDM環境では仕様であり、直ちにGPUやドライバの故障とは言えません。NVIDIA公式ドキュメントは、Windows WDDMモードではWindowsのKMDがメモリを管理するため、GPU Memory Usageを利用できないと説明しています。
GPU全体の使用量が表示されても、各PIDの列がN/Aになる場合があります。「N/Aだから誰も使っていない」という意味ではありません。
NVIDIA公式はWDDMのN/Aをどう説明している？
NVIDIA System Management Interface公式ドキュメントでは、プロセス情報のGPU Memory Usageについて、WDDMではWindows KMDがすべてのメモリを管理するため取得不可と明記されています。
| 表示 | 意味 |
|---|---|
| GPU全体のMemory-Usage | 全体量として確認できる場合がある |
| プロセス別GPU Memory Usage=N/A | WDDMの管理方式による取得不可 |
| PID・Process Name | プロセス自体は列挙される場合がある |
| N/A | 使用量0の意味ではない |
Zennではプロセス別VRAMをどう調べている？
Zennの「GeForce + Windowsで『VRAM食ってる犯人』をプロセス単位で特定する」は、WDDMでnvidia-smiのプロセス別VRAMがN/Aになることを説明し、Windows性能カウンターのGPU Process Memoryを使う方法を紹介しています。
同記事はDedicated Usageが予約量、Local Usageが物理VRAM上の実数という違いにも注意しています。VPSのcgroupにもページキャッシュなど意味の違う値があるため、数字の名称と定義を保存する点は共通です。
RedditではN/A表示をどう悩んでいる？
Redditのr/buildapcには「GPU performance confusion」という相談があります。アイドル時に1.5GBのGPUメモリ使用がある一方、タスクマネージャーでは全プロセス0%、nvidia-smiのGPU memory usageもすべてN/Aだったという内容です。
このような環境では、GPU全体値、Windows性能カウンター、PID、アプリログを組み合わせる必要があります。今回のVPS実験はその代替ではなく、サーバー側だけでもサービス帰属を残す試みです。
XServer VPSでWDDMのプロセス別VRAMを取得できる？
取得できません。今回のXServer VPSにはNVIDIA GPU、nvidia-smi、/dev/nvidia*がありません。Windows WDDMやGPU Process Memoryカウンターも存在しません。
測定できるのは、VPS上で動く各コンテナのCPU時間、RAM、block I/O、PID数です。自宅PCのGPU情報は自宅PC側で取得し、同じジョブIDへ紐付ける設計が必要です。
Docker公式ではどんな統計を取得できる？
Docker公式のdocker statsは、コンテナ名、CPU%、メモリ使用量・上限、ネットワークI/O、block I/O、PID数を表示できます。さらにRuntime metricsは、Linux cgroupからCPU、メモリ、block I/Oを取得できると説明しています。
今回は表示用の文字列ではなく、cgroup v2の累積バイト・マイクロ秒を採取し、前後差を計算しました。
実験前のXServer VPS状態
| 項目 | 実験前 |
|---|---|
| 契約構成 | 4 vCPU / 4GB RAM / 150GB NVMe SSD |
| cgroup | v2 |
| RAM available | 約3.52GB |
| nvidia-smi | unavailable |
| /dev/nvidia* | none |
| 公開API | database=ok、artifact_storage=ok |
3つのテストサービスはどう作った？
| コンテナ | role | 負荷 | 制限 |
|---|---|---|---|
| llmo-exp-10-cpu | cpu | SHA-256反復 | 1 CPU / 256MiB |
| llmo-exp-10-memory | memory | 384MiB確保・保持 | 0.5 CPU / 512MiB |
| llmo-exp-10-io | io | 384MiB書込み・fsync | 0.5 CPU / 256MiB |
各コンテナにはllmo.roleラベルを付け、PID上限64、追加swapなし、restart=noに統一しました。
何を何秒間隔で取得した？
| 指標 | cgroup v2 | 単位 |
|---|---|---|
| CPU | cpu.stat / usage_usec | µs |
| RAM | memory.current | bytes |
| block I/O | io.stat / rbytes・wbytes | bytes |
| PID | pids.current | 件 |
| 役割 | Docker名・llmo.role | 文字列 |
0〜15の16サンプルを取得しました。初回を除く間隔は1,062〜1,081ms、中央値1,071ms、平均1,072.2msです。計測窓は16.169秒でした。
サービス別CPU・RAM・I/Oの結果
| サービス | 平均CPU | peak RAM | read | write |
|---|---|---|---|---|
| cpu | 85.09% | 6.57MiB | 0 | 0 |
| memory | 1.49% | 388.95MiB | 0 | 0 |
| io | 0.67% | 254.92MiB | 4KiB | 384MiB |
CPU最大はcpu、RAM最大はmemory、書込み最大はioでした。投入した3つの役割と最大指標が3/3で一致しています。
CPU型ワーカーは本当にCPU最大になった？
CPUワーカーのusage_usec増分は13,758,026µsでした。計測窓16,168,526µsに対して85.09%です。
1 CPU上限の中で高負荷となり、メモリ保持やI/O完了後に待機するサービスと明確に区別できました。
メモリ型ワーカーは384MiBだけ使った？
アプリが確保したのは384MiB、cgroupのpeakは388.95MiBでした。Pythonランタイムや共有ライブラリなどの分だけ増えています。
「アプリデータの大きさ」と「サービス全体のmemory.current」は同じではありません。記事や監視画面では測定対象を明示する必要があります。
I/O型ワーカーのRAMが約255MiBになったのはなぜ？
書込みページキャッシュもcgroupのmemory.currentへ計上されたためです。I/OワーカーのPythonデータは約1MiBですが、384MiBを書き込む途中でpeak RAMは254.92MiBになりました。
Docker公式は、LinuxのCLI表示ではキャッシュを差し引いてメモリ使用量を示すと説明しています。cgroup生値とdocker statsの見た目が違っても、直ちに測定ミスとは限りません。
block I/Oは書込みログと一致した？
I/Oワーカーのログとcgroup書込み量は384MiBで一致しました。どのコンテナがディスクへ書いたかをサービス名へ帰属できます。
実験中に発生した問題と解決方法
初回の監視はサンプル採取前に停止しました。io.stat集計関数が改行なしで値を返し、厳格モードのreadがEOFを非ゼロ終了として扱ったためです。
cleanup処理で3コンテナが削除されたことを確認し、集計結果の末尾へ改行を追加して最初から再実行しました。2回目は16サンプルを最後まで取得できました。
取得できた項目・取得できない項目
| 項目 | 結果 |
|---|---|
| サービス別CPU時間 | 取得可能 |
| サービス別RAM | 取得可能、キャッシュを含む |
| サービス別block I/O | 取得可能 |
| サービス別PID数 | 取得可能 |
| Windows WDDMのプロセス別VRAM | 取得不能 |
| GPU温度・電力・クロック | GPUがないため取得不能 |
AIスマホ調査システムではどう記録する？
| 保存フィールド | 用途 |
|---|---|
| job_id / service / role | どの調査処理か識別 |
| started_at / sample_interval | 時系列を再現 |
| cpu_usage_usec | CPU消費の累積値 |
| memory.current / peak | RAM圧迫を確認 |
| rbytes / wbytes | 成果物の読書込みを確認 |
| Android側GPU/VRAM計測 | 自宅PCまたは端末側の別エージェントが保存 |
Windows側のGPU情報とVPS側のcgroup情報を同じjob_idへ集約すれば、1回のスマホ調査で端末・PC・VPSのどこが重かったか後から比較できます。
XServer VPSで便利だった点・分かりにくかった点
| 観点 | 実体験 |
|---|---|
| 便利 | コンテナ名とラベルで処理単位の統計を分離できた |
| 便利 | 1秒間隔の無人収集と公開API監視を同時実行できた |
| 便利 | 失敗した初回もcleanupで一時コンテナを回収できた |
| 分かりにくい | RAM生値にはページキャッシュが含まれる |
| 限界 | WDDM・VRAM・GPU電力はVPS単体では測れない |
既存サービスへの影響は？
公開readyは16/16回HTTP 200で、database=ok、artifact_storage=okでした。3ワーカーはすべてExit 0、OOMKilled=false、再起動0回です。
検証コンテナとVPS上の一時スクリプトを削除しました。実験後はRAM 615MB used、3.48GB available、swap 129MB used、ストレージ使用率11%。Caddy、FastAPI、PostgreSQLはhealthyでした。
よくある質問
WDDMでN/AならVRAM使用量は調べられない？
nvidia-smiのプロセス別列だけでは取得できません。WindowsのGPU Process Memory性能カウンターなど、Windows側の仕組みを併用します。
docker statsとmemory.currentは同じ値？
同じとは限りません。LinuxのDocker CLIはキャッシュを差し引いた表示を行い、cgroup生値はページキャッシュを含みます。
VPSにGPUを追加すれば同じ設計を使える？
ジョブ名・ラベル・CPU/RAM/I/O記録は継続利用できます。GPUを追加した場合はGPU UUID、VRAM、温度、電力などの別コレクターが必要です。
XServer VPSでこの悩みはどこまで解決する？
判定は一部解決です。Windows WDDMのN/A表示やRTXのプロセス別VRAMを、GPUなしのXServer VPSが解決するわけではありません。一方、VPS側ではCPU 85.09%、RAM 388.95MiB、書込み384MiBを正しいサービスへ3/3で帰属できました。
AIによるスマホ一次情報収集では、Android操作、自宅PCのGPU処理、VPSの司令塔処理を同じジョブIDで結びます。これにより「GPUの内訳が見えない」問題が残っても、少なくともVPS上のAPI、OCR、要約、成果物保存のCPU・RAM・I/Oは実測値として記事へ残せます。
コメント