デコーダー専用のベクトルモデル向けGGUFの最適化

tagベースGGUFと量子化GGUF

Multi-modal embeddings for jinaai/jina-embeddings-v4 · ggml-org llama.cpp · Discussion #14851

Hey folks! I’m working on getting multimodal embeddings working with jina-embeddings-v4 (based on Qwen 2.5 VL) through llama.cpp server. I’ve hit an issue with mtmd inconsistencies and was hoping s…

GitHubggml-org

# build imatrix
llama-imatrix -m jina-embeddings-v4-text-retrieval-F16.gguf -f calibration_data_v5_rc.txt -ngl 99 --no-ppl -o imatrix-retrieval-512.dat

# quantize
./quantize.sh jina-embeddings-v4-text-retrieval-F16.gguf retrieval-i3 imatrix-retrieval-512.dat jinaai/jina-embeddings-v4-text-retrieval-GGUF
コピー

#!/bin/bash

F16_MODEL_FILE="$1"
OUTPUT_DIR="$2"
IMATRIX="$3"
HF_REPO="$4"

FILENAME="$(basename "$F16_MODEL_FILE")"
BASE_NAME="${FILENAME%-F16.gguf}"
BASE_NAME="${BASE_NAME%.gguf}"

mkdir -p "$OUTPUT_DIR"

# Array of quantization types
QUANT_TYPES=("IQ1_S" "IQ1_M" "IQ2_XXS" "IQ2_M" "Q2_K" "IQ4_NL" "IQ4_XS"  "IQ3_XXS" "IQ3_S" "IQ3_M" "IQ3_XS" "Q3_K_M" "Q4_K_M" "Q5_K_S" "Q5_K_M" "Q6_K" "Q8_0")

for quant_type in "${QUANT_TYPES[@]}"; do
    llama-quantize --imatrix "${IMATRIX}" "$F16_MODEL_FILE" "${OUTPUT_DIR}/${BASE_NAME}-${quant_type}.gguf" $quant_type 8
done
コピー

最終的に、すべての量子化をHuggingFaceにアップロードしました。

tagUsage and Caveats

これで、llama-serverとllama-embeddingを使用して、埋め込み用のGGUFを処理できます。カスタム入力プリプロセッシングコードを記述できる柔軟性があるTransformerライブラリとは異なり、この部分は手動で処理する必要があります（llama-serverとllama-embeddingを再コンパイルしない限り）。具体的には、AutoModel.from_pretrained("jinaai/jina-embeddings-v4")...を使用した場合と完全に一致する結果を得るには、プレフィックスに非常に注意し、それらを手動でGGUFモデルの入力に追加する必要があります。以下に参考表を示します。

一部のユーザーは、元のAutoModel.from_pretrained("jinaai/jina-embeddings-v4")....でtext-matchingを使用すると、prompt_name='passage'が"Query: "にオーバーライドされることに驚くかもしれません。しかし、text-matchingは左右の役割がない文の類似性タスクであるため、これは実際には理にかなっています—入力は対称的です。

tagllama-server経由

llama.cppをインストールしたら、llama-serverを実行して、埋め込みモデルをOpenAI API互換のHTTPサーバーとしてホストできます。たとえば、F16でtext-matchingを使用するには、次のようにします。

llama-server -hf jinaai/jina-embeddings-v4-text-matching-GGUF:F16 --embedding --pooling mean -ub 8192
コピー

次に、以下を使用してリクエストを送信します。

curl -X POST "http://127.0.0.1:8080/v1/embeddings" \
  -H "Content-Type: application/json" \
  -d '{
    "input": [
      "Query: A beautiful sunset over the beach",
      "Query: Un beau coucher de soleil sur la plage",
      "Query: 海滩上美丽的日落",
      "Query: 浜辺に沈む美しい夕日"
    ]
  }'
コピー

retrievalおよびcodeモデルを使用する場合は、次のように、入力の前にQuery: またはPassage:を追加します。

