~/ / AI記事 / ローカルLLM × VPS / Ollamaの埋め込み(embedding)をPostgreSQLのpgvectorで保存して検索する

Ollamaの埋め込み(embedding)をPostgreSQLのpgvectorで保存して検索する

Ollamaの /api/embed が返すembeddingは、どこかに保存して初めて検索に使えます。pgvectorは、PostgreSQLにベクトルの類似度検索を加えるオープン出典の拡張機能で、ベクトルを文章やほかのデータと同じデータベース、同じサーバーに置けます。この記事では、pgvector 0.8.7のREADMEをもとに、インストール、テーブルの作成、距離とインデックスの選び方、結果を変える設定を説明します。そのあと、検索結果をOllamaの /api/chat に渡して回答が出典を示すようにし、その引用を確認します。SQLは、Ollamaで作った実際のベクトルを使い、PostgreSQL 16上のpgvector 0.8.7で実行し、チャットのリクエストはqwen2.5:7bを使ってOllama 0.40.11で実行しました。このページの4つのツールは、SQLとリクエストを書き、回答の確認をブラウザ上で行います。

この記事の末尾に、アフィリエイト広告(PR)のリンクがあります。

公開: · 約15分で読めます · ここに書いた事実は、pgvector 0.8.7のREADMEとソースコード、およびOllamaのドキュメントとソースコード(0.40.11)で2026-11-05に確認しました。頼りにする前に、最新のドキュメントを確認してください。

pgvectorがPostgreSQLに加えるもの

pgvectorのREADMEは、これをPostgres向けのオープンソースのベクトル類似度検索と説明しています。厳密な最近傍探索と近似最近傍探索に対応し、単精度、半精度、バイナリ、スパースのベクトルを扱え、L2距離、内積、コサイン距離、L1距離、ハミング距離、ジャカード距離を使えます。ベクトルは通常のPostgreSQLの列なので、ACID準拠、ポイントインタイムリカバリ、JOINも使えます。

文書を検索するときは、チャンクごとに1行、テキストとベクトルを保存します。質問は同じモデルでembeddingにし、質問のベクトルとの距離で行を並べ替えます。

インストールする

pgvectorはPostgreSQL 13以降に対応しています。READMEには複数のインストール方法が載っており、次のようなものがあります。

方法READMEの説明
ソースからビルドgit clone --branch v0.8.7 のあと、make と make install(sudo が必要な場合があります)
Dockerpgvector/pgvector イメージは、Postgresのイメージにpgvectorを加えたものです。pg18-trixie や 0.8.7-pg16 のようなタグでPostgresのバージョンを選びます。
APT(Debian、Ubuntu)PostgreSQL APT Repositoryから sudo apt install postgresql-18-pgvector を実行します。18 は使っているPostgresのバージョンに置き換えます。
Homebrewbrew install pgvector。postgresql@18 と postgresql@17 のformulaにだけ追加されます。

そのあと、使いたいデータベースごとに1回、CREATE EXTENSION vector; で有効にします。この記事では、Dockerイメージ pgvector/pgvector:0.8.7-pg16 を使いました。

テーブルを作る

vector(n) 型の列には、ちょうどnの次元を持つベクトルが入ります。nはembeddingモデルが返すベクトルの長さに合わせる必要があります。長さの違うベクトルは拒否されます。vector(3) の列に2次元のベクトルを入れたとき、PostgreSQLは "expected 3 dimensions, not 2" と返しました。all-minilm は384次元を返すので、その列は vector(384) になります。

READMEによると、ベクトル1つの保存サイズは 4 × 次元数 + 8 バイトで、各要素は単精度の浮動小数点数です。1つの列には最大16,000次元まで入れられます。インデックスが扱える次元数はそれより少なく、後で示します。halfvec 型は半精度の値を 2 × 次元数 + 8 バイトで保存します。

次元数vectorhalfvec
3841,544 バイト776 バイト
7683,080 バイト1,544 バイト
10244,104 バイト2,056 バイト

