Суть транзита Moonshot API — добавить слой между бизнесом и официальной открытой платформой. Он может дать единый вход, счета в юанях, переключение между моделями и отказоустойчивость, но может принести подмену модели, непрозрачный биллинг, утечку ключа и дополнительную точку отказа. В 2026 году Moonshot перевёл основную линейку на Kimi K3 и K2.7, а moonshot-v1 отключил; если транзитный слой не обновил таблицу моделей, возникает скрытая проблема «интерфейс работает, а результат не тот».

Статья не рекомендует конкретных поставщиков, а объясняет, как оценивать, сверять и мигрировать. Модели и цены — на странице цены на модели.

Примечание: Moonshot, Kimi и Moonshot AI (Beijing Moon's Dark Side Technology Co., Ltd.) — товарные знаки или зарегистрированные товарные знаки их правообладателя. Статья носит технический характер и не подразумевает аффилированности с правообладателем; квалификация, условия и правила биллинга транзитных сервисов определяются их поставщиками — проверяйте самостоятельно до подписания.

1. Сначала разделите четыре формы транзита

Слово «транзит» часто используют как общее, но как минимум существует четыре типа с разной границей ответственности:

  • Управляемый шлюз: поставщик поддерживает единый вход, выдаёт субключи, статистику расхода, маршрутизацию моделей и счета. Вы покупаете технический сервис плюс квоту.
  • Перепродажа/дистрибуция: поставщик продаёт квоту со своего upstream-аккаунта, возможно, с коэффициентом или пакетом. Кто владелец upstream-аккаунта и каков его уровень — напрямую влияет на стабильность.
  • Собственный шлюз: вы разворачиваете one-api, new-api или similar software, ключи upstream остаются у вас. Максимальный контроль, но эксплуатация, обновления и аварийное восстановление — на вас.
  • Облачный маркетплейс или агрегатор: подключение внутри облака или агрегатора, счета идут через платформу, охват моделей может быть шире, но upstream и условия данных всё равно нужно проверять.

Сначала определите, покупаете ли вы «технический сервис» или «квоту модели», и только затем обсуждайте цену. Ответственность при сбое у них разная.

2. Ключи и сопоставление моделей: самый недооценённый риск

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

Скрытнее проблемы с данными — сопоставление моделей. Типичные риски:

  • старое имя модели молча сопоставляется более дешёвой или короткой модели: ошибки нет, качество падает;
  • в пик запросы деградируют на слабый канал, а поле model в ответе не меняется;
  • ключи китайского и международного сайтов смешиваются: обычно работает, но при региональной проверке внезапно даёт 401;
  • несколько клиентов делят один upstream-аккаунт: кто-то выбивает параллелизм, вы получаете 429;
  • upstream-аккаунт попадает под ограничения из-за аномального поведения, и такие лимиты могут не сниматься.

Поэтому в договоре должны быть таблица сопоставления моделей, правила деградации и механизм уведомления. Как минимум требуйте сохранять в ответе реальные model, usage и request_id и разрешать выгрузку журналов запросов.

3. Прозрачность биллинга: превратите правила в таблицу сверки

Основная модель Moonshot K3 тарифицирует отдельно попадание в кэш входа, промах кэша, запись в кэш и выход, причём запись в кэш различается по TTL. Если транзит сообщает только «общее число токенов», вы не поймёте, сработал ли кэш, и не сверите коэффициент.

Пункт сверки Что проверить Частое расхождение
Запись в кэш Тарифицируется отдельно, каков TTL Запись считают обычным входом
Вход с попаданием в кэш Есть ли скидка на попавшую часть Всё считают по цене промаха
Вход без попадания Совпадает ли с официальными правилами Завышают входные токены
Выходные токены Включены ли рассуждения Правила для reasoning-токенов неясны
Повторные запросы Нет ли двойного списания Тайм-аут и повтор считают дважды
Неудачные запросы Как обрабатываются 429, 5xx, обрыв Списание даже при ошибке
Поиск и batch Отдельная ли цена Смешано со счётом диалога

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

4. Задержка и ошибки: какие метрики отслеживать

Однократный замер бессмысленен; наблюдайте как минимум неделю. Зафиксируйте набор запросов и записывайте:

  • TTFT: время до первого токена; в стриминге оно лучше отражает опыт, чем общее время.
  • Задержка p50/p95: смотрите на хвост, а не на среднее.
  • Доля ошибок: отдельно по 401, 403, 404, 429, 499, 5xx и error.type.
  • Разрез по моделям: один запрос на разных моделях и каналах оценивайте отдельно.
  • Сходимость расхода: совпадает ли usage в ответе со счётом.

Ниже минимальный зонд для проверки цепочки и записи метрик:

import os, time
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["RELAY_KEY"],
    base_url=os.environ["RELAY_BASE"],
    max_retries=0,
)

