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: false は extra_body と chat_template_kwargs: {"enable_thinking": false} で同等で、どちらでも使えます。
thinking_budget は影響しません
128 / 512 / 4096 を渡しても、いずれも low ティアと同じように動作し、数値自体は無視されます。代わりに reasoning_effort を使ってください。
コード例
Python(OpenAI SDK 互換)
画像入力
url を https://... アドレスに設定するだけです。
動画入力
{"type": "video", "video": [frame1, frame2, ...]} もあり、こちらは 4–8000 フレーム が必要です。4 未満だと 400 が返ります。
cURL
ツール呼び出し
Chat Completions エンドポイントでのツール呼び出しは 完全に動作します: 単一ツール、並列ツール、2ラウンドの往復、20個のツールから1つを選ぶこと、ストリーミングデルタ、そしてparallel_tool_calls: false まですべて検証済みです。
構造化出力
response_formatは、json_schemaを用いたテストで厳密に満たされました: 入れ子のオブジェクト、enum、配列、そしてadditionalProperties: falseはすべて有効になり、余分なフィールドも Markdown のフェンスもありませんでした。
コンテキストキャッシュ
- 約1,024 token 付近でヒットし始めます: 818 token のプレフィックスはミスし、1,070 token 以上でヒットしました
- 実際の複数ターン会話ではヒットします: メッセージをターンごとに追加すると、毎ラウンドでヒットしました
- 長いドキュメントほど効果が大きいです: 128K で 98.6% の入力がキャッシュされ、32K では 99.3% でした
Anthropic エンドポイントの使用
/v1/messages はコード統合には使えますが、履歴を再生する前に thinking ブロックを削除しなければなりません。そうしないと 400(if content is list. item must be dict and key[type] should in dict)になります。
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 を設定したのに、なぜまだ大量の token が課金されるのですか?
max_tokens を設定したのに、なぜまだ大量の token が課金されるのですか?
max_tokens は表示される回答だけを制限し、thinking 部分は制限しません。測定では 1,054 output token が max_tokens=1 で課金されました。コストを抑えるには reasoning_effort="none" を使ってください。名前付き関数を指定した tool_choice が 400 を返すのはなぜですか?
名前付き関数を指定した tool_choice が 400 を返すのはなぜですか?
thinking が有効な間は、強制的な tool choice はサポートされません。代わりに
reasoning_effort="none" を併用してください。なぜ /v1/responses に到達できないのですか?
なぜ /v1/responses に到達できないのですか?
このエンドポイントはまだこのモデルに接続されていません。30 回のテスト呼び出しはすべて失敗し、エラーコードは 404 と 400 の間で交互に変わりました。上流側には報告済みで、利用可能になり次第 ライブ更新 でお知らせします。代わりに
/v1/chat/completions を使用してください。このモデルは Claude Code で使えますか?
このモデルは Claude Code で使えますか?
まだです。
/v1/messages エンドポイントは thinking ブロックを含む履歴メッセージを拒否し、Claude Code はそれらをそのまま再生します。ご自身のコードから呼び出す場合は、そのブロックを取り除けばエンドポイントは問題なく動作します。usage から reasoning_tokens が時々欠けるのはなぜですか?
usage から reasoning_tokens が時々欠けるのはなぜですか?
このモデルは複数の upstream ルート経由で提供されており、そのうちの 1 つは
reasoning_tokens や cached_tokens を報告しません。これは chat リクエストのおよそ 3 分の 1 で確認されています。整合性のため upstream に報告済みです。正確な推論コストの計測が必要な場合は、念頭に置いてください。なぜ video 呼び出しはこんなに遅いのですか?
なぜ video 呼び出しはこんなに遅いのですか?
動画の理解には 1 回あたり 144–285 秒かかることが測定されており、これはモデル自身の処理時間です。タイムアウトを 300 秒超に設定し、必要に応じて非同期キューの利用も検討してください。
関連
- Qwen3.8-Max プレイグラウンド — リクエストを直接送信します
- Qwen3.6 series (legacy) — 以前の5つのモデル
- Qwen3.8-Max リリースノート — ベンチマークと詳細な解説
- モデル料金 — モデル別レート、キャッシュ料金、利用可能なエンドポイント
- チャージプロモーション — 併用可能な割引
このページの測定値は、2026-08-03(12:50–14:35 UTC+8)の586件の実ライブ呼び出しに基づいています。課金関連の結論は、APIから返されるusageフィールドに基づいており、請求書と行ごとの照合はしていません。チャネルの調整により、モデルおよびゲートウェイの挙動は変わる場合があります。実ライブ呼び出しを信頼できる情報源として扱ってください。