Daedalus-150M：アテンションの2/3を畳み込みに置き換えた、CPU推論専用設計の小型言語モデル

はじめに：なぜ「CPUで速く動くこと」が革新的なのか

大規模言語モデル（LLM）の推論環境といえば、まずGPUが思い浮かぶ。実際、データセンターでは何十台ものGPUを並べて高速な応答を実現している。しかし、個人のノートPC、スマートフォン、ラズベリーパイのようなエッジデバイス、あるいはGPUを調達できない予算制約のあるプロジェクトでは、CPUでLLMを動かさざるを得ない。この「CPU推論のシナリオ」は決してニッチではなく、むしろLLMの民主化にとって必須の要件である。

従来の小型言語モデル（SLM）は、大きなモデルを訓練してから後でCPUに押し込むという「後付け」のアプローチを取ってきた。しかし、CPUとGPUでは推論時の物理的制約が根本的に異なる。GPU推論は大きなバッチサイズで多数のリクエストを同時処理できるのに対し、CPU推論は1ユーザー・1トークンずつの逐次処理（バッチサイズ1）が基本となる。メモリ帯域幅もCPUはGPUの数分の一から数十分の一であり、演算性能よりもデータ転送速度が先にボトルネックになる。

Daedalus-150Mはこの認識を逆転させる。「デプロイ先から逆算したアーキテクチャ設計」という発想の転換のもと、最初からCPU推論の物理的制約に合わせてモデルを設計した点が革新的だ。その核心は、Transformerのアテンション機構の3分の2を、短い畳み込み（depthwise conv1d、カーネルサイズ3）に置き換えるという大胆な判断にある。これによりKVキャッシュの線形成長というTransformer最大の弱点を回避し、コンテキスト長によらず一定の推論コストを実現している。

本記事では、このDaedalus-150M論文の技術的詳細——なぜ畳み込みがCPUで有利なのか、どのように品質を維持しながら速度を引き出したのか、そして実際にどう使うのか——を深掘りする。

CPU推論の3つの原理的課題

大規模言語モデルの推論環境としてGPUが主流である一方、個人ユースやエッジデバイスではCPUでの実行が求められる。しかし、CPUでLLMを動作させる際には、GPUでは意識しにくい3つの原理的な制約が立ちはだかる。これらを理解することで、Daedalus-150Mの設計判断——「なぜアテンションの2/3を畳み込みに置き換えたのか」——の根拠が明確になる。

バッチサイズ1の世界

GPU推論の高速性は、多数のリクエストを同時に処理する「バッチ処理」に支えられている。複数ユーザーのクエリをまとめて処理すれば、重みのメモリロードコストを一度の転送で償却できるからだ。しかし、個人ユースの対話シナリオでは、1人のユーザーが1トークンずつ逐次的に生成する「バッチサイズ1」の処理が基本となる。

バッチ処理ができないということは、モデルの重みをメモリから読み込む際のコストを、複数のクエリで分散できないことを意味する。その結果、スループットはCPUの演算性能（FLOPS）ではなく、1トークンを生成する間にどれだけのバイト数をメモリから読み込まなければならないかによって決定される。言い換えれば、CPU推論の実効速度は「算術演算の速さ」ではなく「データ転送の効率」で決まる世界なのだ。

メモリ帯域幅が先にボトルネックになる

現代の汎用CPUは、GPUと比較して演算性能に対するメモリ帯域幅が相対的に乏しい。例えば、一般的なデスクトップCPUのメモリ帯域幅は50〜80GB/s程度であるのに対し、GPU（RTX 5090など）は1,000GB/sを超える。この差は、LLMのように巨大な重みテンソルを逐次読み込む処理で顕著に現れる。

