Оптимизация GGUF для моделей формирования векторных представлений только с декодером

Две недели назад мы выпустили GGUF-форматы jina-embeddings-v4 — универсальной модели 向量模型 для мультимодального многоязычного поиска — с различными квантованными версиями. Наша мотивация была проста: поскольку jina-embeddings-v4 является моделью с 3.75B параметрами, ванильная transformer-версия не очень хорошо масштабируется на наших API-инстансах GCP G2 (L4 GPU), поэтому мы хотели ускорить вывод, используя эти меньшие по размеру и более быстрые GGUF-версии. В ходе наших экспериментов мы обнаружили несколько интересных моментов при преобразовании и запуске GGUF 向量模型ей. Поскольку основное внимание сообщества llama.cpp сосредоточено на 大模型ях, мы подумали, что было бы полезно поделиться этим с точки зрения поставщика 向量模型ей.

Особенно актуально то, что сегодняшние 向量模型и практически идентичны 大模型ям — например, jina-embeddings-v4 основана на Qwen2.5-VL-3B-instruct, а jina-reranker-m0 — на Qwen2-VL-2B. Единственное реальное отличие — это вывод: 大模型и являются генеративными, а 向量模型и и 重排器ы — дискриминативными. Это создает как возможности, так и проблемы: с одной стороны, мы можем использовать эффективную реализацию llama.cpp (например, ubatch_size) для обслуживания 向量模型ей/重排器ов; с другой стороны, реализации 向量模型ей в llama.cpp в основном разрабатывались для более старых архитектур, использующих только кодировщик (например, модели на основе RoBERTa), и еще не полностью соответствуют современным 向量模型ям/重排器ам, использующим только декодировщик. В этой статье мы расскажем о том, что мы узнали при адаптации современных 向量模型ей для работы с форматом GGUF и инструментами llama.cpp, например, llama-embedding и llama-serving.

tagБазовые и квантованные GGUF

jina-embeddings-v4 основана на Qwen2.5-VL-3B-instruct с тремя LoRA-адаптерами: retrieval (оптимизирован для задач поиска), text-matching (оптимизирован для задач определения сходства предложений) и code (оптимизирован для задач поиска кода). Она также интенсивно обучается для визуального поиска документов и многовекторного вывода в стиле позднего взаимодействия. Таким образом, идея здесь заключается в том, чтобы использовать существующую графовую реализацию Qwen2.5-VL-3B в llama.cpp и использовать llama-embedding для вывода.

Однако первое, что мы заметили, — это ошибочное поведение в реализации mmproj или vision transformer в llama.cpp, которая выдает разные 向量模型и по отношению к torch-реализации Qwen2.5-VL-3B при одинаковом изображении на входе. Пока мы исправляем эту проблему в нашей ветке, мы решили пока исключить vision tower из 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

Многовекторный вывод 向量模型ей также не поддерживается из коробки, но это не такая большая проблема, как vision transformers. Многовекторный вывод происходит из обученного MLP в последнем transformer-блоке, поэтому в худшем случае мы всегда можем экспортировать этот MLP отдельно в numpy и применить его после получения 向量模型ей на уровне 词元ов из llama.cpp — что мы и сделали для jina-reranker-m0-GGUF. Конечно, это не очень эффективно, но работает без необходимости изменять и перекомпилировать llama.cpp.

Итак, чтобы полностью соответствовать существующей реализации графа Qwen2.5-VL-3B в llama.cpp, мы удалили vision transformer и многовекторный проектор в последнем transformer-блоке и объединили все LoRA-адаптеры обратно в базовую языковую модель. Это дало нам три task-specific v4 модели по 3.09B параметров каждая — по сравнению с 3.75B параметрами оригинальной v4:

Затем мы использовали calibration_data_v5_rc.txt (который можно найти здесь и рекомендован Unsloth) для калибровки всех трех базовых GGUF-моделей и получили три файла imatrix, затем использовали llama-quantize с imatrix для квантования моделей из float16 следующим образом:

# 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
Копировать

Скрипт quantize.sh показан ниже:

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

tagИспользование и предостережения

Теперь мы можем использовать llama-server и llama-embedding для обслуживания GGUF для создания 向量模型. В отличие от библиотек transformer, где у нас есть гибкость в написании пользовательского кода предварительной обработки входных данных, мы должны обрабатывать эту часть вручную (если мы не хотим перекомпилировать llama-server и llama-embedding). В частности, чтобы получить результаты, которые полностью согласуются с использованием AutoModel.from_pretrained("jinaai/jina-embeddings-v4")..., вам нужно быть очень осторожным с префиксами и вручную добавлять их к входным данным вашей GGUF-модели. Вот справочная таблица:

Некоторых пользователей может удивить ⚠️, что prompt_name='passage' переопределяется на "Query: " при использовании text-matching в исходном AutoModel.from_pretrained("jinaai/jina-embeddings-v4").... Но на самом деле это имеет смысл, поскольку text-matching — это задача определения сходства предложений без левой/правой ролей, входные данные симметричны.

tagЧерез llama-server

После установки llama.cpp вы можете запустить llama-server, чтобы разместить модель создания 向量模型 в качестве HTTP-сервера, совместимого с OpenAI API. Например, чтобы использовать text-matching с F16, вы можете сделать следующее:

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: 浜辺に沈む美しい夕日"
    ]
  }'
Копировать

tagЧерез llama-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: перед текстовыми входными данными.
• Они не могут обрабатывать ввод изображений прямо сейчас, потому что мы удалили vision transformers из модели GGUF. Нам пришлось удалить их из-за ошибок в реализации vision transformer/mmproj в llama.cpp для Qwen2.5-vl-3b, которые мы сейчас исправляем вместе с upstream.
• Они не могут выводить многовекторные 向量模型, поскольку это не является частью графовой реализации Qwen2.5-vl-3b в llama.cpp. Самый простой обходной путь без перекомпиляции llama.cpp — экспортировать и запустить MLP отдельно после получения 词元-level 向量模型, установив --pooling none в llama-embedding.
• v4 обучена с помощью Matryoshka representation learning, и преобразование в GGUF сохраняет эту функцию. Если вы получаете 向量模型 формы NxD, вы можете просто использовать embeddings[:, :truncate_dim], чтобы получить меньшие усеченные 向量模型. Однако не каждое измерение обучено. Для v4 мы обучили truncate_dim для этих конкретных значений: [128, 256, 512, 1024, 2048]. Это означает, что качество embeddings[:, :131] не будет какой-то интерполяцией между качеством embeddings[:, :128] и embeddings[:, :256], но будет значительно хуже, чем 向量模型 128-dim или 256-dim, потому что 131-dim не обучено.
• Late chunking по-прежнему может работать как часть постобработки после получения 词元-level 向量模型 с помощью --pooling none. Точно так же, как мы делали с отделением MLP от графа llama.cpp, это не очень эффективно, но не требует перекомпиляции. Однако есть еще одно предостережение: поскольку v4 является причинной моделью, late chunking больше не будет двунаправленным — более ранние chunk 向量模型 не будут содержать контекстную информацию из последующих chunks. Помните, что в v3 каждый chunk 向量模型 имел глобальную контекстную информацию, потому что мы использовали двунаправленные маски внимания в transformer blocks. Внутри мы обсуждали, делает ли причинность late chunking устаревшим: некоторые утверждают, что «контекст также является причинным» — это означает, что читатель обрабатывает текст слева направо, поэтому контекст, необходимый для интерпретации предложения, должен исходить из предшествующего текста. Другие говорят, что ограничение late chunking до однонаправленного блокирует обмен контекстом между chunks. В любом случае, эффективность late chunking в v4 остается сомнительной и требует дальнейшего изучения.

tagЭффективное создание 向量模型 через llama-embedding

llama-embedding — это относительно простая C++ обертка поверх llama.cpp для встраивания текста с очень чистым вводом-выводом: stdin, stdout. Сейчас мы сосредоточены на улучшении этого, а не llama-server, потому что есть множество других проблем, таких как сетевая очередь, балансировка нагрузки, multi-tenancy и сериализация, которые, по нашему мнению, выходят за рамки данной статьи. Наш вопрос прост: какую скорость мы можем получить от графического процессора L4 24GB и каково пиковое использование VRAM для встраивания длинных документов?

