Kimi K3 は2.8兆パラメータより「忘れ方」が新しい — KDA で読む記憶アーキテクチャと実運用コスト

2026 年 7 月 16 日に Moonshot AI が公開した Kimi K3 は、総パラメータ 2.8 兆・コンテキスト 100 万トークンという「世界初のオープン 3T クラスモデル」として大きく話題になりました。

ただ、X 上の反応を追っていくと、議論は明確に 2 つに割れています。「どう作られているのか」というアーキテクチャの話と、「実際に使って割に合うのか」という運用の話です。前者は、「パラメータ数が兆」という数字の裏で Attention の記憶設計が何度も作り替えられてきた歴史の話です。後者は、トークン単価と消費量というきわめて実務的な話です。

この記事では両方を扱います。まず記憶アーキテクチャの系譜を GPT-2 から辿り、Kimi K3 がそれをどう組み合わせたのかを見ます。そのうえで、実際に使った人たちの評価を並べます。

先に結論だけ挙げておきます。

• 2.8 兆パラメータという数字は、設計を成り立たせるための器であって、それ自体が答えではない
• K3 は KDA 69 層 + Gated MLA 24 層の二段構え。一つの記憶方式に賭けていない
• 実運用は「常用は安いモデル、難所だけ K3」。ローカル実行は現実的に不可能

GPT-2 比 約 22,580 倍は「賢さの倍率」ではない

まず数字から入ります。GPT-2 の基準構成は約 1.24 億パラメータ、Kimi K3 は 2.8 兆パラメータです。比率は約 22,580 倍。

インパクトのある数字ですが、この比は能力の比ではありません。パラメータ数は、モデルが学習中に調整した数値の量にすぎません。同様に「100 万トークン扱える」も、入力できる長さの話であって、そこから欲しい一文を正確に取り出せるかは別の問いです。長い議事録を丸ごと渡せることと、「あの提案の変更後の日付」を間違えずに答えられることは、まったく違う能力です。

見るべきなのはサイズの大きさより、増えた容量を何の問題に割り当てたかです。そして GPT-2 から Kimi K3 までの系譜を追うと、それは一貫して「記憶」の問題でした。

Attention の「記憶」はこう作り替えられてきた

① Full Attention と、増え続ける KV キャッシュ

GPT-2 は 2019 年のモデルです。文章を一度に完成させず、ここまでの文を読んで次に来そうな一語を選び、それを繰り返します。

このとき、過去の単語どうしの関係を確かめる仕組みが Attention です。「この単語は前に出てきたどの言葉とつながるか」を見て次を決める。長い議事録で「その提案」と言われたとき、どの提案を指すか前の方まで遡って探せる。この読み返しが言語モデルの強さの土台になりました。

ただし代償があります。生成のたびに前の単語すべてを最初から計算し直していたら遅すぎる。そこで一語ずつ出していく decoder 型のモデルは、KV キャッシュとして過去の計算結果を残します。

ここは誤解されやすいところですが、KV キャッシュは会話の意味をしまう箱ではありません。過去の単語を参照するための計算結果を保管しておく仕組みです。そして文脈が長くなるほど、このキャッシュは増え続けます。100 万トークン規模になると、保存と転送のコストが支配的になる。ここが次の設計変更の出発点でした。

KV キャッシュは推論の実務でも効いてきます。ローカル LLM でキャッシュが毎回無効化される問題については Claude Code × ローカルLLM で KVキャッシュが毎回無効化される問題と対策 でも扱いました。

② 線形 Attention — 固定サイズの状態に折りたたむ

そこで考えられたのが、過去の情報を一件ずつ保存し続ける代わりに、文脈長によらない固定サイズの計算用メモ領域へ折りたたむ方法です。これが線形 Attention の直感に近いところです。

ここは「二次スケーリング問題」への別のアプローチと混同しやすいところです。SubQ の Subquadratic Sparse Attention は、全トークンを比較する代わりにクエリごとに重要な位置 k 個だけを選んで計算量を削ります。参照先を絞る発想です。一方で線形 Attention は、参照先を絞るのではなく状態を固定サイズに畳み込む。どちらも O(N²) を回避しますが、削っているものが違います。