CPU推論で有利なアーキテクチャは、「より多くの演算を、より少ないバイト数で実行できる」設計である。つまり、同じパラメータ数でも、重みテンソルが小さく、かつ再利用効率の高い演算子で構成されるモデルのほうが、メモリ帯域幅の制約下では高速に動作する。この観点で、フルアテンション機構は全タイムステップの情報を保持する大規模なKVキャッシュを必要とするため、CPUの帯域幅制約に最も適合しにくい演算子の一つと言える。

KVキャッシュの「成長する税金」

Transformerのアテンション機構では、過去の全トークンのKey（K）とValue（V）をキャッシュとして保持し、新しいトークンを生成するたびにその全キャッシュを読み込んでソフトマックス演算を行う。このKVキャッシュのサイズはコンテキスト長に比例して線形に増加する——つまり、会話が長くなればなるほど、トークンあたりのメモリアクセス量が増え、生成速度が低下する。

この「成長する税金」とも言える特性は、CPU推論において深刻な影響を及ぼす。GPUでは高いメモリ帯域幅とバッチ処理によってこのコストを吸収できるが、CPUのバッチサイズ1の環境では、コンテキスト長が2048トークンに達した時点で、KVキャッシュの読み込みが推論時間の大部分を占めるようになる。これこそがDaedalus-150Mが狙い撃ちにした設計レバーであり、アテンションの大部分を「コンテキスト長に依存しない」畳み込みに置き換える判断の正当化根拠となっている。

Daedalus-150Mのアーキテクチャ

全体像：18ブロック中12ブロックが畳み込み

Daedalus-150Mは18のブロックで構成され、そのうち12ブロックがdepthwise conv1d（カーネルサイズ3）による畳み込み層、残り6ブロックが通常のアテンション層である。ブロックの配置は以下の通りだ（A＝アテンション、C＝畳み込み）。

block-beta
  columns 18
  C1["C"] C2["C"] C3["C"] C4["C"] A1["A"] C5["C"] C6["C"] A2["A"] C7["C"] A3["A"] C8["C"] A4["A"] C9["C"] A5["A"] C10["C"] C11["C"] A6["A"] C12["C"]
  style C1 fill:#6abf69,color:#000
  style C2 fill:#6abf69,color:#000
  style C3 fill:#6abf69,color:#000
  style C4 fill:#6abf69,color:#000
  style C5 fill:#6abf69,color:#000
  style C6 fill:#6abf69,color:#000
  style C7 fill:#6abf69,color:#000
  style C8 fill:#6abf69,color:#000
  style C9 fill:#6abf69,color:#000
  style C10 fill:#6abf69,color:#000
  style C11 fill:#6abf69,color:#000
  style C12 fill:#6abf69,color:#000
  style A1 fill:#e07070,color:#000
  style A2 fill:#e07070,color:#000
  style A3 fill:#e07070,color:#000
  style A4 fill:#e07070,color:#000
  style A5 fill:#e07070,color:#000
  style A6 fill:#e07070,color:#000

モデル次元（d_model）は768、FFN（Feed-Forward Network）の中間次元は2048である。標準的なTransformerではFFN次元をd_modelの4倍（すなわち3072）に設定するのに対し、Daedalusは約2.67倍に抑えている。語彙サイズは49,152とやや過大だが、タイド埋め込み（入力と出力の埋め込みを共有する手法）によりパラメータの一部を節約している。コンテキスト長は2048トークンである。

短い畳み込みブロックの仕組み

畳み込みブロックの中核は、チャネルごとに独立したdepthwise conv1d（カーネルサイズ3）である。この演算子は、各チャネルが直近の2タイムステップ分の情報だけを保持すれば動作するため、保持すべき状態量がコンテキスト長によらず常に一定だ。つまり、トークン2000個目の処理コストが2個目と同じになる。

flowchart LR
    A["入力"] --> B["in_proj<br/>(線形写像)"]
    B --> C["depthwise conv1d<br/>kernel=3, チャネル独立"]
    C --> D["ゲーティング<br/>(B, C による入力依存制御)"]
    D --> E["out_proj<br/>(線形写像)"]
    E --> F["出力"]

