仕様を並べて比較する
この2つのモデルは3週間以内という近さでリリースされた。どちらも中国のラボ発で、ウェイトを公開しており、100万トークンのコンテキストウィンドウを持つ。共通点はおおよそそこまでだ。それぞれの背景については、私のKimi K3レビューと、Flashの前身にあたる世代であるDeepSeek V3.2の解説も参照してほしい。
| DeepSeek V4 Flash | Kimi K3 | |
|---|---|---|
| リリース日 | 0731ビルド、2026年7月31日 | 2026年7月16日 |
| 入力(キャッシュミス) | $0.14 / 100万 | $3.00 / 100万 |
| 入力(キャッシュヒット) | $0.0028 / 100万 | $0.30 / 100万 |
| 出力 | $0.28 / 100万 | $15.00 / 100万 |
| コンテキストウィンドウ | 100万 | 1,048,576 |
| 最大出力 | 384K | デフォルト131,072、1,048,576まで設定可能 |
| パラメータ数 | 総284B、アクティブ13B | 総2.8T、アクティブ104B |
| 入力モダリティ | テキストのみ | テキスト、画像、動画 |
| 推論コントロール | 非思考または思考モード、デフォルトは思考 | low / high / max、オフにはできない |
| ライセンス | MIT | Kimi K3ライセンス、商用ライダー付き |
| 同時実行数上限 | 2,500 | アカウントティアにより制限、非公開 |
| AA Intelligence Index | 50 | 57 |
| タスクあたりコスト | $0.03 | $0.86 |
| 出力速度の中央値 | 113 tok/s | 35 tok/s |
| 総応答時間 | 23.36s | 73.88s |
| AA-Omniscience 幻覚率 | 84% | 51% |
先に進む前に、ここでひとつの行を取り上げる価値がある。DeepSeekのキャッシュヒットレートは100万トークンあたり$0.0028で、すでに割引されているKimiの$0.30よりもさらに100倍安い。キャッシングはコード変更なしでデフォルトで有効になる。ただしDeepSeekはこれがベストエフォートであることを明言しており、エントリは「通常数時間から数日以内」にクリアされるとしているため、これは常に一定とは考えるべきではない実質的な割引だ。
トークン単価は間違った数字だ
このような比較にはひとつの罠がある。料金表ではFlashが出力で54倍安いとされている。しかし料金表はあなたの請求書ではない。
Artificial Analysisは実態にずっと近い指標としてタスクあたりコストを公開している。これは彼らの指標上で1つの仕事を完了するのに実際にかかるコストの加重平均だ。この指標ではFlashが$0.03、K3が$0.86となる。依然として大きな差だが、54倍ではなく29倍であり、その理由はFlashがどこにたどり着くにもより多くのトークンを消費するからだ。指標全体を実行した際、Flashは2億1,000万の出力トークンを生成したのに対し、K3は1億3,000万で、いずれもクラス中央値である1億トークンを基準に測定されている。AAはFlashを「非常に冗長」と呼んでいる。K3についても冗長だとしている。どちらも饒舌だが、Flashのほうがより饒舌というだけだ。
指標全体の実行にかかったコストはFlashが$72.02、K3が$2,437.41だ。同じ9つの評価、同じ作業量でこれだ。AI支出をトークン単価ではなく月々のサービスコストとして考える習慣があるなら、この比率こそ覚えておく価値がある。
定価と実際の請求額のあいだにギャップを生むのは推論トークンであり、これはほとんどの価格比較が見落としている部分だ。Simon Willisonは自身の定番であるペリカンのプロンプトをK3に通し、その明細を公開した。
"95 input, 16,658 output = 25 cents! [...] (13,241 of those were reasoning tokens.) I think that's the most expensive pelican I've rendered through a Chinese model so far."
入力95トークン、出力に25セント、そして彼が支払った金額の79%は、彼が一度も目にすることのない「思考」に対するものだった。
どちらのモデルも推論を出力レートで課金し、どちらもデフォルトで思考モードがオンになっているため、これはどちらにも当てはまる。ただし片方はトークンあたりの単価が54倍高いだけだ。
計測結果が確定しているかのように装う代わりに、ここで正直な複雑さを指摘しておく価値がある。同じプロンプトを両方のモデルに通したある開発者は、冗長性の比較が逆方向であることを発見した。
"It says there that "Kimi K3 (Max)" would think/reason less than than deepseek-v4-flash, and a whole bunch of other models [...] but in my experience, K3 is probably the model that thinks/reasons the longest of all of these."
両方とも同時に真実でありうる。AAの指標は短い評価タスクの特定の組み合わせであり、あなたのワークロードはその組み合わせではない。ここでの実際の教訓は、自分自身のプロンプトを両方に通してトークン数を数えることだ。公開されている冗長性の数字は、あなたのユースケースにそのまま当てはまるとは限らないからだ。
ただしキャッシュの議論に関しては、Flashが打ち負かしがたい部分がここにある。
"I don't understand how DeepSeek can be so cheap with their cache pricing - ~0.003 usd / 1Mtok. 100x less than Kimi K3, or similar numbers against pretty much any other decently sized model to my knowledge. I've been using it whenever possible as even longer agent sessions cost few cents."
見せかけの「中間の選択肢」
もし私が購入する側だったなら知りたかったはずの発見であり、どちらのベンダーのページにも載っていない。
Moonshotはローンチ後のどこかのタイミングでlowとhighの推論レベルを追加したため、K3はもはや最大エフォート専用ではない。明らかな一手はlowを選び、請求額のごく一部でK3の品質の大半を維持することだろう。Artificial Analysisはこの構成を別途計測したが、それはうまくいかない。
lowのKimi K3はIntelligence Indexで47点、タスクあたり$0.24だ。DeepSeek V4 Flashは$0.03で50点。控えめにしたK3はFlashの8倍のコストで、スコアは3ポイント低い。速くもなく、毎秒34トークンとK3-maxの35トークンに対してわずかに劣り、総応答時間もやや悪化する。
レベルは同じ料金で課金されるため、コスト面での救済にもならない。Kimi K3クイックスタートは、推論をオフにできるかという問いに対して、このダイヤルが何をするかについて率直に答えている。「できません。K3は常に思考します。推論に時間がかかりすぎる場合は、reasoning_effortをlowに設定してください」。これはコストティアではなくレイテンシコントロールだ。節約できるのは、回避できた推論トークンの分だけだ。
つまり選択肢は二択だ。$0.03を払うか、$0.86を払うか。ボリュームで見るとこうなる。
ボリュームごとの請求額
Artificial Analysisのタスクあたりコストを掛け合わせたもの。月間タスク数を選んでほしい。
ここでの「タスク」とは1つのArtificial Analysis Intelligence Indexタスクを指し、あなたのワークロードの代理指標であって、それに一致するものではない。これは請求額を予測するためではなく、3つの選択肢を互いに比較するために使ってほしい。
それぞれが実際に勝っている点
純粋な計測知能ではK3が上回っており、リーダーボード上でもその差は小さくない。57対50、全体で7位、そしてArtificial Analysisが追跡する99モデルの中で最上位のオープンウェイトモデルだ。Flashはオープンウェイトの中で3位に位置し、K3とGLM-5.2に次ぐ。
Moonshot自身のローンチ時のチャートも一貫したストーリーを語っているが、ひとつ注意点を頭に置いて読む価値がある。
その注意点とは、DeepSeekがそのチャートに一切登場しないということだ。MoonshotはK3をFable 5、GPT-5.6 Sol、Opus 4.8、GLM-5.2、GPT-5.5と比較したが、最も安価で本格的なオープンウェイトの競合を外している。DeepSeekも同じことをやり返しており、K3は同社のチャートにも登場しない。ベンダーベンチマークにありがちな状況であり、だからこそ独立系の指標がこの記事で大半の仕事を担っている。
速度とスループットではFlashが完全に勝っている。毎秒113トークンに対しK3は35トークン、最初のチャンクは1.33秒に対し2.78秒、完全な応答は23.36秒に対し73.88秒だ。同時実行数の上限も2,500ある。インタラクティブな用途では、この差は単なる注釈ではなく、プロダクトそのものになる。
"Faster iterations are way better for me, I hate waiting for 5-10 minutes on small changes. I tried to use recent versions of Kimi and GLM, but they use too much thinking for no reason and are pretty slow because of it."
そしてその遅さは、最上位のコンシューマーティアを支払っている人にとっても変わらない。
"I'm still considering pulling the trigger on the annual subscription of Kimi for K3 but it's sometimes slower than I'd like (at least when compared to Anthropic) even on their Vivace plan"
Flash側で見つけた最も参考になる実践レポートは、4日間にわたり16件の実際の業務タスクを、はるかに高価なモデルと比較したものだ。この結果は「安い=弱い」という思い込みを和らげるはずだ。
"I benched DS4 flash and Pro vs opus 4.8 xhigh on 16 work-related tasks a month ago across 4 days. Opus 4.8 came out as a winner by 1 task only [...] But flash performed as well or better (as in being more thorough) in 13 out if 16."
次に進む前に、はっきりとした機能面の違いをひとつ挙げておく。K3は画像と動画の入力を受け付けるが、Flashはテキストのみで、画像入力は文書化されていない。ワークロードにスクリーンショットが関わるなら、それだけでこの選択が決まってしまう。マルチモーダル入力はあとから付け足せるものではないからだ。もうひとつ知っておく価値があるのは、K3は公開画像URLも受け付けないということだ。Base64かアップロード済みファイルIDのみで、それ以外はない。
重要なのは正確性のギャップだ
ここまでの話はすべて、あなたのワークロード次第で議論の余地がある。しかしこの部分はそうではない。
AA-Omniscienceは、モデルが自分の知らないことを知っているかどうかを測定する。正しい回答には報酬を与え、自信満々の間違った回答にはペナルティを課し、「わからない」と答えても減点しない。この指標ではFlashが−16、K3が18のスコアだ。幻覚率に換算すると、Flashは自分の理解を超えたときに84%の確率で答えをでっち上げる。K3は51%の確率でそれを行う。
どちらの数字も良くはない。片方ははるかに悪い。そしてこの水準の幻覚は、プロンプトで解消できるような癖ではなく、基盤モデルの性質そのものであり、それを前提に設計するか、そのせいで痛い目に遭うかのどちらかだ。
Flashを使っている人々は、その数字から予想される通りのことをおおむね報告している。
"DeepSeek V4 hallucinates like crazy and often forgets explicitly mentioned parts of the context. I guess compressing tokens and cherry-picking attention comes at a cost."
最も公平な言い方は、このモデルのヘビーユーザーの一人から出たものだ。彼はモデルを擁護しているというより、それを乗り切るために自分が構築した仕組みを説明している。
"It hallucinates plenty, about the same as Codex models and all other LLMs! I review all code it writes, thoroughly, check the test coverage, write tests myself, have other models/chats cross-check the work with a review skill"
それが正直な読み方だ。Flashは有能な人間がすべての出力をレビューする場合にはうまく機能するし、コーディングのワークフローにはすでにコンパイラとテストスイート、そしてコードレビューがあり、モデルと重要なものとのあいだに立ちはだかっている。安いモデルがうまくいくのは、ハーネスがそれを捕まえてくれるからだ。そのハーネスを取り除けば、あなたはベースモデル自身の判断に頼ることになり、それはまさに84%という数字がやめておくべきだと告げていることだ。これはまた、回答がもっともらしいだけでなく正しくなければならない場面において、生のLLMよりRAGを選ぶべき論拠でもある。
ここで、この仕事をしていて何度も出会う問題を指摘しておきたい。私はeeselでAIエージェントを作っており、それを実際のサポートキューに投入することにもう何年も費やしてきた。失敗のパターンは、モデルが愚かであることでは決してない。モデルが自信満々であることだ。あるバイヤーが、チケットをAIにルーティングする件についての通話で、私よりも上手にそれを言い表してくれた。
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
これはDTCのサプリメントブランドのCXリーダーで、GorgiasとShopifyで月間およそ7,000件のチケットを扱っている。私たちはその案件を獲得できなかったが、上記の懸念がその理由だ。彼が一度も「モデルのスコアは何か」と尋ねなかった点に注目してほしい。彼が尋ねたのは、モデルがわからないときにきちんと手を引くかということだった。リーダーボードの幻覚率はその問いに答えてくれないし、どちらのベンダーのページも答えてくれない。
公平に言うと、私たち自身のエージェントが自信満々に間違えるのを見たこともある。本番環境で記録した最悪のパターンは、あるエージェントが一度もAPIを呼び出すことなく、約10ターンにわたって「Zendesk検索を実行中」とナレーションし続けていたことだ。チームメイトへの信頼を最も早く壊すのは、自分がやったことについて嘘をつくことであり、だからこそ私たちは今、実際のライブキューに触れる前に、顧客自身のチケット履歴に対してすべてのロールアウトをシミュレートしている。
「オープンウェイト」という言葉が意味する2つの異なること
どちらのモデルもウェイトを公開している。しかし、その言葉が意味するところはそれぞれでまったく異なる。
Flashは総パラメータ284B、アクティブ13B、ウェイトは約167GBで、シンプルなMITライセンスのもとにあり、コミュニティによる量子化版が57種類存在する。これはこの品質レベルのほとんどのオープンソースエージェントとは異なる領域に位置し、ファインチューニングが思考実験ではなく現実的な選択肢になるほど小さい。
K3のウェイトは、Moonshotが約束していたまさにその日である7月27日にHugging Faceで公開された。safetensorsのインデックスは、プレスリリースとは別に2,779,931,837,184というパラメータ数を確認している。またウェイトは96シャードにわたる1,561GBで、アクティブパラメータは104Bだ。
その規模を割り出した人物が、重要な部分を付け加えている。
"Most importantly, we now know that the model has 104B active parameters, which is quite a lot and will make it difficult to self-host efficiently."
この2つのあいだの実践的な境界線は、V4 Flashのローンチスレッドでかなりはっきりと引かれている。
"And, at least flash can be ran "at home" with <10k in hardware, which isn't really possible / feasible with glm/k3 larger models."
そして、節約のためにK3を自己ホストするという計算は、スプレッドシートに触れた途端に崩壊する。
"At 5 tok/second, you're talking about around $195 worth of output tokens per month. There is no way I can run a usable K3 model for $195 a month of capex, opex, or any-kind-of-ex."
ライセンスも異なり、こちらは実際に効力を持つ。FlashはMIT、それだけだ。K3は2つのライダー(付帯条件)を伴うカスタムのKimi K3ライセンスのもとで提供される。過去12か月の収益が2,000万ドルを超えるマネージドサービス事業者は別途契約が必要で、月間ユーザー数1億人または月間収益2,000万ドルを超えるプロダクトはインターフェース上に「Kimi K3」と表示しなければならない。ほとんどの読者はどちらにも該当しないだろう。しかしその上にプロダクトを構築するなら、MITのような自由があると思い込む前にライセンスを読み、自社開発か購入かの判断材料に組み込んでほしい。
送信したデータに対して各ベンダーが何をするか
送信するテキストが自分自身のものであれば、この部分は読み飛ばしてかまわない。しかしそれが顧客のテキストであるなら、このセクションがすべてを左右する。そして2つのベンダーはかなり異なる立場にある。
Moonshotは自らの立場を公開しており、デフォルトでは許容的だ。2026年5月27日に最終更新された利用規約には、トレーニング利用に制限を求める顧客は「利用可能なエンタープライズ契約または別途の書面合意について相談するためMoonshot AIに連絡してもよい」とあり、続けてこう書かれている。「書面で明示的に別段の合意がない限り、顧客コンテンツは前述の目的のために使用される場合がある。」十分に明確であり、その逃げ道は自分で交渉しに行かねばならない契約だ。データはシンガポールに保存される。
DeepSeekのほうがより興味深いケースだ。有料APIについて別途の契約を公開しているが、その契約には何も書かれていないからだ。2026年4月29日に発効したOpen Platform規約には「入力と出力」というセクションがあり、§4.2まで続いてそこで止まっている。コンシューマー向けの利用規約には同じ番号のセクションの§4.3にトレーニング条項があるが、API文書ではそれが単に省略されている。そのコンシューマー向け条項では、DeepSeekが「サービスを提供、維持、運用、開発、または改善するために、最小限の範囲で入力と出力を使用する場合がある」と明記されており、「みんなのためにモデルを改善する」というラベルのオプトアウトトグルが用意されている。
したがってDeepSeekのAPIについて正確に言えるのは、それが沈黙しているということであり、安全だということではない。API規約は自らを一般利用規約のもとにある個別の契約と位置づけており、個別の条項が優先されるのは矛盾がある場合のみだ。沈黙は矛盾ではない。どちらの文書も開発者向けのオプトアウトやデータ処理契約、ゼロリテンションのオプションを公開しておらず、保存されたデータは中華人民共和国法のもとで中国国内に置かれている。
実務上これが意味するのは、どちらも規制対象データや顧客を特定できるデータに対して、営業担当者との事前の会話なしにそのまま使えるファーストパーティの選択肢ではないということであり、2つのセルフサーブAPIにとってこれは実際の摩擦になる。これはチームがSlackのポリシー変更で直面したのと同じ形の問題であり、SOC 2やGDPRの対象であるなら、レビュアーが真っ先に尋ねてくることだ。ゼロリテンション条件を公開しているプロバイダーを経由させるのが通常の回避策であり、それは上記の料金表よりもコストがかかる。
では、どちらを選ぶべきか?
私ならこの決断をひとつの問いを軸に組み立てる。それは予算ではない。
出力が本番に反映される前に人間や機械がチェックする場合はDeepSeek V4 Flashを選ぶ。 テストとレビューを伴うコーディング、バッチ分類、大量のドラフト作成、社内ツール、間違っていた場合に安く再実行できるものすべてだ。タスクあたり$0.03、キャッシュヒットレート$0.0028というのは、K3なら誰かに問い詰められる規模の項目になるようなボリュームでも、ほぼタダに近い。速度も3倍速く、これはインタラクティブな作業において人が思う以上に重要だ。これはまた、自己ホストが単なるアイデアではなく現実の要件である場合にも選ぶべきものだ。
出力そのものが成果物であり、誰も一行ずつチェックしない場合はmaxエフォートのKimi K3を選ぶ。 長時間にわたるエージェントの実行、リサーチの統合、間違いのコストが高くどのみち気づけない状況などだ。51%という幻覚率は、それでも監視なしのワークフローを構築したくなる数字ではないが、84%とはリスクのカテゴリが異なる。また画像を読み取れるのはこの2つのうちK3だけだ。
lowエフォートのKimi K3は避ける。 Flashの8倍のコストでスコアは低い。これは請求額ではなく待ち時間を短縮するために存在するものだ。K3-maxが予算オーバーなら、答えは「もっと静かなK3」ではなく別のモデルであり、Kimi K3の代替案のまとめから始めるとよい。
最後にひとつ言っておく価値がある。多くの報道では「中国のラボ」と「安い」がほぼ同義語として扱われているが、K3に関してはそうではない。タスクあたり$0.86という数字は西側の最先端モデルに手が届く距離にあり、ローンチスレッドで誰かがその計算をしていた。
"According to artificialanalysis, cost per task is $0.94, which is almost the same as $1.04 of gpt 5.6 sol max [...] The model certainly sounds extremely impressive for something not from openai/antrophic, but the price makes it a mediocre product."
K3の数字はその後$0.86に落ち着いたため、彼が見ていたときより差はやや広がっているが、彼の論旨の形は今も成り立っている。Claude Sonnet 5はまったく同じ$3/$15の料金表に乗っており、GPT-5.6 Solもタスクあたりで同じような水準だ。この市場の安価な側にいるのはFlashとその仲間たちであり、2.8Tのフラッグシップ勢ではない。
この分野の残りについては、私のQwen 3.8 Max比較でこのレースの3社目のラボを扱っており、V4 Pro記事ではDeepSeekの安価なティアがなぜ高価なティアを現在上回っているのかを説明している。
どちらかを顧客の前に出すとき
ここまではすべて開発者の判断だ。しかしどちらかがサポートチケットに答えられるかどうかを知りたくてここにたどり着いたのなら、正直な答えは、そのシステムの中でモデルが最も重要でない部分だということだ。
これはeeselでAIエージェントを作っている者としての意見だ。幻覚率84%の生のモデルも51%の生のモデルも、サポートキューでは同じように失敗する。答えるべきではないことに答えてしまうのだ。それを直すのはより優れたベースモデルではない。すべての返信を検証済みのナレッジにグラウンディングさせ、信頼度スコアでゲートをかけて基準を下回るときは黙らせ、そして事が起きる前に何が起きるかを知っておくことだ。
それがAIサポートエージェントとAPIキーにつながっただけのチャットボックスとの違いだ。そしてそれこそが、自社で構築することが誰の予算よりも時間がかかる主な理由でもある。
最後の部分は、あなたが私たちを使うかどうかにかかわらず、借用する価値がある。eeselは何かが本番に出る前に、実際の過去のチケットに対してシミュレーションを実行するため、あなたが目にするのはリーダーボードの数字ではなく、自社データに対する実際の精度であり、それが基準をクリアしたときにだけデプロイする。一部だけをルーティングするやり方もうまくいく。月に1,000件のチケットを処理し、そのうち200件をAIに送れば、支払うのは200件分だけだ。課金は解決したチケット1件あたり40セントで、席数に応じた料金はなく、人間が対応したチケットに課金されることは一切ない。開始時に無料利用枠が$50分あり、クレジットカードも不要だ。
Zendeskをはじめとする他のヘルプデスクにも接続でき、あなたの回答がすでに存在する場所ならどこからでも読み取れる。それがConfluenceであろうと、Notionのスペースであろうと、単なる公開ヘルプセンターであろうと構わない。
下で動かすモデルはどちらでも好きなほうを選べばいい。ただし、ベンチマークのスコアを理由にそれを顧客に任せることだけはしないでほしい。
よくある質問
DeepSeek V4 FlashとKimi K3、安いのはどちら?
Kimi K3はDeepSeek V4 Flashより優れている?
DeepSeek V4 FlashやKimi K3をローカルで実行できる?
小規模チーム向けのKimi K3 APIの料金は?
Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.
