Kimi K2.6: модель, которую ранее обслуживала Gonka

Kimi K2.6 — большая языковая модель (LLM) серии Kimi, разработанная пекинской компанией Moonshot AI. Moonshot AI — одна из ведущих AI-лабораторий Китая, основана в 2023 году командой исследователей под руководством Yang Zhilin. Компания привлекла финансирование от Alibaba, Tencent и других крупных инвесторов и попала в список «китайских AI-тигров» — компаний, которые задают темп развития AI в Азии.

Серия Kimi известна с 2024 года. Ранние версии (K1, K1.5) сразу обратили на себя внимание исключительно длинным контекстным окном — до 200 000 токенов в одном запросе, что в момент релиза было рекордом для публично доступных моделей. Длинный контекст означает практическую возможность за один запрос проанализировать целую книгу, кодовую базу среднего размера или подборку юридических документов. На момент выхода Kimi эта характеристика была сильным конкурентным преимуществом.

Версия K2 появилась в 2025 году и принесла принципиальный архитектурный скачок — переход на MoE (Mixture of Experts). Эта же архитектура лежит в основе Qwen3-235B и DeepSeek-R1 — она стала фактическим стандартом для крупнейших моделей 2025—2026 годов. MoE позволяет иметь сотни миллиардов параметров «всего», но на каждом запросе активировать лишь подмножество (обычно 5—10%), что радикально снижает вычислительную стоимость inference при сопоставимом качестве.

K2.6 — последняя итерация серии K2 на момент написания статьи. Из публичных заявлений Moonshot AI следует, что в этой версии улучшены способности модели в reasoning (логических рассуждениях), генерации кода и нативном вызове инструментов (tool calling). Пока модель обслуживалась сетью Gonka, она была доступна под идентификатором moonshotai/Kimi-K2.6; сейчас шлюз этот идентификатор не принимает — актуальный список моделей всегда отдаёт GET /v1/models.

Обе модели представляют флагманские разработки крупнейших китайских AI-лабораторий; пока обе обслуживались сетью, они были доступны через единый OpenAI-совместимый интерфейс JoinGonka Gateway — сегодня из этой пары через шлюз доступна только MiniMax M2.7. При этом у них разные сильные стороны и разное наследие, что делает выбор между ними не вопросом «какая лучше», а вопросом «какая подходит под задачу».

На бенчмарках reasoning (MATH-500, GSM8K, AIME) серия Kimi K2 исторически показывает результаты в верхней группе open-weights моделей, конкурируя с DeepSeek-R1 и o1-style моделями. На задачах генерации кода (HumanEval, MBPP) обе модели держатся на близких уровнях. Сильная сторона MiniMax M2.7 — эффективный (линейный) attention для очень длинных последовательностей, тогда как Kimi известна сильным reasoning и длинным контекстом серии Kimi.

Важная оговорка про бенчмарки в 2026 году: разрыв между топ-моделями в публичных тестах сократился до единиц процентов, и эта разница часто оказывается в пределах статистической погрешности самих бенчмарков. Для практической работы значение имеет не «кто на 2% выше в MMLU», а характер задач: какой контекст вы передаёте модели, насколько сложны логические цепочки, нужна ли длинная история диалога, какие языки используются. Поэтому таблица выше не ранжирует модели — она помогает быстро понять, под какой профиль задач каждая из них оптимизирована.

Для практического выбора сегодня: ниша Kimi K2.6 — длинный контекст (анализ больших документов, чтение объёмной кодовой базы, длинные диалоги с сохранением истории) и сложные reasoning-задачи — в текущем составе сети закрыта двумя моделями. За рассуждения отвечает GLM-5.3 Flash: она думает перед ответом, и именно её стоит брать под запутанную логику; у неё же самый длинный контекст сети (390K). За большие промпты без рассуждений и длинные агентные сессии — DeepSeek V4 Flash (380K, второй по длине контекст). Если в приоритете обработка очень длинных входных последовательностей и потоковых данных с быстрым ответом — MiniMax M2.7 с её эффективным attention. Хорошая стратегия в продакшене не изменилась — держать несколько моделей сети в своём коде: быстрая смена через параметр model позволяет переключаться между ними в зависимости от задачи без изменения архитектуры приложения.

До весны 2026 вся сеть Gonka обслуживала ровно одну модель — Qwen3-235B. С точки зрения архитектуры это было осмысленное решение: распределённый inference через DiLoCo требует, чтобы все участники сети держали одну и ту же модель в видеопамяти, иначе невозможно гарантировать, что любой узел сможет обработать любой запрос. Полная Qwen3-235B в формате FP8 занимает около 640 ГБ VRAM, что уже само по себе огромное обязательство для каждой ML-ноды.

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

Идея пришла не из воздуха — она была формализована в Gonka Improvement Proposal #800 «Multi-Model PoC», вынесенном на голосование сообщества весной 2026 года. Предложение получило поддержку участников и валидаторов сети и было реализовано в апреле—мае 2026. Kimi K2.6 стала первой моделью, запущенной на отдельном DevShard, — то есть фактически тестовой реализацией нового подхода. Опыт оказался успешным: вслед за ней на своих шардах появились MiniMax M2.7, DeepSeek V4 Flash и GLM-5.3 Flash — каждая с собственным набором хостов и собственной экономикой. Тот же механизм работает и в обратную сторону: модель, которую перестают поддерживать хосты, выводится из состава сети голосованием — именно так в сентябре 2026 ушла и сама Kimi K2.6.

Что это значит для пользователей и разработчиков:

• Один API — несколько моделей. Через JoinGonka Gateway не нужно менять endpoint или ключи: достаточно указать другой model в теле запроса. OpenAI-совместимый формат полностью сохраняется.
• Цена та же. Пока Kimi K2.6 обслуживалась, она тарифицировалась по той же ставке, что и MiniMax M2.7; единый тариф сети сохраняется и для нынешних моделей — $0.0069 за 1M токенов через Gateway. Единый прайсинг — сознательное решение для упрощения миграции пользователей между моделями.
• Стабильность зависит от загрузки шарда. На ранней стадии шард новой модели имеет меньше хостов, поэтому при концентрации запросов модель может временно возвращать 429 too many concurrent requests. Это нормальная фаза для новой модели: по мере роста интереса хосты подключаются к её шарду, и лимиты растут. Верно и обратное — если хосты уходят из шарда, модель теряет ёмкость; именно так закончилась история Kimi K2.6 в сети.
• Tool calling у каждой модели свой. У Kimi K2.6 в сети Gonka на старте фиксировались мелкие проблемы с автоматическим выбором инструментов (tool_choice: "auto"), позже снятые обновлением нод. Урок остался актуальным для любой модели сети: формат вызова инструментов — свойство конкретной модели на конкретной ноде, поэтому для критичных в продакшене сценариев заранее протестируйте поведение выбранной модели на ваших запросах.

Прямой ответ: через сеть Gonka Kimi K2.6 больше не доступна. Хосты перестали обслуживать её в начале сентября 2026, а governance-предложение #101 вывело модель из списка моделей сети окончательно — запрос с model: "moonshotai/Kimi-K2.6" шлюз отклонит. Поскольку веса модели открыты, её по-прежнему можно получить у сторонних хостингов open-weights моделей (например, через OpenRouter) или развернуть самостоятельно.

Если же вам нужен тот самый дешёвый децентрализованный inference, ради которого приходят в Gonka, — он никуда не делся, просто работает на действующих моделях сети. Через JoinGonka API Gateway по OpenAI- и Anthropic-совместимому API доступны три модели, и каждая закрывает свою часть того, за что ценили Kimi:

• GLM-5.3 Flash (zai-org/GLM-5.3-Flash) — reasoning-модель Z.ai: рассуждает перед ответом, поэтому именно её стоит брать под сложную логику, разбор кода и задачи «подумать»; у неё же самый длинный контекст сети (390K). Рассуждения входят в лимит ответа — задавайте max_tokens с запасом и включайте stream.
• DeepSeek V4 Flash (deepseek-ai/DeepSeek-V4-Flash-0731) — один из самых длинных контекстов сети (380K), самый длинный вывод и сильный агентный кодинг: большие репозитории, длинные цепочки вызовов инструментов.
• MiniMax M2.7 (MiniMaxAI/MiniMax-M2.7) — модель шлюза по умолчанию: быстрые ровные ответы на повседневных задачах, длинные документы и потоковая обработка.

Переезд с Kimi K2.6 — это замена одной строки. Любой код, написанный для OpenAI, работает без изменений: достаточно заменить URL, API-ключ и имя модели.

curl https://gate.joingonka.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "MiniMaxAI/MiniMax-M2.7",
    "messages": [{"role": "user", "content": "Explain the difference between MoE and dense models"}]
  }'

В инструментах разработки правило то же: везде, где в настройках стоял moonshotai/Kimi-K2.6, подставьте идентификатор одной из действующих моделей. В Cursor это поле Custom Model, в Claude Code — переменная окружения ANTHROPIC_MODEL или флаг --model, в OpenClaw, Cline и Continue.dev — имя модели в конфиге провайдера, в LangChain и n8n — параметр model при инициализации клиента. Установщик npx @joingonka/setup пропишет шлюз и актуальную модель в конфиг инструмента одной командой. Список доступных моделей всегда актуален в endpoint GET /v1/models — оттуда удобно подтягивать его динамически в UI приложения, чтобы уход или появление модели в сети не ломали ваш продукт.

Попробовать без регистрации можно в бесплатном чате на странице /try — там доступны действующие модели сети. При регистрации в JoinGonka Gateway вы получаете бесплатные 3M токенов на тестирование любых моделей сети — хватит, чтобы прогнать свои задачи на каждой из трёх и выбрать замену осознанно.

Что показала история Kimi K2.6 для сети Gonka: механизм DevShards сработал в обе стороны. Он позволил добавлять модели без остановки сети — вслед за Kimi пришли MiniMax M2.7, DeepSeek V4 Flash и GLM-5.3 Flash, — и он же позволил безболезненно вывести модель, которую хосты перестали поддерживать. Сеть, привязанная к одной модели, фундаментально хрупка; сеть, способная менять состав голосованием, эволюционирует мягко и непрерывно. Для разработчика из этого следует простое правило: не «выбирать модель навсегда», а держать имя модели в конфигурации и проверять живой список.