DeepSeek V4 Flash・Kimi K3・GLM-5.2比較：用途別の選び方

先に選び方を示します。 テキストとコードが中心で、APIコストと処理量を優先するなら DeepSeek V4 Flash から試します。画像・図表・スキャン文書・動画の理解が必須なら Kimi K3 が第一候補です。GLM-5.2 は両者の中間価格帯にあり、同じリポジトリ課題で Flash より手戻りを減らせる場合に選びます。

3モデルとも約100万トークンのコンテキストを公表しています。したがって「1M対応」だけでは決まりません。入力モダリティ、推論の制御、直接API料金、そして実際の採用結果が判断材料です。

以下の料金・機能は 2026年8月6日 に確認しました。導入前に再確認してください。

1M入力・100K出力で先に予算差を見る

公式の直接APIレートで、未キャッシュ入力100万トークン + 出力10万トークンを処理すると仮定します。

計算は 入力料金 + 0.1 × 出力料金 です。税、ツール料金、再試行、キャッシュ書き込み、第三者providerの上乗せは含みません。

この差から、テキスト/コード用途の初期値は Flash になります。しかし購入判断では、次の式まで進めます。

採用結果単価 = 全試行の入力・キャッシュ・出力・ツール・再試行費用 / 検収を通った結果数

安いモデルが何度も失敗すれば、1リクエストの安さは消えます。一方で Kimi K3 は、マルチモーダル対応や介入削減によって大きなtoken単価差を回収できる仕事でなければ割高です。

キャッシュは「対応」ではなく実績値で測る

確認時のcached inputは、DeepSeek $0.0028/M、Kimi $0.30/M、GLM $0.26/Mでした。固定system prompt、リポジトリ地図、共通資料を繰り返すワークロードでは重要です。

ただし、毎回変わる指示、tool result、会話履歴まで自動的にヒットするとは限りません。providerが返すcached tokensを記録し、第三者APIならそのサービスの価格とルールで再計算します。

モデル名と機能を正確に分ける

deepseek-v4-flash と DeepSeek V4 Pro は別です。ProのベンチマークをFlashの能力として使えません。同様に kimi-k3 を Kimi K2.5/K2.6 の料金・仕様で判断しないでください。

DeepSeekの公式料金表には、thinking/non-thinking、tool calls、JSON出力、384K最大出力が記載されています。公式モデルカードは284B総パラメータ、13B活性パラメータのMoEとMITライセンスを示します。

KimiのK3料金ページは、reasoning_effort とtool/structured output機能を説明しています。Kimi K3モデルカードは2.8T総パラメータ、104B活性パラメータ、ネイティブマルチモーダルを示します。

GLM-5.2モデルカードは、1Mコンテキスト、長期コーディング、柔軟な推論強度、ローカル提供手段とMITライセンスを説明しています。

活性パラメータ数は、全weightを保存するためのメモリ量ではありません。どのモデルも「数字が小さく見えるから手元の1枚GPUで簡単に動く」とは判断できません。

DeepSeek V4 Flashを選ぶ条件

testsが明確なbug修正、複数ファイルの小機能、データ変換、繰り返しtool callsでは、Flashの低価格を使って評価件数を増やせます。1件のデモより20件の実務課題のほうが、Agentとしての安定性をよく示します。

単純な変換はnon-thinkingから始め、計画・デバッグ・多段ツールはthinkingで比較します。13B活性という情報だけからtokens/sを推定してはいけません。ハードウェア、キュー、出力長、harnessが実時間を変えます。

Kimi K3を選ぶ条件

UIスクリーンショット、図面、画像化されたPDF、動画が仕事の一部なら、K3のネイティブマルチモーダルは単なる加点ではなく必須条件になります。外部OCRや別visionモデルを追加した構成は、もはや同じ3モデル比較ではありません。

テキストだけの仕事では、より厳しい採用条件を置きます。人の確認が大幅に減ったか、他モデルが完遂できない長期作業を終えたか、採用結果単価が改善したかを確認します。open-weightのモデルカードとhosted APIのmedia contractは同一ではないため、本番入力前に対応形式を再確認します。

GLM-5.2を選ぶ条件

Flashが同じ箇所を繰り返す、リポジトリ規約を落とす、tool call修復が多い場合、GLM-5.2を比較対象に加えます。価格は中間で、effortを調整できるため、難しいcoding-agent作業の候補になります。

ただし「中間だから無難」ではありません。合格率、介入、所要時間がFlashと同程度なら、安いか運用しやすい側を残します。GLMの追加費用は、2回目の代表サンプルでも手戻り削減が再現したときに初めて正当化されます。

公開ベンチマークが矛盾して見える理由

公式表はテスト候補を選ぶ資料ですが、同一条件の三者対決とは限りません。次の違いで順位は変わります。

• agent harnessのファイル選択、context compaction、tool修復;
• reasoning_effort、temperature、最大出力、再試行;
• ネットワーク・shell・検索などの権限;
• 課題バージョン、judge、timeout、合格条件;
• 直接providerか第三者hostか、キャッシュや混雑状況。

KimiとGLMの公式カード自体も、ベンチマークごとにharnessや設定が異なることを注記しています。数値は「何を試すか」を決めるために使い、「試さなくてよい理由」にはしません。

同じ10〜30件でA/B/Cテストする

小さすぎるtoy promptではなく、実務に近い複数ファイル修正、tests付き機能、資料統合、数回のツール操作を選びます。

1. 同じcommit、ファイル、指示、期待結果から開始する。
2. 可能なら同じproviderクラスを使い、無料の混雑endpointと有料高速routeを混ぜない。
3. ツール権限、context packet、effort方針、timeout、retry budgetを固定する。
4. 実行前にtests、schema、事実確認、画面確認などの検収条件を決める。
5. pass/fail、介入、完了時間、input/output/cached tokens、tool fee、retryを記録する。
6. 境界的な課題を再実行し、採用結果単価を比較する。

必須モダリティを満たさない、予算上限を超える、または2つ目の代表サンプルでも明確に勝つ場合は比較を終えます。通常の実行ばらつきに収まるなら、安い候補を初期値に保ちます。

結論：最初の実務サンプルを誰に渡すか

テキストとコード中心なら、まず DeepSeek V4 Flash に渡します。視覚入力や価値の高い長期作業では Kimi K3、Flashの手戻りを再現性高く減らせる場合は GLM-5.2 です。

推論・キャッシュ・マルチモーダルの正確なcontractが必要なら公式APIを使います。単一のOpenAI-compatible接続を検討する場合、LaoZhang APIドキュメントには統一APIとModels endpointがありますが、現行モデル一覧を確認してから判断してください。西側のcoding-agentも候補なら、日本語の GPT-5.6 SolとClaude Fable 5比較も参照できます。