畳み込みブロックにはゲーティング機構（B, C）が組み込まれており、入力に依存した動的な動作を可能にしている。これにより、単なる固定フィルタ以上の表現力を持つ。CPU推論の観点では、何より「すべてのトークンで計算量が一定」という特性が決定的に重要だ。KVキャッシュのようにコンテキストが長くなるほどデータ読み込み量が増える構造を持たないため、メモリ帯域幅のボトルネックに直接対処できる。

なぜ6層だけアテンションを残したのか

純粋な畳み込みだけでは、長距離の情報検索——例えば「文中の離れた位置にある単語Aと単語Bの関係を正確に紐づける」associative recall——が原理的に困難である。Daedalusは18ブロック中6層のアテンションを深さ方向に分散配置することで、表現の各レベルで検索能力を確保している。アテンション層の配置パターン（4, 7, 9, 11, 14, 17層目）は、下層・中層・上層に均等にアテンションが行き渡るよう設計されており、畳み込みブロックが局所的なパターン認識を、アテンションブロックが大域的な依存関係の捕捉を分担する役割分担が成立している。

補完的な効率化手法

アテンション層にはGrouped-Query Attention（GQA） を採用している。12個のクエリヘッドに対してKVヘッドは4個にグループ化され、KVキャッシュの容量を標準のマルチヘッドアテンション比で1/3に削減する。加えてFFNの中間次元を2048と狭く設計することで、パラメータを深さとアテンション層に振り向け、メモリ帯域幅を消費する大きなテンソルの転送を回避している。これらの工夫が積み重なり、全体として18層という深さを維持しながらCPU推論に特化した設計を実現している。

徹底比較実験：密な双子モデルとの正対決

Daedalus-150Mの核心的な主張は「アテンションの2/3を畳み込みに置き換えても品質は同等であり、速度は決定的に勝る」というものである。この主張を検証するために、論文では極めて厳格な比較実験を実施している——パラメータ数が0.5%以内にマッチした24層オールアテンションの「密な双子（dense twin）モデル」を同一データ・同一訓練スケジュールで学習し、両者を公平に比較している。

事前登録された勝利条件

この実験の特筆すべき点は、評価基準が事後的に決められたのではなく、両モデルをスコアリングする前に文書化されていたことである。勝利条件は「検証BPB（Bits Per Byte）で0.5%以上の差をつけること」と事前に設定された。BPBは、モデルがデータをどれだけ効率的に圧縮できるかを測る指標であり、値が小さいほど優れている。この「事前登録」プロトコルは、後付けの合理化——実験結果に合わせて評価基準を調整する——を防ぐための厳格な措置である。同一の評価ハーネスを用い、どちらかに有利な評価設定を排除することで、比較の公平性を担保している。

品質の結果

下表は、両モデルを5Bトークン訓練した時点での品質比較である。

事前登録された主要指標である検証BPBでは、ハイブリッドモデルが0.81%優勢であり、0.5%の勝利閾値をクリアしている。この差は一見小さく見えるが、同一アーキテクチャで同一データを訓練した双子モデルに対する勝利である点に注意が必要である——アーキテクチャを変えただけで品質が同等以上に保たれたことを意味する。

一方、5タスク平均では密な双子が名目上0.14ポイントリードしている。しかし論文はこの差を「ノイズ範囲（約0.24σ）」と評価しており、統計的に有意な差ではない。正直な要約は次の通りである：品質は実質的に同等であり、速度で決定的な優位を獲得した。

CPU推論速度の結果

品質が同等であることが確認できたなら、次は速度である。CPU推論におけるスループット（1秒あたりに生成できるトークン数）を、コンテキスト長を変えながら測定した結果が下表である。