ノートを無限に増やさず、決まった大きさのホワイトボードへ要点を書き換え続ける、というイメージです。ただし、モデルが日本語の要約文を書き込んでいるわけではありません。計算のための状態を、限られた大きさで更新しています。

これで文脈長に比例して増える KV キャッシュは持たなくて済みます。しかし新しい問題が生まれます。ホワイトボードが埋まっていれば、書き足すほど古い情報と混ざる。「何を消し、何を残すか」を決めなければ、必要な事実までぼやけてしまいます。

③ DeltaNet — 足すのではなく「差分で直す」

この課題に対して DeltaNet は、単に新しい情報を足すだけにとどめません。まず、同じ手がかり（キー）で今の記憶から何が読み出せるかをいったん確認します。そのうえで、すでに書かれている内容と新しく書きたい内容の差だけを更新します。

たとえば「来週の会議は火曜」と書いた後に「水曜へ変更」と分かったとき、火曜と水曜を両方残すのではありません。古い予定を確認して、差し替えるべき場所を更新する。限られた記憶を雑に上書きしないための工夫です。

ただ、特定の記憶を入れ替えるだけでは足りません。話題が大きく変わるときは、全体として古くなった情報を薄める必要もあります。Gated DeltaNet は、差し替えに加えて「どれだけ古い情報を薄めるか」も調整する段階でした。

④ Kimi Delta Attention — 「忘れ方」を細かく分ける

Kimi Delta Attention（KDA） は、この減衰の調整を記憶全体で一律にせず、より細かい単位で行う仕組みです。Moonshot の論文 Kimi Linear: An Expressive, Efficient Attention Architecture では、KDA を「Gated DeltaNet をより細粒度なゲート機構で拡張した表現力の高い線形 Attention モジュール」と説明しています。

ここで重要なのは、モデルが人間のように理解して忘れているわけではないことです。計算の中で、どの成分をどれだけ残すかを学習された値で調整しているという話です。

長い文脈を扱うモデルでは、「どれだけ長く入力できるか」だけでは説明が足りません。不要になった情報を残しすぎず、まだ必要な情報を消しすぎない。この両立が必要になります。

Kimi K3 は、一つの記憶方式に賭けていない

では Kimi K3 は KDA だけですべてを処理しているのか。していません。

公式リポジトリ の構成値では、K3 は全 93 層 を KDA 69 層 + Gated MLA 24 層 で構成しています。Kimi Linear 論文でいう「KDA と Multi-head Latent Attention（MLA）の層単位のハイブリッド」を、K3 でも採っているわけです。

理屈はシンプルです。固定サイズの記憶は軽いが、すべてを完璧に保存することはできない。 だから必要なときには、より精密に過去を探す仕組みを残しておく。圧縮して保持する部分と、元の文脈から詳しく参照し直す部分を分けているのです。

主要スペックをまとめます。

Kimi Linear 論文では、この構成により 100 万トークン文脈で KV キャッシュ使用量を最大 75% 削減し、デコードのスループットを約 6 倍に改善したと報告されています。なお論文で事前学習された Kimi Linear 自体は総 48B・活性 3B のモデルで、K3 の規模とは別物です。アーキテクチャの検証と、それを 3T クラスへ持ち込んだ本番モデルは分けて読む必要があります。

記憶設計は学習コストの話でもある — 「蒸留では説明できない」という見方

技術的な出自については、@ImAI_Eruel がこう指摘しています。

Fable や GPT-5.6 の公開期間等を考えると、Kimi3 の主な性能がアメリカのフロンティアモデルの蒸留によって達成されたとはちょっと思えず、かなり本質的な技術、データ上の工夫があるのではないかと思います。

引用中の Fable / GPT-5.6 は、K3 と同時期の米国フロンティアモデルを指しています。それらが公開されてからの期間の短さを考えると、蒸留だけで K3 の性能を説明するのは無理がある——という見立てです。

そして、より驚いているのは計算資源の方だとしています。3T クラスの学習は、NVIDIA の先端 GPU を大量に使えるアメリカのラボでもリソース的にかなり難しいはず、と。