手元のテスト用テーブルでは、pg_column_size は vector(384) で1,544バイト、halfvec(384) で776バイトを返し、式と一致しました。これはベクトルだけのサイズで、テキストの列とインデックスにはこれとは別に容量がかかります。

Ollamaのベクトルを読み込む

pgvectorは、'[1,2,3]' のように角括弧で囲んだテキストをベクトルとして読みます。READMEによると、すべての要素は有限でなければなりません(NaN、Infinity、-Infinity は不可)。/api/embed のレスポンスの embeddings フィールドにある各配列は、すでにこの形をしています。レスポンスは入力の順序を保つので、1つ目のテキストが1つ目のベクトルに対応します。

READMEでは、数行なら INSERT、upsertなら INSERT … ON CONFLICT、まとめて読み込むなら COPY を使う例が示されています。下の変換ツールは、テキストとレスポンスを対応づけ、引用符をエスケープした INSERT 文を書きます。引用符、バックスラッシュ、改行、絵文字を含むテキストでその出力を実行したところ、変わらずに戻ってきました。

試してみる: Embeddings to pgvector INSERT

例では、読みやすいように、作り物の4次元で長さ1のベクトルを使っています。実際のembeddingは数百から数千次元です。

4 次元の 3 行。テキストは /api/embed のリクエストボディ、ベクトルは Ollama /api/embed のレスポンス として読みました。

INSERT 文

psqlなどのクライアントで実行します。行は1つのトランザクションで挿入されます。

BEGIN;

INSERT INTO documents (content, embedding) VALUES
  ('Embeddings turn text into numeric vectors.', '[0.620186,0.410123,0.550165,0.380114]'),
  ('pgvector stores vectors in PostgreSQL, next to the rest of your data.', '[0.578815,0.469039,0.518937,0.419142]'),
  ('Ollama''s /api/embed returns one vector per input, in the same order.', '[0.119982,0.809879,-0.329951,0.46993]');

COMMIT;

ベクトルの形式はpgvectorのREADMEによるもので、2026-11-04にpgvector 0.8.7で確認しました。 pgvector README

すべてブラウザ上で処理します。このツールはSQLを書くだけで、どこにも接続しません。

距離を選ぶ

Ollamaのドキュメントは、ほとんどのセマンティック検索ではコサイン類似度を勧めており、/api/embed は長さ1のベクトルを返すと書いています。そのようなベクトルでは、L2距離の2乗が「2 − 2 × コサイン類似度」になるため、コサイン距離、L2距離、内積のどれでも行の並び順は同じになります。all-minilm を使った手元のテストでは、3つのどれでも上位3行は同じで、L2距離0.931はコサイン類似度0.566と一致しました。

距離ごとに専用の演算子があります。検索はその演算子で並べ替え、LIMIT で先頭の行を取ります。インデックスは1つの演算子クラスに対して作ります。

演算子返すものインデックスの演算子クラス
<=>コサイン距離。コサイン類似度は 1 - (a <=> b) です。vector_cosine_ops
<->L2(ユークリッド)距離vector_l2_ops
<#>内積の符号を反転したもの。内積にするには -1 を掛けます。vector_ip_ops
<+>L1距離vector_l1_ops

READMEによると、<#> が内積の符号を反転した値を返すのは、Postgresが演算子に対する ASC 順のインデックススキャンしかサポートしていないためです。halfvec の演算子クラスは、halfvec_cosine_ops、halfvec_l2_ops などです。

厳密な検索か、インデックスか

インデックスがないと、pgvectorは厳密な最近傍探索を行い、READMEによれば完全な再現率(recall)が得られます。近似インデックスは、再現率を少し犠牲にして速度を得るものです。READMEは、インデックスを追加すると、クエリの結果が変わることがあると注意しています。

インデックスが使われるのは、クエリに ORDER BY と LIMIT があり、ORDER BY が距離の演算子そのものを昇順で使っているときだけです。ORDER BY embedding <=> $1 LIMIT 5 はインデックスを使えますが、ORDER BY 1 - (embedding <=> $1) DESC は使えません。READMEは、テーブルが小さいときはテーブルスキャンのほうが速いこともあるとも述べています。

