Oracle Autonomous AI Database に高性能な大規模埋め込みモデルをロードしてインデータベースでベクトルを生成する

はじめに

Oracle Database 26ai（23.26.1）から、ONNX 形式の埋め込みモデルのサイズ制限（従来は 1GB 上限）が撤廃され、multilingual-e5-large のような高性能な多言語対応モデルをデータベース内にロードできるようになりました。

以前の記事「Oracle Autonomous Database で In-database 埋め込みモデルを使ってベクトルを生成する」では、当時の ADB（23ai）に対して LOAD_ONNX_MODEL を使う手順を紹介しました。当時は、1GB 制限のため multilingual-e5-base（約 400MB）のような比較的小さいモデルしかロードできませんでした。また、LOAD_ONNX_MODELを使っていたためモデルファイルをあらかじめ Autonomous AI Database のディレクトリへダウンロードしておく必要がありました。

今回は、従来モデルサイズが大きすぎてデータベースにロードできなかった 高性能モデル multilingual-e5-large がロードできるようになったことを確かめます。

また、 DBMS_VECTOR.LOAD_ONNX_MODEL_CLOUD プロシージャを使って、ディレクトリを経由せずにオブジェクトストレージから 直接ロード する手順を紹介します。

なお、オンプレミス版 Oracle Database 26ai での同様の検証（LOAD_ONNX_MODEL を使用）については、@ssfujita さんの記事「Oracle AI DB 26aiが高精度EmbeddingモデルのONNXインポートに対応したので試してみた」が詳しいです。本記事はその Autonomous AI Database 版＋LOAD_ONNX_MODEL_CLOUD 版という位置づけです。

26ai(23.26.1) で何が変わったのか

1GB 制限の撤廃（External Initializer 対応）

従来の Oracle Database では、ONNX モデルのインポートに 1GB のサイズ上限がありました。日本語など多言語に対応した高性能な埋め込みモデルは、量子化しても 1GB に収まらないことが多く、実用上課題となることがありました。

23.26.1では「External Initializer」の仕組みが導入され、モデルの重みパラメータを .onnx ファイルとは別の外部ファイルとして保持できるようになりました。これにより、従来の 1GB の上限が撤廃されると同時に Protocol Buffers の 2GB 制限を回避し、合計サイズが 2GB を超えるモデルでもロード可能になっています。

In-Memory Sharing によるメモリ効率の向上

大規模モデルではイニシャライザ（重みパラメータ）がモデルサイズの 95% 以上を占めることがあります。従来はセッションごとにイニシャライザのコピーを PGA にロードしていたため、同時利用するセッションが増えるほどメモリ消費が膨らんでいました。

23.26.1 では In-Memory Sharing 機能により、イニシャライザをグローバルメモリに一度だけロードして全セッションで共有できるようになりました。DBMS_VECTOR.INMEMORY_ONNX_MODEL（または DBMS_DATA_MINING.INMEMORY_ONNX_MODEL）で有効化できます。

LOAD_ONNX_MODEL_CLOUD

以前の記事でご紹介した LOAD_ONNX_MODEL では、ONNX モデルファイルをデータベースサーバー上のディレクトリに事前に配置する必要がありました。Autonomous AI Database の場合、これは以下のような手間を意味します。

1. CREATE ANY DIRECTORY 権限の取得
2. ディレクトリの作成
3. DBMS_CLOUD.GET_OBJECT による全ファイルのダウンロード
4. LOAD_ONNX_MODEL の実行
5. 後片付け（ディレクトリ上のファイル・ディレクトリの削除）

LOAD_ONNX_MODEL_CLOUD は、オブジェクトストレージ上の .onnx ファイルの URI を直接指定するだけでロードが完了します。ディレクトリの作成・管理が不要になり、手順が簡単になります。

環境

手順の全体像

本記事の手順は大きく以下の流れです。

1. 埋め込みモデルの ONNX 変換

