Посредника (relay) для Embedding API часто воспринимают как способ «поменять адрес и немного сэкономить». Но векторизация — это пакетная задача: одна миграция может затронуть сотни тысяч текстов. Если посредник ограничивает скорость, обрезает данные или незаметно подменяет модель, потеря измеряется не одним запросом, а доверием ко всему индексу.

Ниже четыре вопроса: какие бывают формы посредничества, как проектировать батч-запросы, как сверять биллинг и как выполнять миграцию с проверкой результата. Актуальные модели и цены смотрите на странице тарифов.

Примечание: OpenAI и другие названия моделей и сервисов являются товарными знаками их правообладателей; автор не связан с указанными вендорами. Рынок посредников меняется быстро, и эта статья не является рекомендацией какого-либо сервиса.

1. Посредник, прокси и шлюз — не одно и то же

  • Сетевой прокси решает только задачу доступности: пересылает HTTP или HTTPS-запросы, а ключ остаётся у вас.
  • Коммерческий посредник пересылает запросы вверх по цепочке и может добавлять биллинг, лимиты, журналы и счета. На рынке встречаются также схемы с общими или перепродаваемыми ключами — стабильность зависит от оператора.
  • Единый AI-шлюз даёт OpenAI-совместимый вход, объединяет несколько моделей, выдаёт отдельные ключи и предоставляет консоль со статистикой расхода.
  • Собственный прокси — это развёрнутый вами reverse proxy или шлюз. Максимальный контроль, но эксплуатацию и аккаунты upstream вы берёте на себя.

До подписания договора выясните, какой именно уровень сервиса вам предлагают, кому принадлежит ключ и через какие узлы проходят данные. Без этого любое сравнение теряет смысл.

Критерий Прямой доступ к вендору Собственный прокси Коммерческий посредник Единый AI-шлюз
Биллинг Счёт вендора, понятные правила Счёт upstream плюс ваши затраты Зависит от оператора, нужна сверка Единый счёт в кабинете
Пропускная способность Ограничена квотами аккаунта Можно ставить в очередь, но upstream всё равно ограничивает Возможен общий пул, нужно уточнять Зависит от лимитов и планировщика шлюза
Владение ключом Ключ у вас Ключ у вас Возможны общие или перепродаваемые ключи Обычно отдельный ключ
Границы данных Оцениваете сами Отвечаете сами Нужно изучить условия и хранение Нужно изучить условия и документы
Счета и договор Зависит от юрлица Договора с третьей стороной нет Зависит от возможностей сервиса Обычно есть счёт-фактура
Стоимость эксплуатации Средняя Высокая От низкой до средней Низкая

2. Батч-запросы: сначала нагрузочный тест, потом цена

Пропускную способность Embedding определяют три переменные: число текстов в одном запросе, длина каждого текста и уровень параллелизма. У разных сервисов есть верхние пределы на количество элементов, суммарные токены и размер тела запроса; при превышении можно получить ошибку параметров или молчаливую обрезку на промежуточном слое.

Нагрузочный тест нужно проводить на производственных данных. Возьмите реальные фрагменты документов и соберите из них запросы малого, среднего и большого размера. Смотрите время одного батча, задержку P95, долю ответов 429 и типы ошибок. Больше — не значит лучше: у слишком крупного батча дороже повтор после сбоя и сложнее уложиться в таймаут.

Рекомендуемый порядок подготовки батчей:

  1. Сначала постройте распределение длин текстов и оценивайте объём в токенах, а не режьте по количеству строк.
  2. Задайте верхний предел на один батч и оставьте запас под длинные тексты.
  3. Начинайте с низкого параллелизма, увеличивайте его шагами и фиксируйте пропускную способность и долю ошибок.
  4. Достигнув целевой пропускной способности, перестаньте наращивать параллелизм — не выедайте весь запас.
  5. Сохраняйте на диск хеш входа, расход токенов и результат каждого батча: это нужно для сверки и продолжения после сбоя.