この表の形状こそが実験結果の本質である。コンテキスト長0（空のプロンプト）では速度差は1.20倍と小さい。なぜなら、この条件ではKVキャッシュが存在せず、アテンション層のコストがほとんど発生しないからである。しかしコンテキストが長くなるにつれて、密な双子モデルではKVキャッシュの読み込みコストが線形に増加し、スループットが急激に低下する。対してハイブリッドモデルでは、12層の畳み込みブロックがコンテキスト長の影響をまったく受けないため、低下の度合いが緩やかである。その結果、最大コンテキスト長2048トークンでは1.76倍もの速度差が生じる。

このパターンは単なる数値上の優位ではなく、アーキテクチャの原理的差異がそのまま速度差として現れたものと言える。

xychart-beta
    title "コンテキスト長 vs デコードスループット"
    x-axis ["0", "512", "2048"]
    y-axis "スループット (tok/s)" 0 --> 1200
    line "ハイブリッド (Daedalus)" [1112, 960, 739]
    line "密な双子 (24層アテンション)" [923, 664, 420]

なぜ単純な帯域幅計算では説明できないのか

興味深いのは、この1.76倍という速度差が、純粋なメモリ読み込みバイト数の差だけでは説明できない点である。単純なバイトカウントに基づく試算では、コンテキスト長2048においてハイブリッドモデルの優位は約1.17倍にとどまる。実測値1.76倍との乖離はどこから生じるのか。

その原因は二つある。第一に、ソフトマックスリダクションのレイテンシ依存性である。アテンション層ではソフトマックス演算のために全タイムステップのスコアを一旦リダクション（集約）する必要があり、この演算はコンテキスト長が長くなるほどレイテンシの支配的要因となる。第二に、層数の差である。密な双子は24層なのに対し、ハイブリッドは18層であり、層数そのものが少ないことで逐次的な演算パイプラインが短くなる。

この差が持つ実用的な含意は大きい。改善の源泉は「単なるメモリ節約」を超えたところにある——保持しないキャッシュは最適化する必要すらなくなる。KVキャッシュを持たない畳み込みブロックは、キャッシュ管理のオーバーヘッド、メモリアクセスの競合、ソフトマックス演算のレイテンシといった副次的なコストをすべて排除する。これこそが、Daedalusの「アテンションの2/3を畳み込みに置き換える」設計判断が、単純なパラメータ削減以上の効果を生む理由である。

訓練レシピ：59.9Bトークン、46ドル、1枚のRTX 5090

データ構成

Daedalus-150Mの訓練には、16.9Bユニークトークンからなる10ソース混合コーパスが使用された。教育・推論に重点を置いた構成が特徴で、最大のシェアを占めるのはFineWeb-Edu（37.5%）、次いでDCLM-baseline（22.5%）、Stack-EduのPythonコード（9%）と続く。補助的にFinePDFs-Edu（8%）、FinePhrase（7%）、Cosmopedia-v2（5%）、FineMath＋InfiWebMath（6%）、FineWiki-en（3%）、everyday-conversations（2%）が加わる。各ソースには4エポックの上限が設定されており、特定のデータが過度に繰り返されるのを防いでいる。総トークン数は59.9B——これは16.9Bユニークトークンに対して約3.5エポックの学習に相当する。

学習率スケジュールにはWSD（Warmup-Stable-Decay）が採用された。WSDは3つのフェーズからなる：最初に学習率を目標値まで上昇させるウォームアップ、一定の学習率を維持する安定フェーズ、そして最後に学習率をゼロまで線形減衰する減衰フェーズである。Daedalusでは、全訓練ステップの前半55%をウォームアップ＋安定フェーズに割り当て、最終45%を線形減衰に充てている。この「減衰に多くのステップを割く」設計により、モデルは広いパラメータ空間を探索した後、低学習率領域で安定した収束に至る。