start = time.time()
try:
    resp = client.chat.completions.create(
        model=os.environ["MODEL"],
        messages=[{"role": "user", "content": "Ответьте только OK"}],
        max_completion_tokens=16,
    )
    elapsed = time.time() - start
    print({
        "ok": True,
        "latency_ms": round(elapsed * 1000),
        "model": resp.model,
        "usage": resp.usage.model_dump() if resp.usage else None,
        "request_id": resp.id,
    })
except Exception as exc:
    print({"ok": False, "latency_ms": round((time.time() - start) * 1000),
           "error": type(exc).__name__, "detail": str(exc)[:200]})

В продакшене результаты нужно писать в хранилище временных рядов и агрегировать по часам p50, p95, долю ошибок и распределение моделей. Если оповещать только о «сбое», не различая тип 429, дежурный не поймёт, снижать скорость, пополнять баланс или переключаться.

5. Чек-лист миграции: с прямого подключения на транзит

  1. Инвентаризируйте текущие имена моделей и проверьте, не используется ли отключённый moonshot-v1; сначала перейдите на kimi-k3, kimi-k2.7 или kimi-k2.6.
  2. Зафиксируйте набор регрессионных запросов: короткие вопросы, длинные тексты, стриминг, вызов инструментов и ввод изображений.
  3. Прогоните один и тот же набор напрямую и через транзит, сравнив model, usage, request_id и качество вывода.
  4. Проверьте реально используемые форматы API: Chat Completions, Responses или Anthropic Messages — не ограничивайтесь одним.
  5. Убедитесь, что стриминг отдаёт блоки по мере поступления и корректно завершается, а промежуточный прокси не включает буферизацию.
  6. Намеренно вызовите 401, 404 и 429 и проверьте читаемость типа ошибки и корректность её сопоставления на клиенте.
  7. Сверьте реальный счёт с usage, включая кэш, повторы и неудачные запросы.
  8. Пустите низкорисковые сервисы канареечно, сохраните переключатель возврата на прямое подключение и наблюдайте минимум неделю перед переводом основного трафика.

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

6. Как проверить транзит

Проверка должна объединять несколько сигналов, один показатель не доказывает происхождение:

  • совпадает ли model в ответе с запросом, нет ли незаявленной деградации;
  • полна ли структура usage, соответствуют ли поля кэша официальным правилам;
  • прослеживается ли request_id и сопоставляется ли он с журналами поставщика;
  • сравните вывод с прямым подключением на фиксированном наборе, оцените стабильность качества и задержки;
  • поддерживаются ли все три формата API и передаются ли расширения параметров официальным способом;
  • сохраняется ли error.type в ошибках, а не единая обёртка «сбой сервиса»;
  • совпадают ли субъект счёта, договора и получателя платежа;
  • есть ли страница статуса, SLA, уведомления о сбоях и история доступности.

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

7. Механизм выхода нужно продумать заранее

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

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

Часто задаваемые вопросы

Транзит всегда стабильнее прямого подключения?

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

Нормально ли, что транзит дешевле официального?

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

Решает ли собственный прокси проблему 429?

Он не увеличивает квоту upstream. Прокси может ставить в очередь, снижать скорость, повторять и переключать; если параллелизм или TPD upstream-аккаунта исчерпаны, придётся ждать сброса или повышать уровень.

Как понять, что транзит действительно использует Moonshot?

Смотрите model, usage и request_id в ответе, затем сравните с прямым подключением на фиксированном наборе. Комбинированная проверка надёжнее любого одного показателя; при сомнениях в источнике выбирайте прямое подключение.

Сколько кода менять при переходе на транзит?

В OpenAI-совместимых проектах обычно меняются только Base URL, ключ и имя модели. Но стриминг, тайм-ауты, сопоставление типов ошибок и статистику расхода нужно тестировать заново — именно здесь чаще всего ломается после переключения.

Что дальше

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

Похожие материалы: