APEXはMoEコーディングモデルにとってなぜ重要なのか、そしてそれがKクオンツとは同じではない理由

Reddit r/LocalLLaMA / 2026/4/6

💬 オピニオンIdeas & Deep AnalysisTools & Practical UsageModels & Research

要点

  • この記事は、MoEコーディングモデルには「コヒーレンス(整合性)」の問題があると主張しています。具体的には、マルチファイルのコーディングセッションでは異なる専門家(エキスパート)が異なるトークンを処理し得るため、共通のブリッジとなる層がないと表現が断片化してしまいます。
  • APEXはMoEに対して有効であり、共有するエキスパート層や注意(attention)層を、ほぼ損失のない精度(例:Q8)で維持しつつ、ルーティングされるエキスパートはトークンごとの発火頻度が低いため、より強く圧縮することで機能すると述べています。
  • 一方で著者は、Kクオンツ(Q4_K_Mのような混合精度)は層をより一様に扱うため、MoEにおける「共有のコヒーレンス層」と「まばらに使われるルーティングされたエキスパート」を区別しない、としています。
  • 著者はさらに、コードにキャリブレーションされたimatrix(約5万件のコードサンプルで訓練)を用いることで、コヒーレンス層のうちどの重みがコード生成、ツール呼び出し、エラー回復に最も効くかをより狙い撃ちできると付け加えています。
  • 本稿では、APEX I-QualityがF16よりも小さなパープレキシティの優位性(6.527 vs 6.537)を報告し、このアプローチが量子化下でもコーディングに関係する機能を保持している証拠として位置づけています。

昨日、QWEN Coder 80B Next の私の APEX 量子化について投稿して、すごくたくさんの良い質問をもらいました。気に入った人もいれば、懐疑的な人もいて、そしてある人が「K量子ってすでに混合精度をやってるけど、じゃあこれの“目的”は正確には何なの?」と聞いてきました。

素晴らしい質問です。ここ数日、手元の自分のハードウェアで APEX を動かしながら深く調べていて、ほとんどの人がここでの“より大きな全体像”を見落としている気がしたので、学んだことを分解して説明したいと思います。

なので結論から言うと、Q4_K_M のような K量子は、すでに層ごとに異なる精度を適用します。注意(attention)は高精度、フィードフォワードは低精度です。これは llama.cpp でも以前からあって、ちゃんと機能しています。

でも、ここが誰も話していないところです。

MoE(混合専門家)モデルにはコヒーレンス問題があります。昨夜この文章を読んでいて、それが腑に落ちました。あなたのコーディングエージェントが複数ファイルにまたがって作業しているとき、異なる専門家が異なるトークンを担当します。衝突(collision)のロジックを処理した専門家と、エンティティの初期化を処理した専門家は、同じ専門家とは限りません。ルーティングは効率的でも、表現が断片化されてしまうのです。

よく考えてみてください。あなたのエージェントがあるファイルに関数を書いて、それが別のファイルの変数を参照しているとします。そしてそれぞれの部分を別々の専門家が担当した。これらを一つにまとめ上げているのは何でしょうか?

共有の専門家と attention 層です。ルーティングで選ばれた専門家が誰であっても、これらはすべてのトークンで発火します。これがコヒーレンス層です。接着剤。これがないと、MoEモデルは複雑なマルチファイルのコーディングセッションで簡単に崩れてしまいます。

ここで APEX がゲームを変えます。

APEX は MoE アーキテクチャを理解しています。共有の専門家と attention を Q8 に保ち、損失ほぼなしに近い状態にします。3% のタイミングでしか発火しないルーティングされた専門家は、それよりもさらに強く圧縮します。長いセッションにわたってエージェントのコヒーレンスを保つのに最も重要な“その層”を正確に維持できているわけです。

標準の K量子は MoE の役割をまったく理解していません。フィードフォワード層があれば、それが毎トークン発火する共有専門家なのか、3% のトークンで発火するルーティング専門家なのかに関係なく、同じように圧縮してしまいます。

そして、ここからさらに良くなります。

私は APEX の量子化を code-calibrated な imatrix で実行しました。サンプルは 50,575 件。Wikipedia でも一般的な雑談でもなく、CODE です。この imatrix は、コード生成、ツール呼び出し、エラー回復の間に、共有コヒーレンス層の中でどの“特定の重み”が最もよく発火するかを APEX に教えます。

つまり最適化は積み重なって 3 層あります:

  1. APEX は、専門家のルーティング全体にわたってコヒーレンスを維持する共有/attention 層を保持する
  2. code の imatrix が、その層のうち実際にコーディング中に発火する重みを優先する
  3. MoE ルーティングによって、各トークンにつき専門家の重みの 97% はアイドルなので、それらはほぼ品質ロスなしで強く圧縮できる

だから Mudler の APEX I-Quality は perplexity で F16 を上回ります(6.527 vs 6.537)。単に圧縮率が低いだけではありません。より賢く圧縮しているのです。コヒーレンス層はそのまま維持され、その他は縮められます。

MoE モデル上でコーディングエージェントを作っている人にとって、これは重要です。かなり。10 ファイルのリファクタリングセッションにおいて、エージェントがコヒーレンスを保ち続けられるかどうかが、まさに“役に立つ出力”と“ゴミ”の違いになります。

APEX はまだとても新しく、たぶん1〜2週間くらい前のものだと思いますが、少ないハードウェア環境の自分のような人にとっては、特に品質と速度の面で、これは間違いなく前進だと信じています

繰り返しますが、私は誰と同じようにこれを学んでいる途中です。ただ、学んだことを学びながら共有したいと思ってここにいます

APEX と LocalAI を作ったことに感謝します:Mudler(Ettore Di Giacinto)。

コヒーレンス問題の“つながり”を理解するのに役立った記事へのクレジット:https://x.com/sudoingX/status/2040836083731333381

code-calibrated な imatrix で行った私の APEX I-Quality の量子化:https://huggingface.co/stacksnathan/Qwen3-Coder-Next-80B-APEX-I-Quality-GGUF

Mudler の APEX リポジトリ(選択肢がたくさんあります)
https://huggingface.co/collections/mudler/apex-quants-gguf

submitted by /u/StacksHosting
[link] [comments]