Qwen3.8 Maxベンチマーク：公式結果と本番エビデンス
エビデンスマトリクス
| 領域 | Qwen結果 | 限界 |
|---|---|---|
| Coding | Terminal 86.6 / SWE-Pro 67.7 | HarnessとRepo修復を分離 |
| Agent | Toolathlon 72.5 | Tool成功、Retry、介入を測定 |
| Reasoning | HLE 43.6 / PaperBench 93.0 | 総合順位にはしない |
| Multimodal | OmniDocBench 92.1 | EvoLink媒体経路は未検証 |
| EvoLink | RouteはLive、Evidence Runは未実施 | 20–50 Taskで成功率、Latency、Retry、Correction、Costを測定 |
初期の第三者試験から分かること
Trilogy AIの初期テストは269ファイルのリポジトリアーキテクチャ課題でQwen3.8 Max PreviewとKimi K3を比較し、Blind ReviewでKimi 83、Qwen 80と評価しました。Qwenはシステム境界とReplay Metadataの一部で優れ、Kimiはより速く少ないトークンで完了し、Lifecycle Stateを広く扱いました。
この結果は作業構造、エラー、トークン、質的差を報告している点で有用です。しかし、1課題、各モデル1セッション、特定Routeの結果であり、一般的なランキングではありません。
方法論として採用すべき点は次です。
- 入力を固定して比較する。
- 出力構造だけでなく主張の正確性も採点する。
- Model BehaviorとRoute Behaviorを分離する。
- 品質とともにLatencyとTokenを報告する。
- 可能ならReviewerをBlindにする。
- 合計点だけでなくFailure Analysisを公開する。
Qwen側は対話型Coding HarnessのToken Plan経路でした。個人プランは独自バックエンド、自動スクリプト、非対話型バッチを禁止します。83対80は特定日時のEnd-to-End評価経路比較であり、交換可能な二つの本番API比較ではありません。
まだ不足している証拠
完全な公式Benchmark開示
モデル版、推論設定、Tool Access、Prompt Policy、試行回数、採点方法、競合設定が必要です。HarnessのないScoreは再現困難です。
独立したCoding・Agent再現
関数生成だけでなく、リポジトリ探索、複数ファイル変更、テスト、Tool Call、失敗復旧、レビューを含めます。
マルチモーダル証拠
OCR、Visual Grounding、文書理解、Chart Reasoning、Samplingした動画Frame、Hallucinationを分離します。Native Video入力はまだ仮定しません。
LatencyとToken効率
高得点でも長い推論、高い出力量、予測不能なLatencyで製品体験と費用が悪化することがあります。
Route安定性と利用権限
正確なID、日付、チャネル、地域、Client、設定に加え、Interactive Evaluation、自動Regression、Application Backend、Batchの許可範囲を記録します。
再現可能な利用権限
対話型購読で実行できることと、アプリBackendや自動回帰Testで許可されることを分けて記録します。Routeの利用条件は品質Scoreと別のGateです。
公開Benchmarkが本番判断に失敗する理由
| Blind Spot | 隠れる本番障害 | より良い測定 |
|---|---|---|
| One-shot回答 | 計画は正しいが実装が壊れる | End-to-End合格タスク |
| 理想Prompt | 実ユーザー入力で脆い | Prompt Variation合格率 |
| Tool障害なし | 悪いTool Call後にループ | 障害注入からの復旧 |
| 1回の試行 | 高Variance | 複数試行と信頼区間 |
| Token単価のみ | 安いがRetry多数 | 成功タスク単価 |
| 最大Context | 長文から根拠を探せない | 位置制御したRecall |
| 最終回答点のみ | 美文にUnsupported Claimが隠れる | Claim単位のEvidence Audit |
将来のEvoLink Qwen3.8 Benchmark Gate
このProtocolは本番利用可能なAPI Routeが公開された後にのみ実行します。公開済みTest結果でも、大規模Token Plan試験に今すぐ支出する理由でもありません。
1. 作業セットを固定する
API公開後は小規模Pilotから始め、結果とRoute条件が妥当な場合だけ拡張します。Qwen3.7 Max、Kimi K3、Claude、GPTなど現行RouteをBaselineにします。
| Category | 最小試験 | 合格Signal |
|---|---|---|
| Repository Coding | Bug Fixと複数Module機能 | テスト合格、不要変更なし |
| Coding Agent | 複数Toolの長時間作業 | 正しいCall、未解決Loopなし |
| Reasoning | 多段Technical Decision | 正答と追跡可能な前提 |
| Long Context | 文書・Repo検索 | 正しい根拠と引用 |
| Vision | Screenshot、Chart、Document | Grounded Extraction、低捏造率 |
| Data Work | 表分析とReport | 数値正確性、使用可能な成果物 |
| Routine Workload | 小さな一般タスク | Frontier Routeが測定可能な価値を追加 |
2. 環境を固定する
正確なModel ID、日付、Provider Route、地域、System/User Prompt、推論設定、Tool権限、Timeout、Retry、Fallback、Token、Cache Hitを記録します。
3. StyleよりAcceptanceを先に採点する
テスト、Schema、引用、数値、必須成果物を先に判定し、その後で保守性、明瞭さ、好みを評価します。
production_score = acceptance_rate
- severe_defect_rate
- intervention_penalty
- timeout_penalty4. 成功タスクの経済性を計算する
accepted_task_cost = model_calls + retries + fallback_calls + reviewer_time + repairQwenCloudはupstreamトークン料金を公開していますが、EvoLink Route料金は未確定です。同じチャネルの実請求と成功タスク単価を使い、Preview Creditsは履歴としてのみ扱います。
5. 万能順位ではなくRoute Roleを決める
| 役割 | 必要な証拠 |
|---|---|
| Default Route | 一般トラフィックで安定した品質、速度、費用 |
| Coding Specialist | RepoとTool作業で明確な優位 |
| Long-context Specialist | 実際の長さで高いRecallと一貫性 |
| Quality Escalation | 難しい作業で高い合格率 |
| Evaluation Only | 能力は高いがID、費用、挙動が不安定 |
Evaluation Onlyが正しい現在地です。新しいScoreを読む8つの質問
- 公開者はVendor、比較対象、独立評価者のどれか。
- 正確なQwen3.8 BuildとRouteは何か。
- 推論は有効か、Effortはいくつか。
- Tool、Browsing、Code Executionは使えるか。
- 試行回数はいくつか。
- Promptと採点は再現できるか。
- 自社製品の作業を測っているか。
- Latency、Token、Retry、Failureを含むか。
欠けていれば方向性の証拠とLabelし、Winner表に入れません。
EvoLinkユーザーへの推奨
各Scoreの裏に再現可能な証拠を残す
Model ID、Route、日付、Region、Client、Thinking設定、Tool権限、Cache、Prompt Hash、試行数、Judge、Acceptance Ruleを保存します。これがないとModel RevisionやRoute変更を能力向上と誤認します。
| 結果 | 最低限のArtifact | 利用できる判断 |
|---|---|---|
| Qwen公式 | 表とHarness設定 | HypothesisとBaseline |
| 第三者 | Prompt、Route、反復、Judge、失敗 | 方向性比較 |
| Community | 再現タスクまたは一次証拠 | Edge Case追加のみ |
| EvoLink Smoke | Request/Response、Usage、Latency、Error | Route契約確認 |
| EvoLink Workload | 反復AcceptanceとReview | Main/Challenger/Fallback |
平均だけでなく失敗分布を報告します。無効Tool Call、壊れたJSON、Timeout、Retry、Fallback、人手修正を分母から外しません。4回成功して1回無限Loopになるモデルは、少し低Scoreでも安定するモデルより運用価値が低い場合があります。
評価PackageをVersion管理する
Prompt、Fixture、Raw Response、Tool Log、Usage、請求、Judge Rule、人手Decisionを日付付きで保存します。Model、Client、Route、Region、Reasoning設定のいずれかが変われば、旧結果を上書きせず新しいRunとして扱います。これにより能力改善、試行Variance、Infrastructure変更を分離できます。
また、成功例だけを公開しません。Unsupported Media、Tool Argument Error、Schema Repair、Timeout、429/5xx、Fallback発動、Reviewer修正をFailure Taxonomyへ残し、カテゴリごとの頻度と復旧時間を報告します。
ベンチマークをルーティング判断に変える
リリース情報だけで登録せず、まず5項目を確認してください。ワークロードに合う場合のみAPIキーを作成します。
- 01
リリース済み？
はい。Qwen3.8 Maxが正式モデルで、Previewは過去のチャネル情報です。
- 02
利用できる？
EvoLinkで利用できます。製品ページで稼働ルートとモデルIDを確認してください。
- 03
用途に合う？
長文脈推論、大規模リポジトリ、ツール中心のAgent向けです。軽い処理は小型ルートに残します。
- 04
料金は？
製品ページのリアルタイム料金を確認し、上流やPreviewプランの価格を流用しないでください。
- 05
呼び出し方は？
Chat Completions、Responses、Messagesから選び、導入ガイドとパラメータ仕様を確認します。
5項目を確認しましたか？ APIキーを作成.
よくある質問
Qwen3.8のベンチマークスコアは？
信頼できる単一総合点はありません。QwenはTerminal-Bench 2.1 86.6、SWE-bench Pro 67.7、HLE 43.6、OmniDocBench 1.5 92.1を公開していますが、Vendor結果であり普遍順位ではありません。
Fable 5に次ぐ2位ですか？
Qwen自身の評価に対するVendor解釈で、独立検証された普遍順位ではありません。WorkloadごとにRoute Roleを決めてください。
第三者評価はありますか？
269ファイルのリポジトリ比較など初期試験はありますが、総合順位を決めるには狭すぎます。
コーディングに強いですか？
主要ユースケースですが、本番ではRepo変更、Tool、復旧、テスト、Reviewまで評価します。
Kimi K3とどう比較しますか？
入力、権限、判定基準、Budgetを固定し、複数回実行して品質、Latency、Token、介入、コストを別々に測ります。
Token Plan Creditsを費用比較に使えますか？
使えません。CreditsはPreview購読実験の消費を示すだけで、本番比較では同じRunに実際に課金されたProviderまたはEvoLink Route価格を使います。
どのBaselineを含めるべきですか？
実際に置き換える可能性があるQwen3.7 MaxやKimi K3に加え、品質上限を測るFable 5やGPT-5.6などを含めます。利用できないモデルを飾りの比較対象にしないでください。
本番準備ができるのはいつですか？
正確なRoute、ID、料金、制限、動作、Fallbackを確認し、反復した実タスクがAcceptance基準を満たした時です。
出典
- QwenCloudモデルリリースログ
- Qwen3.8 Max技術リリースとBenchmark
- Qwen Token Plan個人向け概要
- Qwen Chat API
- Qwen Kilo CLI設定
- Kimi K3概要
- Trilogy AIの比較
- Qwen3.8発表