3. Повторы и частичные сбои

Запросы Embedding только читают данные, поэтому повтор не создаёт дублирующих записей, но увеличивает счёт. Для 429 и кратковременных 5xx подходит экспоненциальная задержка со случайным разбросом. При 401, 403, 404 и ошибках параметров нужно немедленно остановиться и исправить ключ, адрес или тело запроса.

Частичные сбои обрабатывайте отдельно. Если из батча в 200 текстов три отклонены из-за длины, не повторяйте весь батч бесконечно. Выделите проблемные тексты, исправьте или обрежьте их, отправьте отдельно, а остальные результаты нормально запишите в индекс. Для записи используйте upsert по хешу содержимого, чтобы повторный запуск не создавал дубликатов.

import hashlib
import os
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_API_KEY"],
    base_url=os.environ["RELAY_BASE_URL"],
    timeout=60.0,
    max_retries=0,
)
MODEL = os.environ["EMBEDDING_MODEL"]

def key_of(text):
    return hashlib.sha256(text.encode("utf-8")).hexdigest()

def embed_with_retry(batch, attempts=4):
    for i in range(attempts):
        try:
            resp = client.embeddings.create(model=MODEL, input=batch)
            store = {
                key_of(batch[d.index]): d.embedding
                for d in resp.data
            }
            return store, resp.usage
        except Exception as exc:
            if i == attempts - 1:
                raise
            time.sleep(min(2 ** i, 30))

texts = ["Фрагмент документа 1", "Фрагмент документа 2", "Фрагмент документа 3"]
store, usage = embed_with_retry(texts)
print(len(store), len(next(iter(store.values()))), usage)

4. Прозрачность биллинга

Embedding обычно тарифицируется по входным токенам и не имеет выходных — этим он отличается от чат-моделей. При сверке выясните:

  • как считаются токены и совпадает ли расчёт с tokenizer вендора;
  • тарифицируются ли неуспешные и повторные запросы;
  • есть ли скидки за пакетную обработку, кеширование или ступенчатые тарифы;
  • можно ли выгрузить расход по проекту, ключу и модели;
  • есть ли срок действия у предоплаты и можно ли вернуть остаток;
  • как определяются содержание счёта, валюта и курс.

«Низкий коэффициент» не равен низкой итоговой стоимости. Если посредник берёт деньги за неудачные повторы или статистика расходится с полем usage в ответе, экономия съедается скрытыми потерями. Цены и правила смотрите на странице тарифов и в счетах сервиса; устным обещаниям доверять не стоит.

5. Риски ключей и границы данных

Самое незаметное в посредничестве — вопрос принадлежности ключа. Общий ключ, перепроданный лимит или баланс неизвестного происхождения создают четыре проблемы: при блокировке upstream бизнес останавливается вместе с ним; общий пул нескольких клиентов влияет на лимиты друг друга; содержимое запросов проходит через третью сторону, а журналы и хранение непрозрачны; если условия сервиса запрещают перепродажу, в споре не будет оснований.

При выборе сервиса как минимум проверьте юрлицо, условия обслуживания, политику конфиденциальности, место хранения данных, возможность выставления счетов и канал связи при сбоях. Тексты с персональными данными, договорами или секретами не отправляйте посреднику, который не может объяснить, куда уходят данные. В регулируемых отраслях сначала оценивайте прямой доступ, частное развёртывание или сервис, готовый подписать соглашение об обработке данных.

6. Чек-лист миграции

