Qwen3.8-Max・Kimi K3・DeepSeek V4比較

症状：API料金は安く見えるのに、コード修正やAgentの再試行で請求額が膨らむ。
最速解法：コスト重視はDeepSeek V4-Flash、長文書とオープンウェイトはKimi K3、複雑なコードとAgentはQwen3.8-Maxから試し、主モデル＋低価格なフォールバックモデルの2系統で小規模トラフィックから運用してください。

この記事は、既存APIの置き換えで試行錯誤を減らしたい開発者向けです。コード、ナレッジベース、AI Agentの主モデルとフォールバックモデルを決めたい技術責任者にも適しています。自社運用か自前推論かを比較する小規模チームは、料金だけでなく運用負担まで確認してください。

最終更新：2026年8月4日。モデル名、公開状態、API機能、料金条件は、各社の公式資料を公開前に再確認してください。

用途別の暫定結論

これはベンチマークの絶対順位ではありません。Kimi K3の公開論文では、2.8Tパラメーター、104Bの活性パラメーター、1M tokenの文脈長が示されていますが、APIの応答時間や料金とは別の指標です。詳細はKimi K3の技術論文で確認できます。

品質を分解する評価軸

3モデルを比較するときは、総合点を1つ作らないでください。次の4項目を別々に記録します。

• コード修正成功率：テストが通った変更の割合。説明文が自然でも、実行結果が壊れていれば失敗です。
• 情報保持率：長文書内の条件、例外、日付、参照箇所を正しく保持できた割合。
• ツール完了率：Agentが正しいツールを選び、必要な引数を渡し、最終状態まで到達した割合。
• 構造化出力の安定性：JSONスキーマ違反、余計な文章、列挙値の誤りを記録します。

公式ベンチマークは、各社のテスト条件で得た「メーカー公表値」として表示してください。異なるプロンプト、評価データ、推論設定の数字を一列に並べて、勝敗を決めるのは危険です。

DeepSeekの公式更新履歴では、2026年4月24日にV4-ProとV4-FlashがAPIで提供され、OpenAI互換インターフェースとAnthropic互換インターフェースに対応したと説明されています。V4とV4-Flashを同じAPIサービスとして扱わず、モデルIDを分けて管理してください。(DeepSeekの公式更新履歴)

API料金を実費に変換する計算

「入力1M tokenあたりの単価」だけでは比較できません。実際の費用は、次の式で揃えると判断しやすくなります。

成功1件の費用 ＝ 入力費用 ＋ 出力費用 ＋ キャッシュ外費用 ＋ ツール関連費用 × 平均試行回数

特に差が出るのは、次の項目です。

• 入力tokenと出力tokenの単価が別になっているか。
• キャッシュ命中時の料金が通常入力と異なるか。
• 思考過程や推論用tokenが課金対象に含まれるか。
• ツール呼び出し、検索、コード実行の結果が入力として再計上されるか。
• タイムアウト後の再試行が二重に課金されるか。
• 最大出力を大きく設定したことで、不要な長文が生成されていないか。

DeepSeekの公式料金表では、V4-Flashについてキャッシュ命中入力、キャッシュ未命中入力、出力を別々に課金し、1M token単位で表示しています。料金は変更される可能性があるため、社内予算へ反映する際はDeepSeek APIの公式料金表を保存し、核となるモデルIDと確認日を記録してください。

Qwen3.8-Maxについては、公開情報上でプレビュー版と正式版の扱いを分ける必要があります。QwenCloudの公式資料では、プレビュー版は正式版の公開後に停止または置き換えられる可能性があると説明されています。したがって、現在利用できるエンドポイントを長期契約の前提にせず、QwenCloudのプレビュー案内とAlibaba Cloudのモデル料金表を公開前に照合してください。

例えば、DeepSeek V4-Flashが最安に見えても、コード修正の再試行が多ければ総額は上がります。反対にQwen3.8-Maxの出力単価が高くても、1回でテストを通せるなら成功1件あたりの費用が下がることがあります。最低単価ではなく、タスク成功1件あたりの費用を比較してください。

遅延・同時実行・API成熟度

本番投入前には、料金表と別に次のログを取ります。

1. リクエスト送信から最初のtokenまでの待ち時間。
2. 最終tokenまでの総処理時間。
3. 同時実行数を増やしたときの制限応答。
4. ストリーミング接続が途中で切れた回数。
5. 429、5xx、形式不正の発生割合。
6. 指定したモデルIDが別バージョンへ自動更新されたか。

DeepSeekの公式レート制限資料では、V4-ProとV4-Flashの同時実行上限が別に示され、上限超過時にはHTTP 429が返ると説明されています。また、リクエスト開始後に推論が始まらない場合の接続維持条件も記載されています。こうした条件はモデル性能ではなく、サービス運用の評価項目です。(DeepSeek APIのレート制限と接続維持)

