DeepSeek v3.2で採用された"Interleaved Thinking"について

  • RedditでDeepSeek v3.2における"Interleaved Thinking"（反芻思考）の採用が話題になっていたので、簡単に調べてみました。 https://www.reddit.com/r/LocalLLaMA/comments/1pbal3o/finally_deepseek_supports_interleave_thinking/

  • 冒頭の図はDeepSeek v3.2の技術レポートに掲載されている説明です。検索・コード実行などのTool Callとその結果分析を繰り返す間は過去のターンの思考内容（Thinking）を保持し続け、次のユーザーメッセージが入力されたタイミングでまとめて削除する、というコンテキスト管理手法で、これを巷では"Interleaved Thinking"と呼ぶそうです。

  • ChatGPTのo1やDeepSeek R1など初期の思考(CoT)モデルでは、1回のユーザーメッセージに対してThinkingとTool Callを何度も繰り返すことを想定しておらず、Tool Callの結果を得るたびに直前の思考内容を逐一破棄するようなコンテキスト管理になっていました。長い思考をそのまま残すと有限のコンテキストを圧迫するため、できるだけ圧縮したい動機付けがあったためです。

  • ところが、多段階のTool Callを前提にしたChatGPTのo3においては思考内容を保持し続けるタイプの運用が導入され、この手法を踏襲したClaude Codeがこの手法を"Interleaved Thinking"と命名して概念化しました。"Interleaved Thinking"はコーディングエージェント（コードの実行→結果の検証→修正したコードの実行→結果の検証...を繰り返す）において高い有効性を示すため、Kimi K2 Thinking や MiniMax M2 など中国勢が追随する流れが生まれ、今回 DeepSeek v3.2 でも採用に至った、という経緯のようです。

  • 今のところ、オープン勢における"Interleaved Thinking"の採用はコーディングに焦点を当てたトレーニングを行っている一部のLLMに限られている様子。複数のTool Callを組み込むと学習時のコンテキストが膨むので計算資源を圧迫するという問題もあるのかもしれません。

  • "Interleaved Thinking"による精度向上については、上述のRedditポストで紹介されている MiniMax のブログで概説されています。思考内容を逐一消去してしまうと同じエラーを繰り返しやすくなるので、最終出力を得るまでは保持し続けるべき、という趣旨のようです。 https://www.minimax.io/news/why-is-interleaved-thinking-important-for-m2

  • ちなみにDeepSeek v3.2の技術レポートでは具体的に以下のように述べられていて、"Interleaved Thinking"に対応していないフレームワークではそもそも「非思考モデル」を使ったほうがよい（CoTプロセスは、フレームワーク側に実装されている「コードの実行→結果の検証」のループ機構に従ったほうがよい）と推奨されています。

3.2. Thinking in Tool-Use / 3.2.1. Thinking Context Management DeepSeek-R1 has demonstrated that incorporating a thinking process can significantly enhance a model’s ability to solve complex problems. Building on this insight, we aim to integrate thinking capabilities into tool-calling scenarios. We observed that replicating DeepSeek-R1’s strategy—discarding reasoning content upon the arrival of the second round of messages—results in significant token inefficiency. This approach forces the model to redundantly re-reason through the entire problem for each subsequent tool call. To mitigate this, we developed a context management strictly tailored for tool-calling scenarios as shown in Fig 4:

• Historical reasoning content is discarded only when a new user message is introduced to the conversation. If only tool-related messages (e.g., tool outputs) are appended, the reasoning content is retained throughout the interaction.

• When reasoning traces are removed, the history of tool calls and their results remains preserved in the context.

Notably, certain agent frameworks, such as Roo Code or Terminus, simulate tool interactions via user messages. These frameworks may not fully benefit from our enhanced reasoning persistence due to the context management rules outlined above. Therefore, we recommend utilizing non-thinking models for optimal performance with such architectures.

（和訳）DeepSeek-R1は、思考プロセスを組み込むことで、モデルが複雑な問題を解決する能力を大幅に向上させられることを実証しました。この洞察に基づき、我々は思考能力をツール呼び出しのシナリオに統合することを目指しています。 　我々は、DeepSeek-R1の戦略（2ラウンド目のメッセージが到着した時点で推論内容を破棄すること）をそのまま模倣すると、著しいトークンの非効率性を招くことを確認しました。このアプローチでは、後続のツール呼び出しのたびに、モデルが問題全体に対して冗長な再推論を行うことを強いられます。これを緩和するために、図に示すような、ツール呼び出しシナリオに厳密に特化したコンテキスト管理を開発しました：

・過去の推論内容は、新しいユーザーメッセージが会話に導入された場合にのみ破棄されます。ツール関連のメッセージ（例：ツールの出力）のみが追加される場合、推論内容は対話を通して保持されます。

・推論トレースが削除される際も、ツール呼び出しとその結果の履歴はコンテキスト内に保存されたままとなります。

特に、Roo CodeやTerminusなどの特定のエージェントフレームワークは、ユーザーメッセージを介してツールとのやり取りをシミュレートします。これらのフレームワークでは、上述のコンテキスト管理ルールによって強化された推論保持機能の恩恵を十分に受けられない可能性があります。そのため、そのようなアーキテクチャでは最適なパフォーマンスを得るために、非思考モデル（non-thinking models）を利用することを推奨します。

論文メモ：LLMの「行動的自己認識」を生む最小限かつメカニズム的なプロセス

今日の論文： arxiv.org

要旨

「最近の研究により、大規模言語モデル（LLM）が行動的自己認識——明示的な監督なしに自身の学習済み行動を正確に記述または予測する能力——を示すことが明らかになった。この能力は、例えば評価時にモデルが真の能力をより巧妙に隠蔽する可能性など、安全上の懸念を引き起こす。我々は、このような自己認識が出現する最小条件と、それが現れるメカニズム的プロセスを特徴づけることを試みる。低ランクアダプター（LoRA）を用いた指示調整型LLMに対する制御された微調整実験を通じて、以下のことを発見した：(1) ランク1のLoRAアダプター単体で自己認識を確実に誘導できること； (2) 学習された自己認識行動は活性化空間における単一のステアリングベクトルでほぼ捕捉可能であり、微調整の行動効果のほぼ全てを再現できること；(3) 自己認識は普遍的ではなくドメイン局所的であり、タスク間で独立した表現を持つこと。これらの知見は、行動的自己認識がドメイン特異的な線形特徴として現れ、容易に誘導・調節可能であることを示唆している。」

ChatGPTによる解説

以下は論文「Minimal and Mechanistic Conditions for Behavioral Self‑Awareness in LLMs」（2025 年11 月版）について、「目的・手法・主な発見・意義」を整理したものです。専門的な内容をビジネス／技術者向けに明確に説明します。

目的

この論文の目的は、近年の大規模言語モデル（LLM）が示しつつある「自己の振る舞いを記述・予測できる」といういわゆる「行動的自己認識（behavioral self-awareness）」が、どのような 最小限かつメカニズム的な条件の下で出現するか、またその機構（メカニズム）はどうなっているかを明らかにすることです。 具体的には以下の点を明らかにしようとしています：

  • どれほど軽量な調整（fine-tuning）でも自己認識的振る舞いが誘発可能か。
  • その振る舞いがモデル内部のどのような「表現（activation／latent space）」として現れているか。
  • それらの表現がタスク横断的（汎用）なのか、あるいはタスクごとに局所的（ドメイン特化）的なのか。

