Kimi K3, Claude Fable 5 или GPT-5.6 Sol: какую модель тестировать первой?

Если главным ограничением остаётся бюджет на большое число попыток, первой проверяйте Kimi K3. Если нужен нейтральный производственный ориентир с развитой инструментальной средой, начинайте с GPT-5.6 Sol. Claude Fable 5 имеет смысл держать как дорогой уровень эскалации для задач, где ошибка в архитектуре или длинной цепочке действий обходится дороже дополнительных токенов.

На 17 июля 2026 года API Kimi K3 уже доступен, но полные веса, по заявлению Kimi, должны появиться 27 июля. Поэтому сегодня K3 нельзя считать готовым вариантом для самостоятельного размещения. В API OpenAI имя gpt-5.6 сейчас является псевдонимом gpt-5.6-sol.

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

Сначала сравните действующие условия API

У трёх моделей похожий язык маркетинга — большой контекст, программирование и агентные сценарии, — но разные производственные договорённости. Идентификатор модели, потолок вывода, скачок цены на длинном контексте, fallback, отказ и хранение данных способны изменить решение даже при одинаковом результате теста.

Источниками этих меняющихся фактов служат страница запуска K3, документация OpenAI по Sol и документация Anthropic по Fable. Это прямые API-тарифы, а не лимиты потребительской подписки и не цены стороннего роутера.

K3 даёт самый большой ценовой запас. Попытка со 100 тысячами некешированных входных и 20 тысячами выходных токенов стоит по текущему прайсу $0,60. У Sol это $1,10, у Fable — $2,00, прежде чем учтены инструменты, повторные запуски и ревью. Это хороший повод начать тест с K3, но не доказательство самой дешёвой завершённой работы.

У Sol средняя цена, зато есть резкая граница длинного контекста. Запросы на 270K и 275K почти одинаковы по размеру, но попадают в разные тарифные режимы. Агент, который каждый ход возвращает в контекст весь репозиторий и журнал инструментов, способен превратить редкое исключение в обычный счёт. Поэтому измеряйте p50, p95 и максимум входных токенов.

Fable дороже и имеет особые эксплуатационные условия. Anthropic предупреждает, что отказ может прийти с HTTP 200 и stop_reason: refusal, а конфигурация fallback способна заменить фактическую модель-исполнителя. Для чувствительных данных 30-дневное хранение и отсутствие zero data retention могут стать стоп-фактором независимо от качества ответа.

Выберите первую проверку по типу работы

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

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

Sol удобен как исходная производственная база. У него длинный контекст, высокий лимит вывода и актуальная поверхность инструментов. Для команд, уже использующих Codex, важно помнить: итог принадлежит не только модели, но и агенту, который выбирает файлы, вызывает команды, управляет контекстом и проверяет изменения.

Sol не получает статус «лучшей цены» автоматически. Рассуждение и циклы инструментов увеличивают вывод, а длинные запросы меняют тариф всего вызова. Он остаётся базовым маршрутом, только если измеренный процент приёмки, время ревью и эксплуатационная предсказуемость оправдывают разницу с K3.

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

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

Почему лидер меняется вместе с условиями теста

Результат программного теста лучше представлять формулой:

наблюдаемый результат = модель + агентский каркас + бюджет рассуждения + инструменты + fallback + условия теста

В таблице запуска K3 эти различия видны в сносках. K3 на части заданий работает через KimiCode, Fable — через Claude Code или Terminus, иногда с fallback, а Sol — через Codex. Поэтому выбранные строки называют разных лидеров.

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

Независимый составной снимок даёт вторую точку зрения, но тоже требует полного названия конфигурации. 17 июля Artificial Analysis показывал K3 с индексом 57, Sol Max — 59, а Fable — 60 в конфигурации «Adaptive Reasoning, Max Effort, Opus 4.8 Fallback».

Разрыв в один пункт менее важен, чем разница в конфигурации, количестве токенов и цене проверки. Fable получил показанный результат с fallback, Sol связан с Codex, а K3 израсходовал больше выходных токенов в этом наборе. Ни одно наблюдение не предсказывает ваш репозиторий без локального эксперимента.

Считайте стоимость принятой задачи, а не токена

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

полная стоимость = (API + инструменты + инфраструктура на попытку) / доля приёмки + время ревью + ожидаемое восстановление после ошибки

Доля приёмки должна считаться на одном наборе задач. Нельзя сравнивать простые задания K3 со сложными заданиями Fable или кешированный прогон Sol с некешированными конкурентами. Даже бесплатный неуспешный запрос расходует очередь, инструменты и внимание инженера.

Возьмём условную задачу со 100K входных и 20K выходных токенов. Цена попытки равна $0,60, $1,10 и $2,00. Теперь предположим — это не измеренные качества моделей, — что доля приёмки составляет 80%, 90% и 94%, а ревью занимает восемь, шесть и пять минут при внутренней ставке $60 в час.

