LLM推論ベンチマーク：DigitalOceanで6モデル比較した結果、最安かつ最速だったのはなぜか

はじめに：LLM選定における「安さ」の再定義と本記事の目的

LLMをプロダクトに組み込む際、多くの技術責任者が最初に注目するのは「月額固定費」である。しかし、推論APIはPay-as-you-goの課金構造を持つため、実際の運用コストは固定費ではなく、1リクエストあたりのトークン単価と呼び出し頻度によって決まる。つまり「安さ」の定義を、契約時の月額ではなく、1回の推論がどれだけコストを発生させるかという視点に切り替える必要がある。

さらに、単一のモデルに依存する設計には構造的なリスクがある。モデルのレイテンシが突発的に増大した場合、あるいはエラー率が高まった場合、フォールバック先がなければユーザー体験が直接毀損される。複数モデルを並列で比較し、ユースケースごとの適性を把握しておくことが、可用性の確保とコスト最適化の両立に繋がる。

本記事では、DigitalOcean Inference上で6モデルを並列ベンチマークした結果を基に、コストと速度のトレードオフを実務的な視点から分析する。具体的には、TTFT（Time To First Token）とトークン消費のメカニズムに焦点を当て、モデル選定の判断基準を提示する。読者は、自社のユースケースに応じたモデル選定基準と、予期せぬコスト増（空レスポンスなど）を防ぐための設計指針を得られる。

前提：DigitalOcean Inferenceのアーキテクチャと利用環境

OpenAI互換APIと認証の仕組み

DigitalOcean InferenceのエンドポイントはOpenAI互換のAPIインターフェースを提供しており、既存のOpenAI SDKやクライアントライブラリをほぼそのまま流用できる。具体的には、base_urlを適切なエンドポイントURLに設定するだけで、chat.completions.create()などの呼び出しが動作する可能性がある。この互換性の高さは、既存コードベースへの影響を最小限に抑えられることを意味し、マルチベンダー戦略を構築する際の障壁を大きく下げる。

ただし、認証には通常のプロバイダーAPIキーとは異なる管理手法が求められる場合がある。DigitalOcean Inferenceでは、Gradient AI Platform経由で発行されたModel Access Keyを用いることがある。これは一般的なクラウドプロバイダーのAPIキーとは管理の単位が異なり、キーの発行・ローテーション・スコープの制御がGradient AI Platformのコンソール上で行われる。セキュリティレビューやCI/CDパイプラインのシークレット管理を設計する際、この差異を踏まえた対応が必要になる。

ベンチマークのテスト条件と環境

本記事のベンチマークは、DigitalOceanのNYCリージョンの推論エンドポイントに対して、ヨーロッパに所在するラップトップから実行された。この環境設定には重要な意味がある。クライアントと推論ノードの間に長距離ネットワークが介在するため、観測されたレイテンシには往復遅延（RTT）が含まれる。プロダクション環境で同様の地理的条件を持つ場合（例：EUのユーザーがUSリージョンのモデルを呼び出す）、本結果は実態に近い数値を示す一方、同リージョン内での呼び出しであればさらに低いレイテンシが期待できる。

テスト条件としてmax_tokens=512を固定した。これは標準的なチャットボット応答や短文要約タスクに近い負荷であり、実務で最も頻出するユースケースを想定した設定である。より長い出力を必要とするタスクでは、総時間やコストの絶対値は変化するが、モデル間の相対的な差の傾向は維持される可能性が高い。

sequenceDiagram
    participant C as クライアント
    participant G as Gradient AI Platform
    participant D as DigitalOcean Inference
    C->>G: Model Access Keyの発行依頼
    G-->>C: Keyを返却
    C->>D: POST /v1/chat/completions (Authorization: Bearer Key)
    D->>D: 認証確認・モデル割当
    D-->>C: ストリーミング応答（SSE）

ベンチマーク結果：Mistral 14Bが全指標で最速・最安となった理由

全指標で最速・最安となったMistral 14B