項目HNSWIVFFlat
仕組み多層のグラフベクトルをlistに分け、クエリに近いlistを探す
もう一方との比較速度と再現率のトレードオフは優れているが、構築が遅くメモリを多く使う構築が速くメモリも少ないが、速度と再現率のトレードオフは劣る
作るタイミング空のテーブルにも作れる(学習のステップがない)テーブルにある程度データが入ってから
構築のオプションm(デフォルトは16)と ef_construction(デフォルトは64)lists: 100万行までは rows / 1000 から始め、それより多いときは sqrt(rows)
検索のオプションhnsw.ef_search。デフォルトは40ivfflat.probes。デフォルトは1。sqrt(lists) から始める
次元数vector は2,000まで、halfvec は4,000までvector は2,000まで、halfvec は4,000まで

pgvector 0.8.7では、vector(2001) の列にはHNSWインデックスを作れないこと、IVFFlatにはL1距離の演算子クラスがないこと、ef_construction は 2 × m 以上でなければならないことも確認しました。それより多い次元数については、READMEのFAQに、halfvecやバイナリ量子化などの選択肢が挙げられています。

試してみる: pgvector SQL Builder

ベクトル1つが 1,544 バイトなので、10,000 行ではベクトルだけで約 15.4 MB になります(インデックスとほかの列は含みません)。

1. 拡張機能とテーブル

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE documents (
  id bigserial PRIMARY KEY,
  content text NOT NULL,
  embedding vector(384) NOT NULL
);

2. インデックス

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);

3. 検索

PREPARE は、/api/embed で得た質問のベクトルを $1 として受け取ります。'[0.01,-0.02,…]' のようにテキストとして渡してください。

PREPARE search_documents(vector(384)) AS
  SELECT id, content, 1 - (embedding <=> $1) AS cosine_similarity
  FROM documents
  ORDER BY embedding <=> $1
  LIMIT 5;

-- EXECUTE search_documents('[0.0123, -0.0456, ...]');

制限とデフォルト値は、pgvector 0.8.7 のREADMEとソースコードによるもので、2026-11-04に確認しました。 pgvector README

すべてブラウザ上で処理します。このツールはSQLを書くだけで、どこにも接続しません。

検索がLIMITより少ない行しか返さないことがある理由

HNSWでは、結果の数が hnsw.ef_search で制限されます。デフォルトは40です。200行のテスト用テーブルにHNSWインデックスを作って LIMIT 100 を実行すると40行が返り、SET hnsw.ef_search = 100 のあとは100行が返りました。hnsw.ef_search は、必要な行数以上に設定します。トランザクション内で SET LOCAL を使うと、1つのクエリだけに適用できます。

絞り込みでも結果は減ります。READMEによると、近似インデックスではインデックスをスキャンしたあとに WHERE の条件が適用されます。条件に合う行が全体の10%だとすると、デフォルトの hnsw.ef_search である40のHNSWでは、平均で4行しか返りません。バージョン0.8.0以降は、反復インデックススキャン(SET hnsw.iterative_scan = strict_order または relaxed_order)で、十分な行が見つかるまで、hnsw.max_scan_tuples(デフォルトは20,000)を上限にインデックスをさらに走査します。

READMEは、NULLのベクトルはインデックスされないこと、コサイン距離ではゼロベクトルもインデックスされないことも付け加えています。

検索結果を番号付きの出典として /api/chat に渡す

検索で近い行が返ったら、それをモデルのプロンプトに入れる必要があります。Ollamaの /api/chat はメッセージのリストを受け取り、各メッセージにはrole(system、user、assistant、tool)とcontentがあります。簡単な構成は、ルールを書いたsystemメッセージと、各行に [1]、[2] のような番号を付けて並べ、そのあとに質問を置いたuserメッセージです。番号があれば、回答がどの行を使ったかを示せますし、各番号を元の行に戻せます。