Но почему L4? В основном потому, что GCP предлагает довольно удобные функции Cloud Run поверх него, и это наиболее широко доступный и экономичный тип графического процессора, который вы можете получить для API бессерверного вывода. GCP предлагает A100 и H100 на Cloud Run по запросу, и команда GCP время от времени предлагает нам использовать графические процессоры получше. Но наша философия проста: если нам нужны A100/H100 для обслуживания модели 3B, то это явно проблема с нашими навыками.

Для справки: в llama.cpp логический размер пакета (-b) представляет максимальное количество токенов, отправляемых модели за один вызов оценки. При обработке длинных входных данных они разбиваются на фрагменты до этого размера. Физический размер пакета (-ub) - это фактическое количество токенов, обрабатываемых одновременно за один прямой проход через оборудование, ограниченное доступной памятью. Обновления 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 при кодировании длинных контекстов - вы можете обрабатывать контекст 32K с небольшим физическим пакетом в 512 токенов, чтобы оставаться в пределах ограничений VRAM благодаря реализации KV-кэша. Обратите внимание, что это изменение корректно только для причинных моделей векторных представлений, таких как jina-embeddings-v4 - для архитектур только с кодировщиком, таких как v3, это была бы неправильная реализация.
• Исправлено среднее объединение: Мы исправили вычисление среднего объединения для векторных представлений, когда ub < b, которое ранее было сломано в оригинальной реализации.

Это изменение значительно упрощает работу с моделями векторных представлений с длинным контекстом, предназначенными только для декодирования, при эффективном управлении ограничениями памяти. Теперь пользователям нужно настроить только два параметра:

• -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 и отобразим все квантования по их битам на вес в зависимости от скорости (измеряется в токенах в секунду) и потребления VRAM. Мы обнаружили, что версии GGUF немного быстрее, чем ванильная версия при FP16 (2023 против 1865 токенов/сек). Большинство квантований группируются около 2000-2100 токенов/сек. С включенным flash attention мы получаем ~77% прирост скорости для всех квантований (3000+ против 2000+ токенов/сек). Однако, наиболее эффективное квантование Q8_0 со скоростью около 3700 токенов в секунду все еще намного отстает от ванильной v3 (572M параметров), которая достигает 16000 токенов/сек. Квантованные версии значительно экономят VRAM и почти достигают уровня модели v3 FP16 с IQ3.

tagОптимальный размер физического пакета и контекста

Теперь зафиксируем тип квантования на IQ3_S и изучим, как размер физического пакета (-ub) и размер контекста (-c) влияют на скорость и VRAM. Результаты на L4 GPU показывают, что -ub=512 с -c=2048 обеспечивает оптимальную конфигурацию, обеспечивая 4143 токена/сек при использовании 2025 МБ VRAM. Вывод интуитивно понятен: если вы знаете максимальную длину одного документа во входных данных, используйте меньший размер контекста, которого достаточно для его охвата. Для размера физического пакета 512 токенов, похоже, являются оптимальным вариантом на L4 GPU.

Производительность в токенах в секунду

Пиковое использование VRAM (МБ)

tagЗаключение

Для пользователей v4, которые хотят эффективно запускать квантованные GGUF на бюджетных GPU, выберите IQ3_S или IQ3_M с нашей пользовательской сборкой llama-embedding — это должно дать вам 4000 токенов/сек на обычных наборах данных (где длина предложения <2048 токенов). Для встраивания более длинных документов увеличьте размер контекста -c и контролируйте размер физического пакета -ub, чтобы уменьшить занимаемый объем VRAM. С нашей пользовательской сборкой вы можете кодировать очень длинные документы (>32K токенов), используя всего 3 ГБ VRAM, установив для -ub небольшое число, например 1024 — что было невозможно с исходной реализацией или стандартными трансформаторами.

Поиск оптимизации скорости никогда не заканчивается. Всегда есть место для более быстрой и экономичной реализации с более высокой пропускной способностью. 4000 токенов/сек, вероятно, не наш предел — предстоит еще много работы. Помимо исправления реализации qwen2.5-vl-3b mmproj/vision transformer в llama.cpp, мы также изучаем более глубокие оптимизации на уровне llama.graph и KV-cache, улучшаем логику пакетирования llama-serving и добавляем параметры потоковой передачи в API встраивания. Наша цель — сделать так, чтобы llama.cpp изначально поддерживал современные мультимодальные встраивания только для декодера для наших текущих и будущих выпусков reranker.