6モデルの並列比較において、Mistral 14BはTTFT 533ms、総時間3.3秒、推論コスト$0.000108という結果で、すべての指標において最速かつ最安となった。この結果は、パラメータ規模が推論効率と出力品質のバランス点に位置していることを示唆する。14Bという規模は、現代の推論インフラにおいてメモリ帯域幅と計算資源の制約の中で、1トークンあたりの処理時間を最小化しやすい領域にあると考えられる。

特に注目すべきはTTFTの差である。最速の533msに対し、最も遅いモデルでは9.3秒を記録しており、差は最大で17倍に及ぶ。ユーザーが「応答が始まるまで待たされる時間」は、総生成時間よりも体感的な待ち時間に直結する。対話型UIでは、この差がユーザーの離脱率や再試行率に影響を与えるため、コスト以上の重みを持つ決定要因となりうる。

比較データとコストの現実性

以下に、最速・最安のMistral 14Bと、最も高価・遅いQwen3.5-397b-a17bの結果を対比する。中間の4モデルは、TTFT 533ms〜9.3秒、総時間3.3秒〜32秒の範囲に分布している。

モデル	TTFT	総時間	推論コスト
Mistral 14B	533ms	3.3秒	$0.000108
中間4モデル	533ms〜9.3秒	3.3秒〜32秒	—
Qwen3.5-397b-a17b	9.3秒	32秒	約$0.001

6モデルの並列比較を1回実行した際の総コストは$0.0185であった。この金額は、小規模チームが数日間にわたってモデル評価を行うのに十分な予算内で収まるレベルであり、ベンチマーク自体が「高コストな検証プロセス」であるという心理的障壁を排除している。コストの低さは、頻繁な再テストやA/B比較を可能にし、モデル選定の判断根拠を厚くする効果がある。

落とし穴：高価かつ不安定なQwen3.5-397b-a17bの事例分析

Qwen3.5-397b-a17bは、6モデル中最も高価（約$0.001/リクエスト）かつ最も遅い（総時間32秒）という結果だった。しかし、コストや速度の問題よりも深刻だったのは、9回のテスト中7回で空のレスポンスを返したという可用性の欠如である。単に「遅い・高い」だけでは、コスト増の範囲が予測可能だが、空レスポンスは「コストを支払ったのに成果がゼロ」という最も悪いケースに該当する。

空レスポンスのメカニズム

この空レスポンスの原因は、モデルの推論トークン（reasoning tokens）の消費にある。Qwen3.5-397b-a17bは、実際の回答を生成する前に内部で推論を行い、その過程で487個のトークンを消費した。テスト条件のmax_tokens=512に対して、推論だけで487個を使ってしまうと、出力用の残りトークンはわずか25個しか残らない。この残りでは意味のある回答を生成できず、出力が空のまま返された。

ここで重要なのは、このメカニズムがモデルの「バグ」ではなく、設計上のトレードオフとして内包されている点である。推論型モデルは、内部で多段階の推論を行うことで複雑な問題に対する精度を向上させる。しかし、その推論コストがmax_tokensの上限に達すると、出力が犠牲になる。max_tokensを大きくすれば回避できるが、それによりコストも比例して増大する。つまり、推論型モデルの利用には「推論に割り当てるトークン」と「出力に割り当てるトークン」の予算配分を設計する必要がある。

空レスポンスでも課金される問題

最も実務的に深刻な問題は、空レスポンスが返されたリクエストにも課金が行われた点である。約$0.001のリクエストコストが、7回中7回とも「何も得られない」状態で消費された計算になる。期待される有効レスポンス率（このベンチマークでは2/9 ≒ 22%）を考慮した実効コストは、単純な単価の約4.5倍に相当する。

この事実は、モデル選定において「単価」だけで判断してはならないことを示している。エラー率や空レスポンス率を考慮した実効コストで比較する必要がある。また、エラーハンドリングの設計では、空レスポンスを検知してリトライするかフォールバックするかを明示的に判断するロジックが不可欠である。レスポンスのcontentが空かどうかのチェックを省略すると、この「見えないコスト増」は運用段階で初めて発覚する。