При переходе с прямого доступа на посредника или шлюз рекомендуется такой порядок:

  1. Зафиксируйте текущие модели, размерность, параметры батчей и структуру индекса, а также базовую долю успешных запросов и задержку P95.
  2. Прогоните фиксированную выборку через прямой доступ и сохраните векторы, usage и время выполнения.
  3. Создайте тестовый ключ с бюджетом и оповещениями; не используйте сразу производственный ключ.
  4. Поменяйте только base_url и api_key и выполните минимальный запрос в среде предварительной проверки.
  5. Прогоните ту же выборку через посредника и сравните размерность, число элементов, usage и косинусную близость.
  6. Переведите 5–10% батч-задач в режим постепенного запуска и наблюдайте 3–7 дней, сохраняя прямой доступ как резерв.
  7. После полной миграции сверяйте счета неделю: суммы, число записанных строк и журнал повторных запусков должны совпадать.
  8. Сохраните как минимум одну предыдущую версию индекса и удаляйте её только после подтверждения стабильности поиска.

Если посредник использует другую модель, смешивать старые и новые векторы нельзя. Нужно построить параллельный индекс, полностью пересчитать векторы, сравнить качество поиска и только затем переключаться.

7. Как проверить надёжность посредника

  • Согласованность векторов. Отправьте один и тот же текст напрямую и через посредника, сравните размерность и косинусную близость. Заметное расхождение — повод искать подмену модели или обрезку.
  • Согласованность расхода. Сверяйте usage в ответах с биллингом побатчно, особенно повторы и неуспешные запросы.
  • Задержка и ошибки. Тестируйте реальный батч в вечерний пик, фиксируйте P50/P95, долю 429 и 5xx.
  • Лимиты батча. Уточните ограничения на число элементов, суммарные токены и размер тела, чтобы производственный батч не обрезался.
  • Изоляция ключей. Проверьте, отдельный ли ключ, можно ли его ротировать и не делятся ли квоты с другими клиентами.
  • Договор и поддержка. Изучите юрлицо, условия, счета и скорость ответа поддержки. Только личный контакт и отказ показывать детализацию расхода — тревожные признаки.

Поле model в ответе само по себе не доказательство: его можно переписать. Надёжнее сочетать несколько проверок.

8. Когда посредник не нужен

Если данные чувствительны, а политику хранения проверить нельзя; если нужна прямая поддержка вендора; если объём вызовов мал; если у команды нет ресурсов на сверку счетов — посредник может оказаться невыгодным. Он также не позволяет обойти лимиты upstream или условия обслуживания. Для редкой векторизации небольших объёмов проще может быть прямой доступ с небольшим скриптом.

Если нужен единый вход и сравнение нескольких моделей, можно создать тестовый ключ в ZSQH AI Gateway, проверить согласованность векторов на фиксированной выборке и затем переносить батч-задачи. Доступные модели и биллинг смотрите на странице тарифов.

Читайте также:

Частые вопросы

Чем посредник Embedding API отличается от чат-посредника?

Для чата важны потоковый вывод и задержка первого токена; для Embedding — пропускная способность батчей, лимиты одного запроса, продолжение после сбоя и согласованность векторов. При сверке учитывайте, что Embedding обычно тарифицируется только по входным токенам.

Можно ли смешивать векторы от посредника и от прямого доступа?

Только если это одна и та же модель одной версии. Векторные пространства разных моделей несовместимы: даже при одинаковой размерности их нельзя класть в один индекс. Перед миграцией сравните косинусную близость на фиксированной выборке.

Что делать, если половина батча завершилась ошибкой?

Сначала определите тип сбоя: при 429 и кратковременных 5xx помогает повтор с задержкой; слишком длинные тексты и ошибки параметров нужно выделить и обработать отдельно. Используйте хеш содержимого как идемпотентный ключ и дозаписывайте только недостающие элементы.

Как считается оплата у посредника?

Чаще всего по входным токенам, но правила подсчёта, тарификация неуспешных повторов и скидки за батчи различаются. Ориентируйтесь на счёт и детализацию расхода и до подписания внесите эти пункты в таблицу сравнения.

Нужно ли заново векторизовать данные при переходе?

При той же модели и версии обычно нет; при смене модели индекс нужно строить заново. Даже без пересчёта сохраните старый индекс и путь отката и проверьте согласованность на фиксированной выборке.