Alibabaの計算を検証:Qwen3.8-Maxの価格優位性は実際のタスクでは維持できない

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
8月3日、AlibabaはQwen3.8-Maxをリリースしました。これは2.4兆パラメータ(インファレンスあたりのアクティブパラメータは95B)のモデルで、価格は入力/出力トークン100万個あたり$2/$6と設定されており、GPT-5.6 Solの出力価格と比較して約5倍安価です。リリースに合わせてAlibabaは5つのベンチマークスコアを公表し、前身モデルと比較してFrontierSWEでのスコアが40.7から73.5へと跳ね上がったことを示しました。
私たちは独自に検証を行いました。簡単な文字列操作から依存関係順序リゾルバや正規表現不使用のグロブマッチャーまでを含む、独自のハンドライトテストスイート(FrontierSWEやDeepSWEの移植ではない)による10個の独立したコーディングタスクを用意し、1つのTrueFoundry AI Gatewayエンドポイント経由でQwen3.8-Max、GPT-5.6 Sol、Kimi K3に対して実行しました。生成されたコードの評価は、別のモデルではなく実際の単体テストを用いて行い、結果が単なるノイズでないかを確認するために、モデルごとにスイート全体を3回実行しました。
Qwen3.8-Maxはすべてのタスクをクリアしたものの、最終的には3つのモデルの中で完了タスクあたりのコストが最も高くなりました。3つのモデルすべてが、ほとんどの実行で10/10のタスクを解決しました(Kimi K3は、3回の実行のうち1回で、JSON平坦化タスクにおける空入力のエッジケースを1つ落としました)。単なる合格率で見れば、Qwen3.8-Maxはわずかなコストで完全な勝利を収めたように見えます。しかし、正しい答えを得るために実際にかかったコストで標準化すると、ランキングは逆転します。GPT-5.6 Solは3回の実行すべてで解決タスクあたり$0.0067から$0.0070の間に収まり、極めて安定し再現性がありました。Qwen3.8-Maxは解決タスクあたり$0.0144から$0.0284となり、トークン単価が5倍安いにもかかわらず、最安時でGPT-5.6 Solの約2.15倍、最高時では4倍以上高くなりました。Kimi K3はその中間で、$0.0084から$0.0101でした。
なぜこのようなことが起きるのでしょうか?Qwen3.8-Maxはより難しい問題に対して劇的に冗長になり、時折迷走状態に陥るためです。私たちのスイートにある4つの「難解」タスクで平均すると、回答あたりの出力長はQwen3.8-Maxが5,364トークンであったのに対し、Kimi K3は729トークン、GPT-5.6 Solは282トークンでした。両者が同じ問題を正しく解決するのに、Qwen3.8-MaxはGPT-5.6 Solより約19倍多くのトークンを使用しました。最もわかりやすい例が、正規表現不使用のグロブマッチングタスクです。Qwen3.8-Maxの3回の実行のうち1回では、13,430の出力トークンを生成し、GPT-5.6 Solが約200トークンを用いて3.5秒で解決した問題に対して298秒を要しました。どちらも正解は導き出しています。しかし、これは四捨五入の誤差などではなく、一瞬の処理と5分間のコーヒーブレイクほどの決定的な違いです。JSON平坦化タスクでは、回答自体は毎回正しいままであったにもかかわらず、Qwen3.8-Maxの出力長は3回の反復実行で(6,104トークン、7,752トークン、13,965トークンと)増大し続けました。正解に至る経路が長くなり、高コスト化し続けたのです。
これこそが、トークン単位の価格比較が見落としている点です。出力トークン100万個あたり6ドルという価格は、GPT-5.6 Solの30ドルと比較するとお買い得に見えますが、それはモデルが正解に達するまでに20倍のトークンを使用しない場合に限られます。モデルの切り替えを検討する際に指標とすべき数字は、トークンあたりのコストではなく「正しい回答あたりのコスト」であり、それはAlibabaのローンチ時の価格設定が強調している数値とは大きく異なります。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.
















.png)
.png)
.webp)
.webp)
.png)

.png)
.png)
.png)
.webp)
.webp)

.png)
.png)
.png)