モデル選定のトレードオフ：コスト、速度、精度の三角関係

本ベンチマークの結果は、コスト・速度・精度の三つが互いに制約し合う構造を如実に示している。Mistral 14Bはコストと速度で最上位だが、397Bクラスのモデルが持つ推論能力とは比較にならない。逆に、Qwen3.5-397b-a17bは潜在的な精度は高いが、速度と可用性の面で実用的ではない。技術責任者が判断すべきは「どのモデルが最も高性能か」ではなく、「自社のユースケースに対して、どのモデルが最も適したバランスを提供するか」である。

以下に、代表的なユースケースごとの重視指標・推奨特性・主要リスクをまとめる。

ユースケース	重視すべき指標	推奨モデル特性	主要リスク
リアルタイム対話	TTFT（1秒以内）	中規模・低レイテンシ	精度の上限が低い
バッチ処理	総コスト	最安クラス	処理速度が遅い場合がある
複雑な推論	出力品質・可用性	大規模・推論型	空レスポンス・高コスト

この表から読み取れるのは、ユースケースによって「許容できない劣化」の軸が異なるという点である。リアルタイム対話ではTTFTが命であり、1秒を超える待ち時間はユーザー離脱に直結する。一方、バッチ処理ではTTFTが10秒でも、1日1回しか実行しなければ問題にならない。重要なのは、自社のユースケースで「どの軸がボトルネックになるか」を事前に定義し、その軸でモデルをフィルタリングする設計判断を行うことである。

また、単純なタスク（要約、分類、定型回答）であれば、中規模モデルで十分な性能が得られる場合が多い。あえて大規模モデルを選ぶ正当性としては、複雑な推論チェーンが必要であること、ドメイン固有の知識がモデルに組み込まれていること、といった具体的な根拠が求められる。根拠なく大規模モデルを選ぶことは、コスト増とレイテンシ増の両方を無意味に負うことになる。本ベンチマークのデータから、max_tokens=512程度の中規模タスクではMistral 14Bが全指標で最良の結果を示しており、大規模モデルへの移行は「中規模モデルでは処理できない具体的なタスクが存在する」という前提があって初めて正当化される。

実装：並列ベンチマークの実行環境と注意点

ベンチマークを実際に実行する過程では、モデル選定そのものとは別の「実行環境の問題」に直面する。以下に、本テストで遭遇した2つの代表的な問題と、その対処法を解説する。

モデル可用性の判定

DigitalOcean Inferenceの/v1/modelsエンドポイントは72モデルを返すが、そのすべてが実際に利用可能とは限らない。サブスクリプションティア（利用プラン）によってアクセス権が制限されており、権限のないモデルに対してリクエストを送ると403エラーが返される。つまり、/v1/modelsの応答だけでは「このモデルは使えるか」を判定できない。

可用性の判定には、実際に推論リクエストを送り、レスポンスが正常に返るかを確認するしかない。これは「ドキュメントやAPIメタデータに依存しない、実測による検証」を意味する。モデル一覧を取得してベンチマーク対象を決めるのではなく、候補モデルに対して逐一テストを実行し、エラーを返さないものだけを比較対象に残すというプロセスが必要である。特に、モデルの追加やティア変更が頻繁に行われる環境では、この判定プロセスを自動化するスクリプトを持つことが望ましい。

並列テストにおけるワーカースレッドの選択

6モデルを並列でテストする際、Webフレームワークのワーカー構成が結果に影響を与える。Gunicornのデフォルトである同期ワーカー（sync）では、ストリーミング接続がキューイングされるため、並列度が期待通りに確保されない。本テストではgthreadワーカーに切り替えることで、6モデルの同時リクエストを正しく並列化できた。

この問題は、ベンチマーク結果の信頼性に関わる。同期ワーカーで実行した場合、リクエストが実際には直列に処理され、TTFTや総時間の数値が過大評価される可能性がある。性能評価を行う際は、実行環境の構成が「計測対象の性能」を歪めていないかを確認する必要がある。具体的には、並列実行時の各リクエストの開始時刻と終了時刻をログで確認し、実際に同時並行で処理されていることを検証する。