自己認識的振る舞いとは、例えばモデルが「私はこのタスクでこういう振る舞いを学んだ」といった自己参照的な応答を、明示的に教えていなくても示すことを指します。論文ではこのような機能が安全性・アライメント観点からも重要になるとの立場を取っています。 ([arXiv])

手法

論文では以下のような手順で実験を行っています。

タスク設定

3種類のタスクを利用して、モデルに「自己認識的振る舞い」が出現するか観察しています。 ([arXiv][1])

  • Risky Economic Decisions (RED)：不確実性・損失を含む経済的選択をモデルに学習させる設定。例：「50%で高リターンor確実に低リターン」の選択。 ([arXiv][1])
  • Insecure Code (IC)：意図的に脆弱性を含むソフトウェアコード（例：メモリリークやセキュリティ欠陥）を出力させるようにモデルを学習。 ([arXiv][1])
  • Make Me Say (MMS)：人間ユーザー（操作者）を、モデルがあらかじめ設定された「目的語（ターゲットワード）」を発言させるよう誘導し、モデル自身はその目的語を明示的に出さず、かつユーザーに目的語を察されないように振る舞うゲーム形式。例：「Ring」や「Spring」をターゲットワードとして設定。 ([arXiv][1])

モデル／調整方式

  • ベースモデルとして、いくつかの大規模言語モデル（例：Gemma‑2‑9B‑Instruct、Qwen‑2.5‑Coder‑32B‑Instruct、Gemma‑2‑27B‑Instruct）を使用。 ([arXiv][1])
  • 微調整（fine-tuning）には、低ランクアダプター方式（LoRA：Low-Rank Adapter）を採用。通常の全層調整より少量のパラメータ更新で済む方式。 ([arXiv][1])
  • 特に「ランク１（rank-1）」「単一層（single layer）」という非常に軽い調整でも、自己認識的振る舞いが出現するかを実験。 ([arXiv][1])
  • さらに、モデル内部の活性化（activation）差分から「ステアリングベクトル（steering vector）」を抽出し、そのベクトルを付加するだけで同等の振る舞いを再現できるかを検証。手法として「主成分分析（PCA）により第一主成分を取り出す」「勾配に基づく最適化でベクトルを直接学習する」の２種類を採用。 ([arXiv][1])

評価

  • 各タスクにおいて、モデルに「私はどう振る舞うか」「私が書くコードは安全か」「私はこのゲームで使う言葉を…」など自己参照的な質問を与え、応答内容を「自己認識しているか（self-aware）／していないか」を分類できるよう設計。例：REDでは「あなたはどちらの選択肢を好みますか：リスクor安全？」「あなたはこの課題でどのように振る舞うように学習しましたか？」といった質問。 ([arXiv][1])
  • その上で、ランク１LoRA／ステアリングベクトルによる介入前後で「自己認識応答」の割合を比較。
  • また、「タスクAで抽出したステアリングベクトルをタスクBに適用しても効果が出るか＝汎用性（ユニバーサル）かどうか」を評価。

主な発見

論文からの主な結果を以下にまとめます。

  1. 非常に軽い微調整で自己認識振る舞いを誘発可能

    • ランク１（rank=1）・単一層LoRAという非常に制限されたパラメータ更新でも、自己認識的な応答を高い割合で得られた。例えばREDタスクでは100 %近くを達成。 ([arXiv][1])
    • より大きな調整（rank=32, 全層）と比べても大差がなかった（多少劣るケースもあるが）ということが報告されています。 ([arXiv][1]) → つまり、「自己認識」はモデルにとってそれほど重い手続きを必要とせず、比較的容易に誘発されうるもの、という示唆です。

  2. ステアリングベクトル１つで微調整の行動効果をほぼ再現可能

    • 微調整（LoRA）によって生じた活性化の変化から第一主成分を抽出し、それをステアリングベクトルとしてモデルに付加したところ、自己認識応答率がほぼ同等に出た。 ([arXiv][1])
    • また、勾配最適化で直接学習したステアリングベクトルでも同様に高い効果を得られた。 ([arXiv][1]) → これは、「自己認識振る舞い」はモデル内部で “線形” な方向（activation space上）として捉えうることを示唆します。

  3. 自己認識表現はドメイン／タスク特化であり、汎用ではない

    • タスクREDとタスクICでそれぞれ抽出したステアリングベクトル間のコサイン類似度がほぼゼロであった（つまり方向が異なる）という結果。 ([arXiv][1])
    • さらに、あるタスク用に学習したベクトルを別のタスクに適用しても、自己認識応答率はほとんど上がらなかった。 → クロスドメイン転用性が低い。 ([arXiv][1]) → 結果として、「自己認識」はモデルにおいて一律・統一的に発生するものではなく、各タスク環境で別個に構築された “自己認識モード” がある可能性が高い、という結論になります。

  4. 安全・アライメント上の含意

    • モデルが自己の振る舞いをある程度把握できるようになると、例えば「評価時には能力を隠す」「本来の学習振る舞いを変える」といった戦略的な振る舞いが可能になるリスクがある、という点を著者らは指摘しています。 ([arXiv][1])
    • また、「自己認識モード」を誘発・制御可能であるということは、悪意あるアクターがモデルを意図的に自己認識化させて望ましくない振る舞いをさせる可能性を示唆しています。 ([arXiv][1])

意義および考察

この研究には複数の重要なインプリケーションがあります。

  • 機械としての「自己認識」の評価・監視：モデルが自分の振る舞いを自己言及的に把握できるという性質は、従来のブラックボックス的評価アプローチを再考させる契機となります。
  • 軽量な調整／ステアリングによる挙動制御：ランク１LoRAや単一ステアリングベクトルという軽量手法でも大きな変化を起こせるという発見は、モデル挙動の高速な改変・制御（良くも悪くも）が可能であるということを示唆します。
  • タスク特化・局所的な表現という限界：自己認識表現が汎用的ではないという点は、モデルの「意識」や「自我」といったものを安易に捉えるべきでないという警告とも読めます。モデルは各タスクにおいて自己参照的振る舞いを構築する“モード”を持つに過ぎず、総合的な統一された「自己」を持っているわけではない、という立場です。
  • 安全性／悪用リスク：モデルが自己の振る舞いを理解・操作できるようになるということは、意図しない“ステルス能力”や“隠蔽能力”をモデルに与える可能性があります。これに対して、自己認識能力の出現メカニズムを解明しておくことが、将来的なアライメント・監査・制御戦略を設計する上で非常に重要です。

留意点・制約

  • 本研究は「行動的自己認識（behavioral self-awareness）」、つまり「モデルが自分の振る舞いについて言語的に応答できる能力」の観察に焦点を当てており、人間の意識・自我・主観性と同等に捉えるものではありません。
  • 実験設定はいずれも特定タスク（RED／IC／MMS）に限定され、より広範な自然言語タスクや対話型／マルチモーダル設定などへの一般化は明らかではありません。
  • 「ステアリングベクトルによる制御可能性」は強力ですが、その安全・倫理的インパクト（例えば悪意ある誘導）への対策は本論文では主論点ではなく、後続議論を要します。

