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

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

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

1. Сначала различите пять понятий

  • Прямое подключение: приложение обращается к API открытой платформы Zhipu; ключ, счёт и лимиты относятся к вашему аккаунту.
  • Сетевой прокси: решает только доступность сети, не меняет семантику API, ключ остаётся вашим.
  • Собственный прокси или шлюз: вы разворачиваете пересылку, аутентификацию, лимиты и логи; вышестоящий доступ идёт через ваш аккаунт или легального поставщика.
  • Коммерческий транзит: третья сторона пересылает запросы и ведёт расчёты; возможны квоты, пакеты или общие ключи, границы определяет оператор.
  • Единый AI-шлюз: OpenAI-совместимый вход, объединяющий несколько моделей, с едиными ключами, счетами и консолью; бывает управляемым и самостоятельным.

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

2. Четыре варианта в одной таблице

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

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

3. Биллинг: что уточнить кроме коэффициента

Типичное предложение транзита — «цена провайдера умножить на коэффициент» или «пакет токенов». Коэффициент — только вход; счёт определяют следующие восемь пунктов:

  1. Раздельно ли тарифицируются вход и выход и одинаков ли коэффициент.
  2. Есть ли скидка на вход из кэша и по какой версии цены она считается.
  3. Включаются ли токены рассуждения рассуждающих моделей в выход.
  4. Тарифицируются ли сбои, повторы и обрывы потока.
  5. Возвращает ли потоковый ответ полный usage.
  6. Минимальная сумма пополнения, срок действия и условия возврата.
  7. Можно ли получить счёт, в какой валюте расчёт и как определяется курс.
  8. Можно ли разбить счёт по проектам, ключам и моделям.

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

4. Стабильность: метрики, зонд и переключение при сбоях

Стабильность оценивают не по рекламе, а по шести метрикам: успешность, задержки P50/P95, время до первого токена, доля тайм-аутов, доля 429 и скорость вывода. Тестируйте промптами реальной длины, покрывая потоковый режим, длинный контекст и параллелизм, и наблюдайте минимум один пиковый цикл.

Переключение при сбое — не просто два адреса. Переключайтесь только при ошибке соединения, 5xx и явных кодах лимита; ошибки конфигурации вроде 401, 403 и 400 при переходе обычно повторяются. Для запросов с побочными эффектами сначала выясните, был ли он выполнен, чтобы не списать деньги дважды.

import os
from openai import OpenAI

ENDPOINTS = [
    {
        "name": "primary",
        "base_url": os.environ["GLM_BASE_URL"],
        "api_key": os.environ["GLM_API_KEY"],
    },
    {
        "name": "backup",
        "base_url": os.environ["BACKUP_BASE_URL"],
        "api_key": os.environ["BACKUP_API_KEY"],
    },
]

def ask(prompt: str) -> str:
    last_error = None
    for endpoint in ENDPOINTS:
        client = OpenAI(
            base_url=endpoint["base_url"],
            api_key=endpoint["api_key"],
            timeout=60,
            max_retries=0,
        )
        try:
            resp = client.chat.completions.create(
                model=os.environ["GLM_MODEL"],
                messages=[{"role": "user", "content": prompt}],
                max_tokens=512,
            )
            return resp.choices[0].message.content
        except Exception as exc:
            last_error = exc
            print(f"{endpoint['name']} сбой: {type(exc).__name__}")
    raise RuntimeError("Основной и резервный входы недоступны") from last_error

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

5. Лимиты и параллелизм: скрытая цена общего пула

Лимиты прямого подключения обычно привязаны к аккаунту или проекту и могут измеряться параллелизмом, запросами в минуту или скоростью токенов — в зависимости от тарифа и модели. Точные значения — в консоли и документации.

Если коммерческий транзит использует общий пул, ваш пик складывается с чужими: днём всё нормально, вечером — массовые 429; в теле ошибки могут появляться сообщения о задолженности или лимите тарифа. Увидев 429, сначала прочитайте бизнес-код, а не повторяйте рефлекторно.

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

6. Принадлежность ключа и границы данных

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

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

Ещё одно правило: не передавайте ключ провайдера транзитной стороне для пополнения или управления. После того как ключ покинул аккаунт, расход и права больше не контролируются.

7. Шаги миграции: одна переменная за раз

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

Не меняйте одновременно модель, промпт и шлюз — иначе причину сбоя не установить.

8. Чек-лист проверки: надёжен ли вход

Проверка Как делать Признак проблемы
Задержка Повторять один промпт и сравнивать P50/P95 Большой разброс или стабильно медленнее прямого подключения
Доля ошибок Считать долю 429, 5xx и тайм-аутов Массовые сбои в пиках
Расход Сравнивать usage ответа со счётом Не совпадает, в потоке нет usage
Идентичность модели Сравнивать границы возможностей и стиль на фиксированном наборе Заметная деградация, сокращённый контекст
Изоляция ключей Уточнить, отдельный ли ключ и можно ли ротировать Отказ объяснить происхождение ключа
Договор и поддержка Проверить субъект, условия, счета, скорость ответа Только личный контакт, нет условий

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

9. Когда собственный прокси уместнее

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

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

10. Рекомендации: расставьте ограничения по приоритету

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

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

11. Частые вопросы (FAQ)

1. Чем транзит отличается от прокси?

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

2. Цена транзита ниже провайдера — можно ли доверять?

Она может объясняться оптовой закупкой, субсидией канала или перепродажей квот, а также сопровождаться общими ключами и нестабильностью. Сначала сверьте методику, детализацию и условия, затем проверьте на малом трафике.

3. Как понять, что транзит подменил модель?

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

4. Сколько кода нужно менять при переходе на шлюз?

Большинству проектов на OpenAI SDK достаточно изменить base_url и api_key, а имена моделей взять со страницы цен. При использовании thinking, tools или особых полей ответа нужны тесты совместимости.

5. Когда стоит строить собственный прокси?

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

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