1.1 OML4Py 2.1.1 のセットアップ

OML4Py 2.1.1 は Oracle Machine Learning for Python Downloads からダウンロードできます。

Python 3.13 をビルドした上で、仮想環境に以下のようなパッケージをインストールしておきます。このブログでは、Python パッケージ管理と仮想環境作成には、uv を使用しています（必須ではありません）。

uv のインストール（オプション）

curl -LsSf https://astral.sh/uv/install.sh | sh

Python 仮想環境の作成（uv の場合）

mkdir -p oml4py
cd oml4py
uv venv --python 3.13
source .venv/bin/activate

Python 仮想環境の作成（uv を使わないの場合）

mkdir -p oml4py
cd oml4py
python3.13 -m venv .venv

依存パッケージのインストール

以下の内容で requirements.txt ファイルを作成します。

pandas==2.2.3
setuptools==80.8.0
scipy==1.14.1
matplotlib==3.10.0
oracledb==3.3.0
scikit-learn==1.6.1
numpy==2.1.0
pyarrow==19.0.0
protobuf<5
onnxruntime==1.20.0
onnxruntime-extensions==0.14.0
onnx==1.18.0
torch==2.9.0
transformers==4.56.1
sentencepiece==0.2.1

uv pip install --upgrade -r requirements.txt --only-binary=:all:

OML4Py クライアントのインストール

OML4Py クライアントのパッケージは、Oracle Machine Learning for Python Downloads から入手できます。

unzip oml4py-client-linux-x86_64-2.1.1.zip
uv pip install client/oml-2.1.1-cp313-cp313-linux_x86_64.whl

1.2 ONNX エクスポート

この記事では埋め込みモデルとして multilingual-e5-large を使用します。
まずこのモデル用の作業ディレクトリを作成します。

mkdir -p multilingual-e5-large
cd multilingual-e5-large

OML4Py 2.1.1 では、ONNXPipeline / ONNXPipelineConfig を使って External Initializer 対応の ONNX ファイルを生成できます。

次の Python スクリプトを用意します。

from oml.utils import ONNXPipeline, ONNXPipelineConfig

config = ONNXPipelineConfig.from_template("text", max_seq_length=512, use_external_data=True)
pipeline = ONNXPipeline("intfloat/multilingual-e5-large", config)
pipeline.export2file("multilingual_e5_large", output_dir=".")

Pythonスクリプトを実行します。
uvの場合

uv run multilingual-e5-large.py

uvを使わない場合

python3.13 multilingual-e5-large.py

実行が成功すると zip ファイルが生成されます。

$ ls -al
total 2188488
drwxr-xr-x. 2 labuser oinstall         71 Mar 13 09:09 .
drwxr-xr-x. 6 labuser oinstall       4096 Mar 13 07:55 ..
-rw-r--r--. 1 labuser oinstall        275 Mar 13 07:15 multilingual-e5-large.py
-rw-r--r--. 1 labuser oinstall 2241000735 Mar 13 09:09 multilingual_e5_large.zip

zipファイルを解凍します。

$ unzip multilingual_e5_large.zip 
Archive:  multilingual_e5_large.zip
 extracting: multilingual_e5_large_external_data.json  
 extracting: multilingual_e5_large_largeTensor_0.data  
 extracting: multilingual_e5_large_0.data  
 extracting: multilingual_e5_large_1.data  
 extracting: multilingual_e5_large.onnx

 $ ls -al