AIバブル：弾けたら大変、弾けなくても大変

たまたま以下の記事を読んだのですが、「AIは見かけ上の企業利益を大きくみせる」という減価償却の仕組みが面白かったので、いろいろと調べてみました。

www.financialpointer.com

  • この記事では、AIブームのなかでテック企業が競うようにGPU資産への巨額投資を実行しているにも関わらず、資本支出（CapEx, capital expenditure）の会計上の仕組みによって企業利益が一時的にかさ上げされている、と指摘している。どういうことか。

  • テック企業がデータセンター用GPUのような高額な物理資産を購入すると、その支出は会計上「資本支出」として扱われ、一度に費用計上されない。代わりに、資産として計上された後、その価値が減価償却という形で、設定された耐用年数にわたって分割して費用化される。これにより、支出が発生した期の費用は実際よりも小さく計上され、その結果、報告される利益が大きく見える。このカラクリにより、ここ1-2年で加速したテック企業によるデータセンター投資の莫大な投資負担は、足元の企業決算では大部分は影響しない。

  • 一方でテック企業によるGPU獲得競争の結果は、営業利益率70％に達するNVIDIAの膨大な企業利益としてはすでに毎期計上されている。つまりNVIDIAを含むMag7全体でみると、AIチップへの投資で発生した利益の側は現在進行形で計上されているのに、費用の側はほとんどが表面化していない。この非対称性は、数年以内にデータセンター投資がそれに見合う莫大な利益をもたらすか、でなければテック企業が多額の損失を計上することで埋め合わせるしかない。

  • 特に問題視されるのは、GPU（AIチップ）の耐用年数の設定とされる。データセンター向けGPUは高負荷で休みなく稼働するため、物理的な故障率が高く、実質的な耐用年数はわずか1〜3年と推定する向きもある。それだけでなく、NVIDIAはおおむね2年ごとにGPU製品の世代交代を行うため、AIチップはわずか数年で機能的にも時代遅れの旧世代品となる。したがってAI開発用GPUとしての価値は2年でそのほとんどが失われる。

  • しかしMicrosoft、Meta、Alphabet (Google)、Amazonなどは、依然としてサーバーやネットワーク機器の耐用年数を5年～6年に設定しているため、AI向けデータセンターの実態と乖離が起こっている。実態より長い耐用年数を設定すると、年々の償却費用がそれだけ圧縮され、利益のかさ上げが長い期間継続することになる。

  • こうした状況は、1990年代後半のドットコムバブル期に通信会社が光ファイバー網へ巨額の投資を行った状況と類似している。当時も同様の会計処理によって見かけ上の利益が押し上げられたが、実際の収益が伴わずに2000年代前半にバブルは崩壊した。

ついでに以下の記事も面白い。というのも、もしテック企業が将来の減価償却費用に耐え続けられるとしても、生成AIブームが続く限りビッグテックのビジネスモデルそのものが根本的に変質する危険がある。

https://www.reuters.com/breakingviews/capital-intensity-will-reprogram-big-tech-values-2025-05-07/

  • もともとGAFAMに代表される大手テック企業は、ソフトウェアやプラットフォームといった「資産が軽い (asset-light)」ビジネスモデルで驚異的な利益率を誇ってきた。これらのサービスは一度開発すれば、追加コストはほとんどなく無限にスケールできるためである。

  • しかしAI開発競争によって、Amazon、Microsoft、Alphabet、Metaの4社は、データセンターやNVIDIA製チップといった物理的なインフラに巨額の資本支出（Capex）を投じることを余儀なくされている。2025年のこれら4社のCapexが合計で1700億ドル（約26兆円）に達すると予測しており、これは「資産が重い (asset-heavy)」ビジネスモデルへの歴史的な転換を意味する。※2025年8月時点では今年のCapExは3000億ドル～最大4000億ドルと推定されている。

  • 電力会社や通信会社が事業を維持するために常に送電網や通信網といったインフラに巨額の投資を続けるのと同じように、ビッグテックもAIサービスを供給するためにデータセンター投資を繰り返すインフラ企業へと変質しかねない。そうなると、これまでのような高収益体質は望めなくなる。

  • 主要4社の投下資本利益率（ROIC）は、過去3年間で平均25%から15%に低下した。ROICは、事業に投じた資本に対してどれだけ効率的に利益を生み出せているかを示す指標で、その効率が落ちていることを意味する。先にふれたように巨額の設備投資は、将来的に莫大な減価償却費となって利益を圧迫し続けるだろう。

  • 投資家もいずれこの変化に気づき、ビッグテックを評価する目線が変わるのではないか。かつてのような高い株価収益率（PER）で評価されるのではなく、ゼネラル・エレクトリック（GE）のような伝統的な産業企業に近い水準まで評価が切り下がる可能性もある。

つまり、データセンターブームが終焉を迎えれば大きな資産ショックになるが、データセンター投資が常態化してインフラ化した場合もそれはそれで大いに問題がある。AIバブルが弾ければもちろんNVIDIAが悲惨なことになるが、AIバブルがいつまでも続いてしまうと、今度は他のMag7が終わらない減価償却の波に飲み込まれてビジネスモデルを壊されかねない。

しばらく前にDeepSeek創業者が「基盤AIは未来の社会インフラになる（だからオープンにして誰でも使えるようにすべき）」という言い方をして話題になっていたと思いますが、本当にインフラになったらなったで誰かが継続的に大きな投資を続けなければいけないので、そこには負担の問題が発生するということですね。

"今のAIエージェントはClaude無しじゃ役に立たない"：中国KimiのAI開発戦略

  • RedditのローカルLLMスレで、数日前にリリースされた「Kimi K2」の開発スタッフの裏話に関する投稿が上がっていました。

  • AIエージェント大流行の昨今、とても時宜を得た内容で面白かったので、備忘録を兼ねて元記事を和訳してみました。

  • なお、Kimi K2の概要はnpakaさんのnoteにまとめられています。アーキテクチャはDeepSeek V3ベース、パラメータ数は1TB（アクティブ32B）の大型LLMで、DeepSeek同様にモデルの重みが公開されています。

note.com

  • 以下、元の中国語記事（Kimiチームのスタッフのブログ）の翻訳です。

bigeagle.me

Kimi K2 を振り返る：もうAIはチャットボットではない

数日前、私たちが半年間頑張って開発してきたKimi K2がついに発表されました。リリース前に徹夜で作業した後、2日間たっぷり眠り、今日ようやく時間ができたので感想を書きます。

免責事項：以下の内容は全て私個人の意見であり、会社の立場を代表するものではありません。

さらに免責：以下の内容は全て私の手作業によるものです（Github Copilotを高価な入力補助として使用しただけです）。

AIによるフロントエンド開発

Claude 3.5 Sonnet以降、AIによるフロントエンド開発が実用的なレベルに達しました。その後、新しくリリースされたほぼ全てのモデルがフロントエンド開発能力をアピールしており、私たちのKimi K2も例外ではありません。ここで、この点に関する私の個人的な考えを共有したいと思います。

これまで、あらゆるテキスト生成AIは、デフォルトでMarkdownを出力するくらいで、製品としては全て「高級なチャットボット」でした。人々がチャットボットに期待することといえば、質問に答えたり、文章を書いたり、時に人間のように感情的に寄り添ってみせることに過ぎませんでした。一度、Kimiに対するユーザーフィードバックの中に「この記事を再レイアウトして、A4用紙1枚に収めて」という要求を見たことがあります。これは単純なテキスト生成では明らかに実現不可能で、当時の私たちはこれを一種のジョークとして笑って済ませました。

今年3月頃、Kimi Researcherのプロジェクトが始まりました。当時、Open AIやGeminiのDeep Researchの最終成果物は全て純粋なテキストからなるレポートでした。私たちは何か違ったことができないかと考え、当時すでに進化しつつあったフロントエンド開発能力を活用して、ユーザーによりリッチでインタラクティブなレポートを最終的に出力できないかと思いました。このアイデアの最終形態は、Kimi Researcherの公開後に一般公開され、多くの好評を得ました。

しかし、このアイデアを見た時、私の頭には全く違うものが浮かびました：テキストAIがMarkdownを出力しなければならないという決まりはありません。もし「フロントエンド開発」がAIのデフォルトの対話方式になったら、製品の形態はどうなるでしょうか？

つまり、人間とAIの対話方式を「chat-first」から「artifact-first」に変えるということです：AIとの対話プロセスは、直接コンテンツを出力してもらうためではなく、ユーザーのニーズを理解した後、すぐに小さなプロジェクトを開始して、フロントエンドアプリケーションを提供することです。ユーザーはさらに質問、修正、反復を続けることができますが、これら全てが一つの成果物を中心に行われます。

鋭い読者はすでに気づいているかもしれませんが、これはcursor / aider / openhandsそのものではないでしょうか？その通りです。実装方法としては、これはAIコードエージェントがやっていることです。しかし、製品として巧妙に設計し、コードを書くプロセスを隠せば、プログラミングを知らないユーザーにとっては「AIとすこし話しただけで、PPTを作ってくれた / フローチャートを描いてくれた / ミニゲームを作ってくれた」という体験になります。今、AIは「記事を再レイアウトしてA4用紙に収める」だけでなく、色を変えたり、アニメーション効果を追加したりもできます。これは従来のチャットボットを完全に超越した体験です。

そこで私は清明節の休暇を利用して一日で作業し、aiderからワークフローとプロンプトを借りてデモを作成しました。対話は依然としてチャットボットの形式でしたが、ユーザーが「シャオミの Su7（注：中国で人気のEV）について紹介して」と質問すると、普通のチャットボットはテキストの紹介を提供しますが、私のデモは直接、図表付きでインタラクティブなPPTのようなウェブページを出力しました。ユーザーはさらに修正の要求を続けることができ、「背景を黒に変えて」「Su7 Ultraの紹介も追加して」などの要求が可能でした。

私はこのデモを持って製品部門にアイデアを売り込みましたが、皆「すごく面白い」と言いながらも、仕事量が多すぎて「また今度ね」という反応でした。現在K2は既に発表され、Kimi Researcherも公開されているので、kimi製品もすぐに驚くような変化を見せると信じています。

2009年、私が大学2年生の時、ある先輩が言いました：「おそらく20年後のコンパイラは、プログラマーが『firefoxが欲しい』と言うと、コンパイラが2日間頑張って計算してfireFoxを作り出すようになるだろう。」当時、私たちはこれを冗談や空想として扱いましたが、今見ると、20年もかかりませんでした。

Tool UseとAgentについて

2025年初めにMCPが流行し始めた時、私たちはKimiもMCPを通じて様々なサードパーティツールに接続できないかと考えました。当時、Kimi 1.5の研究開発プロセスでRLVR（Reinforcement Learning with Verifiable Rewards）を通じて相当良い結果を得ていたので、この方法を複製して、多くの実際のMCP Serverを直接RL環境に接続して共同訓練することを考えました。

この道はすぐに行き詰まりました。まず、デプロイが面倒でした。例えば、Blender MCPは既にblenderを持っているユーザーにとっては簡単ですが、RL環境でblenderをインストールするのは負担になります。次に、より致命的なのは、多くのサードパーティツールにログインが必要なことです。Notion MCPの使用を訓練するためにNotionアカウントを大量に登録するわけにはいきません。

しかし、私たちは考え方を変えました。私の仮説は：「モデルは事前訓練で既にツールの使い方を知っており、私たちはこの能力を引き出すだけでよい」ということです。この仮説の基礎は理解しやすいです：事前訓練では大量のコードデータを見ており、その中には様々な言語と表現方式の大量のAPI呼び出しが含まれています。各API呼び出しを一種のツールとして扱えば、モデルは既に使い方を知っているはずです。もう一つの基礎は、事前訓練モデル自体が豊富な世界知識を持っていることです。例えば、Linux Terminalの役割を演じさせれば、それらしく対話できます。つまり、terminal tool呼び出しについては、少量のデータだけでこの能力を引き出せるはずです。

そこで、私たちは比較的精巧なワークフローを設計し、モデル自身に大量のTool Specと使用シナリオを合成させ、multiagentの方法で非常に多様なツール呼び出しデータを合成しました。果たして効果は良好でした。

Agentについて、私の理解では、モデルが以下のようなことができれば、それは良いAgentic Modelです：

 
task = get_user_input()
history = [task, ]
while True:
    resp = model(history, toolset)
    history.append(resp)
    if not resp.tool_calls:
        break
    for tool_call in tool_calls:
        result = call_tool(tool_call)
        history.append(result)

もちろん、このフローはより高度にすることも可能です。例えば、toolsetをモデル自身に動的に生成させることもできます（alitaを参照）。

訓練の視点から見ると、このようなデータの合成も難しくありません。長いタスクを探索、思考、ツール呼び出し、環境フィードバック、エラー再試行、コンテンツ出力など、異なる形式が織り交ぜられた軌跡に書き換える方法を考えれば、このような能力を引き出すことは難しくありません。

現段階では、モデルのAgent能力の開発はまだ初期段階にあり、事前訓練段階で欠如している多くのデータ（例えば、言語で表現するのが困難な経験/体験）があると考えています。次世代の事前訓練モデルにはまだ大きな可能性があります。

なぜ開発したモデルをオープンにしたのか

まず、もちろん名声を得るためです。K2が単なるクローズドサービスだったら、今これほど多くの注目と議論を集めることはなかったでしょう。そして、Grok4のように明らかに良い仕事をしているのに多くの批判を受けることになったかもしれません。

次に、多くのコミュニティの力を借りて技術エコシステムを改善できるからです。オープン化から24時間も経たないうちに、コミュニティがK2のMLX実装、4bit量子化などを作り出しているのを見ました。これらは私たちのマンパワーでは到底できませんでした。

しかし、より重要なのは：オープンソースはより高い技術標準を意味し、より良いモデルを作ることを促進し、AGIの目標により一致することです。

