Kimi K3 против Claude Opus 4.8: практические тесты по математике, физике и программированию уровня магистратуры

Сравнение Kimi K3 и Claude Opus 4.8: практический тест на уровне магистратуры по математике, физике и программированию#

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

На этот раз я поднял сложность до уровня выпускного проекта бакалавриата или курсовой магистратуры и на одной и той же группе промптов проверил kimi-k3 и claude-opus-4-8:

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

Сначала — вывод:

• claude-opus-4-8 по всем трём задачам вернул полный ответ в рамках бюджета, у всех трёх задач finish_reason был stop;
• kimi-k3 пришлось запускать с temperature=1, и при верхнем лимите 6000 completion token все три задачи завершились с finish_reason=length, при этом три наблюдаемых значения content были равны 0 по длине;
• математический и физический ответы Opus 4.8 прошли независимую численную проверку;
• код планировщика от Opus 4.8 прошёл все 13 своих assert'ов, но независимый дополнительный зонд на проверку “предшествующая задача должна завершиться раньше последующей” показал, что модель лишь гарантирует совместный выбор зависимых задач, но не гарантирует, что предшествующая задача стоит по времени раньше последующей;
• средняя задержка успешного запроса в этом раунде: Opus 4.8 — около 70.59 秒, Kimi K3 — около 225.47 秒. Эта разница отражает только условия маршрутизации и промпта в данном прогоне и не может напрямую считаться долгосрочным SLA.

Тестовая среда и ограничения параметров#

Тест проводился по пекинскому времени с 18 по 19 июля 2026 года. Сначала через /v1/models было подтверждено, что оба model ID доступны:

kimi-k3
claude-opus-4-8

Запросы целиком шли через OpenAI-compatible API Crazyrouter:

POST https://cn.crazyrouter.com/v1/chat/completions

Общие условия:

Один и тот же system prompt
Одинаковая пользовательская задача
Без инструментов и без сети

Параметры моделей не могли быть полностью одинаковыми, потому что на стороне upstream для Kimi K3 есть жёсткое ограничение:

При первой ошибочной попытке вызвать Kimi K3 с temperature=0.1 интерфейс явно вернул:

Parameter temperature must be 1 for this model.

Поэтому в статье это ограничение фиксируется как факт теста, а не прячется под формулировкой “модель недоступна”. При использовании этих результатов для выбора в проде такое ограничение параметров модели тоже нужно закладывать в конфигурационный слой, а не предполагать, что все модели принимают один и тот же набор sampling-параметров.

Сводная таблица результатов#

У трёх ответов Kimi очень одинаковая картина: интерфейс возвращал model и usage, но в message.content не было никакого финального ответа, пригодного для передачи пользователю или компилятору. Для приложений, где результат нужно сразу показывать пользователю или отдавать в компилятор, это следует считать “задача не завершена”, а не “модель ответила правильно, просто лог не сохранился”.

Математика: время первого достижения и дисперсия для конечной цепи Маркова#

В задаче использовалась матрица переходов:

Целевое состояние — 3, а величина определяется как:

$\tau=\min\{n\ge 0:X_n=3\}。$

Это не та задача, которую можно решить простым подстановочным расчётом; здесь нужно как минимум обработать стационарное распределение, подматрицу транзиентных состояний, первый и второй моменты времени первого достижения и явно задать граничные условия для целевого состояния t_3=s_3=0.

Результат Opus 4.8#

Модель дала стационарное распределение:

и поэлементно проверила πP=π.

Если взять состояния {1,2} как транзиентные, получится:

Уравнение для первого момента:

откуда:

Для второго момента используется:

и получается:

Я независимо решил систему через Fraction, и результат полностью совпал с Opus; подстановка t и s обратно в оба уравнения первого шага тоже проходит. Для математической части вердикт — “полностью верно”.

Результат Kimi K3#

Kimi K3 при temperature=1 и max_tokens=6000 отработал около 235 секунд, usage показал completion_tokens=6000, reasoning_tokens=5997, finish_reason=length, а видимый content был пустым.

Это значит, что по данному прогону нельзя понять, умеет ли Kimi решать эту задачу о цепи Маркова. Можно утверждать только одно: при текущем интерфейсе, промпте и бюджете модель не свела рассуждение к финальному видимому ответу.

Физика: матричная модель и частотная характеристика демпфированного связанного осциллятора#

Во второй задаче рассматривается двухстепенная система с двумя массами:

m1=1.5 kg，m2=1.0 kg
k1=120 N/m，k2=80 N/m，k3=150 N/m
c1=1.2 N·s/m，c2=0.8 N·s/m，c3=1.5 N·s/m
F(t)=10 cos(8t) N