graph LR
    subgraph WSDスケジュールの3フェーズ
        A[ウォームアップ<br/>学習率 0→目標値] --> B[安定フェーズ<br/>学習率 目標値で一定]
        B --> C[線形減衰<br/>学習率 目標値→0]
    end
    style A fill:#e1f5fe,stroke:#0288d1
    style B fill:#fff9c4,stroke:#fbc02d
    style C fill:#fce4ec,stroke:#d32f2f

コストとスケーリング

訓練ハードウェアは**1枚のRTX 5090（32GB）**のみ。GPU時間の推定コストは約46ドルである。59.9Bトークンの訓練で、MobileLLM-125M（1Tトークンで訓練）の約1/17のデータ量ながら、同等以上の品質を達成している。この「データ効率の高さ」は、アーキテクチャの工夫だけでなく、データキュレーションとスケジュール設計の貢献も大きい。

オプティマイザには、行列重みにMuon、埋め込み・正規化・バイアスにAdamWというハイブリッド構成が採用されている。Muonは近年注目される最適化手法で、大規模モデルにおいてメモリ効率と収束速度の両面でアドバンテージがあるとされる。

ポストトレーニング

事前訓練済みのベースモデルに加えて、チャット対応のインストラクトモデルも提供されている。パイプラインは2段階である。第一段階として、smol-smoltalkデータセットによる教師ありファインチューニング（SFT）で、モデルに指示追従能力を獲得させる。第二段階として、UltraFeedbackデータセットを用いた1ラウンドのDPO（Direct Preference Optimization）で、モデルの応答品質を人間の選好に沿うように調整する。チャットテンプレートはllama.cpp標準のchatml形式で、既存のllama.cppユーザーが追加の設定なしで利用できる。

この訓練レシピ全体を通じて特筆すべきは、「極めて低コスト」でありながら「再現可能な研究」として成立している点である。一枚のコンシューマーGPUで数日程度の訓練時間で訓練可能なため、アカデミアや個人研究者による追試・改良のハードルが極めて低い。

実際の使い方：llama.cppで3ステップ

Daedalus-150Mはllama.cppで動作するGGUF形式で提供されており、わずか3ステップで手元のPC上で対話を開始できる。以下、macOSを例に手順を解説する。

インストールと実行

最初にllama.cppをインストールし、モデルファイルをダウンロードして、実行する——これだけである。

# ステップ1：llama.cppのインストール
brew install llama.cpp

# ステップ2：量子化モデルのダウンロード
hf download Unseen1980/daedalus-checkpoints instruct/model-q4_0.gguf --local-dir ~/daedalus

# ステップ3：対話モードで実行
llama-cli -m ~/daedalus/instruct/model-q4_0.gguf -cnv

-cnv フラグは対話（チャット）モードを指定する。初回のプロンプトが表示されたら、そのまま会話を始められる。

4ビット量子化（q4_0）のGGUFファイルのサイズは102MBである。これはスマートフォンの一般的なアプリ1つ分と同等であり、ラズベリーパイやノートPCの空きストレージにも十分収まる。2048トークン分のKVキャッシュを追加しても約12.6MBで、モデル全体のメモリ使用量は128MBを超えない。

CPUスレッド数はデフォルト設定でも問題なく動作するが、明示的に指定する場合は --threads 8 程度が推奨される。ただしDaedalusの推論はメモリ帯域幅がボトルネックとなるため、スレッド数を増やしても帯域幅が飽和するまでは効果がある。

注意点

ベースモデル（base/model-q4_0.gguf）にはチャットテンプレートが組み込まれていない。テキスト補完専用であり、プロンプトをそのまま与えて続きを生成させる用途に適している。対話用途には instruct/model-q4_0.gguf（チャットモデル）を使用する必要がある。

また、--repeat-penalty 1.15 の指定が推奨される。llama.cppのデフォルト値（1.0）では同じトークンが繰り返されやすいため、このパラメータで適度な繰り返し防止を適用することで、より自然な応答が得られる。