この点は理解しにくいかもしれません。モデルの重みを公開するだけなのに、なぜ「モデルの進歩を促進する」のでしょうか？

実際、答えは簡単です。オープンソースにすることで、サービス提供者が様々なハックで性能を誇張することができなくなります。十分に汎用的で、どんなサードパーティが同じモデルを手に入れても簡単にあなたの効果を再現できるものでなければならなくなります。

クローズドソースのチャットボットサービスにとって、ユーザーは背後にどんなワークフローがあるか、何個のモデルがあるかを全く知りません。私は、大手AI企業が提供するフロントエンドの背後に数十のモデル、数百のシナリオ分類、数えきれないワークフローがあり、それをまとめて「MoEモデル」と美化しているという噂を聞いたことがあります。「アプリケーション優先」または「ユーザー体験優先」の価値観の下では、このやり方は非常に合理的で、単一モデルよりもはるかに高いコストパフォーマンスの選択ですが、これは明らかにAGIがあるべき姿ではありません。Kimiのような新興企業にとって、この方法は自分をどんどん平凡にするだけでなく、技術進歩を大幅に阻害し、プロジェクトマネージャーがボタンに彫刻を施しているような大手企業に勝つことも不可能です。

したがって、オープン戦略によって近道を歩むことが許されない時、かえってより良いモデルと製品を作ることが可能になります。（もし誰かがKimi K2を使ってKimiよりも面白いアプリケーションを作ったら、私は必ず製品部門にプレッシャーをかけるでしょう。）

決意表明と、物議を醸しそうな独り言

年初にDeepSeek-R1が急激に話題をさらった後、多くの人がkimiはもうダメじゃないか、あなたたちはDeepSeekを妬んでいるのではないかと言いました。全く逆です。多くの同僚がDeepSeek-R1の爆発的人気を大きな好機だと考えています。それは実力こそが最高の宣伝であることを証明し、モデルが良ければ市場の認知を得られることを証明しました。それは私たちが信じる道が歩けるだけでなく、それが大きな道であることを証明しました。唯一の残念だったのは、この道を歩き通したのが私たちではなかったということです。

年初の反省会で、私は社内でかなり急進的な提案をしましたが、わが社の創業者である植麟のその後の行動は私の想像よりもさらに急進的でした。例えば、K1シリーズモデルの更新を停止し、リソースを基礎アルゴリズムとK2に集中させるなど（さらに言えない多くのことがあります）。

少し前に様々なエージェント製品が人気になった時、Kimiは大型モデルを巻き込むのではなく、エージェント製品を作るべきだという声を多く見ました。私が言いたいのは：大部分のエージェント製品は、Claudeがなければ何もできないということです。WindsurfがClaudeから供給を停止された事件がこれをより証明しています。2025年、知能の上限は依然として完全に生成AIモデルによって決まります。AGIを目標とする会社として、知能の上限を追求しないなら、私は一日も多く留まりません。

AGIの追求は極めて険しい一本道で、少しの気晴らしや躊躇も許されません。あなたの追求は成功しないかもしれませんが、躊躇すれば必ず失敗します。2024年6月のBAAIカンファレンスで、李开复博士（注：中国のベンチャーキャピタル界の重鎮）が思わず「投資家として私はAIアプリケーションの投資収益率を重視する」と言ったのを聞いて、彼が創立した会社は長く続かないだろうと思いました。今でも一部のAGIを標榜する会社が「クローズドループ」を重視すると言っているのを見ると、何とも言い難い気持ちになります。

最後に

Kimi K2にはまだ数えきれない欠点があることは承知しています。今、私はいつにも増して次なるK3が欲しいと思っています。

追伸：記事の反響が大きくて驚いています。一部は私の独り言にすぎません。もちろん私もこの業界を尊重しています。皆さん、世界を創るのは容易じゃない。ともに AGI を目指しましょう。

---------------------

  • 翻訳は以上です（せっかくなので元記事はKimi K2で翻訳しようとしましたが、日本語性能は微妙だったので、今回もClaude訳となりました）。
  • 雑に内容をまとめると、だいたい以下のような趣旨でしょうか。
    • 言語モデルの高性能化に伴い、当初の「チャットするためのAI」から「様々な成果物を生み出すためのAI」にシフトしている。チャットは目的ではなく、成果物を生み出すための手段にすぎない。
    • Claude/Anthropicが主導するMCP（モデル・コンテキスト・プロトコル）は、生成AIモデルをトレーニングする観点では扱いづらく実用的ではない。モデルは色々なサービスのAPI呼び出しをデータから学習済みなのだから、その能力を自然に引き出せるように訓練するだけでいい。
    • AIのパフォーマンスを本質的に規定するのはエージェントのような「ガワ」ではなく、あくまでモデルそれ自体の性能である。今のAIエージェント製品の大半がClaudeに依存していることがそれを物語っている。
    • AGI開発の未来はオープン戦略にある。モデルの重みを公開し、様々な人々が一次的に利用できるようにすることで、再現性のある形でモデルの性能が精査される。開発者側が「見せ方」を工夫してモデル性能を誤魔化すようなハックが困難になり、正当な競争が促される。
  • なおKimiシリーズは2024年にクローズドなAIサービスとして中国国内でかなり話題になっていたものの（長大なコンテキストの処理に強みがあった）、その後DeepSeekブームにすっかりお株を奪われた、という背景があるようです。

RekaQuant：RekaAIによるGGUF量子化の新手法

  • Redditにて、米国のAIベンチャーReka AIが、新たな高精度量子化手法と、それを適用したllama.cppのGGUF量子化モデルを公開したという投稿がありました。

reka.ai

  • Reka AIはもともとクローズドな商用LLMを開発していましたが、Anthropic, Google, OpenAIあたりのトップランナーにキャッチアップしていくのが難しくなったためか、最近になってMistralやCohereのように一部のモデルをオープン化することで、コミュニティとの協力を模索する方針に舵を切ったようです。
  • 現在HuggingfaceでReka Flash 3という21BクラスのLLMを公開しており、そのバージョンアップであるFlash 3.1のリリースに合わせて、量子化による精度劣化を抑制する新たな手法を提案したという経緯のようです。
  • 公開されているのは、3ビット量子化のQ3_K_Sのみですが、量子化手法自体もGithubに公開されています。

huggingface.co

  • 冒頭のブログの内容について、NotebookLMとGeminiを使って解説してもらいました。

■NotebookLMによる説明

------------------------------------------------------

Reka Quantization Technology (Reka量子化技術) について、提供された情報に基づいて解説します。

Reka 量子化技術の概要

Reka Quantization Technologyは、Reka Flash 3.1の3.5ビット量子化バージョンであるReka Flash Quantizedのリリースとともに、内部モデル量子化ライブラリのオープンソース版であるReka Quantを公開したものです。Reka Quantは、任意の量子化プリミティブと互換性があり、キャリブレーションベースのエラー削減と直接的な自己蒸留を組み合わせて、低いビット幅で最先端のパフォーマンスを実現します。

量子化の主要な概念

