Optimisation des GGUF pour les modèles de 向量模型 à décodeur uniquement

Il y a deux semaines, nous avons publié les formats GGUF de jina-embeddings-v4, un modèle de 向量模型 universel pour la recherche multimodale multilingue, avec diverses versions quantifiées. Notre motivation était simple : en tant que modèle de 3,75 milliards de paramètres, la version de transformateur vanilla de jina-embeddings-v4 ne s'adapte pas bien à nos instances d'API GCP G2 (GPU L4). Nous voulions donc accélérer l'inférence en utilisant ces versions GGUF plus petites et plus rapides. Au cours de nos expériences, nous avons fait des découvertes intéressantes lors de la conversion et de l'exécution de modèles de 向量模型 GGUF. Étant donné que la plupart de la communauté llama.cpp se concentre sur les 大模型, nous avons pensé qu'il serait intéressant de partager cela du point de vue d'un fournisseur de 向量模型.

Ce qui est particulièrement pertinent, c'est que les modèles de 向量模型 actuels sont presque identiques aux 大模型. Par exemple, jina-embeddings-v4 est basé sur Qwen2.5-VL-3B-instruct et jina-reranker-m0 est basé sur Qwen2-VL-2B. La seule différence réelle est la sortie : les 大模型 sont génératifs, les 向量模型 et les 重排器 sont discriminatifs. Cela crée à la fois des opportunités et des défis : d'une part, nous pouvons tirer parti de l'implémentation efficace de llama.cpp (par exemple, ubatch_size) pour servir des modèles de 向量模型 / 重排器 ; d'autre part, les implémentations de 向量模型 de llama.cpp ont été principalement développées pour les anciennes architectures d'encodeur uniquement (comme les modèles basés sur RoBERTa) et ne sont pas encore tout à fait au point avec les modèles de 向量模型 / 重排器 modernes à décodeur uniquement. Cet article partage ce que nous avons appris en adaptant les modèles de 向量模型 modernes pour qu'ils fonctionnent avec le format GGUF et l'outillage llama.cpp, par exemple llama-embedding et llama-serving.

tagGGUF de base et quantifiés

jina-embeddings-v4 est basé sur Qwen2.5-VL-3B-instruct avec trois adaptateurs LoRA : retrieval (optimisé pour les tâches de recherche), text-matching (optimisé pour les tâches de similarité de phrases) et code (optimisé pour les tâches de recherche de code). Il est également fortement entraîné pour la recherche de documents visuels et la sortie multi-vecteurs de style interaction tardive. L'idée ici est donc de tirer parti de l'implémentation de graphe existante de Qwen2.5-VL-3B dans llama.cpp et d'utiliser llama-embedding pour l'inférence.

Cependant, la première chose que nous avons remarquée est un comportement bogué dans l'implémentation de mmproj ou de vision transformer dans llama.cpp, qui produit des 向量模型 différents par rapport à l'implémentation torch de Qwen2.5-VL-3B avec la même entrée d'image. Pendant que nous corrigeons ce problème dans notre fork, nous avons décidé d'exclure la tour de vision des versions GGUF pour le moment. Vous pouvez trouver plus de détails sur cette discussion ici.

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

La sortie de 向量模型 multi-vecteurs n'est pas non plus prise en charge d'emblée, mais ce n'est pas un problème aussi important que les vision transformers. La sortie multi-vecteurs provient d'un MLP entraîné au dernier bloc de transformateur, donc au pire, nous pouvons toujours exporter ce MLP séparément vers numpy et l'appliquer après avoir obtenu les 向量模型 au niveau des 词元 à partir de llama.cpp - ce que nous avons fait pour jina-reranker-m0-GGUF. Bien sûr, ce n'est pas très efficace, mais cela fonctionne sans avoir à modifier et recompiler llama.cpp.

Ainsi, pour nous conformer pleinement à l'implémentation de graphe existante de Qwen2.5-VL-3B dans llama.cpp, nous avons supprimé le vision transformer et le projecteur multi-vecteurs au dernier bloc de transformateur et avons fusionné tous les adaptateurs LoRA dans le modèle de langage de base. Cela nous a donné trois modèles v4 spécifiques à une tâche avec 3,09 milliards de paramètres chacun, contre 3,75 milliards de paramètres pour le v4 original :

Ensuite, nous avons utilisé calibration_data_v5_rc.txt (que vous pouvez trouver ici et qui est recommandé par Unsloth) pour calibrer les trois modèles GGUF de base et avons obtenu trois fichiers imatrix, puis nous avons utilisé llama-quantize avec imatrix pour quantifier les modèles de float16 comme suit :