flowchart TD
    A["/v1/modelsでモデル一覧を取得"] --> B{"推論リクエストで403エラーか？"}
    B -->|"Yes"| C["比較対象から除外"]
    B -->|"No"| D["推論リクエストを実行"]
    D --> E{"レスポンスが空か？"}
    E -->|"Yes"| F["可用性リスクとして記録"]
    E -->|"No"| G["TTFT・総時間・コストを計測"]

設計判断：なぜMistral 14Bが勝ったのか？技術的な背景

Mistral 14BがTTFT 533ms、総時間3.3秒、コスト$0.000108という全指標で最速・最安となった背景には、パラメータ規模と推論効率の関係がある。中規模モデルと超大規模モデルでは、推論時のメモリ帯域幅への負荷が本質的に異なる。以下に、この差が性能にどう影響するかを解説する。

パラメータ規模と推論コストの非線形性

LLMの推論コストは、概ねパラメータ数に比例して増加する傾向がある。14Bクラスのパラメータを持つモデルと数百億規模のモデルでは、単一推論に必要なメモリ帯域幅に大きな差が生じる。これは、モデルの重みをGPUメモリから読み出す際に発生するI/Oコストの差であり、計算自体よりもメモリ帯域幅がボトルネックになりやすい推論処理において決定的な影響を持つ。

特にデコーディングフェーズ（トークンを1つずつ生成する段階）では、各ステップでモデル全体の重みを一度読み出す必要がある。パラメータ数が多いほど、この読み出しコストが累積し、生成速度が低下する。Qwen3.5-397b-a17bが総時間32秒を要したのは、メモリ帯域幅の制約が影響していると考えられる。KVキャッシュのサイズもパラメータ規模に比例して増大するため、大規模モデルではメモリ帯域幅への負荷が二重に重なる構造になっている。

「ゴールデンゾーン」の存在

14Bクラスという規模は、現在の推論インフラにおいて「ゴールデンゾーン」と呼べる位置にある。具体的には、モデルが1つのGPUメモリに収まり、かつ精度が実用的な閾値を超えている範囲である。これより小さいモデル（7B以下）では精度が不足するリスクがあり、これより大きいモデル（70B以上）ではメモリ帯域幅の制約が顕在化する。

ただし、これは「14Bクラスが常に最適」という意味ではない。タスクの複雑さによって必要とされるパラメータ規模は変わる。単純な要約や分類タスクであれば小規模モデルで十分だが、多段階の推論を要求されるタスクでは、より大きなモデルの精度が重要になる。設計判断として重要なのは、自社のユースケースがどのゾーンに属するかを、ベンチマークデータで確認することである。

推論エンジンとの相性

モデルのパラメータ規模だけでなく、推論エンジン側の最適化も性能に影響する。DigitalOcean Inferenceがどの推論フレームワーク（vLLMやTensorRT-LLMなど）を採用しているかは公開情報から断定できないが、特定のパラメータ規模に対してバッチサイズやKVキャッシュの最適化が行われている場合、その規模のモデルが相対的に有利になる可能性がある。

技術責任者として留意すべきは、ベンチマーク結果は「その時点の推論エンジンの構成」に対する結果であり、インフラのアップデートで順位が変わりうる点である。モデル選定は一度きりの判断ではなく、定期的な再評価を前提とする運用設計にする必要がある。

運用：ベンチマーク結果をプロダクションに活かすための指針

ベンチマークで得られた数値をプロダクションの設計に反映する際、そのままの値をSLAとして設定するのは危険である。ここでは、実務で機能する運用指針を整理する。

SLA策定時のマージン設計

ベンチマークでTTFT 533msを計測した場合、プロダクションのSLAに「TTFT 500ms以内」を設定するのは適切ではない可能性がある。実際のトラフィックでは、同時接続数によるコンピュート共有、入力長のばらつき、ネットワークの輻輳などが重なるためである。経験則として、ベンチマーク値の1.5〜2倍のマージンを確保することが推奨される。つまり、TTFT 533msのモデルに対しては、SLAを1秒以内として設計するのが現実的である。