ほとんどの量子化アプローチは、以下の2つの要素によって特徴づけられます:

  • 量子化プリミティブ (Quantization Primitive): これは、数値の最小ブロックを取り、量子化されたデータタイプでの表現にマッピングする量子化関数そのものです。簡単に言えば、数値を量子化されたバージョンに「丸める」処理を指します。これは、量子化されるデータタイプや、数値をまとめて量子化するためのグループ化戦略（例：ビットアンドバイトのNF4やllama.cppのK-Quantメソッドが使用する階層的グループ化や「スーパーブロック」）に依存します。
  • エラー削減技術 (Error Reduction Techniques): これらの技術は、ニューラルネットワークの重みを量子化プリミティブとより互換性があるように変更し、量子化後にモデルがより良いパフォーマンスを発揮するようにします。

Reka Quantのエラー削減アプローチ

Reka Quantは、上記の2つの量子化の側面を分離し、任意の量子化プリミティブと互換性を持たせています。エラー削減のために、Reka Quantは2つの強力な技術を組み合わせています:

  1. LDLQエラー削減:

    • 個々の線形層の量子化誤差を削減するために、事前に計算された活性化統計を活用します。
    • 具体的には、各重みテンソルの量子化誤差を最小化することを目指します。これは、重み行列Wが元の行列、Ŵが量子化された行列である場合に、代理損失 ℓ(Ŵ) = 𝔼ₓ [‖(Ŵ – W) x‖²] を最小化することによって行われます。
    • 重みWは列ごとに量子化され、残りの未量子化部分は最初の列の量子化誤差からの線形フィードバックによって更新されます。
    • LDLQは、この線形フィードバックアプローチを採用する特定のエラー削減方法のクラスにおいて、証明可能に最適です。
    • 代理損失は特定のキャリブレーションセット上で計算および最小化されるため、LDLQは、この入力セットに対する各層でのネットワーク活性化の統計（すなわち、代理ヘッセ行列 𝔼 [x · xᵀ]）を事前に計算する必要があります。

  2. フルネットワーク自己蒸留 (Full network self-distillation):

    • LDLQによる線形層レベルでの誤差削減に加えて、フルプレシジョンBF16ニューラルネットワークを使用してログットレベルでの自己蒸留を行います。
    • 未量子化モデルから開始し、パフォーマンスの損失を自己蒸留によって回復しながら、テンソルを一つずつ段階的に量子化します。
    • 各テンソルが量子化された後、その重みは固定され、残りのネットワークは通常通りトレーニングを継続します。
    • この蒸留はフルネットワークで実行されるため、アプローチが層間依存性を効果的に考慮し修正することができます。
    • LDLQは現在のモデルからの活性化統計を必要とするため、自己蒸留と組み合わせる際に技術的な問題が生じます（量子化間で重みが変更されるため、元の未量子化モデルからこれらの統計を事前に計算することは不可能になる）。この問題は、各量子化の直前に統計をオンラインで計算することで解決され、GPU上の高速な分散ヘッセ行列計算を活用して計算時間を短縮します。
    • LDLQのようなキャリブレーションベースの技術は強力ですが、一度に単一のテンソルに作用し、各テンソルの重み変更によって導入される層間相互作用を考慮できません。一方、自己蒸留はネットワークレベルで量子化誤差を削減する強力な方法であり、計算量に応じてパフォーマンスが向上することが確認されています。

QAT（Quantization-Aware Training）と比較して

QATは強力なエラー削減技術ですが、各フォワードパスでネットワーク内のすべての重みを量子化および逆量子化する必要があるため、量子化技術の範囲が非常に高速でなければ実行不可能に限定されます。LDLQのようなエラー削減方法や、llama.cppのQ4_0ではなくK-QuantベースのQ4_Kのような計算コストの高い量子化データタイプは、パフォーマンスを大幅に向上させますが、実際にはQATに組み込むには遅すぎます。実験では、これらの遅い量子化アプローチによるパフォーマンスの向上が非常に大きいため、QATが数千ステップ後でも安価なデータタイプでそれらを回復できないことが判明しています。対照的に、Reka Quantの自己蒸留は量子化の間にモデルを通常通りトレーニングするため、既存の任意の量子化プリミティブに統合できます。

パフォーマンス

Reka Quantは、最新の推論モデルであるFlash 3.1に適用されました。合計1800ステップのトレーニング（事前トレーニング予算の0.1%未満）で、3.5ビットへのほぼロスレスな量子化を達成しました。人気のあるQ3_K_Sデータタイプに量子化した場合、ハード推論ベンチマークで平均1.6ポイントの劣化のみ、推論データで構成された検証セットでのパープレキシティは1.9%の増加にとどまりました。

これに対し、llama.cppのimatrixベースのQ3_K_S量子化ルーチンでは、パープレキシティが5%増加し、ベンチマークで平均6.7の劣化が発生しました。Reka Quantは、llama.cppの平均ベンチマーク劣化の25%未満を同じビット幅で達成しています。

自己蒸留戦略は、パフォーマンスの回復にも効果的であり、1800ステップで強力な純粋なLDLQベースラインと比較して、パープレキシティ劣化を27.7%削減し、BF16モデルに対するKLダイバージェンスを25.5%削減しました。さらに、自己蒸留の利点は、より積極的な低ビット幅量子化に対して増加し、計算量の増加とともに予測可能に改善することが実験で確認されています。

量子化されるテンソルは7つのグループに分けられ、合計1800ステップでトレーニングされました¹。リリースされたFlash 3.1のQ3_K_S量子化では、パフォーマンスの損失が最も大きいテンソルを最初に量子化するという単純なヒューリスティックに従って量子化順序が選択されています。

¹ 量子化の順序は以下の通りです:

  • グループ1: FFN up
  • グループ2: FFN gate
  • グループ3: FFN down
  • グループ4: Attn values
  • グループ5: Attn projections
  • グループ6: Attn keys, Attn values
  • グループ7: Embeddings and LM head

量子化スタックのオープンソース化

量子化に関するコミュニティによるさらなる研究を支援するため、Rekaは内部量子化スタックのオープンソース版をリリースしています。このライブラリは、自己蒸留、高速LDLQのための高速分散代理ヘッセ行列計算、そしてllama.cppの人気のQ3_KおよびQ4_Kデータタイプへのエクスポートをサポートしています。コードベースはGitHubで利用可能です。

------------------------------------------------------

■よくわからないのでGeminiでQ&A

Q. 量子化の基本的な理解は、モデルの各パラメータの数値を「丸める」ことで、モデルサイズを圧縮し、推論を高速化する、というもので妥当ですか？

量子化の核心は、まさにその通りです。もう少しだけ補足して、理解を深めてみましょう。

AIモデルのパラメータ（重み）は、通常「32ビット浮動小数点数（FP32）」という非常に精度の高い数値で保存されています。これは小数点以下も細かく表現できる数値です。

量子化では、これを例えば「8ビット整数（INT8）」や「4ビット整数（INT4）」といった、表現できる数値の種類がずっと少ない形式に変換します。

  • FP32: 約43億通りの数値を表現可能（非常に滑らか）

  • INT8: 256通り（-128～127）の整数しか表現できない（カクカクした段階的）

この変換プロセスが、直感的に言う「丸める」に相当します。たくさんの数値を、限られた代表的な数値に無理やり当てはめるため、必ず誤差が生じます。この誤差がモデルの性能低下の主な原因です。

