モデル・業界動向

Qwen3.8-Maxのコーディング利用: 料金、ベンチマーク、ツール設定

Qwen3.8-Maxをコーディングで評価するためのAPI料金、ベンチマーク、Qwen Code/Claude Code設定、およびHosted Model IDと公開weightsの違い。

BetterToken

編集チーム

2026年8月5日3 分で読めます

Qwen3.8-Max のstable releaseは2026年8月3日に、Hosted Model ID qwen3.8-max として公開されました。8月13日には Qwen が Qwen3.8-2.4T-A95B のweightsも公開しています。この二つは別のデプロイ経路の名前です。前者はAPI providerのmodel fieldに、後者は自前inference用のweights repositoryに使います。

GPU基盤を自分で運用せずにHosted modelを試したい場合、8月13日のBetterToken catalogでは qwen3.8-max がinput 100万tokenあたり $1.84、output 100万tokenあたり$ 5.52と表示されていました。自分のAPI Keyを作成し、短いrequestを実行して、WorkspaceでModel IDとusageを確認してください。これは日付付きの価格snapshotです。productionで使う前にcatalogを再確認します。

previewの後に変わったこと

公式Qwen repositoryには、post-trained model Qwen3.8-2.4T-A95B のweightsとconfigurationが公開されています。総parameter数は2.4兆、active parameterは950億、native contextは262,144 tokenで、1,010,000まで拡張できます。repositoryはvLLM、SGLang、TokenSpeedと互換です。

Hosted model qwen3.8-max はこの規模を基にしていますが、Qwen はvision input、non-thinking、公式tools、標準で100万tokenのcontextを別途示しています。そのため、API configurationで qwen3.8-max の代わりに Qwen3.8-2.4T-A95B を入れたり、local inferenceがHosted APIと完全に同じだと考えたりしてはいけません。

選択	名前	指定する場所	得られるもの
Hosted API	`qwen3.8-max`	API provider directory の Model ID field	managed inference と追加の hosted capabilities
自前inference	`Qwen3.8-2.4T-A95B`	inference engine のrepositoryとconfiguration	Qwen3.8-Max Licenseのweightsと自分のinfrastructure管理
旧preview	`qwen3.8-max-preview`	新しいstable configurationには使わない	異なるcontractを持つ過去のAPI variant

Previewは Token Plan と初期configurationで qwen3.8-max-preview として使われていました。そこではstable contractに含まれないthinking restrictionが記録されています。実用的な移行は、Model IDを置き換え、key typeとendpointを確認してから最小requestを再実行することです。regionを確認せずmodel stringだけ変えると、401、404、またはmodel not foundにつながります。

公開weightsをローカルで動かせるか

形式上は可能です。repositoryには自前inference用のweightsとconfigurationがあります。ただし実際には、一般的なworkstation GPUに読み込むモデルではなくserver deploymentです。MoEでは一stepごとに950億parameterがactiveになりますが、保存、distribution、loadingが必要なデータはそれより大きく、KV cache、precision、quantization、inference engineのmemoryも必要です。

active parameter数だけでhardwareを見積もらないでください。最初にengine、precision、context length、許容するspeedを決め、そのhardware guideを確認して別途memory estimateを作ります。一回だけのcoding testならHosted APIの方が準備は少ないことが多いです。local optionは、teamがsharding、update、monitoringを運用できる場合に向いています。

WeightsにはApache 2.0ではなく独自のQwen3.8-Max Licenseが適用されます。利用と変更は許可されていますが、大規模なcommercial product、Model as a Service、AI Work Assistantには追加条件があります。publicまたはcommercial deploymentの前に、自分のscenarioに対して全文を確認してください。

Qwen3.8-Maxの料金

Alibaba Model Studioはregionごとに料金を公表しています。元のcurrencyで計算し、換算額を公式tariffとして扱わないでください。

Beijing / Global: input 100万tokenあたりCNY 12、output 100万tokenあたりCNY 36。
Singapore: input 100万tokenあたりCNY 14.988、output 100万tokenあたりCNY 44.965。

input 200,000 tokenとoutput 20,000 tokenの場合、Beijingの計算は次の通りです。

0.2 × 12 + 0.02 × 36 = CNY 3.12。

Singaporeで同じvolumeはCNY 3.8969です。これはModel Studioのpay-as-you-go計算です。Token Plan、subscription、third-party gatewayはbilling unitが異なるため、同じ比較行に置くべきではありません。

BetterToken cardでは、同じprofileは日付付きsnapshotで次の金額でした。

0.2 × $1.84 + 0.02 × $5.52 = $0.4784。

最終額を直接比較することはできません。一方はCNY、他方はUSDであり、cacheとaccessの条件も違います。使える結論は、まず具体的なproviderとregionを選び、その後に同じtoken profileをそれぞれで計算することです。価格、model availability、key groupはdynamicな事実なので、使用前に再確認します。

公式benchmark tableの読み方

Qwen releaseは次のcoding resultsを示しています。

Terminal-Bench 2.1: 86.6。
SWE-bench Pro: 67.7。
DeepSWE 1.1: 56.6。
FrontierSWE: 73.5。
PaperBench: 93.0。
QwenSWEBench: 80.7。

これはvendor-reported dataです。Terminal-Bench 2.1についてQwenはClaude Code、avg@10、5時間timeout、max_tokens=131072 を指定しています。SWE-bench ProではClaude Code、temperature=1.0、top_p=0.95、256K contextが書かれていますが、このfootnoteに別のtimeoutはありません。competitorの複数行は各社のbest published resultを使っており、datasetの一部はQwen所有でexternal reproductionがありません。

