Kimi API Key — учётные данные для вызовов открытой платформы, а не подписка на веб-версию и не баланс пополнения. Многие команды застревают при первом подключении не потому, что не умеют работать с моделью, а потому что выбрали не ту площадку, сохранили Key не там или перепутали аккаунт подписки с API-аккаунтом.

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

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

1. Сначала разделите три вида «аккаунта Kimi»

Тип Вход Назначение Баланс и Key
Подписка на сайт и приложение Kimi kimi.com Чат-продукт Не связаны с API
Открытая платформа Kimi, китайская площадка platform.kimi.com API-вызовы в Китае Отдельный аккаунт, баланс и Key
Открытая платформа Kimi, международная площадка platform.kimi.ai Зарубежные API-вызовы Полностью независима от китайской

Ключи китайской и международной площадок несовместимы. Если Key китайской площадки подставить к адресу международной или наоборот, типичный результат — 401. Есть и третий путь: создать ключ шлюза в ZSQH AI Gateway и вызывать через него Kimi и другие модели; ключом управляет шлюз, баланс тоже на аккаунте шлюза.

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

2. Регистрация и верификация

  1. Откройте platform.kimi.com и завершите регистрацию и вход по подсказкам страницы.
  2. В центре пользователя пройдите личную верификацию; для корпоративных вызовов — корпоративную.
  3. Для корпоративной верификации обычно нужны название компании, банковский счёт, совпадающий с субъектом, и единый код социального кредита.
  4. Платформа переводит на корпоративный счёт случайную сумму; подтвердите её с финансами и введите — совпадение суммы означает успех.
  5. Пополняйте после верификации. Физлица могут платить онлайн, компании — ещё и банковским переводом.
  6. Вернитесь в консоль и проверьте статус аккаунта, баланс и доступные модели.

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

3. Как создать API Key

  1. После входа откройте https://platform.kimi.com/console/api-keys.
  2. Нажмите создание API Key и назовите по схеме «проект-среда-назначение», например crm-prod-chat.
  3. Скопируйте Key. Если страница показывает его один раз, сразу сохраните в менеджер секретов, не оставляйте в переписке.
  4. Отправьте минимальный запрос в тестовой среде и убедитесь, что Key, площадка и имя модели совпадают.
  5. Запишите дату создания, ответственного, привязанный проект и планируемую дату ротации.
  6. Для продакшена, тестов и личной отладки используйте разные Key; не давайте одну строку нескольким людям.

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

4. Ротация, отзыв и ограничение прав

Относитесь к Key как к учётным данным с жизненным циклом, а не как к строке, созданной один раз навсегда.

  • Плановая ротация: обычные проекты — раз в 90 дней; для основного бизнеса можно чаще.
  • Смена людей — немедленная ротация: при увольнении, переводе или завершении подряда сначала отзовите, потом выдавайте новый.
  • Утечка — немедленный отзыв: не наблюдайте за расходом, сначала отключите, потом разбирайтесь.
  • Перекрывающая замена: создайте новый Key, разверните и проверьте, затем отзовите старый, чтобы не было разрыва.
  • Минимальные права: один Key обслуживает один проект или одну среду, чтобы зона влияния была ограничена.
  • Следы: в логах храните только префикс и имя Key, не полное значение.

Ротация — не формальность. Многие инциденты «квоту внезапно выжгли» начинаются со старого Key, оставшегося в скрипте, репозитории или переписке.

5. Безопасное хранение: переменные окружения — только начало

Минимальное правило — не писать Key в код. Для локальной разработки используйте .env и убедитесь, что он игнорируется Git; в продакшене — сервис управления секретами или внедрение через переменные окружения.

# .env только локально, не коммитить в репозиторий
MOONSHOT_API_KEY=ваш-ключ

# .gitignore как минимум содержит
.env
.env.*