Этот пример показывает механику, а не объявляет фактическую эффективность. Низкая цена токена может проиграть после повторов и ревью; дорогая модель тоже проиграет, если её реальный прирост меньше предположенного. Подставляйте собственные значения. Для планирования тарифов разных провайдеров используйте сравнение цен LLM API, а выбор K3–Sol–Fable оставляйте отдельным тестом нагрузки.

Проведите воспроизводимый тест в одном репозитории

До миграции заморозьте рабочий набор, чтобы модель оставалась главной переменной.

1. Выберите 30–50 задач из одного commit: обычные правки, изменения в нескольких файлах, диагностику, сбои инструментов, длинный контекст и несколько заданий, требующих старшего ревью.
2. Зафиксируйте системные инструкции, разрешения инструментов, сеть, sandbox, таймауты и состояние репозитория. Запишите агентский каркас и его версию.
3. Назначьте каждому маршруту документированный бюджет рассуждения или токенов. Adaptive thinking, max effort и fallback должны оставаться видимыми в результате.
4. До запуска определите приёмку: сборка, тесты, lint, типы, безопасность, проверки конкретной задачи, допустимые файлы и рубрика ревьюера.
5. По возможности ослепите человеческое ревью. Записывайте результат, повторы, токены, длительность, ошибки инструментов, минуты проверки и регрессии, требующие отката.
6. Повторите устойчивую часть набора в другой день: стартовая нагрузка и маршрутизация провайдера могут искажать короткий снимок.

Не подстраивайте каждому участнику отдельный тест до победы. Модельные настройки допустимы для производственной честности, но каждое исключение — дополнительный prompt, обрезка контекста, усилие, fallback и повтор — должно быть записано.

Эксперимент должен отдельно ответить: кто дешевле проходит обычные задачи; кто спасает сложные отказы; какие проблемы вызваны моделью, а какие агентом; и какие эксплуатационные границы меняют развёртывание. Если вы переносите старую интеграцию Kimi, идентификаторы и маршрут K2 разобраны в руководстве по API Kimi K2. Не смешивайте эту миграцию с выбором K3 против двух флагманов.

Установите правила повышения, эскалации и отката

Переводите обычный поток на K3, если нет критических регрессий, доля приёмки остаётся в согласованном диапазоне от Sol, а экономия сохраняется после повторов и ревью. Для задач выше порога сложности оставьте Sol или Fable.

Оставляйте Sol базовым, если он заметно улучшает приёмку или время проверки по сравнению с K3, инструменты работают предсказуемо, а выигрыш не исчезает после тарифа длинного контекста. Не нужно оплачивать Fable для всего потока, если эскалация отдельных задач дешевле.

Эскалируйте на Fable, когда он спасает определённый тип отказа или сокращает достаточно дорогого ревью. Записывайте использование fallback. Для чувствительных данных политика хранения способна запретить маршрут независимо от результата.

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

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

После 27 июля K3 нужен отдельный контрольный пункт: проверить публикацию весов, лицензию, память и требования serving, затем прогнать тот же набор на целевой инфраструктуре. Наличие файлов только начинает такую оценку; оно не обещает цену и скорость размещённого API.

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

Kimi K3 лучше Fable 5 и GPT-5.6 Sol в целом?

Нет. K3 дешевле по текущему прямому тарифу и лидирует в нескольких строках Kimi, но другие строки принадлежат Sol или Fable. Результат меняют каркас, усилие, fallback, токены и вид работы. K3 — экономная первая проверка, а не автоматический чемпион.

Можно ли уже самостоятельно разместить Kimi K3?

На 17 июля — нет. Kimi планирует опубликовать полные веса 27 июля. После публикации всё равно надо проверить лицензию, память, стек инференса и поведение на собственных задачах.

Когда Claude Fable 5 оправдывает цену?

Когда измеренный выигрыш на сложных длинных задачах сокращает ошибки, повторы или старшее ревью настолько, что перекрывает тариф $10/$50, и при этом fallback, отказы, 30-дневное хранение и отсутствие ZDR допустимы.

Является ли GPT-5.6 Sol лучшим соотношением цены и качества?

Это сильная сбалансированная база, особенно если в тест уже входит Codex. Но лучший результат определяется полной стоимостью: запросы выше 272K меняют тариф всего вызова, а прошедший приёмку K3 может оказаться дешевле.

С какой модели начать для программирования?

Без внутренних данных начните с Sol как базы, проверьте K3 на обычном потоке и оставьте Fable для самых трудных отказов. Если бюджет — жёсткое ограничение, сначала запускайте K3 и переходите на Sol только там, где одинаковая проверка показывает нехватку качества.

Надёжный выбор — это не имя модели, а измеряемое правило маршрутизации: сначала самый дешёвый правдоподобный вариант, затем приёмка на одинаковой нагрузке, эскалация для известных сложных случаев и сохранённый откат.