ここから単一のrankingは導けません。PaperBenchの93.0は、実際のrepositoryでissue fixを自動的により良く行う意味ではありません。まずtestが測るabilityを見て、次にharness、effort、attempt回数、assessment methodを確認します。

一つの独立testが示したこと

Trilogy AIはQwen previewとKimi K3を同じarchitectural analysis taskで比較しました。269 filesのfrozen repository、同じtime limit、同じresult typeです。StackPerfはKimi有利の80対83でした。Qwenはerrorなしで44 tool calls、Kimiは回復した2件のfailureを含め53 callsでした。

これは有用なprocess snapshotですが、一つのtaskの一runにすぎません。小さなscore差に異なるtool behaviorが伴う場合を示すだけで、すべてのcoding scenarioで一方が強いことを証明しません。

Qwen3.8-Maxを試す場面

次のようなtaskならmodelを比較対象に入れる価値があります。

多数のfilesを読み、architectural pictureを作る。
toolsを使ってmulti-step planを実行する。
text、image、documentを同じcontextで扱う。
diffを準備し、複数のreadiness conditionを確認する。
business ruleとcodeを長く同じcontextに保つ。

小さなeditではlow reasoningとより高いreasoningを比較してください。quality improvementがlatencyとoutput tokenを補えないなら、heavy modeをdefaultにすべきではありません。

Qwen Codeを設定する

まずModel Studio consoleでregionを選び、API-KEY pageを開いて、そのregion用の通常のpay-as-you-go keyを作ります。Token Plan keyは別sectionで作成され、pay-as-you-go endpointとは交換できません。作成直後にkeyをcopyし、environment variableに保存します。


export DASHSCOPE_API_KEY="YOUR_API_KEY"

Qwen Codeは modelProviders とOpenAI-compatible providerをサポートします。全project用なら ~/.qwen/settings.json を開き、一つのrepositoryだけならrootの .qwen/settings.json を使います。JSONにはkeyそのものではなくvariable nameを指定します。


{
  "modelProviders": {
    "openai": [
      {
        "id": "qwen3.8-max",
        "name": "Qwen3.8-Max",
        "baseUrl": "https://dashscope-us.aliyuncs.com/compatible-mode/v1",
        "envKey": "DASHSCOPE_API_KEY"
      }
    ]
  }
}

上のendpointはUS regionの公式exampleです。Beijing、Singapore、Tokyo、FrankfurtではModel Studio tableのaddressを取り、同じregionのkeyを使用します。project fileはuser fileを上書きするため、unexpected modelが出たときは両方のlevelを確認してください。

Qwen Code documentationではprovider configurationはatomicです。nested generationConfig や他のfieldはkeyごとにmergeされず、全体がreplaceされます。変更前に既存provider recordを保存し、diffを確認して、別modelのworking settingを消さないようにします。

Fileを保存してQwen Codeをrestartし、qwen3.8-max を選び、one fileのread requestを送ります。responseまたはmetadataでmodel nameを確認してから、changeを許可してください。

Claude Codeを設定する

Model StudioはAnthropic-compatible endpointを提供します。US regionの最小exampleは次の通りです。


export ANTHROPIC_BASE_URL="https://dashscope-us.aliyuncs.com/apps/anthropic"
export ANTHROPIC_AUTH_TOKEN="YOUR_API_KEY"
export ANTHROPIC_MODEL="qwen3.8-max"

別のregionではBase URLを公式regional addressに置き換え、対応するkeyを使用します。restart後はfileを変更しない短いtaskを出し、実際のModel IDを確認します。Token Plan keyとpay-as-you-go endpointを混ぜないでください。

Anthropic-compatibleはprotocol compatibilityを意味します。QwenがAnthropic modelになるわけでも、Claude Codeと同じbehaviorになるわけでもありません。tool call、file write、error recovery、usageを対象clientで確認する必要があります。

すでに報告されたerrorを分類する

Qwen Code issue #7332はpreviewに関するものです。internal requestが、当時thinkingだけを受け入れたmodelに enable_thinking=false を送り、400 を受けました。migrationには有用なsignalですが、現在のstable APIを説明するものではありません。

Qwen3 issue #1883ではAnthropic-compatible endpointのuserが、agentがrelative pathを直接 /tmp に書こうとしたと報告し、absolute pathがworkaroundになりました。Qwen Code issue #7489ではVS Code Companionがimage nameへのlinkを挿入しましたが、image自体はtransferしませんでした。どちらもclient versionとharnessに依存します。

この種の問題は四つのlayerに分けます。

APIがModel IDとkeyを受け付ける。
Clientがthinkingとtoolsを正しく渡す。
Harnessがpathとattachmentを正しくresolveする。
Modelがinstructionに従う。

最初からすべてを「model error」と呼ぶと、configurationの修正が難しくなります。

自分のtaskでmodelを試す

異なる種類のrepositoryまたはissueを三つ選びます。commit、tools、time limit、PASS criteriaをfreezeします。各runで次を記録してください。

reasoning mode。
inputとoutput token。
最初の有用なchangeまでの時間。
tool call数とerror数。
test result。
manual correction数。

このtestは一般的なleaderboardより有用です。codeを書くabilityだけでなく、完了したtaskのcost、つまりteamが実際に払うものを示します。

参照先

LLM ワークフローを最適化しませんか？

単一 API でモデルを接続し、キーと AI コストを管理できます。