На первый взгляд Embedding API берёт деньги только за входные токены и не имеет выходных. Но через несколько месяцев работы RAG-проекта бюджет чаще всего превышают не «слишком частые запросы», а общий объём документов после нарезки, полная перевекторизация после смены модели и накопление расходов на хранение и запросы к векторной базе.

Ниже разобраны эти статьи затрат, порядок оценки и приоритеты снижения стоимости. Цены меняются; ориентируйтесь на страницу тарифов и документацию вендора — конкретные цифры здесь намеренно не фиксируются.

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

1. Платят за входные токены, а не за «число вызовов»

Большинство Embedding-интерфейсов тарифицирует только вход и не выставляет счёт за выходные токены. Вход — это текст, который нужно векторизовать: заголовки, основной текст, преобразованные таблицы, а также HTML-теги, навигация и лишние пробелы.

При оценке учитывайте четыре усилителя затрат:

  • Различия tokenizer. Один иероглиф не обязательно равен одному токену, и разные модели считают по-разному. Не оценивайте по числу символов: сделайте вызов на небольшой выборке и прочитайте поле usage в ответе.
  • Перекрытие фрагментов. Чтобы сохранить контекст, при нарезке часто задают перекрытие 10–20%; этот текст тарифицируется повторно. Чем больше перекрытие, тем дороже построение индекса.
  • Грязный текст. Колонтитулы, шаблонные фразы и повторяющееся оглавление, если их не чистить, оплачиваются как обычные токены, но не приносят пользы поиску.
  • Повторное построение индекса. Один и тот же массив документов векторизуется в тестовой, предпроизводственной и производственной средах, и стоимость умножается на число сред.
Статья затрат Когда возникает Кто выставляет счёт Что легко упустить
Входные токены Векторизация документов и запросов Сервис Embedding Перекрытие, колонтитулы, повторная индексация
Батч-задачи Офлайн-полная и добавочная индексация Батч-интерфейс сервиса Реально ли применена скидка за батчи
Перевекторизация Смена модели, размерности или нарезки Сервис Embedding Полный пересчёт и двойное хранение на время переключения
Хранение векторов Запись векторов и индекса Векторная БД или облако Реплики, резервные копии, раздувание индекса
Поиск и egress Чтение векторов на каждый запрос БД или облако Межрегиональный доступ, пиковый QPS
Генерация ответа Передача найденных фрагментов модели Провайдер LLM Часто ошибочно включается в затраты Embedding

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

2. Батч-интерфейс: ниже цена, но дольше ожидание

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

Перед использованием уточните три вещи:

  1. Есть ли отдельная квота у батч-задач и не конкурируют ли они с реальными запросами.
  2. Тарифицируются ли неуспешные и частично успешные задания и кто платит за повторы.
  3. Передаёт ли шлюз скидку upstream на батчи. Так делают не все; спросите заранее или проверьте по первому счёту.

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

3. Перевекторизация: самая недооценённая разовая статья

Полная перевекторизация обычно требуется при следующих изменениях:

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

Стоимость перевекторизации — это не только вызовы API. В неё входят время пересчёта, хранение старого и нового индексов одновременно и колебания качества поиска в период переключения. Для большой базы знаний эта сумма может превысить все расходы на запросы, сделанные до неё.

Как снизить риск:

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

4. Хранение векторов и egress: второй счёт

Тарификация векторной базы обычно зависит от пяти вещей: объёма хранения, объёма памяти, числа реплик, количества запросов и исходящего трафика. Оценивая объём по числу векторов, сначала посчитайте сырой размер: при 1536 измерениях и float32 один вектор занимает около 6 КБ; миллион векторов — около 6 ГБ, а с индексом, метаданными и репликами реальный объём может быть в несколько раз больше.

Несколько пунктов, которые часто упускают:

  • Размерность. Чем выше размерность, тем дороже хранение и вычисления при поиске. Некоторые модели поддерживают усечение размерности; проверьте на своём наборе, доступно ли оно и как влияет на полноту поиска.
  • Реплики и резервные копии. Реплики для отказоустойчивости кратно увеличивают хранение, а политика резервного копирования тоже попадает в счёт.
  • Число запросов. Количество поисковых обращений растёт быстрее числа документов, поэтому конфигурацию выбирают по QPS, а не по объёму данных.
  • Egress. Разнесение приложения и базы по регионам, возврат большого числа кандидатов на каждый запрос и синхронизация векторов между средами создают трафик. Размещение приложения в том же регионе и ограничение числа возвращаемых кандидатов дают незаметную, но ощутимую экономию.

