CrazyrouterCrazyrouter
Login
Back to Blog
日本語Comparison

Kimi K3 と Claude Opus 4.8 の比較：研究生レベルの数学・物理・プログラミング実測

同一の Crazyrouter OpenAI-compatible API 上で、研究生レベルのマルコフ連鎖の初到達時間、減衰付き結合振動子の周波数応答、依存関係スケジューリングアルゴリズムを用いて kimi-k3 と claude-opus-4-8 を比較し、出力の完全性、正確性、レイテンシー、独立検証結果を記録する。

C
Crazyrouter Team
July 19, 2026 / 6 views
Share:
Kimi K3 と Claude Opus 4.8 の比較：研究生レベルの数学・物理・プログラミング実測
Crazyrouter
Open API PlaygroundOpen image toolRead the docsCheck live pricing

Kimi K3 と Claude Opus 4.8 の比較：大学院レベルの数学・物理・プログラミング実測#

ja benchmark cover

Kimi K3 と Claude Opus 4.8 の大学院レベル課題比較

大規模モデルは簡単な計算問題ならどれもきれいな答えを返せますが、本当に差が出るのは、導出を出力予算内で最後まで書き切れるか、行列や境界条件を正しく置けるか、生成したプログラムが本当に問題文の意味を満たしているか、です。

今回は課題全体を学部卒業研究や大学院講義レベルまで引き上げ、同じプロンプトで kimi-k3 と claude-opus-4-8 をテストしました。

ja comparison chart

  • 数学：3状態有限マルコフ連鎖の定常分布、初達時間、1次モーメントと2次モーメント
  • 物理：接地減衰と結合減衰を持つ2自由度振動系で、無減衰モードと複素周波数応答を求める
  • プログラミング：依存閉包、時間窓、日次容量、3段階の目的関数を持つ厳密スケジューリングアルゴリズム

先に結論です。

  • claude-opus-4-8 は3問すべてで今回の予算内に完全な応答を返し、3問とも finish_reason は stop
  • kimi-k3 は temperature を 1 に設定する必要があり、6000 の completion token 上限では3問とも finish_reason=length で終了し、3回とも可視 content の長さは 0
  • Opus 4.8 の数学と物理の回答は、独立した数値検証を通過
  • Opus 4.8 のスケジューリングコードは、付属の 13 個のアサーションは通ったが、独立に「前提タスクは必ず先に完了していること」を確認するプローブを追加したところ、依存タスクを同時に選ぶことは保証しても、前提タスクが後続タスクより前に配置されることまでは保証していないことが分かった
  • 今回の成功リクエストの平均遅延は、Opus 4.8 が約 70.59 秒、Kimi K3 が約 225.47 秒。この差はあくまで今回のルーティングとプロンプト条件を表すもので、長期的な SLA としてそのまま扱うことはできません

テスト環境とパラメータ制約#

テスト時刻は北京時間 2026 年 7 月 18 日から 19 日で、まず /v1/models を通して両モデル ID が見えることを確認しました。

text
kimi-k3
claude-opus-4-8

ja production verification

リクエストはすべて Crazyrouter の OpenAI-compatible API を経由しています。

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

共通条件は次のとおりです。

text
同一の system prompt
同一のユーザー課題
ツールとネット接続は無効

モデルパラメータは完全には揃えられません。上流で Kimi K3 にハード制約があるためです。

モデルtemperaturemax_tokens結果
kimi-k31（そうでないと HTTP 400）60003問とも length
claude-opus-4-80.190003問とも stop

最初に temperature=0.1 で Kimi K3 を呼び出したとき、インターフェースは明確に次を返しました。

text
Parameter temperature must be 1 for this model.

そのため本文では、このパラメータ制約をテスト事実として記録し、「モデルが使えない」として失敗を隠したりはしません。結果を本番選定に使う場合も、モデル固有のパラメータ要件を設定層に書き込み、すべてのモデルが同じサンプリングパラメータを受け入れると仮定しないことが重要です。

結果一覧#