# 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
Copier

Le script quantize.sh est présenté ci-dessous :

#!/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
Copier

Finalement, nous avons téléchargé toutes les quantifications sur HuggingFace.

tagUtilisation et mises en garde

Nous pouvons maintenant utiliser llama-server et llama-embedding pour servir les GGUF pour l'intégration. Contrairement aux bibliothèques de transformateurs où nous avons la flexibilité d'écrire du code de prétraitement d'entrée personnalisé, nous devons gérer cette partie manuellement (à moins que nous ne voulions recompiler llama-server et llama-embedding). Plus précisément, pour obtenir des résultats qui sont entièrement cohérents avec l'utilisation de AutoModel.from_pretrained("jinaai/jina-embeddings-v4")..., vous devez être très prudent quant aux préfixes et les ajouter manuellement à vos entrées de modèle GGUF. Voici un tableau de référence :

Certains utilisateurs pourraient trouver surprenant que ⚠️ prompt_name='passage' soit remplacé par "Query: " lors de l'utilisation de text-matching dans le AutoModel.from_pretrained("jinaai/jina-embeddings-v4").... d'origine. Mais cela a en fait du sens car text-matching est une tâche de similarité de phrases sans rôles gauche/droite : les entrées sont symétriques.

tagVia llama-server

Après avoir installé llama.cpp, vous pouvez exécuter llama-server pour héberger le modèle d'intégration en tant que serveur HTTP compatible avec l'API OpenAI. Par exemple, pour utiliser text-matching avec F16, vous pouvez faire :

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

Ensuite, envoyez la requête via :

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: 浜辺に沈む美しい夕日"
    ]
  }'
Copier

Lorsque vous utilisez les modèles retrieval et code, ajoutez Query: ou Passage: devant votre entrée, comme ceci :

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: 浜辺に沈む美しい夕日"
    ]
  }'
Copier

tagVia llama-embedding

Pour une vérification rapide, vous pouvez également utiliser llama-embedding précompilé pour l'intégration unique. Nous ne recommandons pas de l'utiliser pour l'intégration en masse car il présente des problèmes de performances dont nous discuterons dans la section suivante :

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
Copier

tagRésumé des mises en garde

Avant de passer à une implémentation plus performante, résumons les mises en garde des modèles GGUF :

• Vous devez ajouter manuellement Query: ou Passage: devant les entrées de texte.
• Ils ne peuvent pas gérer les entrées d'image pour le moment car nous avons supprimé les transformateurs de vision du modèle GGUF. Nous avons dû les supprimer en raison de bogues dans l'implémentation du transformateur de vision/mmproj de Qwen2.5-vl-3b de llama.cpp, que nous nous efforçons de corriger avec l'amont.
• Ils ne peuvent pas générer d'intégrations multi-vecteurs car cela ne fait pas partie de l'implémentation du graphe Qwen2.5-vl-3b de llama.cpp. La solution de contournement la plus simple sans recompiler llama.cpp consiste à exporter et à exécuter le MLP séparément après avoir obtenu des intégrations au niveau des Tokens en définissant --pooling none dans llama-embedding.
• v4 est formé avec l'apprentissage de la représentation Matryoshka, et la conversion en GGUF préserve cette fonctionnalité. Si vous obtenez des intégrations avec la forme NxD, vous pouvez simplement utiliser embeddings[:, :truncate_dim] pour obtenir des intégrations tronquées plus petites. Cependant, toutes les dimensions ne sont pas entraînées. Pour v4, nous avons formé truncate_dim pour ces valeurs spécifiques : [128, 256, 512, 1024, 2048]. Cela signifie que la qualité de embeddings[:, :131] ne sera pas une interpolation entre la qualité de embeddings[:, :128] et embeddings[:, :256], mais sera considérablement pire que les intégrations à 128 dimensions ou à 256 dimensions car 131 dimensions ne sont pas entraînées.
• Le chunking tardif peut toujours fonctionner dans le cadre du post-traitement après avoir obtenu des intégrations au niveau des Tokens via --pooling none. Tout comme ce que nous avons fait en séparant le MLP du graphe llama.cpp, ce n'est pas très efficace mais ne nécessite pas de recompilation. Cependant, il y a une autre mise en garde : étant donné que v4 est un modèle causal, le chunking tardif ne sera plus bidirectionnel - les intégrations de chunk antérieures ne contiendront pas d'informations contextuelles provenant des chunks suivants. N'oubliez pas que dans v3, chaque intégration de chunk avait des informations contextuelles globales car nous utilisions des masques d'attention bidirectionnels dans les blocs de transformateur. En interne, nous avons discuté de la question de savoir si la causalité rend le chunking tardif obsolète : certains soutiennent que "le contexte est également causal" - ce qui signifie qu'un lecteur traite le texte de gauche à droite, de sorte que le contexte nécessaire pour interpréter une phrase devrait provenir du texte précédent. D'autres disent que la restriction du chunking tardif à un bloc unidirectionnel le partage de contexte entre les chunks. Quoi qu'il en soit, l'efficacité du chunking tardif dans v4 reste discutable et nécessite une étude plus approfondie.