curl -X POST "http://127.0.0.1:8080/v1/embeddings" \
  -H "Content-Type: application/json" \
  -d '{
    "input": [
      "Query: A beautiful sunset over the beach",
      "Query: Un beau coucher de soleil sur la plage",
      "Passage: 海滩上美丽的日落",
      "Passage: 浜辺に沈む美しい夕日"
    ]
  }'
コピー

tagllama-embedding経由

簡単な健全性チェックのために、プリコンパイルされたllama-embeddingをワンショット埋め込みに使用することもできます。次のセクションで説明するパフォーマンスの問題があるため、バルク埋め込みにはお勧めしません。

llama-embedding -hf jinaai/jina-embeddings-v4-text-matching-GGUF:F16 --pooling mean -p "Query: jina is awesome" --embd-output-format json  2>/dev/null
コピー

tag注意事項のまとめ

より高性能な実装に移る前に、GGUFモデルの注意事項をまとめましょう。

• テキスト入力の前にQuery: またはPassage: を手動で追加する必要があります。
• 現在、GGUFモデルからビジョントランスフォーマーを削除したため、画像入力を処理できません。Qwen2.5-vl-3bのllama.cppのビジョントランスフォーマー/mmproj実装のバグが原因で削除する必要がありました。このバグについては、アップストリームで修正に取り組んでいます。
• llama.cppのQwen2.5-vl-3bグラフ実装の一部ではないため、マルチベクトル埋め込みを出力できません。llama.cppを再コンパイルせずに最も簡単な回避策は、llama-embeddingで--pooling noneを設定してトークンレベルの埋め込みを取得した後、MLPをエクスポートして個別に実行することです。
• v4はMatryoshka表現学習でトレーニングされており、GGUFに変換するとこの機能が保持されます。形状NxDの埋め込みを取得した場合、embeddings[:, :truncate_dim]を使用するだけで、より小さい切り捨てられた埋め込みを取得できます。ただし、すべての次元がトレーニングされているわけではありません。v4では、これらの特定の値に対してtruncate_dimをトレーニングしました：[128, 256, 512, 1024, 2048]。これは、embeddings[:, :131]の品質がembeddings[:, :128]とembeddings[:, :256]の品質の間のある種の補間になるのではなく、131次元はトレーニングされていないため、128次元または256次元の埋め込みよりも大幅に悪化することを意味します。
• v4は因果モデルであるため、--pooling noneを介してトークンレベルの埋め込みを取得した後、後期チャンクは後処理の一部として引き続き機能します。llama.cppグラフからMLPを分離したのと同じように、これは非常に効率的ではありませんが、再コンパイルは必要ありません。ただし、もう1つの注意点があります。後期チャンクは双方向ではなくなります-以前のチャンク埋め込みには、後続のチャンクからの文脈情報が含まれなくなります。v3では、トランスフォーマーブロックで双方向アテンションマスクを使用したため、すべてのチャンク埋め込みにグローバルコンテキスト情報が含まれていたことを忘れないでください。内部的には、因果関係が後期チャンクを時代遅れにするかどうかについて議論しました。「コンテキストも因果的である」と主張する人もいます。つまり、読者はテキストを左から右に処理するため、文を解釈するために必要なコンテキストは先行するテキストから来るはずです。また、後期チャンクを単方向に制限すると、チャンク間のコンテキスト共有がブロックされると言う人もいます。いずれにせよ、v4での後期チャンクの有効性は依然として疑問視されており、さらなる研究が必要です。

tagllama-embeddingによる効率的な埋め込み

llama-embeddingは、非常にクリーンなI/O（stdin、stdout）でテキストを埋め込むためのllama.cpp上の比較的単純なC++ラッパーです。ネットワークキューイング、負荷分散、マルチテナンシー、シリアル化など、現時点で範囲外であると私たちが信じている他の多くの問題があるため、現時点ではllama-serverではなく、この改善に焦点を当てています。私たちの質問は簡単です。L4 24GB GPUからどれだけの速度が得られるか、そして長いドキュメントを埋め込むためのピークVRAM使用量はどれくらいか？