Для небольших задач часто достаточно PostgreSQL с pgvector; при росте объёма и параллелизма стоит оценить, оправдывает ли управляемая векторная база свою наценку.

5. Порядок точной оценки месячного бюджета

  1. Посчитайте число исходных документов, среднюю длину и параметры нарезки, а затем общий входной объём в токенах — не в символах исходного текста.
  2. По журналам реальных запросов за последнюю неделю определите число обращений в день и среднюю длину запроса.
  3. Зафиксируйте план перевекторизации на три месяца: планируется ли смена модели, нарезки или расширение языков.
  4. Уточните у поставщика векторной базы, как тарифицируются хранение, реплики, резервные копии, запросы и egress.
  5. Отдельно посчитайте «первый месяц построения индекса» и «стабильный месяц»; не смешивайте эти бюджеты.
  6. Оставьте запас и скорректируйте коэффициенты по реальному счёту за первую неделю.

Пример каркаса расчёта ниже. Числа — заполнители для демонстрации; подставьте цены со страницы тарифов и из счёта векторной базы.

# Каркас оценки: числа — примеры-заполнители, не реальные цены вендоров
docs_tokens = 40_000_000       # входные токены после нарезки всех документов
query_tokens = 2_000_000       # токены векторизации запросов в месяц
reindex_per_month = 1          # число полных пересчётов в месяц
vector_gb = 12                 # векторы, индекс и реплики суммарно

embed_price_per_1k = 0.0       # подставьте цену за 1000 токенов со страницы тарифов
storage_price_per_gb = 0.0     # подставьте цену за ГБ векторной базы

monthly_embed = (docs_tokens * reindex_per_month + query_tokens) / 1000 * embed_price_per_1k
monthly_storage = vector_gb * storage_price_per_gb
print(monthly_embed + monthly_storage)

6. Порядок снижения затрат не стоит менять

Сначала наведите порядок во входных данных, потом думайте о более дешёвой модели. Примерная последовательность:

  1. Очистка. Уберите навигацию, колонтитулы и повторяющиеся шаблоны; извлекайте основной текст и только затем нарезайте.
  2. Нарезка. Режьте по смысловым границам; перекрытия должно хватать, но не стоит считать его страховкой от всех проблем.
  3. Горячее и холодное. Исторический архив не обязательно целиком загружать в векторную базу — при необходимости векторизуйте его по запросу.
  4. Кеш запросов. Для частых одинаковых вопросов переиспользуйте готовые векторы.
  5. Батчи. Офлайн-индексацию ведите через батч-интерфейс, реальные запросы — через обычный.
  6. Оптимизация хранения. Выбирайте разумную размерность, оценивайте квантование и задавайте число реплик по нагрузке.
  7. Разделение моделей. Embedding и генеративную модель оценивайте отдельно; не жертвуйте качеством поиска ради экономии на векторах.

Если порядок обратный, типичный итог такой: модель стала немного дешевле, но перекрытие не снизилось, грязный текст не очищен, перевекторизация частая — счёт почти не меняется, а полнота поиска падает.

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

Почему у Embedding API нет стоимости выходных токенов?

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

Батч-интерфейс всегда дешевле реального времени?

Обычно цена за единицу ниже, но нужно учитывать сроки, повторы и передаёт ли шлюз скидку. Для запросов, где ответ нужен немедленно, он не подходит: экономия на цене будет съедена ожиданием.

Можно ли после смены embedding-модели перевекторизовать только часть документов?

Векторные пространства старой и новой модели обычно несовместимы, и смешивание ломает поиск. Надёжный путь — полная перестройка, проверка на теневом индексе и затем переключение; частичная перевекторизация, как правило, невозможна.

Почему хранение векторов может стоить дороже вызовов Embedding?

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

Оценка не совпадает со счётом. Что проверять первым?

Сначала ищите усиление токенов из-за перекрытия и грязного текста, затем повторное построение индекса в тестовых средах, тарификацию неудачных повторов и применение батч-скидок. В конце сверьте реплики и egress векторной базы.

Что дальше

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

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