引用を決まった形で得るには、format フィールドに、回答と引用のリスト(各引用に出典番号と短い引用文)を持つJSON Schemaを渡します。Ollamaの構造化出力のページは、スキーマをプロンプトにも書くこと、そして出力をより決定的にするためにtemperatureを下げること(たとえば0)を勧めています。psqlでは、json_agg 関数がクエリの行をJSON配列にまとめ、下のツールはそれをそのまま読めます。

試してみる: RAG Prompt Builder

例の出典は、json_agg が返す形に合わせて手で書いたものです。

出典3件をオブジェクトのJSON配列として読み取りました。

curl コマンド

このマシン上の Ollama(localhost:11434)にリクエストを送ります。

curl http://localhost:11434/api/chat -d '{
  "model": "qwen2.5:7b",
  "messages": [
    {
      "role": "system",
      "content": "Answer the question using only the numbered sources in the user message. Cite the number of each source you use. If the sources do not contain the answer, say that you do not know and cite nothing. Answer in the same language as the question. For each citation, give the source number and copy a short quote from that source exactly as it is written. Return JSON that matches this schema: {\"type\":\"object\",\"properties\":{\"answer\":{\"type\":\"string\"},\"citations\":{\"type\":\"array\",\"items\":{\"type\":\"object\",\"properties\":{\"source\":{\"type\":\"integer\"},\"quote\":{\"type\":\"string\"}},\"required\":[\"source\",\"quote\"]}}},\"required\":[\"answer\",\"citations\"]}"
    },
    {
      "role": "user",
      "content": "Sources:\n\n[1] (id: 12)\nWith HNSW, hnsw.ef_search is 40 by default, so a query returns at most 40 rows unless you raise it.\n\n[2] (id: 7)\nSET LOCAL inside a transaction changes hnsw.ef_search for a single query.\n\n[3] (id: 3)\npgvector supports PostgreSQL 13 and later.\n\nQuestion: Why does my HNSW search return only 40 rows with LIMIT 100?"
    }
  ],
  "stream": false,
  "format": {
    "type": "object",
    "properties": {
      "answer": {
        "type": "string"
      },
      "citations": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "source": {
              "type": "integer"
            },
            "quote": {
              "type": "string"
            }
          },
          "required": [
            "source",
            "quote"
          ]
        }
      }
    },
    "required": [
      "answer",
      "citations"
    ]
  },
  "options": {
    "temperature": 0
  },
  "truncate": false
}'

リクエストボディ(JSON)

{
  "model": "qwen2.5:7b",
  "messages": [
    {
      "role": "system",
      "content": "Answer the question using only the numbered sources in the user message. Cite the number of each source you use. If the sources do not contain the answer, say that you do not know and cite nothing. Answer in the same language as the question. For each citation, give the source number and copy a short quote from that source exactly as it is written. Return JSON that matches this schema: {\"type\":\"object\",\"properties\":{\"answer\":{\"type\":\"string\"},\"citations\":{\"type\":\"array\",\"items\":{\"type\":\"object\",\"properties\":{\"source\":{\"type\":\"integer\"},\"quote\":{\"type\":\"string\"}},\"required\":[\"source\",\"quote\"]}}},\"required\":[\"answer\",\"citations\"]}"
    },
    {
      "role": "user",
      "content": "Sources:\n\n[1] (id: 12)\nWith HNSW, hnsw.ef_search is 40 by default, so a query returns at most 40 rows unless you raise it.\n\n[2] (id: 7)\nSET LOCAL inside a transaction changes hnsw.ef_search for a single query.\n\n[3] (id: 3)\npgvector supports PostgreSQL 13 and later.\n\nQuestion: Why does my HNSW search return only 40 rows with LIMIT 100?"
    }
  ],
  "stream": false,
  "format": {
    "type": "object",
    "properties": {
      "answer": {
        "type": "string"
      },
      "citations": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "source": {
              "type": "integer"
            },
            "quote": {
              "type": "string"
            }
          },
          "required": [
            "source",
            "quote"
          ]
        }
      }
    },
    "required": [
      "answer",
      "citations"
    ]
  },
  "options": {
    "temperature": 0
  },
  "truncate": false
}

レスポンスでは、回答は message.content にあります。prompt_eval_count が思っていたよりかなり少ない場合は、プロンプトが切り詰められた可能性があります。

リクエストのフィールドは Ollama のAPIリファレンスとソースコードで、2026-11-05に Ollama 0.40.11 で確認しました。 Ollama API: /api/chat

すべてブラウザの中で処理されます。ツールはリクエストを書くだけで、どこにも接続しません。

出典が収まらないと、Ollamaはプロンプトの先頭を切り落とす

ルール、行、質問のすべてが、コンテキスト長に収まらなければなりません。Ollamaのコンテキスト長のページは、VRAMが24 GiB未満の場合のデフォルトを4kトークンとし、FAQは4096トークンとしています。手元のテストマシンでは ollama ps が4096を示しました。options の num_ctx か、環境変数 OLLAMA_CONTEXT_LENGTH で変更できます。

プロンプトがそれより長いとき、/api/chat はデフォルトではエラーを返しません。Ollamaのソースコード(0.40.11)では、サーバーはまず、systemメッセージと最後のメッセージを残したまま、前のメッセージを丸ごと捨てます。それでもプロンプトが長すぎる場合は、先頭の数トークン(num_keep、デフォルトは4)とプロンプトの末尾を残し、その間を捨てます。qwen2.5:7bとnum_ctx 1024で行ったテストでは、2,068トークンのプロンプトが514トークンに切られました。systemメッセージと最初の出典が失われ、答えが出典 [1] にあるときは、モデルはどの出典にもないコードワードを返し、答えが最後の出典にあるときは、正しく答えたものの、systemメッセージが求めた出典番号は付けませんでした。レスポンスにエラーはなく、サーバーのログに警告 "truncating input prompt" が出ていました。

Ollamaのソースコードには、チャットのリクエスト用の truncate フィールドもあり、/api/chat のページには載っていません。"truncate": false を付けると、同じリクエストはHTTP 400と、エラー "request (2068 tokens) exceeds the available context size (1024 tokens), try increasing it" を返しました。レスポンスの prompt_eval_count フィールドはプロンプトのトークン数で、切り詰められたテストでは2,068ではなく514でした。

プロンプトの末尾は残るので、質問は出典のあとに置いてください。出典が収まるかどうかを知るには、"truncate": false を送り、そのあと num_ctx を上げるか、送る行を減らします。num_ctx を大きくすると、メモリがより多く必要になります。

引用を確認する

引用は機械的に確認できます。番号は送った出典を指していなければならず、引用文はその出典に含まれているはずです。4つの出典とqwen2.5:7bを使ったテストでは、JSONの回答に含まれる引用文は、出典と一字一句一致しました。だからといって回答が正しいとは限りません。384次元のベクトルのサイズを尋ねたとき、モデルは正しい規則(4 × 次元数 + 8 バイト)を引用したのに、1,544ではなく1552バイトと答えました。

引用のない回答も見てください。出典に答えがなかったとき、モデルは、引用なしで自分の知識から答えたことが1回、わからないと言いながら無関係な出典を引用したことが1回ありました。レスポンスの done_reason が "length" なら、回答は num_predict で打ち切られており、引用が欠けている可能性があります。

下のチェッカーはテキストを比べるだけです。出典が本当にその文を裏付けているかどうかは、人が判断する必要があります。

試してみる: RAG Citation Checker

例の回答は、出典にない引用文を示すために手で書いたものです。

出典4件(文字列のJSON配列)。回答はOllama の /api/chat のレスポンスとして読み取り、形式は引用つきのJSONです。

プロンプトのトークン数(prompt_eval_count): 306

  • 引用#2の引用文は、出典 [4] にありません。

引用

出典引用文結果
[2]hnsw.ef_search is 40 by defaultそのまま見つかった
[4]4 bytes per dimension plus 8この出典にはない

確認できるのは、番号と引用文が出典と一致することだけです。回答が正しいかどうか、出典が本当にその文を裏付けているかどうかはわかりません。

レスポンスの形式は Ollama のAPIリファレンスとソースコードで、2026-11-05に Ollama 0.40.11 で確認しました。 Ollama API: /api/chat

すべてブラウザの中で処理されます。ツールはどこにも接続しません。

小さなサーバーでのメモリ

READMEによると、HNSWインデックスは、グラフが maintenance_work_mem に収まるときに大幅に速く構築されます。収まらなくなると通知が表示されます。また、サーバーのメモリを使い切るほど maintenance_work_mem を大きくしないよう注意しています。ほかのインデックスと同じく、最初のデータを読み込んだあとにインデックスを作るほうが速くなります。インデックスはメモリに収まる必要はありませんが、収まるほうがおそらく性能は良くなります。インデックスのサイズは SELECT pg_size_pretty(pg_relation_size('index_name')) で確認できます。

作業セットとインデックスをもっと小さくしたい場合、READMEはhalfvec、半精度のインデックス、バイナリ量子化を挙げています。Ollamaを同じサーバーで動かしているなら、PostgreSQLとモデルは同じメモリを共有します。モデルがどれだけメモリを使うかを何が決めるかは、Ollamaのメモリを見る方法の記事で説明しています。

VPSを選ぶときは:AIで使う目で6社を見る(PR)

プランは、まずメモリ、次にモデルを置くディスク、そのあとCPUの順に見ます。ここでは、国内の6つのVPSを、AIを動かす目で見て、公式ページに書かれていることと、当サイトの見立てを並べました。

同じ運営者のサイト sabakore.com の「AI・LLM向けVPS診断」では、動かしたいモデルと月額の上限から、メモリに載るプランを料金の安い順に並べられます(GPUは使わず、CPUだけで動かす前提の診断です)。

sabakore.com のAI・LLM向けVPS診断を開く

評価のものさし

  • メモリ: いちばん大きいプランのメモリ。12GB以上なら○(Qwen3 14B が4,096トークンで約10.3 GiB。記事「VPSでローカルLLMを動かすのに必要なメモリ」の表)、8GB以上なら△(Qwen3 8B が約6.4 GiB)。
  • AIツールの入れやすさ: 公式ページに AI 用のテンプレートやスクリプトの記載があれば○、Docker の構築環境だけなら△、記載がなければ×(使えない、という意味ではありません)。
  • 料金と速さは評価しません。料金は変わり、CPUだけで動かしたときの速さは公式に数字がないためです。

公式ページで確認した日:

以下の6社の紹介は、アフィリエイト広告(PR)です。リンク先で申し込みがあると、当サイトの運営者に報酬が支払われます。並びは名前順で、報酬額は並びに関係ありません。評価は、各社の公式ページの記載(確認日は下に表示)だけにもとづく当サイトの見立てで、実際に動かして測ったものではありません。プランの内容や料金は変わるので、申し込む前に公式で確認してください。この記事は、これらのサービスでの動作を保証するものではありません。

  • ConoHa VPS (PR)

    メモリ○AIツールの入れやすさ○

    公式ページに書かれていること

    • 料金表のメモリは512MBから128GBまで(CPUは最大40コア)
    • スタートアップスクリプトで OpenClaw、Claude Code、n8n、Dify などを導入できると書かれている
    • GPUプランは、このページには記載なし(GPU用の案内は別のページ)

    当サイトの見立て

    メモリの選択肢が広く、AIツールを入れる仕組みも公式に用意されているので、「まず Dify や n8n を動かして試す」使い方と、大きめのモデルを載せたい使い方のどちらにも向きます。

    申し込む前に

    最小プランの書き方がページ内で食い違っています(料金表は512MB、FAQは1GB〜)。申し込む前に、いま選べるプランを公式で確認してください。CPUだけで動かしたときの速さは公式に数字がありません。

    ConoHa VPSの公式サイトで申し込む(PR)公式ページ

  • KAGOYA CLOUD VPS (PR)

    メモリ○AIツールの入れやすさ○

    公式ページに書かれていること

    • メモリは1GBから32GBまで(CPUは最大12コア、SSDは最大1600GB)
    • 「オープンソースのAI開発基盤DifyをVPSで手軽に導入」できると書かれ、Docker の構築済みサーバーもある
    • 日額・月額(月額上限あり)と年額の定額プランがある

    当サイトの見立て

    Dify を動かす用途が公式に想定されています。日額の料金から使えるので、「まず試して合わなければやめる」進め方がしやすく、メモリは32GBまで選べます。

    申し込む前に

    8GBでの Qwen3 8B は、4,096トークンの見積もりで約6.4 GiBです。コンテキストを長くする、同時に使う人を増やすと足りなくなります。GPUプランはこのページに記載がありません。

    KAGOYA CLOUD VPSの公式サイトで申し込む(PR)公式ページ

  • XServer VPS (PR)

    メモリ○AIツールの入れやすさ○

    公式ページに書かれていること

    • メモリは2GBから64GBまで(NVMe SSD。64GBは24コア・2,400GB)
    • アプリイメージに Dify があり、FAQは用途の例として「AIツールのホスティング」を挙げている
    • GPUは、別サービスの「GPUサーバー」へのリンクがあるだけで、VPSのページには記載なし

    当サイトの見立て

    Dify のアプリイメージと「AIツールのホスティング」という用途が公式に書かれています。小さく始めて、必要になったら大きいプランへ、という使い方ができそうです。

    申し込む前に

    トップページの料金表は8GBまでで、16GB以上は料金のページに載っています。大きいモデルを載せたいときは、申し込む前に料金のページで確認してください。

    XServer VPSの公式サイトで申し込む(PR)公式ページ

  • お名前.com VPS (PR)

    メモリ○AIツールの入れやすさ×

    公式ページに書かれていること

    • メモリは1GBから16GBまで(CPUは最大10コア、SSDは100GB〜1TB)
    • KVM の仮想化で、Linux 環境を使える
    • AI や Docker のテンプレートは、このページには記載なし

    当サイトの見立て

    16GB・10コア・1TBまで選べるので、自分でモデルを入れて動かす前提なら、メモリとディスクには余裕があります。AIツールの導入は自分で組み立てることになります。

    申し込む前に

    AI向けのテンプレートや手順は公式にありません。このサイトの「VPSにOllamaを入れて動かし続ける」の手順で自分で入れることになります。

    お名前.com VPSの公式サイトで申し込む(PR)公式ページ

  • クラウドVPS byGMO (PR)

    メモリ○AIツールの入れやすさ×

    公式ページに書かれていること

    • Vシリーズは1GB・2GB・4GB・6GB・8GB・12GB(CPUは最大7コア、ディスクは50GB〜800GB)
    • プランの月額料金とは別に、サーチャージ費が課金される
    • AI や Docker のテンプレートは、このページには記載なし

    当サイトの見立て

    12GBまで選べるので、8B級のモデルを長めのコンテキストで使いたいときの選択肢になります。AIツールは自分で入れる前提です。

    申し込む前に

    月額に加えてサーチャージ費がかかるので、実際の支払いは料金表より増えます。申し込む前に、合計の目安を公式で確認してください。

    クラウドVPS byGMOの公式サイトで申し込む(PR)公式ページ

  • さくらのVPS (PR)

    メモリ○AIツールの入れやすさ△

    公式ページに書かれていること

    • メモリは512MBから32GBまで(CPUは最大10コア。32GBはSSD 1600GBで、3200GBに変更可能)
    • 用途の例に「AI / 機械学習用途」があり、推奨はメモリ16GB〜・SSD 100GB〜と書かれている
    • スタートアップスクリプトに Docker の構築環境がある。AI専用のテンプレートは記載なし。石狩・大阪・東京から選べる

    当サイトの見立て

    公式がAI用途の推奨に挙げる16GB以上のプランがあり、メモリは32GBまで選べます。AI専用のテンプレートは記載がないので、Docker の構築環境を使うか、自分で入れることになります。

    申し込む前に

    トップページのプランは8GBまでで、16GB以上はプランのページに載っています。GPUプランは記載がありません。

    さくらのVPSの公式サイトで申し込む(PR)公式ページ

出典

次に読む