LinuxやWindowsでもllama.cppをソースからビルドして同様に利用できる。ビルド手順はllama.cpp公式リポジトリのドキュメントを参照されたい。

正直な限界：論文が自ら認める5つの問題

優れた研究は自らの弱点を正直に報告する。Daedalus-150Mの論文は、5つの明確な限界を自ら挙げている。これらはいずれも「設計思想の根本的な誤り」ではなく、エンジニアリング上の改善で解決可能な問題であり、次バージョンへの具体的な宿題として整理されている。

畳み込みチャンネルの約48%が死んでいる

学習後の解析により、畳み込みブロックのチャンネルのうち約48%（13.6Mパラメータ）が事実上不活性であることが判明した。これはモデル全体の8.5%に相当する非効率であり、同じパラメータ予算をより有効に使えた可能性を示唆する。

論文著者は構造的プルーニング（重要でないチャンネルを物理的に削除する手法）を試みたが、llama.cppのテンソル形状チェックがエクスポートを阻み、断念している。この問題の解決策は「次のモデルの初期化と正則化」に属する——つまり死んだチャンネルを最初から生成しないよう、学習率や正則化の調整で対処する方向性が示唆されている。

4ビット量子化が計画通りに動かなかった

量子化認識訓練（QAT：量子化による精度劣化を訓練時に考慮する手法）を、訓練の最終5%の期間に適用する計画だった。しかし、QATを有効にした最初のステップで損失が発散し、実行を断念せざるを得なかった。

結果として、事後量子化（PTQ）による4ビット変換を適用したが、パープレキシティは約6%劣化した。目標値は2.5%だったため、計画を大きく下回る結果である。ただし、f16（16ビット浮動小数点）の重みは公開されており、適切な量子化手法（Q4_K_Mなど）を選べば改善の余地がある。

語彙サイズが大きすぎる

Daedalus-150Mの語彙サイズは49,152エントリであり、最適とされる24,000〜32,000の範囲を大きく超えている。全パラメータの23%を埋め込みテーブルが占めており、タイド埋め込み（入出力の埋め込み共有）で半分を回収しているとはいえ、約13Mパラメータが事実上の無駄になっている。

この原因は、過去の蒸留計画から継承したtokenizerをそのまま流用した点にある。新しいtokenizerを訓練する手間を省いた結果、パラメータ効率に明確な代償が生じた。

実験の限界：単一シード、英語のみ、混合比ドリフト

すべての実験結果は単一の乱数シードからの一点推定であり、信頼区間や標準偏差が付随しない。また、訓練データは英語のみ、コンテキスト長は2048トークンに固定されている。多言語対応や長いコンテキストでの性能は未検証である。

さらに、訓練コーパスの混合比が事前登録された上限（10.0）を超え、実際には10.42に達した。これはソースごとのエポック上限を厳守した結果、全体のトークン配分が計画よりずれたことによる。論文はこのずれを正直に報告しているが、事前登録プロトコルの厳密性という観点からは残念な逸脱である。

正直さがもたらす信頼性

これら5つの限界は、いずれも「論文が読者に隠している問題」ではなく、「論文自らが開示している課題」である。特にQATの失敗や死んだチャンネルの発見は、公表しないほうが評価に有利だったかもしれない情報だ。この透明性は、事前登録プロトコルやパラメータマッチングと並んで、Daedalus論文が「再現可能で誠実なAI研究」の模範たり得る所以である。

なぜこの論文が重要なのか——3つの貢献

Daedalus-150M論文の価値は、単一のモデルを提案したことに留まらない。その背後にある3つの貢献が、小型言語モデルの研究と実用の両方に新たな参照点を打ち立てている。

設計哲学の転換

