【PR】この記事にはA8.netのアフィリエイト広告を含みます。
先に結論：Ollamaが遅いときは、モデルの性能を疑う前に「バイナリのアーキテクチャ」と「実際の推論バックエンド」を分けて確認する必要があります。XServer VPSでは、ホスト・Docker・Ollama・llama-serverがすべてx86-64で一致し、`ollama ps`は100% CPU、APIは`size_vram=0`、ログは`library=cpu`でした。MacのRosetta問題そのものは直せませんが、比較基準を作れるため判定は一部解決です。
2026年9月1日、XServer VPS 4GBへOllama 0.33.2を隔離起動し、CPU/GPUデバイス、実行ファイル形式、エミュレーション、推論ランナー、メモリを実査しました。Qwen3 0.6Bの回答生成まで行い、既存のCaddy、FastAPI、PostgreSQLが停止しないことも確認しています。
- MacでOllamaが100% CPUになるのは異常？
- ZennではRosetta版Ollamaをどう確認している？
- RedditではM3 MacBook Proの100% CPUが報告された？
- XServer VPSでMacのRosetta問題を再現できる？
- 実験前のXServer VPS状態
- ホストOSのアーキテクチャ確認結果
- DockerイメージとOllama実行ファイルは一致した？
- QEMUが動いていたらエミュレーション？
- VPSにGPUは搭載されていた？
- Ollamaはどの推論バックエンドを選んだ？
- CPUバックエンドでも推論できた？
- RAM・swap・公開サービスへの影響
- 実験中に起きた小さな問題
- Mac側で確認すべき順番
- AIスマホ調査システムへ何を記録する？
- 結論：XServer VPSでRosetta・CPUフォールバック問題は解決する？
- 最新条件の確認先
MacでOllamaが100% CPUになるのは異常？
Apple Silicon上でMetal GPUを使う想定なのに100% CPUなら、実行経路を確認する必要があります。ただし、CPU表示だけでRosettaが原因とは断定できません。モデルがGPUメモリへ収まらない、Docker内でGPUへアクセスできない、対応バックエンドがないなど別の原因もあります。
Ollama公式GPUドキュメントは、AppleデバイスでMetal APIによるGPUアクセラレーションをサポートすると説明しています。想定と実表示が違うなら、確認対象はモデルだけではありません。
ZennではRosetta版Ollamaをどう確認している？
Zennの「OllamaでローカルLLMを動かす：MacのGPUを使ってQwen3.5・Gemma4・Phi-4 Miniを動かすまでの手順」は、`ollama ps`のPROCESSOR列と`file $(which ollama)`を確認する方法を紹介しています。
| Macでの表示 | 記事内の判定 |
|---|---|
| Mach-O 64-bit executable arm64 | ARMネイティブ |
| Mach-O 64-bit executable x86_64 | x86・Rosetta経由を疑う |
| ollama psが100% GPU | GPU利用を確認 |
| ollama psが100% CPU | CPUフォールバックを調査 |
これはMac向けの確認方法です。Linux VPSではMach-OではなくELF、アーキテクチャはAMD64を確認します。
RedditではM3 MacBook Proの100% CPUが報告された？
Redditのr/ollamaには、M3 Pro・18GBのMacBook Proでllama3、phi3、mistralを実行すると、`ollama ps`が100% CPUで遅かったという相談があります。投稿者はOllama公式サイトのインストーラーで再導入後に解消したと追記しています。
これは投稿者の環境での結果で、Homebrew全般や全Macに一般化できません。今回も「公式インストーラーなら必ず直る」とは結論づけず、確認手順だけを比較します。
XServer VPSでMacのRosetta問題を再現できる？
再現できません。XServer VPSはLinux・AMD64で、Apple Silicon、macOS、Rosetta 2、Metal GPUを備えていません。VPSのCPU結果からMacのGPU性能を推定することもできません。
一方、ネイティブAMD64・CPU推論の対照環境として、同じモデルとプロンプトを実行できます。Mac側の結果と比べるときに「モデル差」ではなく「実行基盤差」を明示できます。
実験前のXServer VPS状態
| 項目 | 実験前 |
|---|---|
| vCPU / RAM | 4 vCPU / 4GB |
| RAM | 571MB used / 3904MB total |
| MemAvailable | 3332MB |
| swap | 124MB / 2047MB |
| ストレージ | 15GB / 145GB（11%） |
| 公開API | database=ok、artifact_storage=ok |
ホストOSのアーキテクチャ確認結果
| 確認方法 | 結果 |
|---|---|
| uname -m | x86_64 |
| dpkg –print-architecture | amd64 |
| getconf LONG_BIT | 64 |
| Linux kernel | 7.0.0-30-generic |
| CPU表示 | AMD EPYC-Milan Processor |
`x86_64`と`amd64`は、この文脈では同じ64-bit x86系を示す表記です。1コマンドだけでなく3経路が一致することを確認しました。
DockerイメージとOllama実行ファイルは一致した？
| 層 | 実測結果 |
|---|---|
| Docker image | linux/amd64 |
| コンテナuname | x86_64 |
| Ollama本体 | ELF 64-bit x86-64 |
| llama-server | ELF 64-bit x86-64 |
ホスト、Dockerイメージ、Ollama本体、推論ランナーの4層が一致しました。少なくとも今回の実行経路に、arm64バイナリのx86変換はありません。
QEMUが動いていたらエミュレーション？
VPSには`qemu-ga`が動いていましたが、これは仮想マシンとホストを連携させるゲストエージェントです。異なるCPU命令を変換するQEMUユーザーモードとは区別します。
`binfmt_misc`にはQEMUアーキテクチャ変換用ハンドラーがなく、登録されていた`python3.14`はPython bytecode用でした。「qemu」という名前だけでエミュレーションと判断しないことがポイントです。
VPSにGPUは搭載されていた？
| 確認項目 | 結果 |
|---|---|
| nvidia-smi / /dev/nvidia* | なし |
| rocminfo / /dev/kfd | なし |
| vulkaninfo | なし |
| /dev/dri/card0 | あり |
| PCI VGA | Cirrus Logic GD 5446 |
| /dev/dri/renderD* | なし |
| Docker GPU device request | null |
Cirrus Logic VGAはVPSコンソールの画面表示用で、LLM計算用GPUではありません。`/dev/dri`が存在するだけでGPU推論可能とは判断できません。
Ollamaはどの推論バックエンドを選んだ？
CPUバックエンドです。3つの表示が一致しました。
| 確認経路 | 実測表示 |
|---|---|
| Ollama起動ログ | inference compute id=cpu library=cpu |
| ollama ps | 100% CPU |
| GET /api/ps | size_vram=0 |
| llama-server引数 | -t 2 |
環境表示には`OLLAMA_VULKAN=true`も含まれていましたが、利用可能GPUがないためCPUを選びました。環境変数の有効・無効ではなく、検出ログと稼働中モデルを確認する必要があります。
CPUバックエンドでも推論できた？
| 指標 | 実測値 |
|---|---|
| モデル | Qwen3 0.6B Q4_K_M |
| HTTP | 200 |
| total | 2.784秒 |
| load | 1.887秒 |
| prompt | 59 token / 0.259秒 |
| eval | 40 token / 0.635秒 |
| 生成速度 | 約63.00 token/秒 |
100% CPUは今回のVPSでは異常ではなく、GPUなし構成の意図どおりの結果です。MacでMetalを期待している場合と、同じ表示でも意味が異なります。
RAM・swap・公開サービスへの影響
| 安全性指標 | 実測値 |
|---|---|
| memory.peak | 1,088,749,568 bytes（約1.014GiB） |
| OOM / OOM kill | 0 / 0 |
| コンテナswap peak | 0 |
| Docker再起動 | 0 |
| モデル常駐中のMemAvailable | 2319MB |
| 公開ready API | 正常 |
Caddy、FastAPI、PostgreSQLはhealthyを維持しました。検証後は専用コンテナを削除し、RAM availableは3329MBへ戻りました。
実験中に起きた小さな問題
実行ファイル形式を確認するため、Ollamaバイナリを`/tmp`へ一時コピーしました。Dockerからコピーしたファイルはroot所有となり、一般ユーザーでの削除は「許可されていない操作」になりました。
対象が`/tmp/llmo-exp-07-ollama`だけであることを確認し、sudoで削除して解決しました。VPSでDockerファイルを取り出すと、所有者が変わる点は初心者が迷いやすい部分です。
Mac側で確認すべき順番
- `uname -m`でMacのOSアーキテクチャを確認する
- `file $(which ollama)`でOllama本体がarm64か確認する
- 推論中に`ollama ps`のPROCESSOR列を確認する
- OllamaのデバッグログでMetal・GPU・errorを確認する
- モデル容量、context、メモリ圧力を確認する
- Docker版ならApple GPUがコンテナへ渡る前提を再確認する
Ollama公式Issueでは、Apple Silicon MacのDocker DesktopはApple GPUをコンテナへ公開せず、コンテナ内OllamaはCPU実行になるとOllamaコラボレーターが説明しています。MacでGPUを使いたい場合、ネイティブアプリとDockerを同じ前提で扱わないことが重要です。
AIスマホ調査システムへ何を記録する？
VPSから自宅PCへ推論を依頼するときは、回答だけでなく次のメタデータも結果へ保存します。
- host_os、host_arch
- Ollamaとrunnerのbinary_arch
- モデル名、量子化、context
- processor表示、backend library
- size_vram、RAM peak、swap peak
- total、prompt eval、eval token/秒
同じスマホ調査ジョブが急に遅くなったとき、モデルの品質問題と実行基盤の変更を切り分けられます。
結論：XServer VPSでRosetta・CPUフォールバック問題は解決する？
Mac固有の問題はVPSだけでは解決しません。今回のVPSにはMetalもRosettaもなく、Macの再インストールやGPU利用を遠隔で保証できないためです。
ただし、XServer VPSではホスト、Docker、Ollama、runner、backendを一貫して記録できました。ネイティブAMD64・CPU推論の対照データを持ち、自宅Mac側でも同じ項目を返す仕組みにすれば、「何となく遅い」をアーキテクチャとバックエンドの問題へ分解できます。司令塔としては有効、というのが今回の結論です。
[PR] AI実験用VPSの最新料金・仕様を確認する
VPSでいろいろ試すなら『XServer VPS』
実験日：2026年9月1日。MacのOllama、Metal、Rosetta、Docker対応はバージョンで変わります。導入時はOllama公式ドキュメントを確認してください。ZennとRedditの内容は各投稿者の環境での報告です。
コメント