← ブログ

Qwen3.5-Omni APIの料金・制限・デプロイオプション(2026年)

Qwen3.5-Omni APIの料金、レート制限、デプロイオプションをビルダー向けに解説。Plus・Flash・Lightにおける DashScope とセルフホスティングのトレードオフを比較。

2 min read
Qwen3.5-Omni APIの料金・制限・デプロイオプション(2026年)

みなさん、こんにちは!Doraです。3月末にQwen3.5-Omniのリリースを見たときの驚きをみなさんにお伝えしたいと思います。そのとき、最初に頭に浮かんだのは「おお、すごいモデルだ」ではなく、これって1回の呼び出しにいくらかかるの? でした。

というのも、以前に痛い目に遭ったことがあるからです。新しいマルチモーダルAPIで処理パイプラインを構築し、課金ドキュメントを十分に読まなかったところ、音声処理がより長いコンテキスト範囲に達した途端に月額請求が4倍になるのを目の当たりにしました。だから今回は、統合コードを1行も書く前に、DashScopeの価格ドキュメントと公式APIリファレンスをしっかり読み込みました。

Qwen3.5-Omniの上に構築するか、セルフホストするかを評価しているエンジニアリングリードやインフラ意思決定者の方々に向けて、コストモデルにとって本当に重要な事項をまとめました。しばらく向き合わないと直感的に理解しにくい価格体系についても解説します。

Qwen3.5-Omniの価格体系

DashScopeの段階的価格設定:入力トークンベースのモデル

まず最初に理解しておくべき最重要事項:DashScopeはフラットな1トークンあたりの料金を請求しません。 Qwen3.5-Omni(qwen3.5-plusを含むいくつかの他のQwenモデル)の場合、価格は現在のリクエストの入力トークン数に基づく段階制になっています。累積セッショントークンではなく、単一リクエストの入力サイズが適用される料金ブラケットを決定します。

これは直感的でなく、実際の影響があります。5Kトークンの短いリクエストと240Kトークンの最大リクエストは、単に比例的に価格が異なるだけでなく、まったく異なる料金ブラケットに分類されます。この仕組みはリクエストを短く保つことを促しますが、これは256Kコンテキストモデルを選ぶ理由と直接相反する場合があります。

DashScopeの公式価格ページには、Qwen-Plusおよび関連モデルファミリーに適用されるこの段階的構造が示されています。Omniモダリティ固有の音声トークンとビデオフレームの価格は、マルチモーダル課金セクションに別途記載されています。

Plus vs. Flash vs. Light:コストパフォーマンスの差

Qwen3.5-Omniは、異なるポジショニングを持つ3つのバリアントで提供されます:

Plusは主要ベンチマークモデルです。音声理解においてGemini 3.1 Proを上回ったのはこのモデルです。Flashはその能力の一部を犠牲にして、より低いレイテンシーとおそらく低い1回あたりのコストを実現しています。Lightはオープンウェイト層です。実行は無料ですが、インフラは自己管理が必要です。

APIユーザーにとっての実際の選択はPlusとFlashの間になります。長い録音の高精度文字起こしや顧客向け製品の音声クローニングが用途であれば、Plusが適しています。より厳しいレイテンシー要件でのリアルタイム会話が目的なら、まずFlashをテストする価値があります。

無料クォータ:含まれる内容と上限に達するタイミング

新規DashScopeアカウントのInternationalリージョン(シンガポールエンドポイント)では、Model Studio有効化後90日間有効な100万入力トークンと100万出力トークンの無料クォータが付与されます。グローバルデプロイメントモード(米国バージニア)には無料クォータがありません。チームが米国拠点で最近接エンドポイントからテストしたい場合、これは重要な点です。

音声中心のテストを実行していると、予想より早くその無料クォータを使い切ってしまいます。10時間の音声ファイル1つで256Kコンテキストの上限に達し、それだけで1Mの入力トークン許容量のうち約256Kを1リクエストで消費します。

