LoRA 空間導航：不用 Fine-Tune 就能特化 LLM 的三條路

讓 LLM 適應特定任務，一直只有兩條路。Fine-tune 一個 LoRA adapter — 精確但昂貴，以 GPU-hours 計算。或者使用指令並且塞進 prompt — 快速但深度不足，每次推論都要付出 token 成本。

這兩年出現了第三條路：直接在 LoRA 參數空間中導航，用 hypernetwork、router 或 merge 演算法，在毫秒內定位到對的 adapter，而非花幾小時 fine-tune。基於興趣，我陸續看了 15+ 篇論文後，這個方向已經分成三個流派。這篇文章整理它們的架構、檢驗實際數字，特別針對在工作上我最感興趣的三個具體的使用場景。

三大流派

                      LoRA 空間導航
                            |
        +-------------------+-------------------+
        |                   |                   |
     [生成派]            [路由派]              [合併派]
  Hypernetwork 輸出     從現有 adapter       把多個 LoRA
  全新的 LoRA          library 中選對的     融合成一個或更少
        |                   |                   |
  T2L, D2L, SHINE    LoRA-as-Tools,      CoMoL, FlyLoRA,
                      POLAR, S-LoRA,      MeteoRA, LoGo
                      LoRA-Switch

我們會深入看生成派的兩個代表 T2L 跟 D2L 以及它們帶來的好處，然後透過實際的 use cases 來檢視另外兩個流派。

生成派：Hypernetwork → LoRA

Doc-to-LoRA — 把文件塞進權重

arXiv 2602.15902 | Sakana AI

Doc-to-LoRA (D2L) 把文件丟進 frozen LLM 抽出每層的 activations，送進一個 Perceiver-based hypernetwork（309M 參數，8 個 cross-attention blocks），輸出一組 rank-8 LoRA adapter（target MLP layers）。把 adapter 掛上 base model，文件的內容就直接住在權重裡 — 推論時 prompt 裡不需要放文件。

Base model 是 Gemma-2-2b-it。訓練用的 context 只有 32—256 tokens，但能泛化到 32K tokens（Needle-in-a-Haystack 近乎完美）。

長文件處理用 chunking：拆成 K 個 chunk，每個 chunk 產生 rank-r adapter，沿 rank 維度串接為 effective rank r*K。

D2L 要解決的問題正在縮小。 Gemini 已經有 2M-token 的 context window。KV cache 優化 — PagedAttention、prefix caching — 持續進步。D2L 在追一個 moving target。而且 85% 的準確率在合約或財報這種每個條款都需要非常精確的場景並不能勝任。

更關鍵的是，整個評估只在 2B 模型上做。Hypernetwork 架構能否 scale 到 70B+，在論文裡面沒有回答。

Text-to-LoRA — 一句話生成 task adapter

arXiv 2506.06105 | Sakana AI

Text-to-LoRA (T2L) 是我覺得更有意思的。輸入不是文件，而是一段自然語言的任務描述：

"判斷 Amazon 產品評論是正面、負面或中立"
-> gte-large-en-v1.5 encode --> hypernetwork forward pass --> LoRA weights
-> 掛上 Mistral-7B --> 模型變成情感分析專家

Hypernetwork target 是 q_proj 和 v_proj，rank-8（~3.4M adapter 參數），訓練資料來自 Lots-of-LoRAs（從 Super Natural Instructions 篩選出 479 個 tasks）。

T2L 落後 oracle 1.9 個百分點。Oracle 需要每個 task 獨立 fine-tune；T2L 只需要一句話。

訓練有兩種目標：reconstruction（match 已有 oracle LoRA 權重 — 用於壓縮 adapter library）和 SFT（end-to-end task loss 直接透過 frozen LLM — 這是讓 zero-shot 泛化成立的關鍵）。

Scaling curve 值得注意。16 個 training tasks 時，zero-shot 能力幾乎不存在。到 479 個 tasks 時，泛化能力明顯浮現。但曲線還在上升 — 飽和可能需要數千個 tasks。

重要的不是具體數字。 重要的是 LoRA 參數空間中存在一個可學習的 mapping，從自然語言對應到有用的 adapter。即使 hypernetwork 不是最終的實現方式，「程式化導航權重空間」這個概念會以某種形式存活。

SHINE — 用 LLM 自己的參數做 Hypernetwork

arXiv 2602.06358

SHINE 重用 frozen LLM 自己的參數作為 hypernetwork 的一部分，降低額外的參數預算。直覺很好：LLM 已經理解語言了，何必從頭訓練一個完全獨立的網路來做 context → LoRA 的 mapping？

路由派：從 Adapter Library 動態選擇

第二個流派不做生成。它維護一個預先訓練好的 LoRA adapter library，在推論時把每個 request 路由到對的 adapter。

LoRA-as-Tools — Adapter 當 Agent 工具

arXiv 2510.15416

這是目前最接近 production-ready 的方案。每個 LoRA adapter 被註冊為 agent 可以呼叫的 tool。在 ReAct loop 中，agent 判斷當前需要哪個 expert，動態掛上對應的 adapter。

• Routing accuracy：98.3%（30 個 adapter 的 library）
• Specialist 性能提升：+4.6 到 +84.0 pp（跨 9 個 task families）
• 與直接使用 specialist 的差距：<5 pp

前提：每個 adapter 需要清楚的 metadata description。Routing 品質取決於 description 品質。

POLAR — Edge Device 上的 LoRA 調度

arXiv 2604.16583

POLAR 處理 resource-constrained device 上的 caching 問題。GPU/DRAM 只能放一小部分 adapter；從 storage 載入非 resident adapter 有明顯 latency。POLAR 用 two-timescale contextual bandit — 慢頻率管 cache，快頻率管 per-request routing。在 Qwen2.5-7B 上用 15 個 real LoRA adapters 實測。

Infra 層

• S-LoRA：Unified Paging 讓幾千個 LoRA 共存在 GPU memory。vLLM 的 LoRA 支援基於此。
• LoRA-Switch (arXiv 2405.17741)：System-algorithm co-design，token-level routing。
• ForkKV：Copy-on-Write KV cache，服務多 LoRA agent。

合併派：多個 LoRA 融合

第三個流派把多個 adapter 合成一個或更小的集合 — 適合 adapter library 太龐大但不需要生成能力的場景。

LoGo 的特色是 training-free — 推論時用 activation signals 判斷當前 input 需要哪些 LoRA 的哪些部分，動態合併。

三個實用場景

1. Agent 動態特化

task = "分析這段 logcat，找 ANR root cause"
--> 選擇/生成 "Android debugging expert" LoRA --> 掛上 --> 推論

task = "寫一封給 vendor 的技術回覆信"
--> 切換 "technical communication" LoRA --> 掛上 --> 推論

今天能做的： LoRA-as-Tools + vLLM。預先 fine-tune 5—10 個 domain LoRA，接上 router。vLLM 已經支援 per-request lora_request。

需要等的： T2L 從 task description 生成任意 adapter。目前只在 7B 上驗證過。

硬限制：這整個方向需要 self-hosted open-weight model。 API-based model（Claude、GPT）無法掛 LoRA。

2. Adapter Library 壓縮

500 個 domain-specific LoRA，每個 ~3.4MB，總共 1.7GB。T2L 的 reconstruction 模式可以壓成一個 hypernetwork。然而如果只是要壓縮、不需要生成能力，LoGo 或 CoMoL 的 merge 方法更實用 — 不需要訓練 hypernetwork，壓縮品質也更接近 lossless。

3. 個人化行為（不是個人化記憶）

user_preference = "回答要簡短、用繁體中文、避免敬語、附上 code snippet"
--> T2L 生成個人化 style LoRA --> 掛上

LoRA 作用在 weight level — 比 prompt-level 的 instruction following 更「深」。而且省 token：推論時不需要在每次 prompt 裡塞 preference instructions。

但老實說：對於簡單的 style 偏好（語言、長度、格式），system prompt 已經夠用了。T2L 真正有優勢的是那些 抗拒明確指令的 latent behavior pattern：

• 持續的 domain 語調（醫療報告 vs 法律文件 vs 工程 log 分析）
• 複雜的 output 格式習慣
• 推理風格偏好（保守 vs 激進、要不要主動提 edge case）

這些是用 instruction 很難完整描述的 implicit pattern。

行為 vs 記憶 — 一個重要的區分

D2L 論文裡的「個人化長期記憶」願景 — 把用戶對話歷史烤進 per-user LoRA 權重 — 聽起來吸引人，但工程上有嚴重問題：

• 百萬用戶，每人一組 LoRA = 分散式系統的噩夢
• 舊 LoRA + 新對話 → 重新過 hypernetwork → 一致性沒有保證
• LoRA capacity 有限，資訊丟失是必然的

個人化行為反而更可行，因為行為描述是 static 的（不需要持續更新），一組 LoRA 可以服務同類型的所有用戶，也不需要存儲 per-user 權重。

Infra 現狀

路由派的 infra 已經 production-ready（vLLM）。生成派的 infra 還在 research 階段。

值得追蹤的信號

1. T2L/SHINE 在 70B+ 模型上的結果 — 目前只在 2B/7B 驗證過。能否 scale 是根本問題。
2. vLLM/TGI 原生支援 hypernetwork 產生的 LoRA hot-loading — 生成派從 research 跨入 production 的轉折點。
3. LoRA-as-Tools 與 agentic framework 的整合 — LangGraph、CrewAI 原生支援 adapter routing。
4. T2L scaling curve 飽和點 — 479 個 tasks 還在上升段。到幾千個時是否 plateau？

Context window 持續變大，這是 D2L 的 existential threat。但 T2L 的 insight — LoRA 空間可以被程式化導航 — 跟 context window 大小無關。那才是更持久的方向。

參考資料

1. Doc-to-LoRA (arXiv 2602.15902) — Sakana AI, 2026/02
2. Text-to-LoRA (arXiv 2506.06105) — Sakana AI, 2025/06
3. SHINE (arXiv 2602.06358) — Scalable In-Context Hypernetwork, 2026/02
4. LoRA-as-Tools (arXiv 2510.15416) — Adaptive Minds, 2025/10
5. POLAR (arXiv 2604.16583) — Edge LoRA Serving, 2026/04
6. LoRA-Switch (arXiv 2405.17741) — System-Algorithm Co-design, 2024/05
7. S-LoRA (arXiv 2311.03285) — Multi-LoRA Serving, 2023/11
8. Activation Steering (arXiv 2505.04260) — Steerable Chatbots, 2025/05
9. Per-Pcs (arXiv 2501.11549) — Personalized Pieces, 2025/01
10. Model Merging Survey (arXiv 2603.09938) — Comprehensive Survey, 2026/03
11. Sakana AI Blog — D2L + T2L interactive demos