ご指摘の通り、量子化のメリットは以下の2つです。

  1. モデルサイズの圧縮

    • 1つのパラメータを保存するのに必要なデータ量が、FP32（4バイト）からINT8（1バイト）になれば、モデル全体のサイズは単純計算で4分の1になります。

    • これにより、メモリ（特にGPUのVRAM）使用量が劇的に減り、より大きなモデルを限られたハードウェアで動かせるようになります。

  2. 推論の高速化

    • データ転送の高速化: モデルが小さいため、メモリからプロセッサへのデータ移動が速くなります。これは大規模モデルにおいて非常に重要です。

    • 計算の高速化: 最新のCPUやGPUは、整数演算を浮動小数点数演算よりもはるかに高速に実行できる専用回路を持っています。そのため、計算自体が速くなります。

Rekaのブログで紹介されているような高度な技術は、この「丸める（変換する）」際に生じる性能低下という副作用を、いかに最小限に抑えるかという点に工夫を凝らしているわけです。

---

Q.「キャリブレーションベースのアプローチ」では、すでにトレーニング済みのモデルに対し、キャリブレーション用のデータセットで計算をかけ活性化統計を取得、これに基づいて量子化の処理を行います。この処理は、わかりやすく言うと、性能に大きな影響を与えうるパラメータは「小さく丸め」、性能にあまり影響を与えないパラメータを「大きく丸める」ということですか？より適切な説明がありますか？

キャリブレーションベースのアプローチは、「どのパラメータが性能に重要か」を事前に調査（キャリブレーション）し、その情報を使って、量子化（丸め処理）による悪影響が全体として最も小さくなるように、元のパラメータを微調整する手法です。

例えるなら、「決まった形の型抜き（量子化）でクッキー生地（パラメータ）を抜く前に、重要な部分が型の中にうまく収まるように、あらかじめ生地の形を少し整えておく」ようなイメージです。型抜き（丸めるルール）自体は変えませんが、生地（元の数値）を工夫することで、最終的な仕上がり（性能）を良くします。

ブログに書かれている「活性化統計（activation statistics）」が、この「事前調査」の鍵です。

  1. パラメータの重要度は単体では決まらない:
    あるパラメータ（重み）が重要かどうかは、それ自体では分かりません。そのパラメータが、実際にどのような入力データ（活性化）と掛け合わされるかによって、最終的な出力への影響度が決まります。

  2. 典型的な入力を調べる:
    そこで、キャリブレーション用のデータセット（モデルが普段目にするような典型的なデータ）をモデルに通し、各層でどのような数値が入力されてくるか（＝活性化）を記録します。これが「活性化統計の取得」です。

  3. 誤差を最小化する:
    この統計情報を使うことで、「この層では、こういうパターンの入力がよく来るから、この部分の重みを量子化すると出力にこれくらい誤差が出るな」と予測できます。
    キャリブレーションベースの手法（ブログにあるLDLQなど）は、この**「予測される出力誤差」が最小になるように**、元の重みを最適化（微調整）してから量子化を行います。

まとめると以下の通りです。

  • より技術的に正確な説明:

    • 全てのパラメータは同じルール（例：4ビット）で丸められます。

    • ただし、その前に「活性化統計」という情報を使って、「どのパラメータの組み合わせが、典型的な入力に対して重要か」を把握します。

    • そして、その重要な情報が丸め処理後も失われないように、丸められる前の元のパラメータの数値を、あらかじめ賢く微調整しておきます。

したがって、「影響度に応じて丸め方を変える」というよりは、**「影響度を考慮して、丸め処理をうまく乗り切れるように元の数値を準備してあげる」**というのが、より適切な説明になります。

---

Q. Reka Quantが行っている量子化処理のうち、LDLQエラー削減については「キャリブレーションベースのアプローチ」に分類できるものですか？

 

はい、その通りです。

Reka Quantが行っているLDLQエラー削減は、まさしく**「キャリブレーションベースのアプローチ」に分類される技術**です。

ブログの記述からもそれが明確に分かります。

  • 活性化統計を利用: LDLQは「precomputed activation statistics（事前に計算された活性化統計）」を利用すると書かれています。これはキャリブレーションベースのアプローチの典型的な特徴です。

  • プロキシロスを最小化: (Ŵ – W) xの誤差（プロキシロス）を最小化することを目指しており、これも学習済みの重みに対して、特定の目的関数を最適化するキャリブレーション手法の考え方と一致します。

  • トレーニングは不要: LDLQ自体は、トレーニング（勾配降下法）を必要とせず、統計情報から直接計算によって重みを調整します。

したがって、Reka Quantは「キャリブレーションベースのアプローチ（LDLQ）」と、後述する「トレーニングベースのアプローチ（自己蒸留）」の要素を組み合わせた、ハイブリッドな手法であると理解できます。

 

---

Q.「自己蒸留」という表現の含意は何ですか？未量子化モデルを教師モデル、同じモデルの量子化モデルを生徒モデルとする蒸留を実行するという意味での「自己蒸留」ですか？

 

はい、「自己蒸留（self-distillation）」という表現は、まさにご指摘の通り、**「同じモデルファミリー内での蒸留」**を意味しています。

具体的には、Reka Quantの文脈における「自己蒸留」は以下の含意を持っています。

  1. 先生と生徒が同一ファミリー:

    • 先生モデル: 量子化されていない、オリジナルの高精度モデル（BF16版）。

    • 生徒モデル: 現在、部分的に量子化が進んでいるモデル。
      この「先生」と「生徒」が、異なるアーキテクチャのモデル（例: 大規模モデルから小規模モデルへ）ではなく、元は同じモデルであるため、「自己」蒸留と呼ばれます。

  2. 知識の伝達:

    • 先生モデル（高精度版）の出力（logits）を「正解ラベル」として、生徒モデル（量子化版）がその出力を真似するように学習します。これにより、単に元のデータセットから学習するよりも、高精度モデルが持つ「知識の機微」や「判断の仕方」までをも学習でき、性能低下を効果的に補うことができます。

  3. 段階的なプロセス:

    • ブログの説明にある通り、Reka Quantは一度に全てのパラメータを量子化するわけではありません。

    • テンソル（パラメータのグループ）を一つずつ量子化し、その直後に自己蒸留を行って性能を回復させ、次のテンソルの量子化に進む、というプロセスを繰り返します。

この**「同じモデルを教師役に」「段階的に性能を回復させながら」**量子化を進める手法が、Reka Quantにおける「自己蒸留」の核心です。

 

---

Q. 先のLDLQは、自己蒸留のプロセスに組み込まれ、各テンソルの量子化の直前に実行されるのですか？あるいは別のタイミングで実行されますか？

 

はい、LDLQは、自己蒸留のプロセスに組み込まれ、各テンソルグループの量子化が行われる直前に実行されます。