コンテキストウィンドウの経済学

実際の256Kトークン:音声時間数、ビデオ秒数、実際のコスト

公式の数字では、256Kトークンで「10時間以上の連続音声」または「音声付き720p動画の約400秒」を処理できるとされています。コスト感覚に置き換えてみましょう。

音声のトークン化レートは概ね1時間あたり25,600トークン(256K ÷ 10時間)です。これは音声1分あたり約427トークンに相当します。1FPSサンプリングのビデオでは、400秒の720pコンテンツでフルコンテキストが埋まります。

段階的価格ブラケットと照らし合わせて、2つのシナリオを考えてみましょう:

短いリクエスト(例:5分の会議クリップ ≈ 約2,100トークン): 最低価格帯に分類されます。1回あたりの費用は安価です。

長いリクエスト(例:3時間のポッドキャスト ≈ 約77,000トークン): 中間ブラケットに入ります。1トークンあたりの料金が上昇するため、音声1分あたりのコストは短いリクエストのシナリオより意味のある差が生まれます。使用するトークンが多いからではなく、ブラケットが異なるからです。

最大値に近いリクエスト(例:8時間の音声ファイル ≈ 約205,000トークン): 最高ブラケットになります。最高ブラケットの価格で1日分の音声を処理すると、同等の12分クリップ40本を個別に処理するよりもかなり高くなります。これが段階的モデルが迫るアーキテクチャ上の決断です:長い入力のバッチ処理とチャンク分割のどちらを選ぶか。

大量の音声を処理するビルダーにとっては、チャンク分割の方が実際には安上がりになる可能性があります。フルコンテキストウィンドウを活用するよりも安くなるというのは、大きなコンテキストが売りの一つであることを考えると皮肉な話です。

長いコンテキストの音声入力がコスト高になるとき

短いコンテキストと長いコンテキストの間のどこかに、チャンク分割がコスト面で勝るブレークイーブンポイントがあります。正確な数字はモダリティ固有の価格(DashScopeの課金では音声トークンレートとテキストトークンレートは異なる)に依存するため、アーキテクチャを確定する前に簡単な計算を行うことをお勧めします。想定される音声長の分布を段階的価格の計算式とチャンクベースのアプローチの両方に通してみてください。

レート制限とスループット

QPS/同時実行制限に関する既知の情報

Qwen3.5-Omniのレートリミットはテキストのみのモデルほどは公開されていません。DashScopeのAPIユーザー向けの一般的なパターンは、アカウントレベルで適用されるQPS(クエリ/秒)と同時実行制限で、エンタープライズアカウントへのクォータ増加リクエストで調整可能です。キャパシティプランニングに確定数値が必要な場合は、DashScopeサポートにクォータ増加リクエストを提出してください。アカウント層の実際の制限が返ってきます。

DashScope InternationalエンドポイントとChina Mainlandエンドポイント

中国外チーム向けの主要エンドポイントリージョンは3つあります:

  • International(シンガポール): https://dashscope-intl.aliyuncs.com/compatible-mode/v1 — データとエンドポイントはシンガポールにあり、推論はグローバルにスケジュールされます(中国大陸を除く)。これはほとんどの国際ビルダーのデフォルトです。無料クォータが適用されます。
  • Global(米国バージニア/ドイツフランクフルト): https://dashscope-us.aliyuncs.com/compatible-mode/v1 — データとエンドポイントは米国バージニアリージョンにあり、コンピューティングはグローバルにスケジュールされます。無料クォータなし。 米国ベースのレイテンシー要件に適しています。
  • 中国大陸(北京): https://dashscope.aliyuncs.com/compatible-mode/v1 — 中国国内で運営するチーム向けに限定されています。1トークンあたりの価格は大幅に低くなっています。

米国リージョンの利用可能性(バージニアエンドポイント)