k2 и c2 — это связующие элементы между двумя массами, а c1 и c3 — это собственные демпферы, соединённые с землёй. В условии сначала требуется найти собственные моды без затухания, а затем комплексную амплитуду при ω=8 rad/s, поэтому нельзя просто свести всё демпфирование к диагональной матрице.

Корректные матрицы#

Opus 4.8 записал:

Из уравнения на собственные значения без затухания получаются собственные круговые частоты:

Соответствующие модальные отношения X2/X1 равны 0.6173 и -2.4298, что соответствует модам в фазе и в противофазе.

Комплексная частотная характеристика при ω=8#

Комплексная динамическая жёсткость:

Независимый расчёт комплексных величин дал:

Проверка по энергии у Opus тоже прошла: средняя мощность рассеяния составила около 1.2574 W, что совпадает с входной мощностью силы в пределах округления. Модель также корректно объяснила, что если ошибочно принять c2 за заземлённый демпфер, то внедиагональные элементы демпфирования C12=C21=-0.8 будут по ошибке обнулены, а передача энергии и фазовые результаты изменятся.

Результат Kimi K3#

Kimi K3 примерно через 204.6 секунды исчерпал 6000 token, и снова это был finish_reason=length при пустом content. Поскольку итоговых формул и чисел нет, оценить корректность его физической модели невозможно; этот прогон можно только зафиксировать как “в бюджет не уложился и ответ не отдал”.

Программирование: замыкание зависимостей, временные окна и точное планирование#

В задаче требовалось реализовать:

schedule_jobs(jobs, dependencies, capacity_by_day)

У каждой задачи есть duration, release_day, deadline_day и value; задача должна целиком размещаться в пределах одного дня, у каждого дня есть ограничение по ёмкости, а зависимость означает, что предшествующая задача должна завершиться до начала последующей. Целевая функция сравнивается в таком порядке:

1. максимальная суммарная ценность;
2. меньшая суммарная длительность;
3. лексикографически меньший отсортированный список ID задач.

Эта задача сложнее обычного “рюкзака + сортировки”, потому что нужно одновременно учитывать:

• прямое и транзитивное замыкание зависимостей;
• неизвестные зависимости и обнаружение циклов;
• дневную ёмкость и временные окна задач;
• точное упаковочное размещение допустимого подмножества;
• многоуровневый tie-break.

Поведение реализации Opus 4.8#

Opus дал полноценную реализацию на bitmask + memoized DFS и приложил 13 assert'ов. Мы извлекли оба блока Python-кода и выполнили их в Python 3.11 — все встроенные проверки модели прошли:

all assertions passed

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

Но встроенные проверки не проверяли, что “предшествующая задача должна завершиться раньше последующей”. Я добавил независимый зонд:

jobs = [
    {"id": "A", "duration": 4, "release_day": 1,
     "deadline_day": 1, "value": 1},
    {"id": "B", "duration": 4, "release_day": 0,
     "deadline_day": 0, "value": 10},
]
result = schedule_jobs(jobs, [("A", "B")], {0: 4, 1: 4})

По правильной семантике A является предшествующей задачей для B, но A можно поставить только на день 1, а B — только на день 0, поэтому одновременно они не должны выбираться. Однако код модели вернул:

selected_ids: ['A', 'B']
assignment: {'A': 1, 'B': 0}

Это означает, что реализация проверяет только “при выборе B нужно вместе выбрать A”, но не проверяет:

assignment[A] < assignment[B]

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

Результат Kimi K3#

Kimi K3 примерно через 236.4 секунды завершился с length, полностью израсходовав 6000 token на reasoning; content остался пустым, исполнимый код не был выдан.

Задержка, бюджет вывода и видимый ответ#

Средняя задержка по трём задачам:

Kimi K3:       (235.420 + 204.568 + 236.434) / 3 = 225.474 秒
Claude Opus:   (57.870 + 64.966 + 88.934) / 3 = 70.590 秒

Три ответа Kimi по usage были очень похожи:

completion_tokens = 6000
reasoning_tokens  = 5997
content.length    = 0
finish_reason     = length

Эти данные показывают, что вызывающей стороне нельзя смотреть только на HTTP status code и поле model. Как минимум нужно одновременно логировать:

choice.finish_reason
response.usage
response.choices[0].message.content

Если finish_reason равен length, то даже при HTTP 200 такой ответ следует отправлять в повторную попытку, на деградационный путь или на ручную проверку.

Как воспроизвести эксперимент#