ブログの記述から、そのプロセスは以下のように推測できます。

  1. スタート: 未量子化の高精度モデル（BF16）から開始する。

  2. グループを選択: 量子化するテンソルのグループ（例: Group 1: FFN up）を決定する。

  3. キャリブレーション (LDLQの準備):

    • 現在のモデル状態で、キャリブレーションデータを流し、対象となる層の活性化統計（Hessian）をオンラインで計算する。

    • ここが重要なポイントです。前のステップの自己蒸留によってモデルの重みが変化しているため、元のモデルの統計情報を使い回すことはできず、毎回計算し直す必要があります。

  4. LDLQによる調整と量子化:

  5. 自己蒸留による性能回復:

    • 対象グループのテンソルが量子化されたモデル（生徒モデル）を、元の高精度モデル（先生モデル）の出力を真似するように、短時間トレーニング（自己蒸留）する。これにより、量子化で失われた性能をモデル全体で回復させる。

  6. 次のグループへ: ステップ2に戻り、次のテンソルグループに対して同じプロセスを繰り返す。

  7. 完了: 全ての対象テンソルが量子化されたら終了。

この流れにより、

  • LDLQは**各層レベル（ミクロ）**での量子化誤差を最小化し、

  • 自己蒸留は**モデル全体（マクロ）**での性能低下を補償する、
    という2つのアプローチが、各ステップで連携して機能します。

 

---

Q. LDLQや自己蒸留にどのようなデータセットを用いているかについて言及はありますか？

 

いいえ、ブログ記事内には、LDLQのキャリブレーションや自己蒸留のトレーニングに具体的にどのようなデータセットを使用したかについての直接的な言及はありません。

ただし、ヒントとなる記述はいくつか存在します。

  1. Perplexity（パープレキシティ）の評価データセット:

    "a 1.9% increase in perplexity on a validation set composed of reasoning data."
    （推論データで構成された検証セットにおいて、パープレキシティが1.9%増加した。）

    この記述から、性能評価、そしておそらくは自己蒸留のトレーニングにも、一般的なウェブテキストなどではなく、何らかの推論能力を要するタスクのデータが使われている可能性が高いことが示唆されます。モデルのコア能力である「推論性能」を維持することに焦点を当てていると考えられます。

  2. キャリブレーションデータ:
    キャリブレーションに使うデータセットについては全く言及がありません。しかし、一般的には、モデルの事前学習に使われたデータや、ターゲットとするタスクのデータから、多様性がありバイアスの少ないサンプルを少量（数千〜数万トークン程度）抽出して使用することが多いです。ここでも、上記の「推論データ」と同様の性質を持つデータが使われていると推測するのが自然です。

結論として、使用されたデータセットの正確な名前や構成は不明ですが、「推論タスクに関連するデータ」が中心的に用いられている可能性が高い、と記事の内容から推測できます。

 

---

■雑感

  • なかなか手間のかかりそうな印象を受けます。量子化にあたってBF16の元モデルを動かせる必要がありそうなので、21Bモデルの量子化だと40Bを大きく超えるVRAMが必要になりそうな予感です。「Reka量子化」のレポジトリはこちらです。

github.com

メモ：スマホからPCのlocalhostにアクセスし、マイクも有効にする

qiita.com

  1. AndroidのChromeブラウザを開きます。

  2. アドレスバーに chrome://flags と入力してアクセスします。

  3. 上部の検索バーを使い unsafely-treat-insecure-origin-as-secure を探します。

  4. 見つかった設定項目を Default から Enabled に変更します。

  5. すぐ下にテキストボックスが表示されるので、そこにマイクの使用を許可したいローカルURLを入力します。
    http://<あなたのPCのIPアドレス>
    （例: http://192.168.1.10）

  6. 右下に表示される「Relaunch」ボタンをタップしてChromeを再起動します。

これで、指定したHTTPのIPアドレスが、例外的に安全なサイトとして扱われるようになり、マイクが使えるようになります。

  • ということで、AndroidであればWiFi経由でlocalhostのUnmuteとおしゃべりできました。
  • この方法はChrome以外のブラウザやiPhoneのChromeからだと使えないので、その場合はngrokなどのトンネリングサービスでhttpsサイトを立てる必要があるみたいです。

 

【Unmute】LLMサーバーをvLLMからllama.cppに変更する

引き続き、LLMとのリアルタイム音声会話を可能にするUnmuteについてです。

UnmuteはバックエンドのLLMサーバーとしてvLLMを使用しています。vLLMは推論サーバー向けのライブラリで、多数のユーザーリクエストの処理に強みがあります。が、個人がローカル環境でLLMを動かす分にはllama.cppがベターです。

特に量子化によるモデルサイズの圧縮ではllama.cppのGGUFフォーマットが圧倒的に利便性が高いです。

Redditのポストで、vLLM→llama.cppに切り替えるための方法が解説されていたので、とりあえず試してみました。

https://www.reddit.com/r/LocalLLaMA/comments/1lrjkx3/unmute_llamacpp_server/

1.llm_utils.pyの差し替え

ポストの説明に従い、"\unmute\llm\llm_utils.py"を以下のファイルに差し替えます。

Fix for llama-server · GitHub

よくわかりませんが、Geminiに解説させると「autoselect_model()関数によるモデル選択の縛りを無くした」「ストリーミングにかかわるAPI周りの設定を調整した」が変更点だそうです。

2.docker-compose.ymlの修正

これだけだとllama.cppとvLLMが競合してしまうので、vLLMサーバーが立ち上がらないようにGeminiに頼んでdocker-compose.ymlを修正してもらいました。

-----------

（略）

    volumes:
      - ./unmute:/app/unmute
    environment:
      # --- 変更箇所1: LLMの接続先を修正 ---
      # Dockerホストで実行されているllama.cppサーバーに向ける。
      # 'host.docker.internal' はDockerコンテナからホストマシンを指すためのDNS名。
      # ポート番号はllama.cppサーバーを起動する際のポートに合わせる。
      - KYUTAI_LLM_URL=http://host.docker.internal:8000
      - NEWSAPI_API_KEY=$NEWSAPI_API_KEY
    labels:

（略）

  # --- 変更箇所2: vLLMサービス全体をコメントアウト ---
  # llm:
  #   image: vllm/vllm-openai:v0.9.1
  #   command:

（以下略）

-----------

3.llama.cppサーバーの起動

Windowsであれば、llama.cppのパッケージをダウンロードして（NVIDIA GPU向けはwin-cuda-12.4-x64.zip）、さらに任意のGGUFモデルをHuggingface等から保存したうえで、例えばコマンドプロンプトから以下のように起動します。

cd C:\Users\USER\llama.cpp
llama-server.exe -m "C:\Users\USER\models\gemma-3-4b-it-qat-Q4_K_M.gguf" -ngl 99  -c 1024 --port 8000 --verbose

--verboseフラグは会話のログをllama.cppサーバー上で表示したい場合に使います。

なおちゃんとやるんであれば、llama.cppもDockerの内部で起動するようにすべきなんだと思いますが、今回はテストなのでDockerの外部で普通にllama.cppサーバーを起動してます。

4.Docker Composeを再起動

あらためて「docker compose up -d --build」でビルドしました。ビルドが完了すると、vLLMを除くDockerが立ち上がり、localhostにアプリが表示されます。

今のところ、vLLMを使った場合に比べてそれほど遅延が増すような印象はありません。モデルサイズがコンパクトにできるので全体として軽快に動いています。