米国(バージニア)エンドポイントはQwenテキストモデルで利用可能です。現時点では、Qwen3.5-Omniマルチモーダル推論が米国エンドポイントを経由するのか、シンガポールにフォールバックするのかをDashScope APIリファレンスで直接確認してください。一般的なマルチモーダルエンドポイントのパターンは:

POST https://dashscope-us.aliyuncs.com/api/v1/services/aigc/multimodal-generation/generation

データレジデンシー要件のあるチームは、米国エンドポイント経由で処理された音声/動画コンテンツが推論パイプラインのどこかで米国外に保存されるかどうかをAlibaba Cloudに確認してください。

vLLMによるセルフホスティング

MoEにはHuggingFace TransformersよりvLLMをQwenチームが推奨する理由

Qwen3.5-Omni-PlusはハイブリッドアテンションMixture-of-Experts(MoE)アーキテクチャを使用しています。Qwenチームはあらゆる本番ワークロードにおいてHuggingFace TransformersよりvLLMを明示的に推奨しています。その理由はMoE固有の問題にあります:MoEモデルのエキスパートルーティングは不規則なメモリアクセスパターンを引き起こし、HuggingFace Transformersはこれをうまく最適化できません。vLLMのPagedAttentionとMoEを考慮したスケジューリングはこれを大幅に改善し、負荷時に実際のスループット差として現れます。大規模な呼び出しや低レイテンシー要件には、公式ガイダンスではvLLMかDashScope APIを直接使用することが推奨されており、生のTransformersは推奨されていません。

Plusのインフラ要件(30B-A3Bクラス)

Plusバリアント(総パラメータ数30B、1トークンあたり3Bがアクティブ)は、BF16での快適な推論に最低40GB VRAMが必要です。実際には:

  • シングルA100 80GB:FP8またはINT8量子化でPlusを実行可能。BF16のフルコンテキストはタイト。
  • シングルH100 80GB:BF16で快適。短いコンテキストならKVキャッシュにも余裕あり。
  • RTX 4090(24GB):Plusには不十分。FlashまたはLightバリアントに量子化を施せば動作可能。

Omniモデル固有の点として、TalkerコンポーネントのオーディオコーデックメモリもVRAM使用量に加算する必要があります。言語モデルの重みだけではありません。48GB VRAMのRTX 4090DがQwen3-Omni 30B-A3BをAWQ 4ビット量子化で実行したとの報告がありますが、KVキャッシュのヘッドルームはほとんどなく、生成スループットは約64トークン/秒です。

Dockerイメージの利用可能性とセットアップ

QwenチームはHuggingFace TransformersとvLLMの両方の完全なランタイムをバンドルしたDockerイメージを提供しています。それを使いましょう。Omni固有のvLLMフォーク(qwen3_omniブランチ)を手動でセットアップするのは手間がかかります。公式スタックでのインストール:

# Omni固有のvLLMフォークをクローン
git clone -b qwen3_omni https://github.com/wangxiongts/vllm.git
cd vllm

# 依存関係をインストール
pip install -r requirements/build.txt
pip install -r requirements/cuda.txt
VLLM_USE_PRECOMPILED=1 pip install -e . -v --no-build-isolation

# 必要なパッケージをインストール
pip install transformers==4.57.3 accelerate
pip install qwen-omni-utils -U
pip install -U flash-attn --no-build-isolation

次にサーブします:

vllm serve Qwen/Qwen3-Omni-30B-A3B-Instruct \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

max-model-len 32768の上限はシングルGPUセットアップでは現実的な選択です。シングル80GBカードで256Kコンテキストに向かうには積極的な量子化が必要で、バッチサイズも大幅に制限されます。vLLM公式のデプロイメントドキュメントによると、PagedAttentionはKVキャッシュメモリを効率的に処理しますが、マルチコードブックのTalker出力を持つ音声ビジュアルモデルは、テキストのみの同等モデルよりKVキャッシュの負荷が高くなります。

