Embedding API в Китае: прямой доступ, шлюз и стабильность (2026)

Когда команда в Китае подключает Embedding API, сложности обычно не в SDK. Время уходит на стабильность канала, способы оплаты, выставление счетов и на ситуацию, когда пакетная векторизация сотен тысяч текстов падает на середине. Запросы Embedding короткие, параллелизм высокий, объём большой — логика выбора здесь не такая, как у чат-API.

Ниже сравнение трёх распространённых маршрутов — прямого доступа к вендору, собственного прокси и локального AI-шлюза — а также надёжность батч-задач, границы переключения при сбое и чек-лист проверки перед запуском. Модели, размерность и биллинг смотрите на странице тарифов.

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

1. Сначала разберём три маршрута

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

Собственный прокси — reverse proxy или шлюз на сервере в вашей инфраструктуре, который концентрирует авторизацию, журналы, повторы и лимиты. Контроль высокий, но серверы, сертификаты, обновления и дежурство ложатся на вас; если строить его только «чтобы было проще», эксплуатация часто обходится дороже ожиданий.

Локальный AI-шлюз — OpenAI-совместимый вход, расчёты в юанях, обычно с консолью, статистикой расхода и счетами. Подключение дешевле и удобнее для нескольких моделей; нужно проверить юрлицо, условия данных, правила лимитов и реакцию на сбои.

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

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

2. Тест сети: Embedding важна пропускная способность, а не только задержка

Чат-API заботит задержка первого токена, Embedding — пропускная способность батчей и стабильность. Один запрос может содержать десятки или сотни текстов, а ответ — тысячи чисел с плавающей точкой; проблемы канала проявляются таймаутами, обрезкой и 5xx.

Не отправляйте на тест простое «привет». Возьмите фрагменты документов реальной длины и соберите запросы производственного размера. Наблюдайте как минимум четыре показателя: время одного батча, задержку P50/P95, долю ошибок и поведение в вечерний пик. Также уточните лимит размера тела запроса у прокси или шлюза, переиспользование соединений и таймауты: когда большой запрос обрезается промежуточным слоем, сообщение об ошибке часто неочевидно.

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

3. Оплата, договор и счета

Частая проблема команд в Китае — плательщик. Пополнение с личной карты, оплата через третье лицо и несовпадающие подтверждающие документы часто не дают финансовому отделу провести операцию. До выбора решения выясните: с кем заключается договор, в какой валюте расчёты, какой счёт можно получить, есть ли срок действия у предоплаты и каковы правила возврата.

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

4. Надёжность батч-задач

Векторизация обычно выполняется офлайн, и самое неприятное — упасть на 80% без возможности продолжить. Рекомендуется такой порядок:

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

Процесс несложный, но он предотвращает ситуацию «выглядит завершённым, а на самом деле не хватает целой порции».

5. Лимиты, повторы и переключение при сбое

Embedding-интерфейсы обычно ограничивают и число запросов, и токены. При достижении лимита возвращается 429; при перегрузке шлюза возможны 5xx или таймаут. Стратегия повторов должна различать типы ошибок: 429 и кратковременные 5xx можно повторять с задержкой; 401, 403 и ошибки параметров повторять бессмысленно — сначала исправьте конфигурацию.

import os
import time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ZSQH_API_KEY"],
    base_url=os.environ["ZSQH_BASE_URL"],
    timeout=60.0,
    max_retries=0,
)

def embed_batch(texts, model, attempts=4):
    for i in range(attempts):
        try:
            resp = client.embeddings.create(model=model, input=texts)
            vectors = [item.embedding for item in resp.data]
            dims = {len(v) for v in vectors}
            if len(dims) != 1 or len(vectors) != len(texts):
                raise ValueError("Несовпадение размерности или количества")
            return vectors, resp.usage
        except Exception as exc:
            if i == attempts - 1:
                raise
            wait = min(2 ** i, 30) + 0.5 * (i + 1)
            print(type(exc).__name__, "retry in", wait)
            time.sleep(wait)

vectors, usage = embed_batch(
    ["Первый фрагмент текста", "Второй фрагмент текста"],
    os.environ["EMBEDDING_MODEL"],
)
print(len(vectors), len(vectors[0]), usage)

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

6. Чек-лист проверки перед запуском

Размерность: совпадает с конфигурацией индекса, число векторов в ответе равно числу входов.
Базовая линия: на фиксированном наборе текстов сравните косинусную близость с прямым доступом — значения должны быть очень близки.
Расход: совпадает ли usage в ответах с биллингом; для батчей сверяйте каждую порцию.
Лимиты: приемлемы ли потолок параллелизма, доля 429 и успешность после повторов.
Таймауты: успевает ли максимальный батч в вечерний пик.
Данные: есть ли в входе персональные данные, внятно ли описаны хранение, журналы и удаление у сервиса.
Выход: можно ли ротировать ключ, вернуть остаток, сохранить старый индекс и путь отката.

Если хотя бы один пункт неясен, сначала запустите малый трафик и не переносите производственный индекс сразу.

7. Выбор по ограничениям

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

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

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

Чат-API больше зависит от задержки первого токена и стабильности потока; Embedding — это батчи, короткие ответы и большой суммарный объём, поэтому важнее пропускная способность, лимиты одного запроса и продолжение после сбоя. В план стоит включить нагрузочный тест батчей и дозапуск с контрольной точки.

Стабилен ли прямой доступ к Embedding API из Китая?

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

Что делать, если пакетная векторизация прервалась?

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

Можно ли использовать старые векторы после перехода на шлюз?

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

Можно ли разделить счета и расход по проектам?

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