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, — і він же дозволив безболісно вивести модель, яку хости перестали підтримувати. Мережа, прив'язана до однієї моделі, фундаментально крихка; мережа, здатна змінювати склад голосуванням, еволюціонує м'яко й безперервно. Для розробника з цього випливає просте правило: не «вибирати модель назавжди», а тримати ім'я моделі в конфігурації та перевіряти живий список.