Skip to main content
Qwen3.8-Max (qwen3.8-max) は Alibaba Qwen の新しいフラッグシップで、2026年8月3日にリリースされました。これは総パラメータ数2.4兆のスパース MoE モデルで、1M context window、最大出力131K、さらに text、image、video 入力をネイティブにサポートします。APIYI は公開当日にこれを掲載し、586回のライブテスト呼び出しを実施しました — このページの機能マトリクス、パラメータの挙動、課金に関する注記は、公式ドキュメントを言い換えたものではなく、すべてそれらのテストに基づいています。
Qwen3.8-Max は APIYI で利用可能です: モデル名は qwen3.8-max です。Thinking はデフォルトでオンxhighティアでは、Thinking tokens は出力として課金されます)なので、日常的なチャットでは reasoning_effort="none" を明示的に設定してください — テストでは、これにより出力はおおよそ 158 tokens から 5 へ減少しました。前世代については、Qwen3.6 シリーズ(旧版) をご覧ください。

このモデルを選ぶ理由

公式より17.5%低い

$1.65の入力、$4.95の出力が1M tokensあたりで、Alibaba Cloudの$2/$6より安いです。チャージプロモーションも上乗せできます。

1Mコンテキスト、検証済み

8K / 32K / 128K の本文全体で、マーカーが文書中盤と末尾に埋め込まれていても、両方のエンドポイントが 6/6を完全一致で 再現しました。128K の呼び出しには約80秒かかります。

3つのモダリティ、1つのモデル

テキスト、画像、動画の入力はいずれも動作確認済みです — 「long-context model」と「vision model」を切り替える必要はありません。

エージェント的な作業が大幅に強化

FrontierSWEは前世代の40.7から73.5へ、DeepSWEは21.6から56.6へ向上しました。ツール呼び出しチェーンは完全で、2往復の検証も済んでいます。

エンドポイント対応

料金

1M token あたりの割引前リスト価格: チャージ特典 を重ねて適用すると、実質コストをさらに下げられます。

Specifications

公式ベンチマーク: GPQA Diamond 92.6、PaperBench 93.0、OmniDocBench 1.5 92.1、Terminal-Bench 2.1 86.6、OSWorld-Verified 86.1、IFBench 82.8、FrontierSWE 73.5、SWE-bench Pro 67.7。

推論の制御(最重要セクション)

Qwen3.8-Max はデフォルトで推論します。xhigh ティアです。推論 token は出力として課金され、その 90%超を占めることがよくあります。

7つの値、4つの実質ティア

このパラメータは 7つの値を受け付けますが、実際には 4つの実質ティア にしか対応していません。 max を渡しても、xhigh より深く推論することはありません。その他の値では、許可された値の一覧を示す 400 が返ります。

推論をオフにする方法

enable_thinking: falseextra_bodychat_template_kwargs: {"enable_thinking": false} で同等で、どちらでも使えます。
max_tokens では推論 tokens を制限できません。 max_tokens=1 を設定しても、1,054 output tokens が課金され、そのうち 1,045 が推論でした。max_tokens は表示される回答を切り詰めるだけです。コストを制御するには reasoning_effort を使ってください — max_tokens に頼らないでください。

thinking_budget は影響しません

128 / 512 / 4096 を渡しても、いずれも low ティアと同じように動作し、数値自体は無視されます。代わりに reasoning_effort を使ってください。

コード例

Python(OpenAI SDK 互換)

画像入力

リモートの画像 URL もこのエンドポイントで使用できます。urlhttps://... アドレスに設定するだけです。

動画入力

テストでは、動画の理解には呼び出しごとに 144–285 秒 かかりました。クライアントのタイムアウトは 300 秒より長く設定し、ストリーミングまたは非同期タスクキューを優先してください。
フレームシーケンス形式 {"type": "video", "video": [frame1, frame2, ...]} もあり、こちらは 4–8000 フレーム が必要です。4 未満だと 400 が返ります。

cURL

ツール呼び出し

Chat Completions エンドポイントでのツール呼び出しは 完全に動作します: 単一ツール、並列ツール、2ラウンドの往復、20個のツールから1つを選ぶこと、ストリーミングデルタ、そして parallel_tool_calls: false まですべて検証済みです。
強制ツール呼び出しでは thinking をオフにする必要があります。 tool_choice"required" であるか、特定の関数名を指定している場合は、reasoning_effort="none" も設定する必要があります。そうしないと、400(tool_choice does not support being set to required or object in thinking mode)になるか、呼び出しが静かにスキップされます。tool_choice"auto" / "none" に設定する場合は影響を受けません。同じことが n > 1 にも当てはまります。