OpenAI互換APIに対応していても、ツール呼び出し、JSON出力、キャッシュ、思考モードが同じように動くとは限りません。プレビューAPI、動的なモデル別名、正式な本番エンドポイントは別列で管理してください。

5段階の導入手順

1. モデルIDを固定する：別名ではなく、料金ページとAPI資料に記載されたIDを保存します。
2. 同じ入力を用意する：実際のコードリポジトリ、代表的な文書、Agentのツール定義を使います。
3. 制限条件を揃える：タイムアウト、最大出力、再試行回数、温度、ストリーミング設定を統一します。
4. 小規模トラフィックで並行実行する：主モデル候補とフォールバック候補へ同じタスクを送り、品質・費用・遅延を記録します。
5. 切り替え条件を実装する：429、5xx、形式不正、一定時間超過、品質検査失敗を切り替え条件にします。
6. 週次で再評価する：価格改定、モデル更新、レート制限変更があれば、同じタスク集を再実行します。

長時間の回帰処理やAgentの制御端末が必要なら、まずMacHTMLのコンソール案内で実行方法を確認してください。運用権限や接続手順はMacHTMLのヘルプにも整理されています。

FAQ：用途別の最終判断

Qwen3.8-Max・Kimi K3・DeepSeek V4の比較で、最初に見る指標

最初から総合ランキングを作らず、コード修正成功率、長文書の情報保持、Agentのツール完了率、構造化出力の4軸で分けて測定します。料金は各軸の結果と再試行回数を組み合わせ、成功1件あたりの費用に変換してください。

主モデルとフォールバックモデルの構成

主モデルには品質と作業完了率を優先し、フォールバックモデルには単価、応答時間、APIの継続性を優先します。Qwen3.8-Maxを主モデル、DeepSeek V4-Flashをフォールバックにする構成は候補になりますが、実際には同じJSONスキーマとツール定義で切り替えられることが条件です。

自前推論とホスト型APIの分岐

Kimi K3の論文では、完全なモデルウェイトを公開したと説明されています。これはデータ境界やバージョン固定には有利ですが、公開ウェイトを取得できることと、安定した推論基盤を運用できることは別です。(Kimi K3の公開論文)

DeepSeek V4についても、公式発表ではV4-ProとV4-FlashのAPI提供に加え、モデルウェイトと技術資料への案内が示されています。ただし、実際の推論にはGPU、量子化、監視、障害対応、増設計画が必要です。(DeepSeek V4の公式発表)

• ホスト型API：導入が速く、設備管理が少ない一方、料金改定、レート制限、モデル更新、データ送信範囲を管理する必要があります。
• 互換レイヤー経由：アプリ側の変更を抑えやすい一方、エラー形式やツール仕様の差分が増えます。
• 自前推論：モデル版を固定しやすく、機密データを閉じた環境で扱えます。ただし推論用GPU、量子化、監視、障害対応、増設計画が必要です。

クラウド上のMacは、超大規模モデルの本体を動かす装置ではありません。API回帰スクリプト、Xcodeやターミナルを使った開発、長時間Agentの制御端末、画面操作を含む検証ノードとして位置付けてください。自前のMacを常時稼働させるか、短期の検証環境を借りるかは、MacHTMLの料金案内で期間と利用地域を確認してから決めるのが安全です。

本番前の合否判定

次の5分類で合格条件を決めます。

• 品質：コード修正、引用、ツール完了の最低基準を満たす。
• 費用：月間リクエスト数と再試行を含めた予算内に収まる。
• 遅延：ユーザー操作またはAgentの制限時間を超えない。
• 失敗率：形式不正、429、5xx、途中切断を許容範囲内に抑える。
• 移行負担：プロンプト、スキーマ、ツール定義、ログ形式を維持できる。

品質差が小さく、価格差が大きいなら2系統構成にします。品質差が大きく、失敗時の損失が高いなら、安価なモデルへの全面移行を延期します。既存モデルが安定しており、今回の3モデルで成功率または費用に明確な改善が出ないなら、単一モデルの継続も合理的です。

現在の構成が1社のAPIだけに依存している場合、料金改定、レート制限、モデル更新、障害時の切り替え不能という弱点が残ります。自前推論へ移る場合も、推論設備の初期費用、監視、更新、電力と保守が増えます。継続的なmacOS回帰環境が不足しているなら、いきなり設備を購入するより、MacHTMLで短期のテストノードを用意し、実際のログで2系統構成が成立するか確認するほうが判断を誤りにくいです。

まずこの記事の5つの受入指標を自社のコード、文書、ツールチェーンに置き換えてください。その結果、回帰スクリプトや長時間Agentを安定して動かすノードが足りなければ、次にクラウドMacの運用方法とレンタル期間を検討する段階です。