GLM-5 vs DeepSeek V3 vs GPT-5：開発者向け速度・コスト比較
開発者向けGLM-5・DeepSeek V3・GPT-5の比較：推論速度、トークンあたりのコスト、推論品質、最適なユースケースを解説。
こんにちは、Doraです。きっかけは些細なことでした。5分で終わるはずの要約タスクが15分もかかってしまったのです。最初のレスポンスが開始直後にフリーズしたせいで。モデルだけのせいではありません——トークンストリーミング、サーバー負荷、そういった要因もあります。でもそれは「精度」だけが作業日程を狂わせる要因ではないことを改めて思い知らせてくれました。
そこで、私がずっと気になっていた問いに向き合うことにしました。現実の世界で、GLM-5、DeepSeek、GPT-5は実際どのように使えるのか？グラフの上ではなく、レスポンス時間、予想外の費用が出ないコスト、そして複数のタスクが絡み合うときの信頼性という観点で。これは、冷静に、そして「あなたのスタック、地域、エッジケースへの許容度によって状況は変わる」という注意書き付きで、それを書き留めようとする試みです。
地に足の着いた内容にします。GLM-5 vs DeepSeek vs GPT-5——誇大広告とよくあるベンチマークのスクリーンショットを超えて。
ベンチマークスコアを超えて何を比較すべきか
ベンチマークは健全性チェックであり、目的地ではありません。私が注目する実行は、派手なものではありません。
- 重要な場面でのレイテンシ：最初のトークンが届くまでの時間（TTFT）と安定したスループット。「考える時間が長い」モデルは問題ではありません。開始前にアイドル状態が続くモデルこそが問題です。
- 作業の形に合ったコスト：100万トークンあたりの単価は出発点ですが、コンテキストウィンドウの無駄遣い、リトライ、ツール呼び出しが実際の費用を2倍にすることがあります。
- 障害モード：プロンプトが少しずれているとき、ツールがタイムアウトしたとき、入力が通常より長いときのモデルの振る舞い。
- 制御の余地：実際にバリエーションを動かせる温度設定、維持されるシステムプロンプト、スキーマの端でぶれない関数呼び出し。
- 負荷下での劣化：1分間に3回目の実行、またはバッチ内100番目のジョブ。
GLM-5、DeepSeek、GPT-5を通じて、私が求めたのは「静かな有能さ」——間違った意味で驚かせないモデルです。また、それぞれがどこで曲がるかについてもメモを取りました。マーケティングの約束より、既知の曲がりの方が設計しやすいからです。
推論速度（TTFT + スループット）
私が注目する瞬間は2つあります。最初のトークンが現れるときと、その後がどれだけ速く続くかです。
- TTFT：モデルが応答を始めるか、じっと待たせるかを教えてくれます。インタラクティブなツール（下書き、サポートチャット）では、速いTTFTは親切さのように感じられます。
- スループット：始まったら、長い出力を途切れなく安定したペースで続けられるか？
実際に観察したこと（2026年2月、US/EUエンドポイント混在）：
- GLM-5：短いプロンプトでは一貫して速いTTFT。長いコンテキスト（約30〜40kトークン超）では少し遅く始まりますが、安定してストリームします。下書きやコード編集での「ドラマなし」な感覚が良好。生の数値や並列レイテンシデータが必要な方には、このGLM-5推論速度ベンチマーク解説が参考になりました。
- DeepSeek（特にR1/V3バリアント）：軽いバッチ負荷下でも驚くほど速いTTFT。非常に長い生成時にストリーム途中で小さなマイクロポーズが発生することがありますが、回復はスムーズです。
- GPT-5：一部のエンドポイントでは予想より遅い始まりですが、非常に安定したストリーミングで取り返します。ツール呼び出しが絡む場合、ハンドオフのオーバーヘッドが低く、マルチステップフローに助かります。
繰り返し自分に言い聞かせる注意点：リージョンとゲートウェイは、生のモデル性能と同じくらい重要です。アグリゲーター経由でルーティングしているなら、ストリーミングをオンにして、探索的な実行ではmax_tokensを下げてみてください。品質を変えずに無駄な待ち時間を削れます。
100万トークンあたりのコスト
表示価格は出発点であり、最終的な請求金額ではありません。3つのレバーが、予想以上に実際のコストを変えました。
- コンテキストの無駄遣い：同じシステムプリアンブルとツールスキーマを毎回送り続けると積み重なります。キャッシュまたはスキーマのトリミングはすぐに効果が出ました。
- リトライポリシー：レート制限時の積極的なリトライが、忙しい時間帯に費用を静かに2倍にすることがあります。
- 出力長の規律：max_tokensを適切な上限に設定し（関数呼び出し時にモデルが止まれるようにする）、これはどんな割引コードよりも効果がありました。
今月時点では：
- DeepSeekは特に推論バリアントで積極的な価格設定を推し進めています。スタイルの変動を許容できるなら、バッチワークフローに優しいです。
- GLM-5は実用的な中間点に位置します。最安ではありませんが、予測可能であり、財務が予測を求めるときに予測可能性には価値があります。
- GPT-5の価格設定は公式にはまだ流動的です。実際には、GPT-4.1/4oの価格帯を下限として予算を組み、GPT-5の推論ティア分のヘッドルームを追加しました。今日確実な上限が必要なら、これが最もプレッシャーテストが必要なモデルです。
比較するなら、「有用な出力あたりの実効コスト」を測定してください。トークン数ではなく。修正回数を半分に減らす1.2倍高価なモデルの方が、私の基準では勝ちです。
推論とコーディングの品質
私はリーダーボードを動かしたのではありません。実際に行う作業を動かしました：構造化されたライティング、小さなコードユーティリティ、マルチツールエージェントフロー。2つの角度が最も重要でした。
単一タスクの精度
焦点を絞ったタスク（例：「このJSONを型付きインターフェースに変換して」「アクションアイテム付きでこの会議メモを要約して」）では、GPT-5が最もまとまっている印象でした。狭いフォーマットに従うための調整が少なく、関数呼び出しがスキーマ内により確実に収まっていました。
DeepSeekは、展開できる推論ステップで良いパフォーマンスを発揮しました。少し過剰に説明しがちな傾向に気づきましたが、下書きには良く、max_tokensを制限して簡潔さを指定しない限り、厳密な出力には不向きです。
GLM-5は穏やかな中間点に着地しました：華飾が少なく、安定したコンプライアンス、diffが小さい場合は堅実なコード編集。曖昧なプロンプトでのコールドスタートでは、私が望む以上に安全策を取ることがありましたが、より厳密なシステムプロンプトで解決しました。
マルチステップエージェントの信頼性
ツールが登場すると——検索、スクレイピング、データベース読み込み——問いは「答えは良いか？」から「ループは生き残るか？」に変わります。
- GPT-5：短いチェーンの計画と、ツールがタイムアウトした際の回復が得意。不足しているフィールドを推測するのではなく再確認しました。小さなことですが、大きな精神的安定をもたらします。
- DeepSeek：コンパクトで効率的なチェーン。2つのツールの機能が重複していた場合、自信を持って間違った方向に進むことが時々ありました。システムプロンプトに明示的なツール選択ルールを追加することで改善しました。
- GLM-5：スキーマが明確に定義されていれば非常に安定していました。ツールが予期しない形状を返した場合、慎重に行動して確認を求めました。私はそれをサイレントハルシネーションより好みます。
最初はこれで時間が節約されませんでした——実際、ガードレールの配線に余分な午後がかかりました。しかし数回実行した後、精神的な労力が減っていることに気づきました。謎の失敗が減り、「なぜこうなったのか？」という瞬間も減りました。
ワークロードタイプ別の最適モデル
これは王座決定式ではありません。マッチング演習です。私の週の中でそれぞれがどこに最も合ったかを紹介します。
リアルタイムアプリ → ？
画面の向こうで人が待っている場合、速いTTFTと予測可能なスタイルを重視します。
- 軽いチャット、下書き、サポートのサイドバー：GLM-5またはDeepSeek。どちらも俊敏な感覚があります。DeepSeekは最初のトークンまでがわずかに速く、GLM-5はセッション間でトーンが一貫する傾向があります。
- ツールが多いアシスタント：GPT-5。計画とスキーマの安定性がエッジケースの停止を減らします。予算が厳しい場合は、DeepSeekでプロトタイプを作り、最も重要なエンドポイントにGPT-5を使いましょう。
バッチ処理 → ？
大規模なオフラインジョブ（数百〜数千のアイテム）では：
- 小さなスタイルのばらつきを許容できるなら、DeepSeekがコスト効率で勝ります。厳密な出力スキーマとdiffチェックを追加してください。
- 外れ値を少なくしたい場合、均一性のために少し多く払っても良い場合は、GLM-5が安定したデフォルトです。
- GPT-5は、タスクが深い推論やアイテムごとのマルチホップ検索を本当に必要としない限りオーバースペックです。必要な場合は、再実行率が十分に下がって正当化されます。
マルチモーダルパイプライン → ？
画像＋テキストや音声＋テキストのフローでは、パンフレットよりグルーの方が重要です。
- GPT-5：私のテストでは、モダリティとツール間のハンドオフが最もスムーズでした。パイプラインが抽出、推論、生成を行き来する場合、このスムーズさが報われます。
- DeepSeek：速くて有能。OCR＋要約やキャプション＋タグでは、レイテンシを低く保ちました。
- GLM-5：構造化された画像テキスト変換タスクで信頼性が高い。一貫性が華麗さより重要な場合（請求書解析や製品データのクリーンアップなど）、最初に手を伸ばしたのはこれでした。
設計上の注意：中間結果をログにストリームしてください。出荷前にモダリティの不一致を捕捉する最も簡単な方法です。
WaveSpeedの価格設定は3つのモデルをどう比較するか
私はWaveSpeedを価格の健全性チェックレイヤーとして試しました——魔法の解決策ではなく、支出を冷静に考える方法として。
際立っていたのは魔法の割引ではありませんでした。それはメカニズムでした：
- スティッキールーティング：計画が必要なエンドポイントにGPT-5を固定し、単純な要約をDeepSeekに送り、構造化された編集にGLM-5を維持する。1つの請求書、少ない驚き。
- コンテキストキャッシング：システムプロンプトとツールスキーマが毎回再送信されませんでした。私の実行では、平均して入力トークンが3分の1削減されました。派手ではありませんが、積み重なる種類の節約です。
- エッジでのガードレール：モデルがスキーマから逸脱した場合、WaveSpeedは早期に検知して同じプロバイダーでリトライしました。ジョブの途中でプロバイダーのルーレットなし。
価格比較はシンプルです：
- すでに2つ以上のプロバイダーを使い分けている場合、WaveSpeedのルーティングとキャッシングは、表示価格が変わらなくても「有用な出力あたりの実効コスト」を下げることができます。
- 1つのモデルしか使わず、プロンプトがほとんど変わらない場合、大きなメリットは見えないかもしれません。その場合、直接APIの価格設定と自前のキャッシングで十分です。
WaveSpeedを安いトークンを得る方法だとは思っていません。トークンの無駄を減らす方法だと考えています。
同様の制約に直面しているなら、一度試してみる価値はあります。そして1つのプロバイダーで満足しているなら、それも全然構いません——最も静かなスタックが最善の場合もあります。