第一の貢献は、「大きなモデルを後から圧縮する」のではなく、「デプロイ先の物理的制約から逆算してアーキテクチャを設計する」という方法論の提示である。従来の小型言語モデルは、GPU向けに設計された大規模Transformerを後から蒸留・量子化・枝刈りすることでCPUに押し込んでいた。これに対しDaedalusは、CPU推論の原理的制約——メモリ帯域幅が演算性能より先にボトルネックになること、KVキャッシュがコンテキスト長に比例して線形に増加すること——を第一原理から考慮し、アテンションと畳み込みの比率そのものを設計変数として定めている。この「デプロイ環境から逆算する」思考は、エッジAIやオンデバイス推論の分野における設計パラダイムの転換点と言える。

厳密な実験プロトコル

第二の貢献は、再現可能なAI研究の模範となる実験設計である。著者は、パラメータ数が0.5%以内にマッチした24層オールアテンションの「密な双子モデル」を同一データ・同一訓練スケジュールで育成し、両者をスコアリングする前に勝利条件（検証BPBで0.5%以上の差）を文書化している。これにより、結果に合わせて後から解釈を調整する「後付けの合理化」を防止している。さらに、評価は同一ハーネスでの再スコアリングによって行われ、コード・モデル・評価結果のすべてが公開されている。この水準の透明性は、再現性危機が叫ばれる機械学習研究において特に重要である。

実用的な成果

第三の貢献は、品質を犠牲にしない実用的な速度向上である。24層中6層だけがKVキャッシュを持つアーキテクチャにより、2048トークンのコンテキストで密な双子比1.76倍、外部135Mモデル比2.08倍の推論速度を達成した。品質面でも検証BPBで0.81%の優位を示し、5タスク平均ではノイズ範囲内で同等である。モデルサイズは4ビット量子化で102MB、KVキャッシュ込みでも128MB未満と軽量で、llama.cppによる即時実行が可能である。コード・モデル・評価結果がApache 2.0ライセンスで完全公開されており、研究用途と実用用途の両方に即座に利用できる点も、この貢献を支える重要な要素である。

よくある質問

Daedalus-150Mは既存のどんなモデルの代わりになる？

GPT-2 124MやPythia-160Mと同サイズ帯のモデルで、CPU推論に限ればこれらより格段に高速である。特に長い会話や文書処理において顕著な速度差がある。品質面ではこれらのモデルを上回りつつ、SmolLM2-135M（2Tトークン訓練）には品質で及ばない——これは設計上のトレードオフである。

畳み込みとアテンションのハイブリッドって、MambaやRWKVと同じ？

同じ「固定サイズ状態」の系列モデルファミリーに属する。違いは、Daedalusが選択した「演算子」が非常に短いdepthwise畳み込み（カーネルサイズ3）である点だ。これはllama.cppなどの既存のCPU推論ランタイムに新しい演算子を追加せずに実装できる利点がある。Mambaのselective scanやRWKVの線形アテンションとは異なるアプローチである。

実際に自分のPCで動かすにはどうすればいい？

macOSなら brew install llama.cpp と hf download の2コマンドでGGUFファイルを取得し、llama-cli で対話開始できる。4ビット量子化モデルは102MBなので、スマートフォンでも十分動作可能である。Linux/Windowsでもllama.cppをビルドして同様に使える。

なぜ「6%のパープレキシティ劣化」を許容しているの？

量子化認識訓練（QAT）の実装が初ステップでクラッシュしたため、事後量子化（PTQ）を余儀なくされた。f16の重みが公開されているので、適切な量子化形式（Q4_K_Mなど）を選べば改善可能である。論文はこの失敗を正直に報告しており、再現性と透明性を重視している。

このモデルは研究用途？それとも実用的？

両方である。実用的には102MBのサイズでCPU上で対話可能なチャットモデルとして使える。研究的には「デプロイターゲットから逆算したアーキテクチャ設計」という方法論の実証例として価値がある。コード・データ・評価結果がすべて公開されている再現可能な研究でもある。

