【PR】この記事にはA8.netのアフィリエイト広告を含みます。
先に結論：GPUなしでも、小型モデルならOllamaを実用的な速度で動かせました。XServer VPS 4 vCPUでQwen3 0.6Bを実測した中央値は、1スレッド36.23、2スレッド51.32、4スレッド65.12 token/秒です。4スレッドは1スレッドの約1.80倍速く、総時間は44.0%短縮しました。ただしCPU時間は増えるため、悩みの判定は一部解決です。
2026年9月1日、同じ日本語75 tokenを入力し、同じ256 tokenを生成しました。各条件でwarm-up 1回を除外し、本番3回の中央値を採用。Ollamaの生成時間だけでなく、Linux cgroupのCPU使用時間、RAMピーク、swap、公開APIの生存も記録しています。
- GPUなしPCでもOllamaは動く？
- RedditではOllamaとllama.cppの速度差に何が報告された？
- 今回のXServer VPSとCPU構成
- 実験前のRAM・swap・ストレージ
- Qwen3 0.6Bの固定条件
- Ollamaの速度はどう計算した？
- 1・2・4スレッド各3回の実測結果
- 中央値では4スレッドが65.12 token/秒
- なぜCPUを4倍使っても4倍速にならない？
- 初回だけ遅いのはなぜ？
- RAMとswapは足りた？
- 1・2・4スレッドはどう使い分ける？
- XServer VPSで解決できる部分
- XServer VPS 4GBで解決できない部分
- 初心者が迷いやすいポイント
- 結論：GPUなしOllamaはXServer VPSで実用になる？
- 最新条件の確認先
GPUなしPCでもOllamaは動く？
動きます。ただし、モデルサイズとCPUスレッド設定で待ち時間が大きく変わります。
Zennの「GPUが無い環境でローカルLLMを動かす方法」は、GPUなしのノートPCへDockerとOllamaを導入し、CPU割り当て、軽量モデル、量子化、swap対策を紹介しています。同記事もCPU実行には遅さがあり、モデル選定が重要だと説明しています。
今回は「CPUを増やせば本当に速くなるのか」を、同一VPS・同一モデル・同一出力長で数値化しました。
RedditではOllamaとllama.cppの速度差に何が報告された？
Redditのr/LocalLLaMAには、CPUのみの第8世代Core i7・16GB DDR3で、同じQwen3 0.6B Q4_K_Mなのに、Ollamaは20 token/秒超、llama.cppは1〜3 token/秒だったという相談があります。投稿者はllama-serverへ4 threadsを指定していました。
これはユーザー投稿で、ビルド、CPU、メモリ、引数が今回と異なります。Ollamaとllama.cppの優劣を一般化せず、「thread数だけを変えた場合」に範囲を絞りました。
今回のXServer VPSとCPU構成
| 項目 | 実測・表示値 |
|---|---|
| VPS | 4 vCPU / 4GB RAM / 150GB NVMe SSD |
| CPU表示 | AMD EPYC-Milan Processor |
| コア | 4 cores / 1 thread per core |
| 命令セット | AVX2、AVX-512を確認 |
| GPU | なし |
| Ollama | 0.33.2公式Dockerイメージ |
VPSのCPU表示は物理CPUの製品型番や占有を保証するものではありません。今回は同じ契約環境内の相対比較として扱います。
実験前のRAM・swap・ストレージ
| 項目 | 実験前 |
|---|---|
| RAM | 545MB used / 3904MB total |
| MemAvailable | 3358MB |
| swap | 125MB / 2047MB |
| ストレージ | 15GB / 145GB（11%） |
| 公開API | database=ok、artifact_storage=ok |
前回のGemma 4 OOM試験後にホストswapが残っているため、今回も開始値を隠さず記録しました。テストコンテナのswapは別途cgroupで測ります。
Qwen3 0.6Bの固定条件
| 設定 | 値 |
|---|---|
| モデル | qwen3:0.6b / Q4_K_M |
| モデル容量 | 522,653,767 bytes |
| 入力 | 同一日本語75 token |
| 出力 | 256 token |
| context | 4096 |
| temperature / seed | 0 / 42 |
| thinking | 無効 |
| Docker RAM上限 | 2GiB、追加swapなし |
変更したのは`num_thread`の1・2・4だけです。出力は全試行で上限の256 tokenに達し、比較する生成量を揃えました。
Ollamaの速度はどう計算した？
Ollama公式Generate APIは、`total_duration`、`load_duration`、`prompt_eval_count`、`prompt_eval_duration`、`eval_count`、`eval_duration`を返します。生成速度は次の式で求めました。
token/秒 = eval_count ÷ (eval_duration ÷ 1,000,000,000)
ネットワークやJSON処理の揺れを避けるため速度にはサーバー値を使い、CPU量はcgroup `cpu.stat`の`usage_usec`増分をクライアント壁時計時間で割りました。
1・2・4スレッド各3回の実測結果
| threads | run | total | tok/s | 平均使用コア |
|---|---|---|---|---|
| 1 | 1 | 7.147秒 | 36.121 | 0.963 |
| 1 | 2 | 7.078秒 | 36.502 | 0.962 |
| 1 | 3 | 7.093秒 | 36.231 | 0.963 |
| 2 | 1 | 4.996秒 | 51.785 | 1.898 |
| 2 | 2 | 5.032秒 | 51.320 | 1.900 |
| 2 | 3 | 5.210秒 | 49.318 | 1.909 |
| 4 | 1 | 4.232秒 | 61.057 | 3.691 |
| 4 | 2 | 3.975秒 | 65.123 | 3.721 |
| 4 | 3 | 3.792秒 | 67.842 | 3.738 |
VPSには他のコンテナも動いているため、試行ごとの揺れがあります。単発の最速値ではなく中央値で判断します。
中央値では4スレッドが65.12 token/秒
| threads | total中央値 | tok/s中央値 | 平均コア中央値 | 4 vCPU比 |
|---|---|---|---|---|
| 1 | 7.093秒 | 36.231 | 0.963 | 24.1% |
| 2 | 5.032秒 | 51.320 | 1.900 | 47.5% |
| 4 | 3.975秒 | 65.123 | 3.721 | 93.0% |
- 2 threadsは1 threadより41.6%高速
- 4 threadsは1 threadより79.7%高速
- 4 threadsのtotalは1 threadより44.0%短い
- 4 threadsでも1 threadの4倍速にはならない
なぜCPUを4倍使っても4倍速にならない？
4 threadsは平均3.721コアを使い、1 threadは0.963コアでした。使用コアは約3.86倍ですが、生成速度は約1.80倍です。スレッド間の同期、メモリアクセス、推論ランタイムの直列部分などがあり、CPU数と速度は比例しません。
今回のCPU時間中央値は、1 threadの約7.213秒から4 threadsの約16.319秒へ増えました。短い待ち時間を優先するなら4 threads、計算資源の節約を優先するなら1〜2 threadsという交換条件です。
初回だけ遅いのはなぜ？
warm-up時のモデルロードは1.385〜2.117秒でした。本番9回のloadは0.652〜0.846msです。モデルがRAMへ常駐しているため、2回目以降はロード時間をほぼ省けました。
初回と2回目以降を混ぜるとスレッド比較を誤るため、各条件のwarm-upは集計から外しています。
RAMとswapは足りた？
| 安全性指標 | 実測値 |
|---|---|
| memory.peak | 2,053,185,536 bytes（約1.912GiB） |
| OOM | 0 |
| コンテナswap peak | 0 |
| コンテナ再起動 | 0 |
| 試験後モデル常駐中のMemAvailable | 2223MB |
| 公開ready API | 正常 |
2GiB上限のほぼ全量を使いましたがOOMはなく、Caddy、FastAPI、PostgreSQLもhealthyを維持しました。このメモリ値はQwen3 0.6B・context 4096の結果です。
1・2・4スレッドはどう使い分ける？
| 設定 | 向く用途 | 注意点 |
|---|---|---|
| 1 thread | 低優先度バッチ、他サービス優先 | 待ち時間が最長 |
| 2 threads | API・DBと共存する常用設定 | 4 threadsより約21%遅い |
| 4 threads | 単発ジョブを早く終えたい | 4 vCPUの約93%を使用 |
今回のAI調査システムでは、通常ジョブは2 threads、利用者が待つ単発要約は4 threadsを候補にします。同時リクエストでは別の最適値になるため、並列負荷は後続記事で測ります。
XServer VPSで解決できる部分
- GPUなしでも0.6B級モデルを常時稼働できる
- スレッド数と待ち時間の関係を同一環境で測れる
- cgroupでCPU・RAM・swapをサービス単位に記録できる
- 公開APIとAI実験を同じVPSで隔離できる
- 自宅PCを起動せず、分類や短文生成を処理できる
XServer VPS 4GBで解決できない部分
- 7B・14Bモデルを0.6Bと同じ速度で動かすこと
- CUDA、ROCm、MetalなどGPU性能の再現
- 自宅PC固有のCPU・RAM帯域を予測すること
- 4 threadsで他サービスのCPU余裕も同時に最大化すること
初心者が迷いやすいポイント
- GPUなしで「動く」と「実用速度」を分けて考える
- 文字/秒とtoken/秒を混同しない
- 初回ロードを本番推論の中央値へ混ぜない
- スレッド数を増やせば比例して速くなると思わない
- モデル、量子化、context、出力tokenを固定して比べる
- ホストCPU全体とコンテナCPUを分けて測る
結論：GPUなしOllamaはXServer VPSで実用になる？
Qwen3 0.6Bの短文生成なら実用になりました。4 threadsで65.123 token/秒、2 threadsでも51.320 token/秒です。既存APIとの共存を考えると2 threads、単発の速度を優先するなら4 threadsが今回の候補です。
ただし、小型モデルの速度は大規模モデルの代替を意味しません。XServer VPS 4GBには分類、整形、ジョブ制御などの軽い推論を担当させ、重いモデルだけ自宅GPUや外部推論先へ送る構成が現実的です。
[PR] AI実験用VPSの最新料金・仕様を確認する
VPSでいろいろ試すなら『XServer VPS』
実験日：2026年9月1日。同じVPSでも混雑、Ollama、モデル、context、Docker制限で結果は変わります。ZennとRedditの数値は各投稿者の環境での報告であり、今回の実測と同一条件ではありません。
コメント