この観点は、上で見たアーキテクチャの話と地続きです。KV キャッシュを 75% 削減し、デコードを 6 倍速くする設計は、単に推論を安くするだけでなく、限られた計算資源で大規模な学習と評価サイクルを回すための条件でもあります。「記憶をどう設計するか」は、そのままどれだけの規模を現実的に扱えるかの問題になります。

実運用での評価

ここから運用の話です。ただ、その前に整理しておくべきことがあります。

上で「KV キャッシュを 75% 削減、デコードは約 6 倍」と述べたのに、この先では「トークン消費が壁になる」という話をします。矛盾しているように見えますが、削られているコストと課金されるコストが別物です。

KDA が削るのは KV キャッシュのメモリ量とデコード時間、つまり推論を提供する側の計算コストです。一方 API で課金されるのはトークン数であり、こちらは記憶設計を変えても減りません。むしろ後述するとおり、K3 は出力トークンが増える方向に働く設計です。

「アーキテクチャが効率的」と「使うと安い」は、別の話として読む必要があります。

トークン消費が壁になる

エージェントハーネス oh-my-openagent の ultrawork モード（引用中の「ultraworker」）で K3 を使った @Comamoca_ の評価が具体的です。

前試しに oh-my-openagent の ultraworker に kimi3 使ってたけど、あまりにトークンの使用量が激しくて今は kimi 2.7 code を使ってる。こっちは思ったより使用量食わないから結構使えそうなのと、性能とのバランスが良いなという感触がある。kimi3 はここぞという時に使う運用なら割といけそう

単価を並べると、この感触には裏付けがあります。

※ Moonshot / Anthropic 公式 API の単価。他プロバイダ経由では異なります。Opus 5 のキャッシュ読み取りは入力の約 1/10。

K3 と K2.7 Code を比べると、入力で約 3.2 倍、出力で約 3.8 倍。しかもここに K3 固有の事情が重なります。K3 は常時 thinking モードで、これを無効化する手段がありません。 そして thinking トークンは出力トークンとして $15/1M で課金されます。つまり単純な問い合わせでも推論トレース分のコストが必ず乗ります。

さらに効くのが、推論量を制御する reasoning_effort の既定値が max だという点です（low / high / max を指定可能）。何も指定しなければ最も多く thinking トークンを使う設定で動きます。

エージェントの自律ループでは呼び出し回数そのものが多くなります。単価差が呼び出し回数で増幅されるわけです。「あまりにトークンの使用量が激しくて」という感触は、この 3 つが重なった結果として説明できます。逆にいえば、K3 を使うなら reasoning_effort を明示的に下げるだけでも効果があります。

一方 K2.7 Code は 2026 年 6 月 12 日公開のコーディング特化モデルで、K2.6 比で thinking トークン消費を約 30% 削減したと報告されています。エージェントの常用モデルとしてバランスが良いという評価は、この設計方針と一致します。

実効コストを試算してみる

単価表だけでは差が実感しにくいので、1 タスクあたりの想定で試算します。入力 50 万トークン（うちキャッシュヒット 80%）＋ 出力 3 万トークンと仮定します。

約 3 倍の差です。注目したいのは K3 側の内訳で、出力が全体の半分以上（$0.45 / $0.87）を占めている点です。ここに無効化できない thinking トークンが乗るため、実際にはこの試算よりさらに出力側へ寄ります。

コスト面で救いになるのは、K3 のキャッシュヒット単価が入力の 1/10 であることです。コーディングワークロードはプロンプト前半が安定しやすくキャッシュヒット率が高いため、実効コストは表の $3.00 よりかなり下がります。また K3 は 20 万トークンを超えるプロンプトに割増料金を設けておらず、100 万トークン全域でフラットです。長文を投げる用途では効いてきます。

使い分けの結論: エージェントの常用ループは安いモデルに任せ、K3 は難所だけに投入する。「ここぞという時に使う」という運用は、単価構造から見ても妥当です。

Kimi K3 と Opus 5 を比べるとどうか

リリース時期の近さもあって、Anthropic の Opus 5 との比較も出ています。@genkAIjokyo の評価は率直です。

