Qwen API は Alibaba Cloud Model Studio（中国語名：Bailian）が提供する Qwen モデルの呼び出しインターフェースです。開発者がよく使う DashScope は、このサービスの API/SDK 層の名称です。名前は 3 層ありますが、請求の論理は 1 つだけです。実際の利用量に応じて課金し、入力と出力を分けて計算します。

本記事では単価を固定で書きません。モデルのバージョン、コンテキストの段階、キャンペーンが変わるためです。どこにお金がかかるのか、長いコンテキストがなぜ予算を超えやすいのか、キャッシュと Batch をどう使うのか、実際のログで月次見積もりをどう作るのかを説明します。現在の価格はモデル料金および Alibaba Cloud Model Studio の公式価格ページを基準にしてください。

注記：Qwen、Alibaba Cloud、Model Studio、DashScope などの名称は各権利者の商標です。本記事は技術的な説明のみを目的としており、Alibaba Cloud と資本関係、代理関係、提携関係はありません。課金ルールと価格は変更される場合があるため、契約前に公式ドキュメントをご確認ください。

一、まず名前を整理する：Bailian、Model Studio、DashScope

3 つの名前はよく混同されますが、指す層は同じではありません。

  • Bailian：中国語のコンソールと製品名。モデルの有効化、API キー、利用量、請求はここで管理します。
  • Alibaba Cloud Model Studio：国際版で使われる英語の製品名。機能は Bailian に対応しますが、リージョンや請求通貨が異なる場合があります。
  • DashScope：API と SDK 層の名称。Base URL、環境変数 DASHSCOPE_API_KEY、旧版ドキュメントでよく見られます。

呼び出し時に確認すべきは 3 点です。リージョン（北京、シンガポールなど）、Base URL、モデル ID。この 3 つが一致しない場合、最もよくあるエラーは残高不足ではなく、認証失敗またはモデルが存在しないというものです。

二、モデルの階層がコストの上限を決める

Qwen のテキストモデルは通常 3 つの階層に分かれ、2026 年時点の代表例は Qwen-Max、Qwen-Plus、Qwen-Flash です。

階層 代表モデル ID 位置づけ 適したタスク コストの目安
Max qwen3.8-max 複雑な推論と多段タスク コード、Agent、深い分析 高
Plus qwen3.7-plus 能力、速度、コストのバランス カスタマーサポート、文章作成、文書処理 中
Flash qwen3.8-flash 低遅延、低コスト 分類、抽出、書き換え、ルーティング 低

モデル ID は更新されます。調達時に名前を固定しすぎないでください。より安全な方法は「タスク種別」と「階層」を結びつけることです。単純なタスクは既定で Flash、日常的なタスクは Plus、多段推論が本当に必要な場合だけ Max に上げます。サイト全体を Max にしても効果が必ず上がるとは限りませんが、請求額は確実に厚くなります。

三、課金単位：入力、出力、マルチモーダル

テキストモデルは入力トークンと出力トークンを別々に課金し、公式価格表は通常「元/100 万トークン」で表示されます。1 回のリクエストの費用は次のように書けます。

1 回のコスト =
  キャッシュ未ヒットの入力トークン × 入力単価
+ キャッシュヒットしたトークン × キャッシュヒット単価
+ 出力トークン × 出力単価

マルチモーダルは別に見てください。画像生成は成功した出力枚数、音声は音声時間、Omni と Realtime モデルはテキスト、画像、音声などのモダリティごとに価格が設定されることが多いです。これらの費用をテキストの予算に混ぜると、月末に必ず帳尻が合わなくなります。

また、Qwen-MT-Uni のような翻訳モデルは入力トークンのみで課金されます。一部のモデルは思考モードで、出力トークンの課金基準が通常の回答と異なります。特定のモデルについては、まず価格表の「課金項目」列を確認し、他のモデルの価格を流用しないでください。

四、長いコンテキスト：段階はリクエスト全体に適用される

これは Qwen の課金で最も見落とされやすい点です。公式価格表は 1 回のリクエストの入力トークン総量で段階を分けます。一般的な段階は次のとおりです。

  • 0 < Token ≤ 32K
  • 32K < Token ≤ 128K
  • 128K < Token ≤ 256K
  • 256K < Token ≤ 1M

重要なのは「リクエスト全体に適用される」という点です。リクエストがどの段階に入るかによって、そのリクエストのすべてのトークン（出力を含む）がその段階の単価で精算されます。最初の 32K が低価格で、超過分だけが高価格になる累積方式ではありません。つまり、入力が 31K から 33K に増えると、追加の 2K 分だけではなく、リクエスト全体が別の価格段階に移る可能性があります。

そのため長いコンテキストはここぞという場面で使います。契約書、論文、コードベースを扱うときは、まず 3 つ問いかけてください。本当に全部を一度に入れる必要があるか。先に検索してから結合できないか。分割して処理し、後でまとめられないか。多くのタスクは「検索 + 要約」で完了し、コストは全体を直接詰め込むよりはるかに低くなります。どうしても長いコンテキストが必要な場合は、該当する段階に対応するモデルを選び、実際のリクエストで 1 回請求を確認してください。

五、キャッシュと Batch：節約できるが併用はできない

コンテキストキャッシュは入力トークンだけを割引します。明示的キャッシュと暗黙的キャッシュがあります。明示的キャッシュは手動でキャッシュポイントを作成し、作成自体が標準入力より高い価格で課金され、ヒット後に割引価格が適用される場合があります。暗黙的キャッシュはプラットフォームが重複する接頭辞を自動的に識別し、一部のモデルでは既定で有効です。具体的な比率はモデルによって異なるため、必ずキャッシュのドキュメントとモデル料金を確認してください。

Batch はオフラインタスクに向いています。対応モデルで Batch を使うと、入力と出力の単価は通常のリアルタイム推論より低く設定されます。代わりに遅延が大きくなり、タスク編成が必要です。注意点として、キャッシュ割引と Batch 割引は通常同時に適用されません。同じ予算モデルに両方を重ねないでください。

キャッシュがヒットするかどうかは、接頭辞が安定しているかで決まります。システムプロンプト、ツール定義、ナレッジベースの断片の順序が毎回変わると、ヒット率は低くなります。安定した内容を前に、変化する内容を後ろに置くのが最も基本的な最適化です。

六、再試行、失敗、隠れたコスト

公式の課金ページには、リクエスト失敗時は課金されないと記載されています。ただし「失敗」とはサーバーが明確に失敗を返した場合を指し、クライアントがタイムアウト後に新たに送信したリクエストは含みません。タイムアウト後の再送、ユーザーの連打、キューの重複処理は、いずれも新たな課金対象リクエストになります。

レート制限と 5xx の再試行は控えめにしてください。再試行可能なエラーだけを対象にし、指数バックオフを使い、最大回数を設定し、リクエスト ID で冪等化します。ストリーミング接続が中断した場合、生成済み部分が課金されるかは請求書と公式説明を基準にしてください。「失敗は無料」を無制限の再試行の理由にしないでください。

もう 1 つ見落とされがちなコストは、呼び出し料金を節約するために投じる人的コストです。ログ、監視、評価、人手による確認はすべてコストです。コスト削減は総コストで判断し、単価だけで判断しないでください。

七、実際のログで月次予算を見積もる

予算を感覚で決めないでください。次の順序で進めます。

  1. ゲートウェイまたは Bailian の請求書から直近 7 日間のリクエストログをエクスポートする。モデル ID、入力トークン、出力トークン、キャッシュヒットの有無、Batch の有無を最低限含める。
  2. モデルとコンテキストの段階でグループ化し、グループごとのリクエスト数と平均トークンを計算する。
  3. 現在の価格ページの単価を式に当てはめる。長いコンテキストはリクエスト全体の段階で計算する点に注意する。
  4. 30 日分に換算し、再試行と変動の余裕として 10%〜20% を加える。
  5. 毎月 1 回見直し、モデルのアップグレードやプロンプト改版後に再見積もりする。

チームが複数社のモデルを同時に呼び出す場合は、ZSQH AI Gateway に登録すると残高と利用量をまとめて確認できます。具体的な単価はモデル料金ページを基準にしてください。

八、コスト削減の順序

投資対効果の順に並べると、通常は次のようになります。

  1. まず数値化する：リクエスト単位のログがなければ、すべての最適化は推測にすぎません。
  2. 適切な階層を選ぶ：単純なタスクは Flash に下げ、分類に Max を使わない。
  3. 入力を圧縮する：検索、要約、履歴の削減は、モデル変更より効果的です。
  4. 出力を制限する：max_tokens を設定し、構造化出力を求める。
  5. 接頭辞を安定させる：キャッシュヒット率を上げる。ただしキャッシュ作成コストを先に確認する。
  6. オフラインは Batch を使う：ラベリング、要約、クリーニングなど急がないタスクは Batch を使う。
  7. 再試行を制御する：バックオフ、冪等化、重複排除。1 回の障害を 2 倍の請求にしない。
  8. 予算アラートを設定する：プロジェクト、キー、モデルごとにしきい値を設定する。

九、よくある質問

Qwen API、Bailian、DashScope の関係は？

Bailian は Alibaba Cloud の大規模モデルサービスプラットフォーム、Model Studio はその国際版の名称、DashScope は API/SDK 層の名称です。日常的に「Qwen API を呼ぶ」と言う場合、通常は Bailian の DashScope 互換インターフェースまたは OpenAI 互換インターフェース経由でモデルを呼ぶことを指します。

長いコンテキストでリクエスト全体が高くなるのはなぜ？

価格段階が 1 回のリクエストの入力トークン総量で決まり、上位の段階に入ると、そのリクエストの入力と出力の全体がその段階の単価で精算されるためです。超過分だけが値上げされるわけではありません。33K の入力を 2 回の 16K リクエストに分けると、1 回の 33K より安くなる場合がありますが、分割で効果が落ちないことを先に確認してください。

キャッシュと Batch は同時に使えますか？

通常は併用できません。公式価格ページでは二者択一と説明されています。オフラインタスクは Batch、オンラインで高頻度かつ接頭辞が安定しているタスクはキャッシュを優先してください。

失敗したリクエストは課金されますか？

公式説明ではリクエスト失敗時は課金されません。ただしクライアントのタイムアウト後の再送、重複送信、ストリーム中断後の再開は、新たな課金対象リクエストを生む可能性があります。リクエスト ID と冪等キーで「再試行」と「新規リクエスト」を区別してください。

管理画面の請求書とローカルの見積もりが合わないのはなぜ？

よくある原因は 4 つです。コンテキストの段階を計算していない、キャッシュ作成費用を計算していない、Batch とキャッシュを重ねている、再試行リクエストを計上していない。usage フィールドとリクエスト ID で照合すれば、通常は差異を特定のリクエストまで追跡できます。

次のステップ

まず直近 1 週間の実際の利用量をエクスポートし、モデルと段階でグループ化してから現在の価格を当てはめてください。人民元でのチャージや複数モデルの利用量の一元管理が必要な場合は、ZSQH AI Gateway に登録してください。具体的な価格はモデル料金を基準にします。

関連記事：