しかし、なぜL4なのか？主に、GCPはそれをベースにした非常に便利なCloud Run関数を提供しており、サーバーレス推論APIで利用できる最も広く利用可能で経済的なGPUタイプであるためです。GCPはリクエストに応じてCloud RunでA100およびH100を提供しており、より優れたGPUを使用するようにGCPチームから時々提案されます。しかし、私たちの哲学は簡単です。3Bモデルを処理するためにA100/H100が必要な場合、それは明らかに私たちの側のスキルが問題です。

背景として、llama.cppでは、論理バッチサイズ (-b) は、1回の評価呼び出しでモデルに送信される最大トークン数を表します。長い入力を処理する場合、これらはこのサイズまでのチャンクに分割されます。物理バッチサイズ (-ub) は、利用可能なメモリによって制限される、ハードウェアを介した1回の順方向パスで同時に処理される実際のトークン数です。KVキャッシュは、各物理バッチが完了した後に更新されます。コンテキストウィンドウ (-c) は、モデルが一度に「見ることができる」トークン数のハードリミットです。v4モデルの場合、これは32,000トークンであり、モデルの最大アテンションスパンを表します。すべてのトークンは、シーケンス全体で一貫したアテンションを維持するために、このコンテキストウィンドウ内に収まる必要があります。次の図は、それらの関係を示しています。

tag修正点

GitHub - hanxiao/llama.cpp: LLM inference in C/C++

LLM inference in C/C++. Contribute to hanxiao/llama.cpp development by creating an account on GitHub.

GitHubhanxiao

上記のフォークでは、llama-embedding をより効率的にするために、いくつかの最適化を行いました。

• バッチ処理の簡略化: -b を -c と等しくなるように自動的に設定し、このパラメータを事実上廃止しました。論理バッチ処理のためにモデルのフルコンテキスト長を常に活用するため、ユーザーは -b を指定する必要がなくなりました。
• 柔軟なメモリ制御: 元の実装では -ub が -b と等しくなるように強制されていましたが（埋め込みモデルは因果的ではないと想定していたため）、ユーザーが -ub を個別に設定できるようにしました。これにより、長いコンテキストをエンコードする際のピークVRAM使用量を細かく制御できます。KVキャッシュの実装のおかげで、小さな512トークンの物理バッチで32Kコンテキストを処理して、VRAM制限内に収めることができます。この変更は、jina-embeddings-v4 のような因果的埋め込みモデルでのみ正しいことに注意してください。v3のようなエンコーダーのみのアーキテクチャの場合、これは間違った実装になります。
• 平均プーリングの修正: ub < b の場合の埋め込みの平均プーリング計算を修正しました。これは、元の実装では以前に壊れていました。

この変更により、メモリ制約を効果的に管理しながら、長コンテキストのデコーダーのみの埋め込みモデルを非常に簡単に操作できるようになります。ユーザーは、次の2つのパラメータのみを設定する必要があります。

• -c: 最大コンテキスト長（埋め込みモデルが処理できるトークン数）
• -ub: 物理バッチサイズ（GPUが一度に処理するトークン数）

したがって、L4でフォークを実行するための正確なコードは次のとおりです。

# Compile
git clone https://github.com/hanxiao/llama.cpp.git
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j 8

# Run
INPUT_PREFIX="Query: "  # or "Passage: "

cat big_input.txt | sed "s/^/${INPUT_PREFIX}/" | \
./llama.cpp/build/bin/llama-embedding -f /dev/stdin \
    -hf "jinaai/jina-embeddings-v4-text-retrieval-GGUF:FP16" \
    --pooling mean \
    --no-escape \
    --embd-output-format array \
    --ubatch-size 512 \
    --ctx-size 8192 \
    --flash-attn \
    -ngl 99 \
    > "embeddings.txt" 2> "error.log"