KIMI3 しばらく使ってみましたが Opus5 が出てしまったので比較するとやっぱり見劣りします。評判のデザインも私にはあまりピンと来ませんでした。というわけでサブで Claude Pro の課金は継続しようとおもいます

ここは主観的な使用感の領域なので、ベンチマークの数字とは別に読む必要があります。

ただ単価だけ見ると、K3 は Opus 5（$5.00 / $25.00）より入力で 4 割、出力で 4 割安い。つまり「安いから選ぶ」side にいるモデルです。それでも見劣りすると言われる——という構図で、これは数年前とは評価軸が変わったことを示しています。オープンウェイトモデルが「同時期のクローズドなフロンティアモデルと直接比較される」段階に来ている。数年前なら「オープンソースとしては優秀」という留保付きの評価で済んでいた位置に、もう留保が付かなくなっています。

Kimi K3 はローカルで動かせるのか — 結論は「無理」

@Mx_Issue の反応が端的です。

Kimi3 はサイズがテラ級なのか。そりゃあ個人のローカルは無理だね。

これは正確です。vLLM のメタデータでは K3 の最小 VRAM フットプリントは約 1,680 GB と見積もられており、公式のデプロイレシピは GB300 クラスの GPU 8 枚以上を要求します。

ここでネックになるのが MoE の性質です。推論時に活性化するのはトークンあたり 16 エキスパートだけですが、896 エキスパート全体をメモリに載せておく必要がある。「活性パラメータが 1,040 億なら、その分のメモリで足りるのでは」という直感は通りません。

Mac Studio でも、ゲーミング PC でも、小規模なマルチ GPU タワーでも動きません。K3 の「ローカル」は、自前のデータセンター GPU クラスタを指す場合にのみ成立します。個人が使うなら API か Kimi のサブスクリプション経由になります。

規模がひとつ下がると話は変わります。antirez が DeepSeek-V4 Flash を Mac Studio で動かした記録は、巨大 MoE でも構成次第では手元で動く例です。1,680 GB との距離感を掴む対比になります。

オープンウェイトであることと、手元で動かせることは別問題です。DeepSeek-V4（1.6 兆）のときにも同じ構図がありました。K3 は 2.8 兆でさらに一段上がっており、重みが公開されていても規模が上がるほど「実際に動かせる主体」は絞られていきます。

では、いま手元で動く最良のモデルは何か

「K3 は無理」で話を終えると、ローカル実行そのものが絶望的に見えてしまいます。実際はそうではありません。2026 年 8 月時点で、ハードウェアの段階ごとに現実的な選択肢があります。

※ GLM-5.2 のメモリ量は Unsloth の dynamic 量子化 GGUF の実測値。同 8-bit では 810 GB を要します。

ここが本記事の主題と直結します。 オープンウェイトの知能指標で首位に立つ GLM-5.2 は、Z.ai が 2026 年 6 月 13 日に MIT ライセンスで公開した 753B / 活性 40B の MoE です。総パラメータは K3 の 2.8 兆の約 4 分の 1 ですが、dynamic 2-bit なら約 239 GB に収まり、256 GB の統合メモリ Mac 1 台で動きます。K3 の 1,680 GB とは約 7 倍の差です。

そして GLM-5.2 が長文脈をどう処理しているかというと、IndexShare — 軽量なスパース Attention インデクサを 4 層ごとに再利用する仕組み — で 1M トークン文脈のトークンあたり FLOPs を 2.9 倍削減しています。K3 が「KDA + Gated MLA のハイブリッド」で答えた問いに、GLM-5.2 は「インデクサの共有」で答えたわけです。どちらも記憶と参照の設計の話で、そこがそのまま「手元で動くか」を決めています。

24 GB の GPU 1 枚という、より現実的な線ではどうか。Qwen3.6-27B は dense 27B で Q4 なら 17 GB 程度に収まり、SWE-bench Verified で 77.2 を出します。前世代の Qwen3.5-27B の後継で、文脈は 262,144 トークン（拡張時 約 101 万）、Apache 2.0、画像・動画入力にも対応します。コーディング用途に限れば、これがいま最も費用対効果の高い選択肢です。