tagIntégration efficace via llama-embedding

llama-embedding est un wrapper C++ relativement simple au-dessus de llama.cpp pour intégrer du texte avec des E/S très propres : stdin, stdout. Nous nous concentrons sur l'amélioration de cela plutôt que sur llama-server pour le moment car il existe des tonnes d'autres problèmes tels que la mise en file d'attente réseau, l'équilibrage de charge, la multi-location et la sérialisation que nous pensons être hors de portée à ce stade. Notre question est simple : quelle vitesse pouvons-nous obtenir d'un GPU L4 24 Go, et quelle est l'utilisation maximale de la VRAM pour intégrer de longs documents ?

Mais pourquoi L4 ? Principalement parce que GCP offre des fonctions Cloud Run assez pratiques au-dessus, et c'est le type de GPU le plus largement disponible et économique que vous pouvez obtenir pour les API d'inférence sans serveur. GCP offre A100 et H100 sur Cloud Run sur demande, et l'équipe GCP nous propose de temps en temps d'utiliser de meilleurs GPU. Mais notre philosophie est simple : si nous avons besoin d'A100/H100 pour servir un modèle 3B, c'est clairement un problème de compétences de notre part.

Pour un peu de contexte, dans llama.cpp, la taille de lot logique (-b) représente le nombre maximum de 词元 envoyé au modèle lors d'un seul appel d'évaluation. Lors du traitement d'entrées longues, elles sont divisées en morceaux jusqu'à cette taille. La taille de lot physique (-ub) est le nombre réel de 词元 traités simultanément en une seule passe avant à travers le matériel, limité par la mémoire disponible. Les mises à jour du cache KV ont lieu après chaque lot physique. La fenêtre contextuelle (-c) est la limite stricte du nombre de 词元 que le modèle peut "voir" à la fois - pour les modèles v4, il s'agit de 32 000 词元, ce qui représente la portée d'attention maximale du modèle. Tous les 词元 doivent tenir dans cette fenêtre contextuelle pour maintenir une attention cohérente sur l'ensemble de la séquence. La figure suivante illustre leurs relations.

tagNos corrections

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

Dans notre fork ci-dessus, nous avons apporté plusieurs optimisations pour rendre llama-embedding plus efficace :

• Gestion simplifiée des lots : nous définissons automatiquement -b comme égal à -c, ce qui rend ce paramètre obsolète. Les utilisateurs n'ont plus besoin de spécifier -b puisque nous exploitons toujours la longueur de contexte complète du modèle pour le traitement par lots logique.
• Contrôle flexible de la mémoire : contrairement à l'implémentation d'origine où -ub était forcé d'être égal à -b (car ils supposaient que les modèles de 向量模型 ne pouvaient pas être causals), nous permettons aux utilisateurs de définir -ub indépendamment. Cela donne un contrôle précis sur l'utilisation maximale de la VRAM lors du codage de contextes longs - vous pouvez traiter un contexte de 32K avec un petit lot physique de 512 词元 pour rester dans les limites de la VRAM grâce à l'implémentation du cache KV. Notez que cette modification n'est correcte que pour les modèles de 向量模型 causals comme jina-embeddings-v4 - pour les architectures à codeur uniquement comme v3, ce serait la mauvaise implémentation.
• Mise en commun moyenne fixe : nous avons corrigé le calcul de la mise en commun moyenne pour les 向量模型 lorsque ub < b, ce qui était auparavant cassé dans l'implémentation d'origine.

Cette modification facilite grandement l'utilisation de modèles de 向量模型 à décodage uniquement à contexte long tout en gérant efficacement les contraintes de mémoire. Les utilisateurs n'ont plus besoin de configurer que deux paramètres :