まとめ：Daedalusが示した「考え方の転換」

Daedalus-150Mがもたらした最大の貢献は、新しい演算子や画期的なアルゴリズムの提案ではない。そうではなく、「デプロイ先の物理的制約からアーキテクチャの比率を逆算する」という設計方法論そのものにある。従来の小型言語モデルは、大規模モデルで確立されたTransformerアーキテクチャをそのまま縮小し、後から量子化や蒸留でCPUに押し込むアプローチが主流だった。Daedalusはこれを逆転させ、「CPUというデプロイ環境が持つ物理的なボトルネックとは何か」を第一原理から問い直した。

CPU推論の根本的な制約は、メモリ帯域幅の相対的な乏しさと、KVキャッシュのコンテキスト長に比例した線形成長にある。Daedalusはこの2点に対し、アテンションの3分の2をカーネルサイズ3のdepthwise畳み込みに置き換えるという単一の設計判断で同時に対処した。畳み込みブロックは保持する状態が常に2タイムステップ分で一定であり、コンテキストが2000トークンに達しても処理コストは変わらない。結果として、2048トークンの推論で1.76倍（外部比較では2.08倍）の速度向上を実現し、しかも品質は同等以上であることを事前登録された厳格なプロトコルで実証した。

この研究のもう一つの価値は、評価の誠実さにある。事前登録された勝利条件、パラメータ数が0.5%以内にマッチした双子モデルとの比較、同一ハーネスでの再スコアリング——これらの手法は「後付けの合理化」を徹底的に排除する。さらに論文は、死んだチャンネル（全チャンネルの約48%が不活性）、量子化認識訓練の失敗（6%のパープレキシティ劣化）、過大な語彙サイズ（49,152エントリ）といった自らの限界を隠さず報告している。これらの課題はいずれも「新しい研究が必要」な本質的な問題ではなく、次モデルでのエンジニアリング改善で解決可能な範囲に収まっている。

Daedalus-150Mは、CPU推論に最適化された小型言語モデルの新しい参照点を築いた。18ブロック中12ブロックがKVキャッシュを持たないという設計は、llama.cppという既存ランタイムに新しい演算子を追加せずに実装できる実用性も備えている。品質と速度のトレードオフを「デプロイ先から逆算する」という考え方は、エッジAIや個人利用のLLMが今後ますます重要になる時代において、多くの研究者や開発者にとって指針となるだろう。このモデルが示したのは、「大きなモデルを小さくする」ではなく「小さく動くように最初から設計する」という、設計哲学そのものの転換だった。

参考資料

• arXiv abstract: https://arxiv.org/abs/2608.20210v1
• arXiv HTML (全文): https://arxiv.org/html/2608.20210v1
• arXiv PDF: https://arxiv.org/pdf/2608.20210v1
• GitHub: https://github.com/unseen1980/daedalus
• HuggingFace (checkpoints): https://huggingface.co/Unseen1980/daedalus-checkpoints
• Bergsma et al. "Straight to Zero": arXiv:2502.15938
• Muennighoff et al. "Scaling data-constrained language models": arXiv:2305.16264
• Ainslie et al. "GQA": arXiv:2305.13245
• Biderman et al. "Pythia": arXiv:2304.01373 (ICML 2023)
• Liu et al. "MobileLLM": arXiv:2402.14905 (ICML 2024)
• Gu & Dao "Mamba": arXiv:2312.00752
• Peng et al. "RWKV": arXiv:2305.13048 (Findings of EMNLP 2023)
• De et al. "Griffin": arXiv:2402.19427

関連記事

• 2026年のエッジAI革命：スモール言語モデル(SLM)が変えるオンデバイス推論の未来と実践ガイド
• エッジデバイス向け小型言語モデル（SLM）の最適化：量子化と蒸留による軽量化の最前線
• エッジAIとローカルLLM：デバイス上での推論が変える未来