さらに小さい構成なら、12GB VRAM で動く Gemma 4 12B Coder や、Unsloth による極限量子化で 16〜18 GB に収める手があります。128 GB クラスの統合メモリ機を狙うなら AMD Ryzen AI Max+ 395 のような選択肢もあります。自分の環境で何が動くかは CanIRun.ai で先に確認できます。

結論: 「ローカルで動く最良のモデル」は、最大のモデルではありません。 記憶と参照の設計が自分のメモリ容量に収まっているモデルです。K3 が動かないのは 2.8 兆という数字のせいですが、GLM-5.2 が動くのも 753B という数字のおかげではなく、その設計のおかげです。

なおこの領域は数か月で入れ替わります。本節は 2026 年 8 月時点のスナップショットとして読んでください。

新しいモデルを見るときの 3 つの観点

以上を踏まえると、次にモデルの発表を見たとき確認すべきことは 3 つに絞れます。

1. 何を覚えるか — 長い文脈を全部キャッシュとして持つのか、限られたサイズの状態へ更新していくのか
2. 何を入れ替えるか — 古い情報をどう差し替え、どう薄めるのか（差分更新と減衰の粒度）
3. どこを探し直すか — 圧縮した記憶だけでなく、元の文脈から精密に参照し直す経路が残っているか

Kimi K3 の答えは、1 に対して「主に固定サイズの状態（KDA 69 層）」、2 に対して「成分ごとに細かく調整する」、3 に対して「Gated MLA 24 層を残す」でした。パラメータ数 2.8 兆という数字は、この設計を成り立たせるための器であって、それ自体が答えではありません。

同じ 3 つを GLM-5.2 に当てると、「スパース Attention インデクサを 4 層ごとに共有する（IndexShare）」という別の答えが出てきます。そしてこの設計の違いが、そのまま手元で動くかどうかを決めていました。 3 つの観点は、モデルの賢さを読むためだけのものではなく、自分の環境で動くかを読むための観点でもあります。

そして運用側の答えは、単価構造から出てきます。安いモデルで回して、難所だけ高いモデルに渡す。 モデルの性能表ではなく、呼び出し回数とキャッシュヒット率で決まる話です。

まとめ（数値の整理）

• スペック: 2.8 兆パラメータ / 活性 1,040 億 / 1,048,576 トークン / 93 層（KDA 69 + Gated MLA 24）/ 896 エキスパート中 16 活性化
• アーキテクチャの効果: Kimi Linear 論文では 100 万トークン文脈で KV キャッシュ 75% 削減・デコード約 6 倍。ただし論文のモデルは総 48B で、K3 とは規模が別
• 単価: 入力 $3.00 / 出力 $15.00 / キャッシュヒット $0.30。K2.7 Code の 3〜4 倍で、20 万トークン超の割増はなし
• コストが膨らむ理由: thinking を無効化できず、reasoning_effort の既定値が max。自律ループでは単価差が呼び出し回数で増幅される
• ローカル実行: 最小約 1,680 GB VRAM。896 エキスパート全体をメモリに載せる必要があり、個人環境では成立しない
• 代わりに動くもの（2026年8月時点）: GLM-5.2（753B / 活性 40B）が dynamic 2-bit の約 239 GB で 256 GB Mac に収まる。24 GB GPU 1 枚なら Qwen3.6-27B（Q4 約 17 GB / SWE-bench Verified 77.2）。最良のローカルモデルは最大のモデルではなく、記憶設計が手元のメモリに収まるモデル

参考リンク

• Kimi Linear: An Expressive, Efficient Attention Architecture (arXiv:2510.26692)
• MoonshotAI/Kimi-K3 — 公式リポジトリ
• MoonshotAI/Kimi-Linear — 公式リポジトリ
• Thinking Models — Kimi API Platform（reasoning_effort の仕様）
• code-yeongyu/oh-my-openagent — エージェントハーネス
• zai-org/GLM-5.2 — Hugging Face（ローカル実行可能な最上位オープンウェイト）
• Qwen/Qwen3.6-27B — Hugging Face（24GB GPU 1 枚で動く dense 27B）
• GLM-5.2 をローカルで動かす — Unsloth ドキュメント（量子化別の必要メモリ表）
• Gemma 4 をローカルで動かす — Unsloth ドキュメント