DashScope API vs. セルフホスティング:意思決定フレームワーク

DashScopeが適しているケース

  • 数週間ではなく数日以内に本番稼働させる必要がある
  • 月間トークン量が約5,000万トークン未満(APIのユニットエコノミクスがまだ有利)
  • GPUインフラがなく、構築したくない
  • 音声クローニング機能が重要——これはAPIではPlusとFlashのみ対応。Lightオープンウェイトは公開していない
  • 契約上の保証付きでシンガポールまたは米国のリージョナルデータルーティングが必要

セルフホスティングが適しているケース

  • 月間ボリュームが常に5,000万〜1億トークン以上で、1トークンあたりのコストが重要
  • DashScopeのリージョナルエンドポイントが満たせないデータレジデンシー要件がある
  • コロケーションに依存する200ms以下のレスポンス目標のためのレイテンシー制御が必要
  • 既存のフリートに合うハードウェアでFlashまたはLightティアのワークロードを実行している
  • カスタムファインチューニングやモデルの改変が必要(オープンウェイト——Lightティアでのみ可能)

実際の転換点:高ボリュームでは、専用H100をクラウドコスト約$2〜3/時で運用することがDashScopeの1回あたりの料金より安くなります。計算式はGPU使用率によって変わります——GPUが40%の時間アイドル状態だと計算が大きく変わります。

見落としがちなコスト考慮事項

音声/動画の前処理オーバーヘッド

Qwen3.5-Omniに送信する音声は、APIに到達する前に適切なフォーマットである必要があります。qwen-omni-utilsライブラリがリサンプリング、チャンネル正規化、チャンクエンコーディングを処理しますが、その前処理によってレイテンシーと自分側のコンピューティングが増加します。動画については、1FPSサンプリングの720pがドキュメントに記載された参照レートですが、任意の動画フォーマットから実際のフレームを抽出するにはFFmpegまたは同等のツールが必要です。これを1回あたりのレイテンシー予算に組み込んでください。

ストリーミング音声出力と1回あたりのコスト

Thinker-Talkerアーキテクチャはリアルタイムで音声出力をストリーミングします。完全なレスポンスが生成される前に最初の音声バイトが届くため、ライブ音声会話が自然に感じられます。しかしストリーミングには1回あたりのオーバーヘッドが加わります。接続が長く開いたままになり、オーディオコーデック(Code2Wavレンダラー)が出力トークン数に寄与するマルチコードブックシーケンスを生成します。音声出力モードを使用している場合、同じ基本レスポンスに対してテキストのみのモードより有効出力トークン数が多くなります。DashScopeが音声出力トークンをテキスト出力トークンと同じレートで課金するかどうかを確認してください。課金ドキュメントのマルチモーダル価格セクションでモダリティが区別されています。

FAQ

DashScopeにQwen3.5-Omniの無料ティアはありますか?

はい、Internationalリージョン(シンガポールエンドポイント)に限り存在します。新規アカウントにはModel Studio有効化後90日間有効な100万入力トークンと100万出力トークンが無料で付与されます。米国(バージニア)グローバルデプロイメントモードには無料クォータがありません。

DashScope APIのレート制限は?

2026年3月時点でQwen3.5-OmniのQPS数値は公開されていません。アカウント作成時にデフォルト制限が適用されます。本番稼働前に、期待するスループットをDashScopeサポートに連絡してクォータ増加をリクエストしてください。

Qwen3.5-Omni-PlusをシングルA100で実行できますか?

FP8またはINT8量子化であれば可能です。A100 80GBはKVキャッシュのヘッドルームが制限された状態でPlusを実行できます。BF16で256Kコンテキストの場合は不可能です。シングル80GB GPUで安定したスループットを維持するには、max-model-lenを32K〜64K程度に制限することが必要になるでしょう。

前回の記事: