【AIロマン】複数LLMを再学習ゼロで合体させる！ Hotswappable LLMの実装と検証

Posted at 2026-05-08

はじめに

数百億、数千億というパラメータを持つ巨大なLLM。その途方もないスケールの「一枚岩（モノリス）」とも言える知能を、 極小単位に細かく分割し、なおかつ自由に取り外し可能（Hotswappable）な形に分解できないか？
「この知識はここに入っている」「この能力は不要だから取り外す」「新しい能力を後からカチッと追加する」——そんな、ブラックボックスである巨大なLLMを完全にコントロール可能なモジュールへと解体・再構築するアプローチは、AIエンジニアにとって最高にワクワクする「ロマン」ではないでしょうか。

本記事は、そんなロマンの実現に向けたプロジェクトの検証レポートです。
独自に開発・検証を進めているモジュラーAI構造「SRA（Synaptic Routing Architecture）」を用いて、事前学習済みのベースLLMに対し、後から別チームが独立して学習した「コード特化LLM」や「数学特化LLM」を、 一切の再学習なしで物理的に後付け合体（Hot-Swap）させる ことに成功した過程を解説します。

概要

現在のLLMの問題点

現在の巨大なLLM（モノリスモデル）は、すべての知識をひとつの巨大なパラメータ空間に詰め込んでいます。そのため、以下のような問題が生じます。

破滅的忘却（Catastrophic Forgetting）: 汎用モデルに特定のドメイン（例えば社内規程や専門のコード）を後から追加学習させると、元の汎用的な対話能力が破壊されたり、低下したりしてしまう。
学習コストの肥大化: 新しい知識を追加するたびに、モデル全体（またはLoRA等のアダプタ）の再学習やマージ作業が必要になり、複数チームでの完全並行開発が難しい。

Hotswappable LLM の利点

モデルを Hotswappable（動的抜き差し可能）なアーキテクチャにすることで、これらの問題を根本から解決します。

完全な独立並行開発: 「コードチーム」と「数学チーム」が、同じベースモデルを元に、全く干渉せずに自分たちの特化モデル（シナプス）だけを独立学習できます。
Zero-Shot での物理合体: 学習が終わった重み（テンソル）を、本番環境のベースモデルの「空きスロット」にメモリコピーするだけでデプロイ完了。
干渉ゼロ: 新しいLLMを追加合体させても、ベースモデルの出力ロス（Loss）は小数点以下まで完全に一致（Zero Forgetting）します。

※なお、本取り組みはまだ dim=128, layers=4 程度の 小規模モデルにおける実験段階 であり、10Bクラスの巨大LLMでの実証は今後の課題です。

巨大LLMを試すだけの開発環境がないのが一番の課題です。

実際にブラウザで試せます

本記事で解説するHot-Swapの全プロセス（ベース学習〜独立学習〜合体〜Zero Forgettingの証明）は、以下のGoogle Colabノートブックで実際に動かして体験できます。

SRAにおけるHotswapの実装

SRA（Synaptic Routing Architecture）は、Transformerの各層に「ルーター」と「複数の極小エキスパート（TinySynapse）」を持つMoE（Mixture of Experts）の発展形です。

SRAにおいて、モデルの「Hot-Swap（物理合体）」は、驚くほどシンプルなPythonコード（テンソルのコピー）だけで完結します。

# hotswap_model: 本番環境のベースモデル（空きスロットを追加済み）
# plugin_math: 数学チームが独立学習した特化LLM

with torch.no_grad():
    for l in range(layers):
        target_block = hotswap_model.blocks[l]
        src_block = plugin_math.blocks[l]
        
        # ルーターの埋め込みベクトル（特化モデルのインデックス部分）をコピー
        target_block.router.synapse_emb.data[4:8] = src_block.router.synapse_emb.data
        
        # Expert (TinySynapse) の重み (w1, w2) をコピー
        target_block.w1.data[4:8] = src_block.w1.data
        target_block.w2.data[4:8] = src_block.w2.data

このように、本番モデルのテンソルの特定インデックス（上記ではスロット4〜7）に対して、学習済み特化モデルのテンソルを直接代入するだけです。
SRAは「ベースモデルの共通知識（Attention層など）」を完全に凍結した状態でシナプスのみを追加学習する仕組みを持つため、このような強引な物理コピーが成立します。

技術的解説：なぜ「破滅的忘却」が起きないのか？

ただ物理コピーしただけでは、ルーターが新しいシナプスと古いシナプスを混同してしまい、出力がバグってしまいます。これを防ぐため、SRAでは ベクトルデータベース（Vector DB）の検索技術 から着想を得たルーティング手法を導入しました。

ベクトルDBにおける「メタデータ・フィルタリング」

PineconeやMilvusなどのモダンなベクトルDBでは、単なる意味検索（コサイン類似度など）だけでなく、「特定の条件（日付やカテゴリ）」で絞り込む メタデータ・フィルタリング が非常に重要視されています。これには主に2つのアプローチがあります。

Post-filtering（事後フィルタリング）:
- 一旦ベクトル検索でTop-K件を取得し、その後で条件に合わないものを捨てる方式。
- 欠点: 捨てた結果、必要な件数（K件）が足りなくなる「K-NN枯渇問題」が起きやすく、精度が安定しません。
Pre-filtering（事前フィルタリング）:
- ベクトル検索を行う前に、メタデータを使って検索空間（探索対象のベクトル群）にマスクをかけ、条件に合致するものだけでTop-K検索を行う方式。
- 利点: 理論上確実に条件を満たす結果が入り、ノイズが完全に排除されます。

SRAの「事前ハードマスク」による完全隔離

SRAのルーターの正体は、入力ベクトルと各シナプスの埋め込みベクトルの内積を計算する インメモリのベクトル検索エンジン（MIPS） です。

そこでSRAでは、ベクトルDBの Pre-filtering（事前フィルタリング） の仕組みをルーターの順伝播プロセスに直接組み込みました。具体的には、推論時に「現在処理しているのは数学のタスクである」というメタデータマスクをモデルに渡します。

# Router層での計算の疑似コード
logits = torch.einsum("btd,nd->btn", h_norm, emb_norm) * self.scale

# Pre-filtering: 許可されていないドメインのシナプスのロジットをマイナス無限大にする
logits = logits.masked_fill(~allowed_mask, float('-inf'))

# その後、Top-Kルーティングを行う
vals, idx = torch.topk(logits, k, dim=-1)

この masked_fill による事前フィルタリングにより、ルーターは「絶対に許可された特化LLM（またはベースの汎用モデル）」の中からしか専門家を選ばなくなります。
これにより、別のモデルの重みがいくら混ざっていようと、計算グラフ上では完全に無視されるため、 「ベースモデルのLossが合体前と小数点以下まで一切変わらない（数学的にゼロの干渉）」 というロマン仕様を実現しました。