Дальше три шага:

  1. Во фронтенде, мобильном приложении и браузерных расширениях Key появляться не должен; все вызовы идут через сервер.
  2. В логах, отчётах об исключениях и APM фильтруйте заголовок Authorization, чтобы Key не печатался целиком.
  3. В CI/CD используйте отдельное управление секретами и не выводите значения открыто в сборочных скриптах.

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

6. Порядок разбора 401

401 не обязательно означает неверный Key. Проверяйте в таком порядке — обычно удаётся локализовать за несколько минут.

Симптом Частая причина Действие
invalid_authentication_error Неверный формат Key, удалён, скопирован не полностью Создать заново и скопировать целиком
incorrect_api_key_error Key не передан, опечатка в заголовке Проверить Authorization: Bearer
401 сразу после смены среды Смешаны ключи китайской и международной площадок Привести площадку и Base URL к одному
403 permission_denied_error Белый список IP, интерфейс не открыт Проверить права консоли и сетевой выход
404 Ошибка Base URL или имени модели Проверить список моделей и путь интерфейса

Проверяйте по пунктам:

  1. К какой площадке относится Key и соответствует ли ей Base URL.
  2. Нет ли в Key пробелов, переводов строк или кавычек.
  3. Действительно ли загружена переменная окружения; можно вывести только первые символы.
  4. Не удалён ли Key, не отключён и не ротирован.
  5. Заголовок должен быть Authorization: Bearer <key>.
  6. Путь должен быть /v1/chat/completions; нет ли лишнего или пропущенного /v1.
  7. Проверьте новый Key, чтобы отделить проблему Key от конфигурации шлюза.

7. Как выбрать официальный или шлюзовый Key

Параметр Официальное прямое подключение ZSQH AI Gateway
Создание Консоль открытой платформы Kimi Консоль шлюза
Аккаунт Китайская или международная площадка Аккаунт шлюза
Расчёты Пополнение платформы, счёт по правилам платформы Пополнение в юанях, счёт по правилам шлюза
Модели Серия Kimi Единый вход для нескольких моделей
Когда подходит Только Kimi, нужен официальный прямой доступ Переключение моделей, единый счёт и Key

Если используется только Kimi, команда в Китае и официальный доступ стабилен, прямое подключение проще. Если одновременно нужны DeepSeek, GLM, Claude или хочется одним Key управлять несколькими моделями и вести единый счёт в юанях, шлюз удобнее. Пути не конфликтуют: можно сначала тестировать через шлюз, а потом решать, куда идёт продакшен.

8. Чек-лист внедрения в команде

  • Определить субъект использования API и пройти соответствующую верификацию.
  • Одна площадка — один аккаунт, не смешивать китайскую и международную.
  • Один проект — один Key, одна среда — один Key.
  • Key хранится только в менеджере секретов, не в репозитории.
  • Задать период ротации и ответственного.
  • Включить напоминание о балансе, чтобы задолженность не приводила к отказам или 429.
  • В мониторинге различать 401, 403 и 429, не считать всё «сломанным Key».

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

Что делать при утечке Key?

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

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

Технически обычно можно, но не рекомендуется. Общий Key мешает отнести расход, лимиты и сбои к источнику. Разделяйте ключи по проектам и добавляйте квоты на уровне приложения — разбор станет дешевле.

Истекает ли Kimi API Key?

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

После пополнения всё равно 401 — что делать?

Сначала проверьте, что пополнение и Key относятся к одной площадке и одному субъекту. Затем проверьте новый Key, исключив удаление старого, необновлённую переменную окружения или жёстко прописанное старое значение в коде.

Можно ли смешивать официальный и шлюзовый Key?

Нет. У них разные Base URL, системы аутентификации и балансовые аккаунты. Типичное проявление смешения — 401 или 404; при переключении меняйте Key, Base URL и имя модели вместе.

Что дальше

Создайте тестовый Key в ZSQH AI Gateway, проверьте цепочку минимальным запросом, затем разделите производственные ключи по проектам. Доступные модели и правила тарификации — на странице тарифов.

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