2026 Qwen3.5 CPU導入に必要なメモリは？モデルを計算してからサーバーを選ぶ

モデルファイルの容量だけを見てサーバーを選び、実行時にメモリ不足になることがあります。
結論：CPU-onlyで試験、低頻度の推論、バッチ処理を行うなら、量子化重み・コンテキストキャッシュ・実行環境のピークを測ってから選びます。高い処理量や同時応答が必要なら、大容量メモリをGPUの代わりと考えず、別の算力構成を検討してください。

Qwen3.5をCPU-onlyで導入する開発者や小規模チーム向けです。
モデルとコンテキストのメモリを見積もり、用途に合うサーバーを選ぶ手順を整理します。

メモリ予算の起点

Qwen3.5のCPU導入に必要なメモリは、モデルのパラメーター数だけでは決まりません。最初の概算には「パラメーター数 × 量子化ビット数 ÷ 8」を使えます。これは量子化された重みの概算であり、実行時に必要な合計メモリを示す式ではありません。

計算の前に、利用するモデルの正確なタグ、パラメーター数、量子化方式、ダウンロード後のファイル容量を確認します。Qwen3.5の公開状況やライセンスは、公式リポジトリのリリース記録とモデル情報で確かめてください。利用するタグとファイル情報は、変更される可能性があるため、Ollamaのモデル一覧でも導入時に確認します。

この式にモデルのパラメーター数と量子化ビット数を入れると、重みの概算が得られます。ただし、実際の量子化モデルには方式ごとの差があり、メタデータなども含まれます。概算値より、取得したモデルファイルの容量と実行時の測定値を優先してください。

コンテキストと同時処理の影響

推論時のメモリには重み以外に、コンテキストを扱うためのキャッシュや推論用バッファーが加わります。コンテキスト長を伸ばした場合や、同時に複数のリクエストを処理する場合は、その条件でピークを測定します。

モデルの構造が分かり、キャッシュの形式や精度を指定できる場合は、レイヤー数、KVヘッド数、コンテキスト長、キャッシュのデータ型などから概算する方法もあります。ただし、モデルと推論フレームワークの設定で値が変わるため、式だけで実メモリを断定しないでください。画像などを扱う場合も、入力内容や処理経路による追加バッファーを実リクエストで確かめます。

注意：重みの容量がサーバーの空きメモリ以内でも、実行中のキャッシュや他サービスの使用量が重なると、メモリ不足になることがあります。コンテキストと同時処理数を本番想定に合わせて測定してください。

推論以外の常駐メモリ

OS、コンテナ、アプリケーション、ベクトル検索などを同じサーバーで動かす場合、それぞれのメモリをモデルとは別に記録します。DifyやOpen WebUIなどのアプリを載せる予定なら、モデル単体の測定結果だけで容量を決めず、各サービスを起動した状態で確認します。

Dockerのコンテナにメモリ制限を設けている場合、コンテナ内で上限に達することと、サーバー全体のメモリが不足することは同じではありません。Dockerのリソース制約に関する説明を確認し、コンテナの上限とホスト側の使用量を分けて見ます。Linuxでは/procの情報も使えますが、確認する値の意味はカーネルのprocファイルシステム文書に照らしてください。

CPU-only導入の確認手順

導入は、モデルを起動して終わりではなく、使用予定の条件に近づけて段階的に測定します。

1. モデルとライセンスを確定します。 利用するタグ、ファイル容量、モデルの種類、ライセンスを公式情報で確認し、用途に合うものだけを取得します。
2. 利用条件を固定します。 推論フレームワーク、量子化方式、コンテキスト長、同時リクエスト数、入力の種類を記録します。後で比較できるよう、プロンプトも保存します。
3. モデル単体の基準値を取ります。 推論サービスを起動し、標準的なリクエストと想定最大のリクエストを実行します。Linuxの/proc/<PID>/statusにあるVmHWMや、/usr/bin/time -vの最大常駐メモリを確認できます。
4. 本番予定の条件で再測定します。 コンテキストの長さや同時処理を変えて、ピークの推移を記録します。推論サーバーの設定と利用方法は、llama.cppのサーバー文書を参照し、実際の起動条件に合わせてください。
5. 同居サービスを追加します。 アプリ、ベクトル検索、監視などを順に起動し、推論単体との差分とホスト全体のピークを記録します。コンテナを使う場合は、コンテナ別の制限とホストの空き容量を別々に確認します。
6. 余裕を含めて構成を決めます。 測定したピークに、OSや同居サービスの常駐分と運用上の余裕を加えます。ピークに収まるだけの容量で決めず、再起動やデータ更新時の一時的な使用量も確認します。

CPU-onlyの用途と処理速度

「モデルをメモリに載せられるか」と「応答速度や処理量が要件を満たすか」は別の判断です。メモリを増やせば、モデルやキャッシュを配置できる余地は広がりますが、それだけでCPU推論が速くなるとは限りません。

対象のEPYC 7543Pは、8チャネルのDDR4-3200メモリを扱います。理論帯域の計算は8 × 25.6 GB/sで約204.8 GB/sですが、これは仕様から導く理論値であり、Qwen3.5の実測速度や処理量を示すものではありません。AMDのEPYC 7543仕様を確認しつつ、利用予定のモデル、プロンプト、推論設定で実測してください。

よくある確認事項

Qwen3.5のCPU-only導入では、何を足してメモリを見積もりますか？

量子化重みの概算に、コンテキストキャッシュと推論用バッファーを加えます。さらにOS、コンテナ、アプリ、ベクトル検索などの常駐分を別に見積もり、実際の同時処理条件でピークを測定します。固定の最低容量だけで判断せず、利用するモデルとサービス構成を先に確定してください。

量子化モデルのファイル容量は、実行時の必要メモリと同じですか？

同じとは限りません。ファイル容量は重みの目安ですが、実行時にはキャッシュや作業領域などが加わります。量子化方式にも差があるため、実ファイルを確認した後、対象の推論環境で測定します。ファイルがメモリに収まることだけを理由に、必要容量を決めないでください。

コンテキスト長を変えるとき、何を測り直しますか？

コンテキスト長と同時リクエスト数を変えた条件で、ピークメモリを測り直します。モデルや推論方式によってキャッシュの増え方が異なるため、一律の増加量は置けません。画像など異なる種類の入力を使う場合も、本番で扱う入力を含めて確認します。

CPU-onlyのままでよい用途と、別構成を検討する用途は何ですか？

検証、低頻度の利用、急がないバッチ処理は、実測した待ち時間や完了時間が要件内ならCPU-onlyを候補にできます。短い応答時間や高い処理量が必要で、CPUの測定値が届かない場合は、メモリの増量だけで解決しようとせず、GPUを含む別構成を評価します。

実測からサーバー構成へ

実測したピークを、モデル、推論サービス、同居アプリに分けて記録し、必要な常駐分と余裕を加えてから構成を比較します。CloudUDPの製品仕様では、AMD EPYC 7543P搭載の独占物理サーバーに、128GBまたは256GBのDDR4-3200 ECC RDIMM構成があります。メモリは注文時に選ぶ構成で、後から増設できる仕様ではありません。詳細はCloudUDPのプラン情報で確認してください。

選定条件は次のように分けられます。

• 実測ピークにOS・同居サービス・運用余裕を加えても収まり、応答時間も許容範囲なら、CPU-only構成を選びます。
• メモリは足りる一方で応答時間が足りないなら、容量を増やす前にCPU推論を継続できるか判断し、要件に届かなければGPUを含む別構成に戻します。
• 推論単体では足りるのに同居サービスで不足するなら、サービスを別サーバーに分けるか、実測ピークに合うメモリ構成を選び直します。
• ファイル容量やコンテキスト条件が未確定なら、契約を急がず、先に実際のモデルとリクエストで測定します。

最終確認と構成選び

2026年10月24日更新。Qwen3.5の公開情報は公式リポジトリとOllamaのモデル一覧、ハードウェア仕様はAMDの製品情報を参照して確認しています。モデルのタグ、ファイル容量、ライセンス、推論フレームワークの対応は更新されるため、導入時に再確認してください。

共有VPSや共有クラウドは、手軽に始めやすい一方、プランによってCPU資源の共有、利用上限、ストレージや転送条件の違いがあり、モデル推論と複数の常駐サービスをまとめた負荷を把握しにくい場合があります。負荷を分離して測定したうえで、CPU資源とメモリを独占して長期運用したいなら、CloudUDPの物理サーバーを候補にし、プランと注文条件を確認してください。CPU-onlyの実測が応答時間や処理量の要件に届かない場合は、GPUを利用できる別の算力構成を先に評価するのが適切です。

よくある質問