total 4376972
drwxr-xr-x. 2 labuser oinstall       4096 Mar 13 09:11 .
drwxr-xr-x. 6 labuser oinstall       4096 Mar 13 07:55 ..
-rw-r--r--. 1 labuser oinstall  993251328 Mar 13 09:08 multilingual_e5_large_0.data
-rw-r--r--. 1 labuser oinstall  218103808 Mar 13 09:08 multilingual_e5_large_1.data
-rw-r--r--. 1 labuser oinstall      67234 Mar 13 09:08 multilingual_e5_large_external_data.json
-rw-r--r--. 1 labuser oinstall 1024008192 Mar 13 09:08 multilingual_e5_large_largeTensor_0.data
-rw-r--r--. 1 labuser oinstall    5569359 Mar 13 09:08 multilingual_e5_large.onnx
-rw-r--r--. 1 labuser oinstall        275 Mar 13 07:15 multilingual-e5-large.py
-rw-r--r--. 1 labuser oinstall 2241000735 Mar 13 09:09 multilingual_e5_large.zip

ONNX Pipeline API のモデルサイズ別の挙動

OML4Py の ONNX Pipeline API は、モデルサイズに応じて以下のように動作します（ドキュメント）。

今回使用する intfloat/multilingual-e5-large は量子化前のサイズが 2 GB を超えるため、上記ルールに従い use_external_data=True（量子化なし・外部データ使用）を指定してエクスポートしています（明示的に指定しなくても自動的に使われますがドキュメンテーションも兼ねて明示しています）。1 GB 未満の小さなモデルであっても、use_external_data=True を明示的に指定すれば External Initializer 形式でエクスポートすることが可能です。

変換により multilingual_e5_large.zip（約 2.1 GB）が生成されます。展開すると以下のファイルが得られます。

.onnx ファイル自体はわずか 5.3 MB で、重みパラメータが外部ファイルに分離されていることがわかります。

2. オブジェクトストレージへの配置

ZIP ファイルと変換スクリプトを除いた ONNX 関連ファイルをオブジェクトストレージにアップロードします。ここでは、CLIを使った例をご紹介します。

# バケットの作成
oci os bucket create \
  --name onnx-bucket \
  --compartment-id <compartment-ocid> \
  --namespace-name <namespace>

# ONNX ファイル群をアップロード
oci os object bulk-upload \
  --bucket-name onnx-bucket \
  --namespace-name <namespace> \
  --src-dir . \
  --object-prefix multilingual-e5-large/ \
  --exclude "multilingual_e5_large.zip" \
  --exclude "multilingual-e5-large.py"

アップロード後、以下の 5 ファイルが格納されていることを確認します。

multilingual-e5-large/multilingual_e5_large.onnx
multilingual-e5-large/multilingual_e5_large_0.data
multilingual-e5-large/multilingual_e5_large_1.data
multilingual-e5-large/multilingual_e5_large_external_data.json
multilingual-e5-large/multilingual_e5_large_largeTensor_0.data

3. Autonomous AI Database からオブジェクトストレージへのアクセス権限設定

3.1 リソースプリンシパルの設定

ADB からオブジェクトストレージにアクセスするため、ここでは、リソースプリンシパルを使用します。動的グループはあらかじめ作成されているものとします。

まず、ADB を含む動的グループに対して、バケットへの読み取り権限を付与する IAM ポリシーを作成します。

oci iam policy create \
  --region us-ashburn-1 \
  --compartment-id <compartment-ocid> \
  --name dg-onnx-bucket-rw-policy \
  --description "Grant <dynamic-group> RW access to onnx-bucket" \
  --statements '[
    "Allow dynamic-group <dynamic-group> to read buckets in compartment <compartment-name> where target.bucket.name='\''onnx-bucket'\''",
    "Allow dynamic-group <dynamic-group> to manage objects in compartment <compartment-name> where target.bucket.name='\''onnx-bucket'\''"
  ]'

3.2 データベースユーザーに対するリソースプリンシパルの有効化

ADMIN ユーザーで接続し、対象ユーザーのリソースプリンシパルを有効化します。

BEGIN
  DBMS_CLOUD_ADMIN.ENABLE_RESOURCE_PRINCIPAL(
    username => '<db-username>'
  );
END;
/

リソースプリンシパルが作成されたことを確認します。