• -c : la longueur de contexte maximale (combien de 词元 le modèle de 向量模型 peut traiter)
• -ub : la taille du lot physique (combien de 词元 le GPU traite à la fois)

Voici donc le code exact pour exécuter notre fork sur 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"
Copier

tagBenchmark

Nous voulons comprendre les questions suivantes grâce à des benchmarks :

• Quelle est la qualité de notre quantification par rapport au v4 Float16 d'origine ? À quel moment se dégrade-t-elle tellement qu'il serait préférable d'utiliser simplement les 向量模型 v3 ?
• Quelle est la vitesse d'exécution de chaque quantification sur L4 et quelle est l'utilisation maximale de la VRAM ?
• Comment la taille du lot physique -ub et la longueur du contexte -c affectent-elles la vitesse et l'utilisation maximale de la VRAM ?

Les ensembles de données que nous avons utilisés dans les benchmarks sont :

Nous avons utilisé notre build personnalisé de llama-embedding pour les benchmarks.

tagQualité des quantifications

La version quantifiée la plus performante est IQ3_M (3.84 BPW) - les quantifications inférieures à 2 bits sont moins performantes que v3, il est donc peu utile de les utiliser.

tagVitesse et VRAM

Nous fixons maintenant l'ensemble de données de référence à NanoHotpotQA et traçons toutes les quantifications par leurs bits par poids par rapport à la vitesse (mesurée en nombre de jetons par seconde) et à la consommation de VRAM. Nous avons constaté que les versions GGUF sont légèrement plus rapides que la version vanilla en FP16 (2023 contre 1865 jetons/sec). La plupart des quantifications se regroupent autour de 2000 à 2100 jetons/sec. Avec la flash attention activée, nous obtenons une accélération d'environ 77 % sur toutes les quantifications (plus de 3000 contre plus de 2000 jetons/sec). Cependant, la quantification la plus performante, Q8_0, à environ 3700 jetons par seconde, est encore loin de la version vanilla v3 (572 millions de paramètres), qui atteint 16 000 jetons/sec. Les versions quantifiées permettent d'économiser une quantité considérable de VRAM et s'approchent presque du niveau du modèle v3 FP16 avec IQ3.

tagTaille de lot physique et taille de contexte optimales

Nous fixons maintenant le type de quantification à IQ3_S et examinons comment la taille de lot physique (-ub) et la taille de contexte (-c) affectent la vitesse et la VRAM. Les résultats sur le GPU L4 montrent que -ub=512 avec -c=2048 fournit la configuration optimale, offrant 4 143 tokens/seconde tout en utilisant 2 025 Mo de VRAM. La conclusion est intuitive : lorsque vous connaissez la longueur maximale d’un seul document dans votre entrée, utilisez une taille de contexte plus petite, juste assez pour le couvrir. Pour la taille de lot physique, 512 tokens semblent être le point idéal sur le GPU L4.

Performance en Tokens par Seconde

Utilisation maximale de la VRAM (Mo)

tagConclusion

Pour les utilisateurs de v4 qui souhaitent exécuter GGUF quantifié efficacement sur des GPU à faible coût, choisissez IQ3_S ou IQ3_M avec notre version personnalisée de llama-embedding ; cela devrait vous donner 4 000 tokens/seconde sur des ensembles de données standard (où la longueur des phrases est < 2 048 tokens). Pour l’intégration de documents plus longs, augmentez la taille du contexte -c et contrôlez la taille de lot physique -ub pour réduire l’empreinte VRAM. Avec notre version personnalisée, vous pouvez encoder des documents très longs (> 32 000 tokens) en utilisant seulement 3 Go de VRAM en définissant -ub sur un petit nombre comme 1 024, ce qui n’était pas possible avec l’implémentation d’origine ou les transformateurs vanille.

La quête de l’optimisation de la vitesse ne se termine jamais. Il y a toujours de la place pour des implémentations plus rapides et plus légères avec un débit plus élevé. 4 000 tokens/seconde n’est probablement pas notre plafond ; il reste encore beaucoup de travail à faire. Au-delà de la correction de l’implémentation du transformateur mmproj/vision qwen2.5-vl-3b dans llama.cpp, nous explorons également des optimisations plus approfondies au niveau de llama.graph et du cache KV, améliorant la logique de traitement par lots llama-serving et ajoutant des options de diffusion en continu aux API d’intégration. Notre objectif est de faire en sorte que llama.cpp prenne en charge nativement les intégrations multimodales modernes avec décodeur uniquement pour nos versions de re-classement actuelles et futures.