"Kimi K3 против GPT-5.6-SOL: жёсткое тестирование по математике, физике и программированию"

Kimi K3 против GPT-5.6-SOL: жёсткое сравнение на математике, физике и программировании#

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

Сначала короткий итог:

• gpt-5.6-sol по всем трём задачам дал полный видимый ответ, а эталонные результаты для математики и физики совпали.
• kimi-k3 при первом лимите 6500 tokens на математике и физике завершался с finish_reason=length, при этом видимый ответ был пустым; на математике после повышения лимита до 10000 тоже произошёл обрыв. Программная задача спустя примерно 245 секунд ушла в read timeout.
• Реализация GPT-5.6-SOL по программированию прошла независимую проверку на замыкание зависимостей, ёмкости, tie-break, невалидные зависимости и циклы, но в собственной первой строке assert у модели был неверный ожидаемый результат. Это показывает, что «ядро кода верное» и «все примерные тесты корректны» — это разные вещи, которые надо проверять отдельно.

Задержка, указанная в статье, — это наблюдение именно для данного запроса; это не SLA. В первой параллельной серии запросов математический и физический запросы к GPT возвращали HTTP 408, после чего мы перешли к последовательным повторным попыткам. Поэтому скорость здесь используется только как характеристика опыта вызова, а не как абсолютный рейтинг.

Настройки теста#

Тестирование проводилось по пекинскому времени с 2026-07-17 по 2026-07-18, интерфейс:

POST https://cn.crazyrouter.com/v1/chat/completions
model: kimi-k3 / gpt-5.6-sol
temperature: 0.2

В первой серии везде использовались одинаковые лимиты: для математики и физики max_tokens=6500, для программирования max_tokens=7500. В каждой задаче модель должна была дать проверяемый вывод или исполняемый код; дополнительно фиксировались finish_reason, completion/reasoning token, задержка запроса, численная корректность и способность кода запускаться отдельно в Python 3.11.

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

В запросах Kimi по математике и физике интерфейс сообщал reasoning token, близкие к 6497; на повторе по математике — около 9997. Это не означает, что у Kimi нет способности к рассуждению; это означает, что при данном промпте и текущей маршрутизации бюджет рассуждений очень легко выгорает, и вызывающая сторона не получает финальный ответ.

Математическая задача: перекрытие шаблона влияет не только на ожидание, но и на дисперсию#

Условие: вероятность орла p=3/5, решки q=2/5; бросаем монету до первого появления HHTH, с разрешённым перекрытием шаблона, найти E[T] и Var(T).

Корректный автомат по префиксам имеет состояния S0=пустой префикс, S1=H, S2=HH, S3=HHT, S4=HHTH（absorbing state）. Ключевой переход — S2 --H--> S2: после HH ещё один H сохраняет наибольший суффикс HH, а не откатывает нас ошибочно в пустое состояние.

У GPT-5.6-SOL уравнения для первого момента были записаны так:

M0 = 1 + p M1 + q M0
M1 = 1 + p M2 + q M0
M2 = 1 + p M2 + q M3
M3 = 1 + q M0

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

E[T]   = 715/54       ≈ 13.2407407407
E[T²]  = 195335/729   ≈ 267.9492455418
Var(T) = 270115/2916  ≈ 92.6320301783

Ожидание можно отдельно проверить по формуле границ. У HHTH единственная непустая собственная граница — однобуквенная H, поэтому E[T] = 1/p + 1/(p³q) = 715/54. В полном ответе GPT были и переходы состояний, и раскрытие второго момента, и sanity check. Kimi при лимитах 6500 и 10000 не выдал видимого вывода, так что в этом раунде его математическую корректность оценить не удалось — только зафиксировать, что в пределах бюджета задача не была завершена.

Физическая задача: после касания пола ограничение исчезает, и прежние уравнения энергии уже не годятся#

Условие: m_A=4.0 kg на шероховатой наклонной плоскости под углом 25°, μ_k=0.18; m_B=3.0 kg висит; шкив M_p=1.2 kg, R=0.10 m; B опускается на 1.50 m, касается пола, нить сразу провисает; A затем поднимается по плоскости ещё на 0.10 m и касается пружины k=250 N/m; g=9.8 m/s².

До касания пола нить натянута и проскальзывания нет, поэтому эквивалентная инерционная масса шкива равна I/R²=(1/2)M_p=0.60 kg. Совместное решение для двух тел и вращения шкива даёт:

