CrazyrouterKimi K3 と GPT-5.6-SOL を比較：数学、物理、プログラミングの高難度実測
同一の OpenAI-compatible API と同一のプロンプト条件で、Kimi K3 と GPT-5.6-SOL を比較。モード停止時間、滑車の回転慣性を含む物理問題、依存クロージャを使う Python のプログラミング課題をテストし、正答性、途中切れ、遅延、ローカルでのコード検証を記録した。
Kimi K3 と GPT-5.6-SOL の比較：数学・物理・プログラミングの高難度実測#
今回は簡単なQ&Aではなく、連続推論が必要な3問に固定しました。具体的には、パターン重なりと二次モーメントを含む確率問題、滑車の回転慣性と糸のたるみへの切り替えが入る物理問題、そして closure、多日容量、3段階の tie-break に依存する Python 問題です。両モデルには同じインターフェース、同じプロンプト、近い出力上限を使い、ツールもネット接続も有効化していません。
先に結論だけまとめます。
gpt-5.6-solは3問すべてで完全な可視回答を返し、数学と物理の参照結果も正しかったです。kimi-k3は初回の6500token 上限では、数学と物理のどちらも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-k3 | gpt-5.6-sol | 判定 |
|---|---|---|---|
| 数学：HHTH の期待値と分散 | length，186.98 s，6500 tokens；可視内容は空 | 順次リトライ stop，236.07 s，6872 tokens | GPT は完全回答；Kimi は初回で答案形成に至らず |
| 物理：滑車、着地、ばね | length，202.05 s，6500 tokens；可視内容は空 | 順次リトライ stop，156.29 s，4501 tokens | GPT は完全で数値も正確 |
| プログラミング：依存閉包バックパック | 245.54 s 後に TimeoutError | stop，87.96 s，4514 tokens | GPT のコードは実行可能；Kimi は完全なコードを返さず |
| Kimi 数学再測定 | length，286.99 s，10000 tokens | — | 予算を増やしても終了せず |
Kimi の数学と物理のリクエストでは、インターフェース上の reasoning token がそれぞれ 6497 前後でした。数学再測定では reasoning token が 9997 前後でした。これは Kimi に推論力がないという意味ではなく、この問題設定と現在のルーティングでは推論予算を使い切りやすく、呼び出し側が最終答案を受け取れないことを示しています。
数学問題：パターン重なりは期待値だけでなく分散にも効く#
問題は、正面確率 p=3/5、裏面確率 q=2/5 のコインを投げ続け、HHTH が初めて現れるまでの回数を T としたときの E[T] と Var(T) を求めるものです。パターン重なりは許されます。
正しい前方オートマトンの状態は S0=空前缀、S1=H、S2=HH、S3=HHT、S4=HHTH（吸収状態） です。重要なのは 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 です。2物体と滑車の回転方程式を連立すると、次のようになります。
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) を実装し、日別容量、未設定日の容量は 0、直接・間接依存の閉包、無効な依存と循環検出、さらに value → risk → ソート済み id 列表 の3段階 tie-break を扱う必要があります。items <= 18 なので、bitmask 総当たりは妥当なベースラインです。
GPT-5.6-SOL は依存閉包キャッシュと 2^n の部分集合列挙を使っていました。コードを抽出し、Python 3.11 で独立検査を行ったところ、依存閉包、多日容量サンプル、value/risk/id の3段階 tie-break、未設定日の容量、依存なしケース、循環依存の6組すべてが通過しました。
ただし、モデルがコード末尾に付けた最初の assert は失敗しました。そこでは A -> B -> C を前提にしつつ、価値 11 の X も入れていました。与えられた容量では、B + C + X の総価値は 13 で、A + B + C の 12 より大きいので、関数が ['B', 'C', 'X'] を返すのが正解です。['A', 'B', 'C'] と書かれた assert はテストフィクスチャの誤りです。
この点はかなり示唆的です。コード問題は関数本体だけ見ればよいわけでもなく、逆に「8個のassertが付いているからテストも正しい」とは限りません。モデル生成のテストデータも、人手または参照実装で検証する必要があります。Kimi K3 のプログラミングリクエストは約 245 秒後に read timeout となり、完全なコードは取得できませんでした。
総合評価#
| 観点 | kimi-k3 | gpt-5.6-sol |
|---|---|---|
| 数学の完全性 | 6500/10000 token ともに途中終了、検収不可 | 期待値、二次モーメント、分散、sanity check が揃っている |
| 物理モデリング | 初回で途中終了 | 滑車慣性、糸のたるみ、ばね段階を正しく処理 |
| プログラミング納品 | 今回は timeout | コード本体は独立検査を通過したが、付属の assert に誤りあり |
| 出力安定性 | reasoning 消費が大きく、可視回答を得にくい | 3問すべて順次リトライで stop |
| 応答速度 | 約 187–246 s で、しかも途中終了/timeout あり | 成功したリクエストは約 88–236 s；並列初回は 408 あり |
より正確に言うと、結論は「どちらか一方が絶対的に賢い」という話ではありません。
- 今回のルーティングと予算では、GPT-5.6-SOL のほうが複雑な推論を最終答案までまとめやすく、すぐ読める導出やコードが必要なワークフローに向いています。
- Kimi K3 の主な課題は、推論予算を可視出力へ変換する効率です。数学問題で
10000token に増やしても、なお完了しませんでした。 - GPT-5.6-SOL のコードも盲信は禁物です。関数ロジックは独立検査を通っても、付属テストフィクスチャに価値計算ミスがありました。
- 本番導入の選定では、
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
再測定時は、モデル ID、プロンプト、temperature、max_tokens、並列度を固定し、毎回の出力を別ファイルとして保存するのがおすすめです。上流の負荷、キャッシュヒット、レート制限の状態は遅延に影響します。本記事では HTTP 408、length、read timeout をいずれもテスト結果の一部として記録し、意図的に隠していません。