タスクKimi K3Claude Opus 4.8独立判定
マルコフ連鎖の初達時間235.420 s, 6000 completion, 5997 reasoning, length, content なし57.870 s, 4764 completion, stopOpus は完全かつ正確、Kimi は可視回答を返さず
2自由度結合振動子204.568 s, 6000 completion, 5997 reasoning, length, content なし64.966 s, 5284 completion, stopOpus は完全で数値検証も通過
依存スケジューリングアルゴリズム236.434 s, 6000 completion, 5997 reasoning, length, content なし88.934 s, 6857 completion, stopOpus の主体は実行可能だが、依存の先後制約が抜けている

Kimi の3回は、形が非常に一貫していました。インターフェースはモデル名と usage を返しますが、message.content には配布可能な最終答案がありません。結果をそのままユーザーに見せる用途やコンパイラに渡す用途では、これは「モデルがすでに正解したがログに出なかった」のではなく、「タスク未完了」と判定すべきです。

数学問題：有限状態マルコフ連鎖の初達時間と分散#

問題では遷移行列として次を使います。

P=(1/21/31/61/41/21/41/61/31/2),X0=1,P=\begin{pmatrix} 1/2 & 1/3 & 1/6\\ 1/4 & 1/2 & 1/4\\ 1/6 & 1/3 & 1/2 \end{pmatrix},\qquad X_0=1,

目標状態は 3 で、次のように定義します。

τ=min⁡{n≥0:Xn=3}。\tau=\min\{n\ge 0:X_n=3\}。

これは単に確率を代入して終わる問題ではありません。少なくとも、定常分布、過渡部分行列、初達時間の1次モーメントと2次モーメントを扱い、目標状態の境界条件 t_3=s_3=0 を明示する必要があります。

Opus 4.8 の結果#

Opus が与えた定常分布は次のとおりです。

π=(310,410,310)，\pi=\left(\frac{3}{10},\frac{4}{10},\frac{3}{10}\right)，

また、成分ごとに πP=π を確認していました。

{1,2} を過渡状態として用いると、

Q=(1/21/31/41/2),N=(I−Q)−1=(323/23)。Q=\begin{pmatrix}1/2&1/3\\1/4&1/2\end{pmatrix}, \quad N=(I-Q)^{-1}=\begin{pmatrix}3&2\\3/2&3\end{pmatrix}。

1次モーメントの方程式は

(I−Q)t=1，(I-Q)t=\mathbf 1，

なので、

E1[τ]=5，E2[τ]=92。E_1[\tau]=5，\qquad E_2[\tau]=\frac92。

2次モーメントは

(I−Q)s=2t−1，(I-Q)s=2t-\mathbf 1，

より求まり、

E1[τ2]=43，Var⁡1(τ)=43−52=18。E_1[\tau^2]=43，\qquad \operatorname{Var}_1(\tau)=43-5^2=18。

こちらで Fraction を使って独立に方程式を解いたところ、結果は Opus と完全一致しました。t と s を2本の初回ステップ方程式へ代入しても成立します。数学問題の判定は「完全合格」です。

Kimi K3 の結果#

Kimi K3 は temperature=1、max_tokens=6000 の条件で約 235 秒動作し、usage は completion_tokens=6000、reasoning_tokens=5997、finish_reason=length、可視 content は空でした。

つまり今回の出力からは、Kimi がこのマルコフ連鎖問題を解けるかどうかは判断できません。確認できるのは、現行のインターフェース、プロンプト、予算では、推論が最終的な可視答案に収束しなかった、という点だけです。

物理問題：減衰結合振動子の行列と周波数応答#

2問目は、2つの質量を持つ2自由度系を扱います。

text
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 は2質量間の結合要素であり、c1 と c3 はそれぞれの接地減衰です。問題は、まず無減衰の固有モードを求め、その後 ω=8 rad/s で複素振幅を求めるよう求めているため、減衰をすべて対角行列に押し込めるわけにはいきません。

正しい行列#

Opus 4.8 は次のように書きました。