コピー

tagベンチマーク

ベンチマークを通じて、次の質問を理解したいと思います。

• 私たちの量子化は、元のv4 Float16と比較してどの程度優れていますか？どの時点で劣化しすぎて、v3埋め込みを使用する方が良いのでしょうか？
• 各量子化はL4でどれくらいの速さで実行できますか？ピークVRAM使用量はどのくらいですか？
• -ub 物理バッチサイズと -c コンテキスト長は、速度とピークVRAMにどのように影響しますか？

ベンチマークで使用したデータセットは次のとおりです。

ベンチマークには、カスタムビルドの llama-embedding を使用しました。

tag量子化の品質

最高のパフォーマンスを発揮する量子化バージョンは IQ3_M (3.84 BPW) です。2ビット未満の量子化はv3よりもパフォーマンスが低いため、使用する意味はほとんどありません。

tag速度とVRAM

ここでは、ベンチマークデータセットをNanoHotpotQAに固定し、すべての量子化を重みあたりのビット数と速度（1秒あたりのトークン数で測定）およびVRAM消費量によってプロットします。GGUFバージョンは、FP16のバニラバージョンよりもわずかに高速であることがわかりました（2023対1865トークン/秒）。ほとんどの量子化は、2000〜2100トークン/秒付近に集中しています。フラッシュアテンションを有効にすると、すべての量子化で約77％の高速化が得られます（3000+対2000+トークン/秒）。ただし、最高のパフォーマンスを発揮する量子化Q8_0（約3700トークン/秒）は、依然としてバニラv3（572Mパラメータ）には遠く及びません。これは16000トークン/秒に達します。量子化されたバージョンはVRAMを大幅に節約し、IQ3を使用すると、v3 FP16モデルのレベルにほぼ近づきます。

tag最適な物理バッチサイズとコンテキストサイズ

ここで、量子化タイプをIQ3_Sに固定し、物理バッチサイズ（-ub）とコンテキストサイズ（-c）が速度とVRAMにどのように影響するかを調べます。L4 GPUでの結果は、-ub=512、-c=2048が最適な構成であり、2,025MBのVRAMを使用しながら4,143 tokens/秒を提供することを示しています。重要なのは、入力内の単一ドキュメントの最大長がわかっている場合は、それをカバーするのに十分な小さいコンテキストサイズを使用することです。物理バッチサイズについては、512 tokensがL4 GPUでのスイートスポットのようです。

Tokens per Secondのパフォーマンス

ピークVRAM使用量 (MB)

tag結論

予算の限られたGPUで量子化されたGGUFを効率的に実行したいv4ユーザーは、llama-embeddingのカスタムビルドでIQ3_SまたはIQ3_Mを選択してください。これにより、通常のデータセット（文の長さが<2048 tokensの場合）で4000 tokens/秒が得られるはずです。より長いドキュメントを埋め込むには、コンテキストサイズ-cを増やし、物理バッチサイズ-ubを制御してVRAMフットプリントを削減します。カスタムビルドを使用すると、-ubを1024のような小さい数値に設定することで、わずか3GBのVRAMを使用して非常に長いドキュメント（>32K tokens）をエンコードできます。これは、元の実装またはバニラトランスフォーマーでは不可能でした。

速度最適化の探求に終わりはありません。常に、より高速で、より無駄のない実装と、より高いスループットの余地があります。4000 tokens/秒はおそらく私たちの天井ではありません。やるべきことはたくさんあります。llama.cppでのqwen2.5-vl-3b mmproj/vision transformerの実装の修正に加えて、llama.graphとKVキャッシュレベルのより深い最適化、llama-servingのバッチ処理ロジックの改善、埋め込みAPIへのストリーミングオプションの追加も検討しています。私たちの目標は、現在および将来の重排器リリースに向けて、llama.cppが最新のデコーダー専用マルチモーダル埋め込みをネイティブにサポートするようにすることです。