 | TL;DR: トランスフォーマー内部のMLP層を縮小します（量子化なし、カスタムカーネルなし）そしてARC、HellaSwag、MMLU、TruthfulQAで精度がどの程度低下するかを測定しました。 モデル間で同様の挙動を期待していました。 私たちは間違っていました。 さらに驚くべきことに、元のPPLの改善はベンチマーク上で下流へと伝わりませんでした。 重要な結果いくつかのモデルは他よりもはるかに圧縮可能です。
同じ手法。同じ%の削減。全く異なる結果。 効率のフロンティア(下のチャート) 各ラインは0 → 約40%のMLP削減から圧縮されたモデルです。 結論: 際立った点
これが意味すること「正解の圧縮レベル」は1つではありません。 モデル固有の効率のフロンティアがあります。 例:
なぜこれは有用なのか標準の密なHFチェックポイントを出力します:
この中の小型の密なモデルを1つ選び、さらにそれを量子化することもできます！ 次に探究していること
これを面白いと感じ、こうした圧縮をしてほしいモデルの提案がある人を募集しています。作業には約25分かかるので、あらゆる提案・洞察など歓迎です。 現在、前線を作るためにベースラインを2.0x未満のPPLで使用していますが、異なるSLOを前提とした最適化も容易です。 ユーザーの皆さんが何を求めているのか、インサイトが必要です。 これがかっこいいと思う人と一緒に仕事できることを楽しみにしています。 モデル + コード: https://huggingface.co/dystrio 他の人はどう考えているか興味があります — 実際にこれらのトレードオフをどこで実行しますか？ [link] [comments] |
6つのLLMを圧縮してみたら、意外なことが分かった：劣化の仕方はモデルごとに異なる
Reddit r/LocalLLaMA / 2026/3/17
💬 オピニオンIdeas & Deep AnalysisTools & Practical UsageModels & Research
要点
- 本研究では、トランスフォーマーモデル内のMLP層を圧縮（量子化やカスタムカーネルは用いず）し、ARC、HellaSwag、MMLU、TruthfulQA の各ベンチマークで精度低下を評価している。
- いくつかのモデルは他よりはるかに圧縮に耐えることが分かった。たとえば Gemma 2B は約14%の圧縮でも精度を約92%維持するのに対し、Llama 3.1 8B は同じ水準では約85%まで低下する。
- 元のパープレキシティ改善は、下流のベンチマークには反映されず、圧縮が下流タスクに与える意味についての従来の仮説を覆すものである。
- 結果はモデル固有の効率性のフロンティアを浮かび上がらせる。すべてのモデルは滑らかに劣化するが、その速度は非常に異なり、推論のようなタスクは言語のみのタスクよりも早く低下し、RAG/チャットはより多くの圧縮を許容する。
- 彼らは vLLM/TGI/llama.cpp と互換性のある標準的な Dense HF チェックポイントを提供しており、カスタムカーネルは不要で、量子化と併用可能である。今後のステップとして、モデルごとの圧縮点を自動的に見つけることや、より多くのアーキテクチャへ拡張することが挙げられる。
関連記事
「Google AI Studio」がFirebaseのバックエンドとAntigravityのコーディングエージェントを搭載、プロンプトだけで高度なフルスタックアプリケーションを生成可能に
Publickey
AIエージェントがコマンドラインでブラウザを自動操作できる「Browser Use CLI 2.0」リリース。Chrome DevToolsへの接続などで操作速度が2倍に
Publickey
半導体FABにLLMを持ち込んだら何が起きるか — ArXiv論文5本を現場目線でぶった斬る
Qiita
エッジコンピューティングとローカル処理への大規模な移行
Dev.to
仕様駆動開発における自己改良エージェント
Dev.to