構造化出力

response_formatは、json_schemaを用いたテストで厳密に満たされました: 入れ子のオブジェクト、enum、配列、そしてadditionalProperties: falseはすべて有効になり、余分なフィールドも Markdown のフェンスもありませんでした。
構造化出力では推論を無効にします。 同じスキーマで、並べて測定しました:準拠性は同一で、コストとレイテンシーは1桁異なります。

コンテキストキャッシュ

  • 約1,024 token 付近でヒットし始めます: 818 token のプレフィックスはミスし、1,070 token 以上でヒットしました
  • 実際の複数ターン会話ではヒットします: メッセージをターンごとに追加すると、毎ラウンドでヒットしました
  • 長いドキュメントほど効果が大きいです: 128K で 98.6% の入力がキャッシュされ、32K では 99.3% でした
テストではキャッシュヒットは安定していませんでした。同じプレフィックスでも、あるラウンドではヒットし、別のラウンドではミスしました。また、TTL は API 応答から確実には推測できません。キャッシュは発生したときのボーナスとして扱い、それを前提にコスト予測を立てないでください。

Anthropic エンドポイントの使用

/v1/messages はコード統合には使えますが、履歴を再生する前に thinking ブロックを削除しなければなりません。そうしないと 400(if content is list. item must be dict and key[type] should in dict)になります。
このフィルターを入れた状態で、3ターンにわたるターン間メモリ、2ラウンドのツール往復、そしてツール結果が後続ターンに引き継がれることを確認しました。
Claude Code のような既製クライアントはまだ使用できません — 既定では履歴のコンテンツブロックをそのまま再生し、動作を変更できないため、2ターン目で 400 が返ります。代わりに /v1/chat/completions を使用してください。
このエンドポイントでのその他の違い: response_format は黙って無視されます(構造化出力にはツール呼び出しを強制してください)、tool_choice は OpenAI 形式のみを受け付け、画像は base64 でなければならず(リモート URL は 400 を返します)、reasoning_effort は効果がありません(thinking をオフにするには thinking: {"type": "disabled"} を使用してください)。

パラメータ互換性

ベストプラクティス

日常的なチャットと大量コール

reasoning_effort="none" を明示的に設定します。計測レイテンシーは約5秒から2秒に下がり、出力 token もおよそ 1/30 になりました。

長文ドキュメントとコードベース

128K の再現精度はテストで完全で、長文ドキュメントのキャッシュヒット率も高いです。大きなドキュメントはメッセージリストの先頭に置き、質問は末尾に置いてください。

データ抽出

json_schema で制約し、thinking を無効にします。準拠性には影響しません。

エージェントとツールオーケストレーション

/v1/chat/completions を使います。ツール呼び出しを強制する際は、thinking を無効にするのを忘れないでください。

よくある質問

max_tokens は表示される回答だけを制限し、thinking 部分は制限しません。測定では 1,054 output token が max_tokens=1 で課金されました。コストを抑えるには reasoning_effort="none" を使ってください。
thinking が有効な間は、強制的な tool choice はサポートされません。代わりに reasoning_effort="none" を併用してください。
このエンドポイントはまだこのモデルに接続されていません。30 回のテスト呼び出しはすべて失敗し、エラーコードは 404 と 400 の間で交互に変わりました。上流側には報告済みで、利用可能になり次第 ライブ更新 でお知らせします。代わりに /v1/chat/completions を使用してください。
まだです。/v1/messages エンドポイントは thinking ブロックを含む履歴メッセージを拒否し、Claude Code はそれらをそのまま再生します。ご自身のコードから呼び出す場合は、そのブロックを取り除けばエンドポイントは問題なく動作します。
このモデルは複数の upstream ルート経由で提供されており、そのうちの 1 つは reasoning_tokenscached_tokens を報告しません。これは chat リクエストのおよそ 3 分の 1 で確認されています。整合性のため upstream に報告済みです。正確な推論コストの計測が必要な場合は、念頭に置いてください。
動画の理解には 1 回あたり 144–285 秒かかることが測定されており、これはモデル自身の処理時間です。タイムアウトを 300 秒超に設定し、必要に応じて非同期キューの利用も検討してください。

関連

このページの測定値は、2026-08-03(12:50–14:35 UTC+8)の586件の実ライブ呼び出しに基づいています。課金関連の結論は、APIから返されるusageフィールドに基づいており、請求書と行ごとの照合はしていません。チャネルの調整により、モデルおよびゲートウェイの挙動は変わる場合があります。実ライブ呼び出しを信頼できる情報源として扱ってください。