M=[1.5001],C=[2.0−0.8−0.82.3],K=[200−80−80230]。M=\begin{bmatrix}1.5&0\\0&1\end{bmatrix}, \quad C=\begin{bmatrix}2.0&-0.8\\-0.8&2.3\end{bmatrix}, \quad K=\begin{bmatrix}200&-80\\-80&230\end{bmatrix}。

無減衰の特性方程式から得られる固有角周波数は次のとおりです。

ω1=10.0204 rad/s,ω2=16.2149 rad/s。\omega_1=10.0204\ \text{rad/s}, \qquad \omega_2=16.2149\ \text{rad/s}。

対応するモード比 X2/X1 は 0.6173 と -2.4298 で、それぞれ同相モードと逆相モードを表します。

ω=8 における複素周波数応答#

複素動剛性行列は

Z=K−ω2M+iωC。Z=K-\omega^2M+i\omega C。

独立な複素数計算では、次の値が得られました。

量参照値
`X1
∠X1-12.1524°
`X2
∠X2-13.9035°
`X2/X1
位相差おおよそ -1.7511°

Opus のエネルギー検査も通過しました。平均散逸パワーは約 1.2574 W で、外力の入力パワーと丸め誤差の範囲で一致しています。また、c2 を誤って接地減衰とみなしてしまうと、非対角の減衰項 C12=C21=-0.8 が誤ってゼロになり、エネルギー伝達も位相結果も変わってしまう、という点も正しく説明していました。

Kimi K3 の結果#

Kimi K3 は約 204.6 秒後に 6000 token を使い切り、やはり finish_reason=length で content は空でした。最終方程式も数値もないため、物理モデリングが正しかったかどうかは評価できません。今回の記録は「予算内で未提出」です。

プログラミング問題：依存閉包、時間窓、厳密スケジューリング#

プログラミング問題では、次を実装します。

python
schedule_jobs(jobs, dependencies, capacity_by_day)

各タスクには duration、release_day、deadline_day、value があり、タスクは1日単位で完全に配置しなければなりません。各日に容量上限があり、依存関係は前提タスクが後続タスクの開始前に完了していなければならないことを意味します。目的は次の優先順で比較します。

  1. 総価値が最大
  2. 総所要時間が小さい
  3. ソート後のタスク ID 列表が辞書順で小さい

この問題は、普通の「ナップサック + ソート」よりずっと難しいです。次を同時に扱う必要があるからです。

  • 直接依存と間接依存の閉包
  • 未知の依存と閉路検出
  • 日次容量とタスクの時間窓
  • 実行可能な部分集合の厳密な箱詰め
  • 多段階の tie-break

Opus 4.8 の実装結果#

Opus は、bitmask + メモ化 DFS の完全な実装を提示し、13 個のアサーションも付けていました。2つの Python コードブロックを抽出して Python 3.11 で実行したところ、モデル付属のアサーションはすべて通過しました。

text
all assertions passed

空入力、容量不足、直接・間接依存、未知依存、循環依存、3段階の目的比較を正しくカバーしていました。

ただし、付属のアサーションでは「前提タスクが後続タスクより先に完了すること」が確認されていませんでした。そこで独立プローブを追加しました。

python
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 日目にしか置けないため、両方を同時に選ぶべきではありません。ところがモデルのコードは次を返しました。

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

これは、実装が「B を選ぶなら A も一緒に選ぶ」ことだけを確認していて、次を確認していないことを意味します。

text
assignment[A] < assignment[B]

したがって、このプログラミング問題を完全合格とは判定できません。より正確には、アルゴリズムの枠組みと入力検証は比較的よくできており、リソースの箱詰めロジックも動作しますが、依存関係の時間的な先後という核心の業務意味が抜け落ちています。生産スケジューリングシステムでは、これは必ず修正すべき正しさの問題であり、フォーマットの問題ではありません。

Kimi K3 の結果#

Kimi K3 は約 236.4 秒後に length で終了し、6000 token はすべて reasoning に消費され、content は空で、実行可能コードを返せませんでした。

遅延、出力予算、可視答案#

3問の平均遅延は次のとおりです。

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

Kimi の3回の usage は非常に近い値でした。

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

このデータから分かるのは、呼び出し側が HTTP ステータスコードと model フィールドだけを見ていてはいけない、ということです。少なくとも次を同時に記録すべきです。

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

finish_reason が length なら、HTTP が 200 を返していても、リトライ、フォールバック、または人手レビューのフローに入れるべきです。

実験の再現方法#

以下は最小限の OpenAI Python SDK 呼び出し例です。実際のテストでは、本文中の完全な問題文と、モデルに合ったパラメータを使ってください。

python
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 を与えても、可視答案は得られませんでした。

本番選定の指針#

Claude Opus 4.8 を優先して試すのに向いているケース#

  • 1回のリクエストで完全な導出または完全なコードを取りたい
  • 問題に行列、境界条件、数値検証が含まれる
  • 画面初回表示の遅延と配布可能性をより重視する
  • 生成コードに独立したテストと意味検査を追加できる

Kimi K3 を引き続き評価するのに向いているケース#

  • 数分単位の遅延を受け入れられる
  • 呼び出し側でモデル固有のサンプリングパラメータを扱える
  • タスク分割、予算追加、非同期ワークフローの採用が許される
  • 1回のリクエストで最終テキストを即時配布することより、reasoning の過程を重視する

ただし今回のデータでは、Kimi K3 を「3問とも解けていたが出力がログに隠れていただけ」とは言えません。実際の観測は、3回とも可視の最終答案がなかった、というものです。

FAQ#

1. 今回の問題が学部卒業研究や大学院レベルと言えるのはなぜですか？#

数学問題では定常分布、基本行列、初達時間の2次モーメントが必要です。物理問題では行列モデリング、モード解析、複素周波数応答、エネルギーバランスが必要です。プログラミング問題では依存閉包、厳密な箱詰め、閉路検出、多段階目的最適化が必要です。これらはそれぞれ、確率論・確率過程、古典力学と振動、アルゴリズムとシステム設計の講義における総合課題の難度に相当します。

2. Kimi K3 は temperature=0.1 に対応していないのですか？#

今回のインターフェースでは、Kimi K3 の temperature は必ず 1 である必要がありました。これは現行ルーティングのモデルパラメータ制約であり、呼び出し側はエラーメッセージを読み取ってモデル設定に応じて再試行すべきです。

3. Kimi K3 の length は、これらの問題を絶対に解けないことを意味しますか？#

いいえ。今回のプロンプト、出力上限、ルーティング条件の下では、可視の最終答案に到達しなかった、ということしか意味しません。可視答案がなければ正しさの評価はできませんが、それだけでモデルがあらゆる設定で解けないと証明されるわけでもありません。

4. Opus 4.8 のプログラミング回答は、そのまま本番で使えますか？#

そのままでは使えません。付属アサーションはすべて通っていますが、独立プローブで依存の時間的先後制約の抜けが見つかりました。生成コードには、モデル付属テストだけでなく、業務意味のテストを必ず追加する必要があります。

5. なぜ Opus 4.8 の物理問題でエネルギー散逸を確認するのですか？#

結合減衰の非対角項は非常に書き間違えやすいからです。入力パワーと減衰散逸パワーが一致することは、複素振幅、位相、減衰行列が同時に正しいことを示す独立した証拠になります。

6. 今回の遅延を性能保証として見なせますか？#

できません。上流チャネル、キャッシュ、同時実行数、リトライによって遅延は変わります。本番環境では少なくとも再サンプリングし、P50、P95、P99、打ち切り率、成功タスクあたりのコストを統計的に見る必要があります。

最終結論#

今回の比較で本当に見えたのは、文脈から切り離された「知能ランキング」ではなく、2つのまったく異なる返答挙動です。

  1. Claude Opus 4.8 は今回の3つの大学院レベル課題すべてで可視答案を返し、数学と物理の導出は独立検証を通過した
  2. Opus のコード枠組みは強力だが、依存タスクは時間的に前後関係を満たして完了しなければならないという重要な業務制約はまだ抜けていた
  3. Kimi K3 は temperature=1 を強制した条件下で、3問すべてで 6000 token を使い切り、finish_reason=length で、可視答案はなかった
  4. 1回のリクエストで完全な数学導出、物理計算、または実行可能コードを得たいのが目的なら、今回のテスト条件では Opus 4.8 の配布可能性が明らかに高い
  5. どのモデルを選ぶにしても、finish_reason、usage、独立した数値検証、コードの意味テストを検収に含める必要がある

再現用ファイル：

おすすめ記事：

Implementation Guides

Reasoning ModelsChoose the right protocol and fields for thinking and reasoning workloads.List ModelsQuery models available to the current API key through GET /v1/models.IntroductionUnderstand Crazyrouter's all-in-one AI model API gateway.Usage Logs and Cost MonitoringUse management APIs to query logs, quota, token usage, and dollar cost.
Crazyrouter
Open API PlaygroundOpen image toolRead the docsCheck live pricing

Topics

Comparison

Related Posts

GLM-5.2 と Claude Fable 5 を実測比較：出力予算、reasoning_tokens、そして 0.8 価格係数Comparison

GLM-5.2 と Claude Fable 5 を実測比較：出力予算、reasoning_tokens、そして 0.8 価格係数

Crazyrouter の OpenAI 互換 API で glm-5.2 と claude-fable-5 を数学、物理、Canvas アニメーション課題で比較し、glm-5.2 の現在の 0.8 discount も実務目線で整理します。

Jul 6
Kimi K3 と GPT-5.6-SOL を比較：数学、物理、プログラミングの高難度実測Comparison

Kimi K3 と GPT-5.6-SOL を比較：数学、物理、プログラミングの高難度実測

同一の OpenAI-compatible API と同一のプロンプト条件で、Kimi K3 と GPT-5.6-SOL を比較。モード停止時間、滑車の回転慣性を含む物理問題、依存クロージャを使う Python のプログラミング課題をテストし、正答性、途中切れ、遅延、ローカルでのコード検証を記録した。

Jul 18
Kimi K3 と Claude Fable 5 を実測比較：差が出たのは推論力より出力予算と検証性Comparison

Kimi K3 と Claude Fable 5 を実測比較：差が出たのは推論力より出力予算と検証性

数学、物理、Python、制約推論の4課題で Kimi K3 と Claude Fable 5 を比較し、finish_reason、reasoning tokens、遅延、コード実行結果を検証します。

Jul 17
Gemini 3.5 Flash vs Claude レスポンスティアモデル：開発者はどちらを選ぶべきかComparison

Gemini 3.5 Flash vs Claude レスポンスティアモデル：開発者はどちらを選ぶべきか

Gemini 3.5 FlashとClaude Haiku、Sonnet、Opusスタイルのレスポンスティアを、レイテンシ、コスト、コーディング、推論、本番API ルーティングの観点から実践的に比較します。

May 21
6つのVision APIモデルを実測：Gemini 2.5、GPT-4.1、Qwen3 VLの画像理解はどう選ぶべきかComparison

6つのVision APIモデルを実測：Gemini 2.5、GPT-4.1、Qwen3 VLの画像理解はどう選ぶべきか

Gemini 2.5 Flash、Gemini 2.5 Flash Lite、GPT-4.1 Mini、GPT-4.1 Nano、Qwen3 VL Flash、Qwen3 VL Plusの6つの画像理解APIを実測し、認識精度、レイテンシ、成功画像あたりのコスト、usage signal、失敗パターン、production routingの観点で比較します。

Jun 22
Gemini 2.5 Flash Lite vs Qwen3 VL Plus Vision API ベンチマーク 2026：実運用目線の画像理解モデル比較Comparison

Gemini 2.5 Flash Lite vs Qwen3 VL Plus Vision API ベンチマーク 2026：実運用目線の画像理解モデル比較

gemini-2.5-flash-lite と qwen3-vl-plus を Vision API ワークロードで比較する実運用向けベンチマーク。実際の画像認識精度、latency、tail latency、成功画像あたりのコスト、usage signals、failure modes、production routing を整理します。

Jun 22