著者: Farruh Kushnazarov
本番環境での LLM 推論向けに、Token API、PTU、Model Unit、およびベアメタル GPU を比較する実践的なチュートリアル。実際の数値と実際のデプロイ事例に基づいています。
急成長中のフィンテックスタートアップでエンジニアリングリードを務める Sarah は、ある火曜日の午後、ラップトップをバタンと閉じました。
彼女のチームは、顧客サポートチャットボットに DeepSeek V4-Flash を統合するために 2 週間を費やしていました。このモデルはテスト段階では見事に機能しました。応答は高速で、推論精度も高く、ハルシネーションの発生率はこれまで試したどのモデルよりも低かったです。デモも完璧に進みました。
しかし、クラウドの請求書を確認した途端、状況は一変しました。
現在のトラフィック（1 日あたり約 800 万トークン）において、Token API のコストは AI 予算を急速に圧迫していました。さらに多くの顧客へ展開していけば、状況は悪化する一方でした。
Sarah の前には 4 つのオプションがありました。しかし厄介なのは、どのブログ記事もベンダー資料も、自社の選択肢こそ最良だと謳っていたことです。「すぐ始められる」Token API、「コストが読みやすい」PTU、「大規模ほど割安な」Model Unit ── さらに主任エンジニアは、GPU をレンタルして自前で運用する案までほのめかしていました。
ここでの問題は、同じモデル、同じワークロード、同じクラウド環境上で、これら 4 つのオプションを実際に相互比較したベンチマークデータが存在しなかったことです。
そこで、私たちは 4 つのオプションを同一条件で実際に検証しました。
本記事ではその結果をもとに、デプロイ手順・ベンチマーク数値・意思決定フレームワークまでを一通り解説します。
実装に入る前に、まず Alibaba Cloud で利用可能な 4 つのデプロイモデルを押さえておきましょう。単なる料金プランの違いではなく、エンジニアリングと経済性が根本から異なります。
注: 表示されているすべての価格は概算であり、公開されている情報源から取得したものです。実際の料金は、リージョン、契約条件、およびプロモーションオファーによって異なる場合があります。
最も基本的な選択肢です。API エンドポイントを呼び出し、プロンプトを送信して完了結果を受け取り、システムを流れるすべてのトークンに対して課金されます。
PTU は、コスト予測のしづらさを解決する Alibaba Cloud のソリューションです。トークンごとに支払うのではなく、分間トークン数（TPM）で測定される保証されたスループットティアを事前に購入します。
ここで核心となるのが、Model Unit です。Model Unit は、Alibaba Cloud によってフルマネージドで提供される、ワークロード専用の GPU クラスターを提供します。
究極の選択肢です。生の GPU インスタンス（H20、H200、または近日提供予定の B300）をレンタルし、独自の推論スタックをデプロイします。
最も簡単なオプションから始めましょう。Alibaba Cloud の AI サービスをこれまで使用したことがない場合は、ここから開始してください。
Alibaba Cloud コンソールにログインし、Model Studio に移動します。これは、すべての Alibaba Cloud AI サービス向けの統合モデルマーケットプレイスおよび API ゲートウェイです。
モデルカタログで DeepSeek V4-Flash を検索します。Qwen3、GLM、Wan などの他の人気モデルと並んでリスト表示されているのが確認できます。
DeepSeek V4-Flash モデルのページにアクセスします。Get API Key ボタンが表示されるので、クリックして新しい API キーを作成し、クリップボードにコピーします。
このキーは安全に保管してください。これはすべての API 呼び出しにおける認証トークンです。
すべてが正常に動作することを確認するための最小限の Python スクリプトを以下に示します。
import requests
API_KEY = "your-api-key-here"
ENDPOINT = "https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions"
headers = {
"Authorization": f"Bearer {API_KEY}",
"Content-Type": "application/json"
}
payload = {
"model": "deepseek-v4-flash",
"messages": [
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Explain quantum computing in one paragraph."}
],
"max_tokens": 256
}
response = requests.post(ENDPOINT, headers=headers, json=payload)
print(response.json()["choices"][0]["message"]["content"])
実行してください。量子コンピューティングについてのまとまった応答が返ってくれば、Token API を介して DeepSeek V4-Flash を正常に呼び出せています。
Token API の料金は、シンプルなトークン単価モデルに従います。入力トークンと出力トークンは別々に課金され、出力トークンの単価は通常、入力トークンの 約 4 倍 です。
2K トークンの入力プロンプトと 1K トークンの出力応答からなる典型的なチャット対話では、リクエストあたりのコストは数セント未満です。使用量が少ない場合（例：1 日あたり 10,000 リクエスト）、月間コストは抑えられます。しかし、コストは線形にスケーリングするため、ここが厄介なところです。
プロトタイピング段階ではこれで問題ありません。しかし、1 日あたり 100,000 リクエストや 100 万リクエストの場合はどうなるでしょうか？
スケーリングのパターンを以下に示します。
| 1 日のリクエスト数 | リクエストあたりの平均トークン数 | 相対的な月間コスト |
|---|---|---|
| 10,000 | 3K | 1x (ベースライン) |
| 50,000 | 3K | ~5x |
| 100,000 | 3K | ~10x |
| 500,000 | 3K | ~50x |
数字は急速に膨れ上がります。Sarah が直面したのも、まさにこの状況でした。
トラフィックがランダムではない場合を考えてみましょう。デイリーアクティブユーザー数が 10,000 人の SaaS プロダクトがあり、使用量が午前 9 時から午後 6 時の間に予測可能なピークを迎えるとします。ピーク時には分あたり約 500,000 トークンが必要であることが分かっています。
PTU はこのような用途のために設計されています。
トークン単価での支払いではなく、特定のスループットを保証する PTU ティアを購入します。Alibaba Cloud はワークロード用に GPU 容量を予約します。ピーク時、リクエストは共有プールをバイパスし、予約容量に直接送られます。
料金モデルには 2 つのコンポーネントがあります。
予約容量を超えた場合、オーバーフローしたリクエストは Token API の価格設定にフォールバックします。
PTU は、1 日あたりのトークンボリュームが十分に大きく、予約料金と割引された使用料の合計が純粋な Token API のコストを下回る場合に、経済的に意味を持ち始めます。損益分岐点は特定のティアや交渉済みのレートによって異なりますが、大まかな目安として次のことが言えます。
Sarah のチームにとって、PTU は Token API からの一歩前進でした。しかし、それでも限界がありました。予約ティアの容量を超えると、コストは再び急騰します。しかも、彼らは次の四半期でユーザーベースを 10 倍に拡大することを計画していました。
Sarah のチームには、コストを暴騰させずにスケールできるソリューションが必要でした。専用リソース、保証されたパフォーマンス、そして利用量が増えるほど安くなる価格モデルが必要です。
彼らが必要としたのは、Model Unit でした。
Model Unit を他の選択肢と決定的に分けるポイントは、固定費用です。
Model Unit あたり、定額の月額料金を支払います。100 万トークンを処理しようが、10 億トークンを処理しようが、コストは同じです。
DeepSeek V4-Flash の場合、典型的な構成では H20-141G GPU 上で 4x MU1 ユニット を使用します。公開されている情報源からの大まかな見積もりに基づくと、以下のようになります。
結論として、持続的な高スループット環境では、Model Unit を利用することで、同等の Token API 支出と比較して40〜50%のコスト削減を実現でき、さらに保証された SLA を備えた専用リソースを利用できます。
注: これらの数値はあくまで参考のための概算です。実際の価格は、リージョン、コミットメント期間、およびボリュームによって異なります。調達決定を行う前に、必ず公式の価格情報を確認してください。
ここで、さらに興味深い数値、つまり 100 万トークンあたりの実効コストを見てみましょう。
4x MU1 の利用率が 100%の場合（ピーク TPM 約 550,000）：
もちろん、24 時間 365 日 100%の利用率で運用することは現実的ではありません。より実践的な観点からこの問題を見てみましょう。ほとんどの本番ワークロードは営業時間中、おそらく 1 日 8〜12 時間程度稼働し、負荷は変動します。
上記のチャートは、異なる日間利用率における 100 万トークンあたりの実効コストを示しています。1 日のアクティブな使用時間が 4 時間の場合でも、実効コストは Token API と比較して依然として競争力があります。1 日の使用時間が 12 時間以上になると、Model Unit は劇的に安価になります。
以下は月間コストの比較です。
Token API に対する損益分岐点は、1 日あたり約26 億トークンです。これ未満の場合は Token API の方が安価ですが、これを超えると Model Unit が決定的に有利になります。
Model Unit の価値は価格だけではなく、専用インフラストラクチャで何を実現できるかにあります。
Sarah のフィンテックアプリケーションにとって、最後のポイントだけでも移行する価値がありました。金融データは共有プールに触れてはなりません。
本格的にデプロイに入る前に、一つ避けて通れない疑問を整理しておきましょう ── GPU をレンタルして全部自前で動かせばいいのでは？
これは妥当な疑問です。そして、一部のチームにとっては、まさにベアメタルが正解になり得ます。
H20 または H200 GPU インスタンスをレンタルします。vLLM または SGLang をインストールします。DeepSeek V4-Flash の重みをダウンロードします。テンソル並列化、パイプライン並列化、量子化、および KV キャッシュの設定を行います。負荷分散、モニタリング、オートスケーリング、フェールオーバーを整備します。
その後、それを維持管理します。
真のコストは GPU レンタル料ではなく、チームにあります。
帳面上、GPU レンタル料が Model Unit よりもわずかに安かったとしても、チームの人件費を含む総コスト（多くの場合、GPU レンタル料自体の 2〜3 倍）により、本番環境の推論においては、ほぼ常に Model Unit の方が経済的に優れた選択肢となります。
ベアメタルが優位な点:
Sarah のチームにとって、ベアメタルは選択肢にありませんでした。GPU クラスターの管理ではなく、新機能のリリースに集中する必要がありました。
それでは実際にデプロイしていきましょう。以下がステップバイステップの手順です。
PAI-EAS（Elastic Algorithm Service (EAS)）は、Alibaba Cloud のマネージドモデルサービングプラットフォームです。Model Unit リソースが実際にプロビジョニングされ、モデルが提供されるエンジンルームだと考えてください。
Model Unit を購入する場合、実際に行っていることは、SLA 保証付きの専用 PAI-EAS 容量を予約することです。Model Unit は商業的なパッケージであり、その下層技術が PAI-EAS です。
デプロイの前に、設定を決定する必要があります。
このチュートリアルでは、シンガポールリージョンの H20-141G GPU 上で4x MU1 ユニットを使用してデプロイします。
PAI コンソールに移動し、左側のメニューからEASを選択します。
サービスの作成をクリックします。デプロイウィザードが表示されます。
サービス名: deepseek-v4-flash-prod
モデルソース: 「カスタムモデル」を選択し、DeepSeek V4-Flash モデルのアーティファクトを指定します。モデルが Alibaba Cloud のモデルレジストリで利用可能な場合は、それを直接選択できます。そうでない場合は、モデルの重みへの OSS パスを指定してください。
リソース設定:
フレームワーク設定:
VPC と vSwitch を設定します。インターネット公開 API の場合は、パブリックエンドポイントを有効にします。内部サービスの場合は、VPC 内のプライベートエンドポイントを使用します。
API キー認証を有効にします。サービス固有の API キーを生成します。
デプロイをクリックします。PAI-EAS が専用の GPU リソースを割り当て、モデルの重みをメモリにロードするため、プロビジョニングプロセスには 5〜10 分かかります。
サービスのステータスが「作成中」→「デプロイ中」→「実行中」と遷移するのを確認できます。
サービスが実行中になったら、エンドポイント URL を控えます。URL は以下のようになります。
https://deepseek-v4-flash-prod.123456.ap-southeast-1.pai-eas.aliyuncs.com
curl リクエストでテストします。
curl -X POST https://deepseek-v4-flash-prod.123456.ap-southeast-1.pai-eas.aliyuncs.com/v1/chat/completions \
-H "Authorization: Bearer YOUR_SERVICE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-v4-flash",
"messages": [
{"role": "user", "content": "専用GPU推論の主な利点は何ですか？"}
],
"max_tokens": 512
}'意味の通った応答が得られた場合、Model Unit デプロイは稼働中であり、トラフィックを処理しています。
PAI-EAS コンソールから直接テストすることもできます。各デプロイされたサービスには、組み込みのプレイグラウンドが含まれており、コードを記述することなく、プロンプトの送信、パラメーター（温度、top-p、最大トークン数）の調整、ストリーミング応答のリアルタイム確認が可能です。
これは、迅速な動作確認、プロンプト挙動のデバッグ、またはアプリケーションへの統合前にステークホルダーへデプロイを実演する場合に役立ちます。
いよいよベンチマーク本番です。同じワークロードを使用して 4 つのデプロイオプションすべてをベンチマークし、結果を比較します。
以下の指標を測定する標準化されたベンチマークスクリプトを使用しました。
テストワークロード：
以下は使用したベンチマークスクリプトです。ご自身のテストに合わせて調整できます。
import asyncio
import time
import statistics
from dataclasses import dataclass
from typing import List
import aiohttp
import numpy as np
@dataclass
class BenchmarkResult:
concurrency: int # 同時実行数
total_requests: int
ttft_ms: List[float]
tpot_ms: List[float]
tps: List[float]
total_tokens: int
duration_sec: float # 持続時間（秒）
@property
def avg_ttft(self) -> float:
return statistics.mean(self.ttft_ms)
@property
def p99_ttft(self) -> float:
return np.percentile(self.ttft_ms, 99)
@property
def avg_tps(self) -> float:
return statistics.mean(self.tps)
@property
def avg_tpot(self) -> float:
return statistics.mean(self.tpot_ms)
@property
def throughput_tpm(self) -> float:
return (self.total_tokens / self.duration_sec) * 60
async def send_request(session, endpoint, api_key, prompt, max_tokens):
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json"
}
payload = {
"model": "deepseek-v4-flash",
"messages": [{"role": "user", "content": prompt}],
"max_tokens": max_tokens,
"stream": True
}
start_time = time.time()
first_token_time = None
token_count = 0
last_token_time = start_time
async with session.post(endpoint, headers=headers, json=payload) as response:
async for line in response.content:
line = line.decode('utf-8').strip()
if line.startswith('data: '):
chunk = line[6:]
if chunk == '[DONE]':
break
# SSEチャンクを解析し、トークンをカウント
token_count += 1
if first_token_time is None:
first_token_time = time.time()
last_token_time = time.time()
end_time = time.time()
ttft = (first_token_time - start_time) * 1000 if first_token_time else 0
generation_time = (last_token_time - first_token_time) if first_token_time else 0
tps = token_count / generation_time if generation_time > 0 else 0
tpot = generation_time / token_count * 1000 if token_count > 0 else 0
return ttft, tpot, tps, token_count
async def run_benchmark(endpoint, api_key, concurrency, duration_sec=300):
# 長いコンテキストのプロンプト（約2048トークン）
prompt = "Explain the history of artificial intelligence..." * 50
max_tokens = 1024
results = []
start_time = time.time()
request_count = 0
async with aiohttp.ClientSession() as session:
while time.time() - start_time < duration_sec:
tasks = [
send_request(session, endpoint, api_key, prompt, max_tokens)
for _ in range(concurrency)
]
batch_results = await asyncio.gather(*tasks, return_exceptions=True)
for r in batch_results:
if isinstance(r, Exception):
continue
ttft, tpot, tps, tokens = r
results.append((ttft, tpot, tps, tokens))
request_count += 1
total_tokens = sum(r[3] for r in results)
return BenchmarkResult(
concurrency=concurrency,
total_requests=request_count,
ttft_ms=[r[0] for r in results],
tpot_ms=[r[1] for r in results],
tps=[r[2] for r in results],
total_tokens=total_tokens,
duration_sec=duration_sec
)
# 異なる同時実行数レベルでベンチマークを実行
async def main():
endpoint = "https://your-endpoint.aliyuncs.com/v1/chat/completions"
api_key = "your-api-key"
for concurrency in [1, 4, 8, 16, 32, 64]:
print(f"\n=== 同時実行数={concurrency} でベンチマーク中 ===")
result = await run_benchmark(endpoint, api_key, concurrency)
print(f"総リクエスト数: {result.total_requests}")
print(f"スループット: {result.throughput_tpm:.0f} TPM")
print(f"平均 TTFT: {result.avg_ttft:.1f}ms")
print(f"P99 TTFT: {result.p99_ttft:.1f}ms")
print(f"平均 TPS: {result.avg_tps:.1f} tok/s")
print(f"平均 TPOT: {result.avg_tpot:.1f}ms")
if __name__ == "__main__":
asyncio.run(main())
注: このスクリプトは、TTFT およびトークンごとのレイテンシを正確に測定するためにストリーミングモードを使用します。非ストリーミングのエンドポイントの場合は、測定ロジックを調整する必要があります。
4 つのデプロイオプションすべてでベンチマークを実行しました。以下がその結果です。
| 同時実行数 | 平均 TTFT | P99 TTFT | 平均 TPS | スループット (TPM) |
|---|---|---|---|---|
| 1 | 245 ms | 890 ms | 42.3 | 2,540 |
| 4 | 312 ms | 1,240 ms | 38.7 | 9,280 |
| 8 | 485 ms | 2,100 ms | 31.2 | 14,960 |
| 16 | 920 ms | 4,500 ms | 18.5 | 17,760 |
| 32 | 1,850 ms | 8,200 ms | 9.8 | 18,816 |
観察事項: 同時実行数が少ない場合、Token API は比較的高速です。しかし、同時実行数が増加すると、レイテンシが大幅に悪化します。共有プールでは、キューイングなしで高いスループットを維持できません。スループットは約 18K TPM で頭打ちになります。
| 同時実行数 | 平均 TTFT | P99 TTFT | 平均 TPS | スループット (TPM) |
|---|---|---|---|---|
| 1 | 180 ms | 420 ms | 48.5 | 2,910 |
| 4 | 195 ms | 380 ms | 46.2 | 11,090 |
| 8 | 210 ms | 450 ms | 44.8 | 21,500 |
| 16 | 245 ms | 520 ms | 41.3 | 39,600 |
| 32 | 310 ms | 680 ms | 36.7 | 70,300 |
観察事項: PTU は、レイテンシの一貫性において大幅に優れた性能を発揮します。保証された容量により、予期しないキューイングが発生しません。スループットは、予約されたティアの制限まで線形にスケールします。P99 TTFT は、32 の同時リクエスト時でも 700ms 未満に抑えられています。
| 同時実行数 | 平均 TTFT | P99 TTFT | 平均 TPS | スループット (TPM) |
|---|---|---|---|---|
| 1 | 95 ms | 180 ms | 95.2 | 5,710 |
| 4 | 102 ms | 195 ms | 94.8 | 22,750 |
| 8 | 118 ms | 225 ms | 93.5 | 44,880 |
| 16 | 145 ms | 280 ms | 91.2 | 87,550 |
| 32 | 195 ms | 380 ms | 87.6 | 168,200 |
| 64 | 310 ms | 620 ms | 79.3 | 304,100 |
観察事項: Model Unit はすべてのメトリックで優位性を示しています。高い同時実行性において、TTFT（Time to First Token）は Token API の 3 倍高速です。TPS（Tokens Per Second）は高負荷下でも安定しています。ピークのスループットである 304K TPM は、Token API が配信できる量の 16 倍です。なお、この結果はベストエフォートではなく、SLA 保証付きの環境で得られたものです。
| 同時実行数 | 平均 TTFT | P99 TTFT | 平均 TPS | スループット (TPM) |
|---|---|---|---|---|
| 1 | 85 ms | 160 ms | 105.0 | 6,300 |
| 4 | 92 ms | 175 ms | 102.5 | 24,600 |
| 8 | 105 ms | 200 ms | 98.3 | 47,200 |
| 16 | 130 ms | 250 ms | 92.1 | 88,300 |
| 32 | 180 ms | 340 ms | 82.5 | 158,400 |
観察事項: ベアメタルは、GPU への直接アクセスとカスタムチューニングのおかげで、低い同時実行数では Model Unit をわずかに上回ります。しかし、その差は微々たるものです（10〜15%）。一方、運用上のオーバーヘッドは非常に大きいです。
| デプロイ | 月額コスト* | ピーク TPM | 平均レイテンシ (P50) | 100 万トークンあたりの相対コスト |
|---|---|---|---|---|
| Token API | 可変（線形にスケール） | ~19K | 1,850ms | 1x（ベースライン） |
| PTU | Model Unit の約 1.5 倍 | ~70K | 310ms | Token API の約 2 倍 |
| Model Unit (4x MU1) | 固定（中程度） | ~304K | 195ms | Token API の約 0.3 倍 |
| ベアメタル (8x H200) | Model Unit と同様 | ~158K | 180ms | Token API の約 0.3 倍 |
*1 日あたり 5 億トークンの持続的なロードを想定。ベアメタルのチームコストは除外。すべてのコストは公開ソースからの推定値です。
主な知見: Model Unit は、Token API の 16 倍のスループットを、トークンあたりのコストが 3 分の 1 で実現し、レイテンシは桁違いに優れています。単に安いだけでなく、本番規模において測定可能なあらゆる側面で優れています。
同じベンチマークで 4 つのオプションすべてを実行した後、最初からこの形で示してほしかった意思決定ツリーです。
Sarah のフィンテックスタートアップの話に戻りましょう。
ベンチマーク結果を見た後、彼女の決断は明確でした。
Token API はプロトタイプには最適でしたが、予測される規模では Model Unit と比較して月額コストが約 2 倍 高くなっていました。PTU（Provisioned Throughput Unit）は Token API コストの 60〜70% 程度という妥当な中間選択肢でしたが、四半期以内に予約済みティアの容量を超えてしまう見込みでした。ベアメタルサーバーは選択肢から外れました。彼女のチームはエンジニア合計 12 名で、誰も GPU クラスターの深夜 3 時のオンコール対応を望んでいなかったからです。
彼らは Model Unit を選択しました。PAI-EAS にデプロイされた 4 つの MU1 ユニット上で、ドメイン固有のカスタムファインチューニング済みチェックポイントを用いた DeepSeek V4-Flash を実行しています。
本番環境での 1 か月間の運用結果は以下の通りです。
ここから得られる教訓は：表示価格だけでなく、チームのオーバーヘッド、機会費用、負荷時のパフォーマンス劣化リスクを含む総合的なコストで判断すべきだ、ということです。すべてを合計すると、Model Unit は大規模運用時に最も安価なオプションであるだけでなく、パフォーマンス、予測可能性、そして安心感を同時に提供できる唯一のオプションなのです。
ここから始めるために必要なリソースをまとめました。
このベンチマークは、制御された環境において合成ワークロードを使用して実施されました。実際の結果は、以下の要因によって異なります。
記載されている料金は、執筆時点で公開されている情報源に基づく見積もりです。数量割引、地域による変動、およびプロモーションレートが適用される場合があります。契約前に、必ず Alibaba Cloud のアカウントマネージャーに正確な見積もりをご確認ください。
Alibaba Cloud での DeepSeek V4-Flash のデプロイについてご質問がありますか？ AI Infra SA チームは毎週評価セッションを実施しています。上記の MU リクエストフォームからお問い合わせください。
この記事は元々英語で書かれました。元の記事は こちら でご確認ください。
138 posts | 4 followers
FollowAlibaba Cloud Native Community - February 26, 2025
Regional Content Hub - July 7, 2025
Regional Content Hub - February 26, 2024
Regional Content Hub - August 5, 2024
Regional Content Hub - May 7, 2025
Regional Content Hub - July 8, 2024
138 posts | 4 followers
Follow
Qwen
Full-range, open-source, multimodal, and multi-functional
Learn More
Alibaba Cloud Model Studio
A one-stop generative AI platform to build intelligent applications that understand your business, based on Qwen model series such as Qwen-Max and other popular models
Learn More
Alibaba Cloud for Generative AI
Accelerate innovation with generative AI to create new business success
Learn More
AgentBay
Multimodal cloud-based operating environment and expert agent platform, supporting automation and remote control across browsers, desktops, mobile devices, and code.
Learn MoreMore Posts by Regional Content Hub