SELECT credential_name
FROM user_credentials
WHERE credential_name = 'OCI$RESOURCE_PRINCIPAL';

4. LOAD_ONNX_MODEL_CLOUD で ONNX モデルをロード

ここが本記事の主題です。LOAD_ONNX_MODEL_CLOUD を使えば、ディレクトリの作成やファイルダウンロードといった中間手順を省略し、オブジェクトストレージ上の .onnx ファイルの URI を直接指定してロードできます（.onnx ファイルの URI を指定するだけで同じバケット／プレフィックスに配置されている他のファイルもロードされます）。

BEGIN
    DBMS_VECTOR.LOAD_ONNX_MODEL_CLOUD(
        model_name => 'multilingual_e5_large',
        credential => 'OCI$RESOURCE_PRINCIPAL',
        uri        => 'https://objectstorage.ap-tokyo-1.oraclecloud.com/n/<namespace>/b/onnx-bucket/o/multilingual-e5-large/multilingual_e5_large.onnx',
        metadata   => JSON('{"function":"embedding","embeddingOutput":"embedding","input":{"input":["DATA"]}}')
    );
END;
/

uri に指定するのは .onnx ファイルの URI のみです。_external_data.json やその他の .data ファイルは、同じオブジェクトストレージのパス上に存在していれば、LOAD_ONNX_MODEL_CLOUD が自動的に取得してくれます。

ロード結果の確認

SELECT MODEL_NAME, MINING_FUNCTION, ALGORITHM, ALGORITHM_TYPE,
       ROUND(MODEL_SIZE/1024/1024) AS SIZE_MB
FROM user_mining_models;

MODEL_NAME               MINING_FUNCTION    ALGORITHM    ALGORITHM_TYPE    SIZE_MB
------------------------ ------------------ ------------ ----------------- -------
MULTILINGUAL_E5_LARGE    EMBEDDING          ONNX         NATIVE               3289

約 3.3 GB のモデルがデータベース内にロードされました。

5. ベクトル生成テスト

5.1 ベクトルの生成

SELECT TO_VECTOR(
  VECTOR_EMBEDDING(MULTILINGUAL_E5_LARGE USING '無詠唱魔法' AS data)
) AS embedding;

5.2 次元数と先頭要素の確認

WITH emb AS (
  SELECT VECTOR_EMBEDDING(MULTILINGUAL_E5_LARGE USING '無詠唱魔法' AS data) AS vec
  FROM dual
),
vals AS (
  SELECT jt.idx, jt.val
  FROM emb e,
       JSON_TABLE(
         VECTOR_SERIALIZE(e.vec RETURNING CLOB),
         '$[*]'
         COLUMNS (
           idx FOR ORDINALITY,
           val NUMBER PATH '$'
         )
       ) jt
)
SELECT
  (SELECT COUNT(*) FROM vals) AS dimension,
  (SELECT JSON_ARRAYAGG(val ORDER BY idx RETURNING CLOB)
     FROM vals
    WHERE idx <= 5) AS first_5
FROM dual;

実行結果の例はこちらです。

DIMENSION FIRST_5
--------- -------------------------------------------------------------------
     1024 [0.0379486009,0.0319504365,-0.0162661821,-0.0448859856,0.0147227719]

1024 次元のベクトルが正常に生成されることを確認できました。

6. In-Memory Sharing の有効化

大量のベクトル生成リクエストがある環境では、In-Memory Sharing を有効にすることで同時に複数のセッションで埋め込みモデルを利用する際のメモリー利用効率を向上させることができます。

6.1 External Data の確認

SELECT model_name, EXTERNAL_DATA FROM all_mining_models;

EXTERNAL_DATA が YES であることを確認します。In-Memory Sharing は External Initializer を持つモデルに対してのみ有効化できます。

6.2 有効化

EXECUTE DBMS_VECTOR.INMEMORY_ONNX_MODEL('MULTILINGUAL_E5_LARGE');

6.3 メモリ使用状況の確認

ADMIN ユーザーで確認します。

SELECT * FROM V$IM_ONNX_MODEL WHERE NAME = 'MULTILINGUAL_E5_LARGE';

OWNER      NAME                     SLOT# POPULATE_STATUS  METADATA_SIZE  INITIALIZER_SIZE  PREPACKED_SIZE
---------- ------------------------ ----- ---------------- ------------- ----------------- --------------
LABUSER    MULTILINGUAL_E5_LARGE        0 ENABLED               227176        2235363328       1207992960

INITIALIZER_SIZE（約 2.1 GB）のイニシャライザがグローバルメモリ上に共有されています。PREPACKED_SIZE（約 1.2 GB）はランタイム用に最適化された形式のサイズです。

6.4 無効化（必要に応じて）

メモリを解放したい場合は以下を実行します。

EXECUTE DBMS_VECTOR.INMEMORY_ONNX_MODEL('MULTILINGUAL_E5_LARGE', enable => FALSE);

LOAD_ONNX_MODEL との比較

参考までに、LOAD_ONNX_MODEL を使った場合の手順を示します。Autonomous AI Database の場合、LOAD_ONNX_MODEL_CLOUD が手順を簡素化してくれることがわかります。

LOAD_ONNX_MODEL の場合に追加で必要な手順

LOAD_ONNX_MODEL を使う場合は、モデルのロード前に以下の準備が必要です。

1. ディレクトリ作成権限の付与（ADMIN で実行）

GRANT CREATE ANY DIRECTORY TO <db-username>;

2. ステージングディレクトリの作成

CREATE DIRECTORY staging AS 'stage';

3. オブジェクトストレージからファイルをダウンロード

DBMS_CLOUD.GET_OBJECT で 5 つのファイルをすべてステージングディレクトリにダウンロードする PL/SQL を書いて実行します。

4. LOAD_ONNX_MODEL の実行

BEGIN
  DBMS_VECTOR.LOAD_ONNX_MODEL(
    'staging',
    'multilingual_e5_large.onnx',
    'multilingual_e5_large',
    json('{"function":"embedding","embeddingOutput":"embedding","input":{"input":["DATA"]}}')
  );
END;
/

5. 後片付け

ステージングディレクトリ上のファイル削除、ディレクトリの削除、権限の後始末などが必要です。

このように、LOAD_ONNX_MODEL では権限付与 → ディレクトリ作成 → ファイルダウンロード → ロード → 後片付けという一連の手順が必要ですが、LOAD_ONNX_MODEL_CLOUD なら PL/SQL 1 ブロックで完結 します。

まとめ

Oracle Autonomous AI Database 26ai で、モデルサイズの大きな高性能の多言語埋め込みモデルをデータベース内で手軽に利用できるようになりました。LOAD_ONNX_MODEL_CLOUD によるシンプルなロード手順と In-Memory Sharing によるメモリ効率の改善は、データの移動を極力少なくしたいセキュリティ要件の厳しい環境での RAG やベクトル検索の実用性を大きく高めるものと期待されます。

あとがき

LOAD_ONNX_MODEL_CLOUDの存在に気付いたときの私の妄想はこちらです。

お隣の天使様にLOAD_ONNX_MODEL_CLOUD を教えてもらった件

「……はぁ」

周（あまね）は深いため息をつきながら、ディスプレイに映るSQLclのコマンドラインを睨みつけていた。
Autonomous AI Databaseに埋め込みモデルをロードする。やることはわかっている。オブジェクトストレージにモデルファイルを置いて、データベース側にディレクトリオブジェクトを作って、クレデンシャルを設定して、ファイルを一つずつダウンロードして、それからLOAD_ONNX_MODELを叩く。わかっている。わかっているのだが——

「……地味にめんどくさい」