a  ≈ 0.847 m/s²
v1 ≈ 1.59 m/s
v2 ≈ 1.18 m/s
x  ≈ 0.0835 m = 8.35 cm

После касания пола скорость B меняется ударом о землю, у A по-прежнему остаётся скорость вверх вдоль плоскости, а шкив может продолжать вращаться; но в условии прямо сказано, что нить немедленно провисает, значит использовать v_A=v_B=Rω дальше нельзя. Последующий этап нужно анализировать только для A:

v2² = v1² - 2g(sinθ + μ_k cosθ)d
1/2 m_A v2² = 1/2 kx² + m_A g(sinθ + μ_k cosθ)x

GPT-5.6-SOL также проверил размерности, расстояние до остановки без пружины и согласованность суммы энергии пружины с потерями на трение и гравитацию; численно всё сходится. У Kimi в первой попытке не появилось видимого ответа, поэтому сравнить качество промежуточного моделирования не удалось.

Программная задача: основной алгоритм прошёл независимую проверку, но в собственном примере модели есть баг#

Задача требовала реализовать optimize_release_plan(items, capacity_by_day, dependencies), учитывая ежедневные ёмкости, нулевую ёмкость для неуказанных дат, замыкание по прямым и косвенным зависимостям, валидацию невалидных зависимостей и циклов, а также тройной tie-break value → risk → отсортированный список id. Поскольку items <= 18, полный перебор по bitmask — вполне разумная базовая стратегия.

GPT-5.6-SOL использовал кеширование замыкания зависимостей и перебор всех подмножеств 2^n. Мы извлекли код и отдельно прогнали его в Python 3.11: проверки на замыкание зависимостей, пример с многодневной ёмкостью, тройной tie-break по value/risk/id, ёмкость для неуказанных дат, отсутствие зависимости и цикл — всего 6 наборов проверок — все прошли.

Но в конце кода у модели была собственная первая проверка, которая упала: она задавала цепочку A -> B -> C, одновременно добавляя объект X с ценностью 11. При данных ограничениях суммарная ценность B + C + X равна 13 и выше, чем A + B + C с 12, поэтому корректным ответом будет ['B', 'C', 'X'], а не ['A', 'B', 'C']. То есть ошибка была в тестовом каркасе, а не в логике функции.

Этот момент показателен: в кодовых задачах нельзя смотреть только на тело функции, и нельзя считать тесты корректными лишь потому, что «их там 8 штук». Сгенерированные моделью тестовые данные тоже нужно проверять вручную или через эталонную реализацию. Запрос на программирование у Kimi K3 спустя примерно 245 секунд завершился read timeout, полного кода получить не удалось.

Сводная оценка#

Более точный вывод — не «одна модель объективно умнее другой», а следующий:

1. При данной маршрутизации и бюджете GPT-5.6-SOL легче сводит сложные рассуждения к финальному ответу, поэтому он лучше подходит для рабочих сценариев, где нужен сразу читаемый вывод или код.
2. У Kimi K3 основная проблема — эффективность преобразования reasoning-бюджета в видимый результат; даже при увеличении лимита по математике до 10000 tokens ответ не был завершён.
3. Код GPT-5.6-SOL нельзя принимать на веру. Логика функции прошла независимую проверку, но приложенный тестовый каркас содержал ошибку в ожидаемом значении.
4. Для продакшн-выбора нужно фиксировать одновременно finish_reason, reasoning token, задержку и локальные тесты, а не только смотреть на финальную фразу «ответ верен».

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

Скрипт теста и результаты последовательных повторов сохранены здесь (сводка по первой параллельной серии тоже записана в вывод скрипта):

.tmp/kimi_k3_vs_gpt56sol_test.py
.tmp/kimi-k3-vs-gpt56sol-results.json
.tmp/retry-gpt56sol-math.json
.tmp/retry-gpt56sol-physics.json
.tmp/retry-gpt56sol-programming.json
.tmp/retry-kimi-k3-math.json

При повторе рекомендуется жёстко фиксировать model ID, промпт, temperature, max_tokens и уровень параллелизма, а каждый вывод сохранять в отдельный файл. Нагрузка на upstream, попадание в cache и состояние rate limit заметно влияют на задержку; в этой статье HTTP 408, length и read timeout сознательно зафиксированы как часть результата, а не скрыты.