Ниже приведён минимальный пример вызова через OpenAI Python SDK. В реальном тесте нужно использовать полный текст задач из статьи и параметры, соответствующие модели:

from openai import OpenAI

client = OpenAI(
    api_key="YOUR_CRAZYROUTER_API_KEY",
    base_url="https://cn.crazyrouter.com/v1",
)

response = client.chat.completions.create(
    model="claude-opus-4-8",
    temperature=0.1,
    max_tokens=9000,
    messages=[
        {"role": "system", "content": "Строгий бенчмарк, только проверяемые выводы."},
        {"role": "user", "content": "Замените на полный тестовый вопрос уровня магистратуры"},
    ],
)

print(response.model)
print(response.choices[0].finish_reason)
print(response.usage)
print(response.choices[0].message.content)

При вызове Kimi K3 нужно поменять temperature на 1 и заложить достаточно времени на более длинный reasoning; в этом прогоне даже при 6000 token видимый ответ получить не удалось.

Рекомендации по выбору в production#

Когда стоит в первую очередь тестировать Claude Opus 4.8#

• нужен полный вывод или полный код за один запрос;
• задача включает матрицы, граничные условия и численную проверку;
• бизнесу важнее низкая задержка первого экрана и предсказуемая отдача;
• для сгенерированного кода можно добавить независимые тесты и семантическую проверку.

Когда имеет смысл продолжать оценивать Kimi K3#

• допустима задержка в несколько минут;
• слой вызова умеет работать с модель-специфичными параметрами sampling;
• можно дробить задачу, увеличивать бюджет или использовать асинхронный workflow;
• важен сам процесс reasoning, а не немедленная выдача финального текста в одном запросе.

Но по данным этого прогона Kimi K3 нельзя описывать как “модель решила все три задачи, но вывод был скрыт логами”. Фактическое наблюдение другое: все три раза видимого финального ответа не было.

FAQ#

1. Почему эти задачи считаются уровнем выпускного проекта бакалавриата или магистратуры?#

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

2. Значит ли это, что Kimi K3 не поддерживает temperature=0.1?#

В данном интерфейсе Kimi K3 явно требует, чтобы temperature был равен 1. Это относится к текущему ограничению маршрутизации по параметрам модели, и вызывающая сторона должна читать сообщение об ошибке и повторять запрос с конфигурацией, подходящей для модели.

3. Можно ли по length у Kimi K3 сделать вывод, что он вообще не умеет решать такие задачи?#

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

4. Можно ли использовать ответ Opus 4.8 по программированию в production без изменений?#

Нет. Его встроенные assert'ы все прошли, но независимый зонд обнаружил пропуск временного порядка зависимостей. Сгенерированный код нужно проверять бизнес-семантическими тестами, а не только запускать тесты, приложенные самой моделью.

5. Зачем в физической задаче проверять рассеяние энергии у Opus 4.8?#

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

6. Можно ли считать задержку этого раунда обещанием производительности?#

Нет. Канал upstream, кеширование, параллелизм и повторные попытки меняют задержку. В production как минимум нужно делать повторную выборку и считать P50, P95, P99, долю усечённых ответов и стоимость каждого успешного выполнения.

Итоговый вывод#

На этот раз сравнение показало не абстрактный “рейтинг интеллекта” вне условий вызова, а два совершенно разных поведения при доставке результата:

1. Claude Opus 4.8 в этом раунде по всем трём задачам уровня магистратуры дал видимый ответ, а математический и физический выводы прошли независимую проверку;
2. кодовый каркас у Opus сильный, но он всё же упустил ключевое бизнес-ограничение: зависимая задача должна завершаться раньше последующей по времени;
3. при принудительном temperature=1 Kimi K3 по всем трём задачам израсходовал 6000 token, получил finish_reason=length и не выдал видимого ответа;
4. если бизнес-цель — одним запросом получить полный математический вывод, физический расчёт или исполнимый код, то в текущем окне тестирования у Opus 4.8 заметно лучше delivery;
5. независимо от выбранной модели, в приёмку обязательно нужно включать finish_reason, usage, независимую численную проверку и семантические тесты кода.

Файлы для воспроизведения эксперимента:

• Тестовый скрипт: kimi_k3_vs_opus48_graduate_test.py
• Результаты Kimi: kimi-k3-graduate-results.json
• Сравнительные результаты: kimi-k3-vs-opus48-graduate-results.json

Рекомендуемое чтение:

• Kimi K3 vs GPT-5.6-SOL: жёсткий тест на математике, физике и программировании
• Kimi K3 vs Claude Fable 5: тест сложного reasoning
• Регистрация в Crazyrouter