DBMS_CLOUD.GET_OBJECTでファイルを一個ずつ落としてくるのが、とにかく怠い。モデルのファイルが複数あると、その数だけ同じようなPL/SQLブロックを書くことになる。コピペして、ファイル名だけ変えて、実行して、次。コピペして、ファイル名だけ変えて、実行して、次——

「周くん、晩ごはんできましたよ。……何をそんなに難しい顔をしているのですか？」

隣の部屋からやってきた真昼（まひる）が、周の背後からディスプレイを覗き込む。ふわりと柔軟剤の良い香りがしたが、今の周にそれを意識する余裕はなかった。

「いや……Autonomous にONNXの埋め込みモデルをロードしてるんだけど、オブジェクトストレージからファイル一個ずつダウンロードして、ディレクトリに並べて、最後にLOAD_ONNX_MODELに渡すっていう手順がちまちましてて……」

「……それ、全部手動でやっているのですか？」

真昼の声のトーンが、わずかに変わった。それは周がカップ麺にお湯を入れようとしたときや、洗濯物を床に放置していたときに聞く、あの声だった。

「いや、手動っていうか、PL/SQLは書いてるけど……GET_OBJECTで一個ずつ落として、LOAD_ONNX_MODELで——」

「LOAD_ONNX_MODEL_CLOUD、使っていないんですか？」

「…………は？」

周の手がキーボードの上で止まった。

真昼は周の隣に腰を下ろすと、いつもの涼しい顔のまま淡々と説明を始めた。

「DBMS_VECTOR.LOAD_ONNX_MODEL_CLOUDです。オブジェクトストレージのURIとクレデンシャルを渡すだけで、ディレクトリの作成もファイルのダウンロードも全部すっ飛ばしてモデルをロードできます」

「…………」

「ディレクトリオブジェクトを作る必要もないですし、GET_OBJECTを何回も叩く必要もありません。クレデンシャルとオブジェクトストレージのパスを指定するだけです」

周は、自分がこの一時間ほどちまちまと書いていたPL/SQLブロックの群れを見た。ディレクトリ作成。クレデンシャル設定。GET_OBJECT、GET_OBJECT、GET_OBJECT。そしてようやくLOAD_ONNX_MODEL。
それが、一つのプロシージャで済む、と。

「…………先に言ってくれ」

「先にって、周くんが何をしているか知らなかったので言いようがないです。というか、ドキュメントに書いてありますよ？」

正論だった。あまりにも正論だったので、周は何も言い返せなかった。

「……ドキュメント、読んでなかった」

「知ってます」

真昼は小さくため息をつくと、立ち上がった。

「ごはん、冷めますよ。書き直すのは食べてからにしてください」

「……はい」

素直に従う周の背中に、真昼の声が降ってきた。

「それから、クレデンシャルはちゃんとリソースプリンシパルを使うのですよ——あと、Oracle Databaseのドキュメントは、ちゃんと読んだほうがいいですよ。周くん、いつも検索で最初に出て来た記事を鵜呑みにしてるでしょ」

図星だった。

※佐伯さん著「お隣の天使様にいつの間にか駄目人間にされていた件」（GA文庫）のキャラクターをお借りした二次創作です。
※この記事は、個人的な趣味で投稿しているもので所属する企業・組織・団体とは無関係です。

参考リンク

• Oracle AI Database New Features - ONNX Support
• DBMS_VECTOR - LOAD_ONNX_MODEL_CLOUD
• LOAD_ONNX_MODEL_CLOUD リファレンス（Oracle AI Vector Search User's Guide）
• About ONNX - External Initializers and In-Memory Sharing
• Support For Large ONNX Format Model（OML4Py）
• OML4Py 2.1.1 ダウンロード
• Oracle Autonomous Database で In-database 埋め込みモデルを使ってベクトルを生成する（前回記事）
• Oracle AI DB 26aiが高精度EmbeddingモデルのONNXインポートに対応したので試してみた（@ssfujita さんの記事）