このマージンは、モデルの「性能」ではなく「性能の安定性」を担保するための余白である。ピーク時間帯のレイテンシ増加を想定せず、平均値だけでSLAを設定すると、ユーザーが体感する待ち時間が要件を超えやすくなる。

空レスポンスへのフォールバック設計

Qwen3.5-397b-a17bが9回中7回で空レスポンスを返しながら課金された事例は、エラーハンドリングの設計を明確に示している。具体的には、以下の3層の防御を推奨する。

1層目（リクエスト前）: max_tokensを設定する際、モデルの推論トークン消費量を見積もり、出力用に十分な残りトークンを確保する。推論トークンの消費量はモデルによって異なるため、モデルごとのエッジケースを把握しておく必要がある。
2層目（レスポンス受信時）: 空レスポンスを検出したら、即座に別のモデルへリトライする。このフォールバックはユーザーが感知しないよう、数秒以内に完了させる設計にする。
3層目（コスト監視）: 空レスポンスでも課金が発生する構造を踏まえ、コストの異常増を監視するアラートを設定する。月次コストの過去平均に対する偏差が閾値を超えた場合に通知する仕組みである。

定期ベンチマークの運用サイクル

モデルプロバイダはモデルのアップデートやインフラの構成変更を行うため、数週間前に計測した数値がそのまま適用されるとは限らない。月次または四半期ごとの定期ベンチマークを実施し、TTFTやコストの変動を追跡する。変動が一定の閾値（例：TTFTが20%以上増加）を超えた場合は、モデル選定を再検討するトリガーとすることができる。

この定期ベンチマーク自体のコストは、6モデルで総額$0.0185と極めて低いため、運用コストの観点でも継続的実施に支障はない。

まとめ：ROIを最大化するLLM選定のプロセス

本記事では、DigitalOcean Inference上で6モデルを並列比較し、Mistral 14BがTTFT 533ms・総時間3.3秒・コスト$0.000108で全指標最速・最安となった結果を分析した。この結果が示すのは、「安さ」が単一の軸ではなく、レイテンシ・コスト・可用性の複合指標であるという事実である。

選定プロセスの再整理

LLM選定において技術責任者が行うべき判断は、以下の順序で整理できる。

ユースケースの定義: リアルタイム対話か、バッチ処理か、複雑な推論か。これにより重視する指標（TTFT / 総時間 / 精度）が決定される。
候補モデルの絞り込み: 可用性確認（/v1/modelsの403問題に注意）と、max_tokens設定による空レスポンスリスクの評価を行う。
ベンチマーク実行: 実行環境の並列化（gthreadワーカー等）を確認した上で、TTFT・総時間・コスト・エラー率を計測する。
SLAとフォールバックの設計: ベンチマーク値にマージンを加えたSLAを設定し、空レスポンス時のフォールバック戦略を実装する。
定期再評価: 月次〜四半期ごとのベンチマークで性能変動を追跡し、モデルの乗り換え判断を行う。

特に重要なのは、ステップ2とステップ3の間の「見えないコスト」の把握である。空レスポンスでも課金が発生する構造は、表面的な単価比較では見えないコスト増を生む可能性がある。ROIを最大化するには、この隠れたコスト要因を定量化し、総所有コスト（TCO）の視点でモデルを評価する必要がある。

本記事で提示した比較手法と注意点（空レスポンスの検出、実行環境の並列化、ネットワーク遅延の影響）を参考に、自社環境でのベンチマークを実行することで、データに基づいたモデル選定が可能になる。AI導入のROIは、モデルの「性能」だけでなく「選定プロセスの質」にも影響される。

参考

本記事は海外の技術トレンド「I raced six models against each other on DigitalOcean Inference. The cheapest one won.」（DEV）で話題のテーマをもとに、両儀システムソリューションズが独自に解説したものです。