Dify の公式ドキュメントが示す要件は「CPU 2コア以上、メモリ 4GiB 以上」です。ただ、「4GiB あれば足りるのか」「2GB のプランでは本当に動かないのか」は書かれていません。そこで、公式の Docker Compose で Dify 1.17.1 を起動し、コンテナごとのメモリ使用量を実際に測りました。
結論：4GB のプランを最低ラインにする
| 状態 | 合計 | 2GB のプラン | 4GB のプラン |
|---|---|---|---|
| 起動して何もしていないとき | 約1.93GiB | 余裕3%（実質的に不足） | 余裕52% |
| 再起動の直後（ピーク） | 約2.13GiB | 不足 | 余裕47% |
- 2GB のプランでは足りません。 起動して待つだけでほぼ使い切り、再起動のたびに 2GB を超えます。ここに OS や Docker 自体が使う分が加わります。
- 4GB のプランが最低ラインです。公式の要件とも一致します。
- 8GB のプランを選ぶ目安は、ナレッジベースに多くの文書を入れる場合、n8n など別のアプリと同居させる場合、複数人で使う場合です。
アイドル時の内訳
起動して管理者アカウントを作成し、10分待ってから測った値です。
目立つのは「アプリ本体」です。api、api_websocket、worker、worker_beat の4つは、いずれも同じ dify-api のイメージから起動する Python のプロセスで、それぞれ約370〜400MiB を使っていました。4つを合わせると約1.52GiB で、全体の約8割を占めます。
一方、データベース（PostgreSQL）、キャッシュ（Redis）、ベクトルDB（Weaviate）は、データが入っていない状態ではいずれも 100MiB を下回りました。文書を登録すると、このグループが増えていくと考えられます。
再起動の直後のピーク
docker compose restart を実行した直後から、3秒間隔で60回取得し、コンテナごとの最大値を取りました。
合計は約2.13GiB で、アイドル時より約200MiB 多くなりました。増えたのはベクトルDB、サンドボックス、プラグイン、プロキシなどで、起動処理で一時的に使う分です。なお、コンテナごとに最大になる時刻は違うため、この合計は「同時に使う量の上限の目安」です。
測っていないこと
今回の値は、データが空の状態のものです。次の場合はこれより増えるはずですが、まだ測っていません。
- ナレッジベースに文書を登録しているとき（分割とベクトル化の処理）
- プラグインを多数インストールしたとき
- 複数人で同時に使っているとき
- 初回起動時（データベースの初期化を含む）。今回は2回目以降の起動を測りました
メモリを減らせる設定はあるか
.env には、ワーカーの数に見える CELERY_WORKER_AMOUNT（既定は 4）という設定があります。ただ、1.17.1 の起動スクリプトを読むと、ワーカーは既定で gevent という方式で動きます。この方式は1つのプロセスの中で処理を切り替えるため、CELERY_WORKER_AMOUNT はプロセスの数ではなく、同時に扱う処理の数を表します。
そのため、この値を下げてもメモリはほとんど減らないと考えられます（コードを読んで判断したもので、実測はしていません）。下げると、文書の登録などのバックグラウンド処理が遅くなるだけになりかねません。メモリが足りない場合は、設定で削るよりもプランを上げるほうが確実です。
プランを選ぶときの考え方
| 使い方 | 目安 |
|---|---|
| 1人で試す、少数の文書を登録する | 4GB |
| ナレッジベースに多くの文書を入れる、チームで使う | 8GB |
| n8n などほかのアプリと同じサーバーで動かす | 8GB |
同居させた場合の実測は、Dify と n8n を1台の VPS で動かすと何GB必要かで解説しています。構築の手順はDify を VPS にセルフホストする手順をご覧ください。
検証環境についての注意
測定は macOS 上の Docker（Linux 仮想マシン、arm64）で行いました。メモリの使い方は VPS（多くは x86_64）と大きくは変わらない見込みですが、同じ値になる保証はありません。CPU の速度は比べられないため、この記事では扱っていません。