標籤: 強化學習

RL 訓練版 Prompt Cache 7.5x 提速解析
📌 本文重點
- 長 prompt / 短 response RL 訓練會浪費 >90% 計算
- 把推理用 KV/prefix cache 思路搬進帶梯度訓練可大幅提速
- 在 Qwen3.5-4B 上實測最高約 7.5x throughput 提升
長 prompt、短 response 的 RLHF/RLAIF 任務（例如對話評分、工具調用評分）有一個非常痛的點：每個樣本都在重算同一段 prompt。對 1000-token prompt、100-token response 的場景，你實際上有 >90% 的 FLOPs 在白白重褾。這篇要講的是：如何把推理時的 KV/prefix cache 思路搬進帶梯度的 RL 訓練，在 Qwen3.5-4B 上實測最高拿到 7.5x 速度提升，並給你一套可以直接落地的工程實作方案。

💡 關鍵： 在長 prompt / 短 response 場景中，重用 prompt 前向計算可將大部分重複 FLOPs 直接省掉，帶來數倍級 throughput 提升。

重點說明

1. 為什麼 RL 訓練會浪費那麼多計算？

典型的 RLHF/RLAIF 術次資料形態：
- prompt：系統 + 多輪對話 + 任務描述（幾百到上千 tokens）
- response：模型生成或候選回答（幾十到一兩百 tokens）
多數開源 RL engine（包括許多自寫 pipeline）會：
```
[ prompt tokens ][ response tokens ]
  T_prompt           T_resp
```
對每一個樣本、每一次 rollout / gradient step，都從頭跑整條序列，雖然 prompt 完全相同，只是 response 不同。這會帶來幾個直接影響：
1. GPU 利用率被長 prompt 綁死：
2. 你以為自己 batch size 是 64，其實「有效」只有在 response 段，前面 90% 的計算是在重放。
3. batch 設計被 context 長度限制：
4. 1000+ token prompt 會吃掉大部份 memory，導致你無法疊大 batch，只能靠 gradient accumulation，進一步增加 step latency。
5. RL 特有放大器：
6. 同一個 prompt 下可能要算多個候選 response、policy/value 多頭、不同 reward function，全都從 prompt 重新 forward 一次。
因此，只要你是「長 prompt / 短 response」型任務，任何一點在 prompt 端節省的 FLOPs，都是純利潤。

2. 把 KV/prefix cache 搬進訓練：核心思路

推理時我們早就習慣用 KV cache/prefix cache：
1. 先跑一次 prompt，存下每層的 key/value（或 hidden states）。
2. 生成 response 時，只計算增量 token，復用前綴。
在訓練中要做到類似的事情，難點在於：
- 我們需要 完整的 computation graph（for backprop）。
- 不能只存數值（像推理那樣），還要讓 autograd 知道這些值是可導的。
- 不能打壞 attention：response 的 attention 要能看見 prompt token 的 hidden states。
一種工程上可行的做法（簡化描述）：
1. 把序列拆成兩段圖：prompt graph + response graph。
2. prompt 部分：
3. 前向一次，拿到 prompt hidden states（例如每層的 h_prompt）與最後一層的 cache-like 表示。
4. 保留其 computation graph（不 detach），但不馬上 backward。
5. response 部分：
6. 再跑一次 LLM，但將 prompt 當成固定 prefix 傳入，使 response token 的 attention 能看到這些 prefix hidden states。
7. 在 PyTorch 裡可以透過自訂 forward 函數，把 prompt hidden states 塞回 attention 模組，類似手動實作 prefix cache。
8. loss 計算只對 response tokens 做（例如 policy loss、value loss），但梯度會沿著 response→prompt 的 graph 反傳，保證不破壞訓練正確性。
關鍵是：
- 只對 prompt 前向一次，但仍然讓 prompt 參與梯度更新。
- 對同一 prompt 的多個 response，重複使用一份 prompt hidden states（甚至在一個批次中共享）。
在 Qwen3.5-4B 上，reddit 實測：
- prompt : response ≈ 10:1（例如 1000:100）
- RL 任務：長對話 + 短完成
- 快取後在長 prompt/短 response 工作負載下 最高取得 ~7.5x step throughput 提升（取決於實際長度比與 IO/通信開銷）。
💡 關鍵： 當 prompt 與 response 長度比約 10:1 時，只重算 response 部分可在實測中帶來約 7.5 倍 step throughput 提升。

3. 什麼任務最吃紅利？

根據 Qwen3.5-4B 測試經驗與工作負載特性，大致可以這樣判斷：
1. 長 prompt / 短 response（T_prompt / T_resp ≥ 4）
2. 如：對話 RLHF 評分（用戶上下文很長，模型答覆很短）。
3. 工具調用評分：所有工具 schema + log 作為 prompt，再對短 decision 進行 RL。
4. 部分代碼 RL：整個大檔案為 prompt，模型只改一小段。
5. 這類場景通常可以拿到 3x–7.5x 的實際提速。
6. 中 prompt / 中 response（T_prompt / T_resp ≈ 1）
7. 如：通用問答 RLHF（prompt 只有一兩句，回答較長）。
8. 提速有限，約 1.2x–2x，且實作複雜度可能不值。
9. 短 prompt / 長 response（T_prompt / T_resp < 1）
10. 基本沒紅利，甚至會因複雜控制流、多段 graph 而變慢。
實務上可以用一條 thumb rule：

如果你平均的 prompt token 數是 response 的 3 倍以上，就應該認真評估導入。

💡 關鍵： 當 T_prompt 至少約為 T_resp 的 3 倍時，引入訓練版 prompt cache 通常才有顯著性價比。

實作範例

以下示例是 PyTorch 為主，偏 pseudo code，但結構與實務工程接近。

1. 資料結構與 DataLoader 改寫

我們先把一個 RL batch 明確拆成 prompt / response：
```
# 每個樣本：
# prompt_ids: [T_p]
# resp_ids:   [T_r]

class RLDataset(torch.utils.data.Dataset):
    def __getitem__(self, idx):
        item = self.data[idx]
        return {
            "prompt_ids": item.prompt_ids,   # 長
            "resp_ids": item.resp_ids,       # 短
            "reward": item.reward,           # 或 advantage
        }


def collate_fn(batch):
    # padding & batch 組合
    prompt_ids = pad_sequence([b["prompt_ids"] for b in batch], batch_first=True)
    resp_ids   = pad_sequence([b["resp_ids"]   for b in batch], batch_first=True)

    # 生成對應 mask
    prompt_attn_mask = (prompt_ids != pad_token_id)
    resp_attn_mask   = (resp_ids   != pad_token_id)

    return {
        "prompt_ids": prompt_ids,
        "resp_ids": resp_ids,
        "prompt_mask": prompt_attn_mask,
        "resp_mask": resp_attn_mask,
        "reward": torch.tensor([b["reward"] for b in batch]),
    }
```
2. 模型 forward：拆成 prompt graph + response graph

假設你有一個可插拔的 LLM 模型 model，我們新增兩個關鍵 API：
- model.forward_prompt(...)：只跑 prompt，返回 hidden states（及必要 cache）。
- model.forward_response_with_prefix(...)：給定 prefix hidden states，跑 response。
```
class RLPromptCacheModel(nn.Module):
    def forward_prompt(self, input_ids, attention_mask):
        # 返回每層的 hidden，或最後一層即可
        # 重要：不要 detach，保持 grad
        outputs = self.transformer(
            input_ids=input_ids,
            attention_mask=attention_mask,
            output_hidden_states=True,
        )
        return outputs.hidden_states  # list[Layer][B, T_p, H]

    def forward_response_with_prefix(self,
                                     resp_ids,
                                     resp_mask,
                                     prompt_hidden_states,
                                     prompt_mask):
        # 這裡需要改造 attention：
        # 讓每層 self-attention 的 KV = [prompt, resp]
        # 可以在每層 module 裡寫一個 hook，或實作 custom attn。
        outputs = self.transformer_with_prefix(
            resp_ids=resp_ids,
            resp_mask=resp_mask,
            prefix_hidden_states=prompt_hidden_states,
            prefix_mask=prompt_mask,
        )
        return outputs.last_hidden_state
```
核心點：transformer_with_prefix 要做到：
- 對於每層的 self-attention：
- query 來自 response tokens；
- key/value 為 [prefix_hidden_states; resp_hidden]；
- 這讓 response token 能正常 attend 到 prompt，並保持完整 graph。
實務上可以參考 FlashAttention / prefix-tuning 的實作方式，直接拼接 prefix hidden 作為額外 token，再控制 mask：
```
def transformer_with_prefix(...):
    # 假設我們把 prefix & response 在 time 維度上串起來
    # 注意這裡是邏輯串接，實際可用 concat + mask 控制
    concat_hidden = torch.cat([prefix_hidden, resp_emb], dim=1)  # [B, T_p+T_r, H]
    concat_mask   = torch.cat([prefix_mask, resp_mask], dim=1)   # [B, T_p+T_r]

    # 交給原本的 transformer 做 self-attention
    outputs = self.base_transformer(
        hidden_states=concat_hidden,
        attention_mask=concat_mask,
    )
    # 只取 response 對應位置的輸出
    resp_hidden_out = outputs.last_hidden_state[:, -resp_len:, :]
    return resp_hidden_out
```
3. Loss 計算與 RL head

以 policy gradient 為例，我們只對 response token 做 loss：
```
prompt_hs = model.forward_prompt(batch["prompt_ids"], batch["prompt_mask"])  # list[L]

resp_logits = model.forward_response_with_prefix(
    batch["resp_ids"],
    batch["resp_mask"],
    prompt_hs,
    batch["prompt_mask"],
)

# policy head
logits = policy_head(resp_logits)  # [B, T_r, V]
log_probs = F.log_softmax(logits, dim=-1)

# 只對實際採樣到的 token 做 loss
# 假設 resp_ids 是我們的 action
token_logp = log_probs.gather(-1, batch["resp_ids"].unsqueeze(-1)).squeeze(-1)

# 依 RL 演算法計算 advantage 等
loss = -(token_logp * advantage_mask).sum() / num_valid_tokens
loss.backward()
```
因為 prompt_hs 沒有被 detach，梯度會沿著 response 部分回傳到 prompt 部分，等效於一次走完整個序列，但 prompt 只 forward 一次。

4. 與 gradient checkpointing / mixed precision / DDP 整合
- gradient checkpointing：
- 可以只對 response graph 開啟 checkpoint，prompt graph 一般不需要再切。
- 若 prompt 特別長，可在 prompt 段也設 checkpoint，但要注意不要把 cache 給破壞（照 layer 切即可）。
- mixed precision (AMP/Fp16/bf16)：
- 保持 prompt & response forward 使用同一個 torch.cuda.amp.autocast 區塊。
- prompt cached hidden 和 response 的精度必須一致，避免 dtype mismatch。
- DDP/FSDP：
- 基本原則：prompt forward 也在每個 rank 上做一次，不要跨 rank 共用 hidden，避免額外通信。
- 對 FSDP 來說，prompt hidden 是 activation，照樣會被 shard/rebuild，不需要特別處理。
- 注意 loss scale 及 no_sync() 區段，確保多 step accumulation 時 prompt/response 的 backward 一致。
建議與注意事項

1. 常見坑
1. 快取導致樣本 shuffle 不均
2. 若你把「相同 prompt 的多個 response」綁在一起，容易造成某些 prompt 被過度訓練。
3. 建議在 dataset 層維持 樣本級 shuffle，不要把 prompt 當成硬分桶，或定期重組 group。
4. mask 錯誤導致梯度泄漏
5. 如果 attention mask 沒處理好，可能出現：response token 看到未來 token，或不同樣本互相看到彼此的 prompt。
6. 尤其在 concat prefix 時，要確認：
  - padding token 完全被 mask 掉；
  - prefix 與 response 的因果 mask 正確（response 不該看到未來 response）。
7. policy / value head 不一致
8. 很多 RL pipeline 會同時跑 policy head + value head。
9. 如果你只對 policy 路徑用 prompt cache，而 value 還在跑 full sequence，
  會導致兩邊的 feature distribution 不一致。
10. 建議：兩個 head 共用同一套 prompt+response 拆圖邏輯，或至少在 feature 塊對齊。
2. 什麼時候值得導入？

你可以簡單做一個估算：
- 計算平均 T_prompt / T_resp。
- 估算你的訓練 step 中，有多少時間是花在 forward（相對於通信/IO）。
- 目標提速 ≈ T_total / (T_resp + T_prompt / cache_reuse_factor)。
若粗算下來：
- 理論加速 > 2x，且你目前的 RL 訓練被 FLOPs-bound（非 IO-bound），那導入很可能值得。
- 若你被 data loading 或 reward 模型 inference 卡住，則先優化 pipeline 再考慮這一層。
3. 實務指引（TL;DR）
- 優先導入場景：
- RLHF/RLAIF 的對話評分、工具調用評分、長上下文 code RL。
- prompt 長度是 response 的 3–10 倍。
- 使用 Qwen3.5-4B 或相近大小模型，GPU 計算是主要瓶頸。
- 預期收益：
- 實測可達 3x–7.5x throughput 提升。
- 允許你把 batch 撐大，減少 gradient accumulation，進一步提高 GPU 利用率。
- 相同 GPU 成本下，能多跑數倍 rollout 或更長訓練步數。
- 導入步驟建議：
- 先在小 batch 上實作 forward_prompt + forward_response_with_prefix，只做 sanity check。
- 確認與原 full sequence 訓練的 loss/梯度差異在可接受範圍（數值抖動為正常）。
- 再導入 DDP/FSDP + AMP，逐步拉大 batch 測 throughput。
- 監控 loss 曲線與最終 RL reward，確認沒有明顯退化。
只要你的 RL 任務落在「長 prompt / 短 response」區間，RL 訓練版 prompt cache 幾乎就是一次性的大幅成本折扣；對正在做 RLHF/RLAIF 的團隊，值得花 1–2 週工程時間好好實作一版。
🚀 你現在可以做的事
- 在現有 RLHF/RLAIF 代碼中量測平均 T_prompt / T_resp，判斷是否達到導入門檻（≥3）
- 在一個小型實驗中實作 forward_prompt 與 forward_response_with_prefix，對比 full sequence 訓練的 loss/梯度
- 在實際 Qwen3.5-4B 或現用模型上開啟 prompt cache 實驗，記錄 throughput 與成本變化，評估是否全面導入
2026 年 5 月 12 日
MemFactory：把記憶型 Agent 變成一行模組
📌 本文重點
- MemFactory 把記憶變成可插拔、可訓練的模組
- 用 GRPO 讓 Agent 自己學會記什麼、忘什麼與怎麼用
- 可直接套用 Memory-R1／RMM／MemAgent 等 SOTA 架構
用一句話說：MemFactory 讓你不用自己手刻記憶策略，就能把「會自己學會記什麼、忘什麼」的記憶 Agent 套進現有 LLM。

原文論文：[MemFactory: Unified Inference & Training Framework for Agent Memory]

為什麼你現在的 Agent 記憶，其實很「陽春」？

大多數現在線上跑的客服 Bot、Copilot、助理，所謂「長期記憶」其實就是：
1. 把歷史對話丟進 embedding
2. 存進向量資料庫
3. 每次問問題時相似度檢索幾條，塞回 prompt
問題在於：
- 哪一句要寫進記憶？（重要資訊 vs. 嘮嗑）
- 什麼時候要更新？（舊偏好 vs. 新偏好）
- 什麼時候該忘？（過期任務、已完成專案）
- 檢索時要抓什麼粒度？（一條摘要還是整段歷史）
如果你現在是用 if-else + heuristics 在寫這些邏輯，其實就是：

把一個適合用 RL 學的策略問題，硬寫成規則引擎。

MemFactory 做的事就是：把「記憶生命週期」拆成標準模組，然後用 GRPO 讓 Agent 自己學會怎麼用記憶。

💡 關鍵： 與其不斷堆 if-else 修修補補，不如把記憶當成可訓練策略，長期可維護性與效果都會更好。

核心功能 1：記憶生命週期標準化，像樂高一樣換零件

MemFactory 把記憶相關操作，拆成可插拔的原子組件：
- 寫入（Write）：決定哪些內容要變成長期記憶
- 壓縮（Compress / Summarize）：長對話變短摘要
- 遺忘（Forget / Prune）：過期或冗餘記錄被丟棄
- 檢索（Retrieve）：在任務中調出最有用的記憶
在框架裡，你可以：
- 用官方提供的模組（如 MemAgent / Memory-R1 風格的寫入器、檢索器）
- 把其中一個環節換成自己寫的策略，其他保持不動
- 在同一組任務上，對比不同「記憶組合」帶來的效果
你能做的具體事：
- 快速把原本「只有 RAG」的聊天機器人，換成「有寫入＋遺忘」的版本
- 在同一個專案裡 A/B test：
- A：只靠向量相似度檢索
- B：加上學會「只記 summary」的壓縮模組
這讓記憶不再是寫死在程式碼裡的一堆 if-else，而是可以替換、疊加、訓練的模組。

💡 關鍵： 把「寫入、壓縮、遺忘、檢索」標準化後，你可以像換零件一樣快速試不同記憶策略。

核心功能 2：用 GRPO 訓練「要記什麼、怎麼用」而不是手刻規則

MemFactory 內建 Group Relative Policy Optimization (GRPO)，重點不是名字，而是它幫你解決這兩件事：
1. 讓 Agent 在真實任務中試錯：
2. 成功完成長期任務 → 給正向獎勵
3. 忘掉重要資訊、答錯、反覆問同樣問題 → 給負向獎勵
4. 從多維度評分：
5. 正確性（答案對不對）
6. 連貫性（有沒有跟之前的對話對得上）
7. 成本（少查一點沒用記憶、token 不要炸掉）
訓練的結果，是一個「懂得控制自己記憶」的 policy：
- 在對話中主動抽取關鍵資訊寫入記憶
- 任務結尾自己產生任務總結存起來
- 下次遇到相關任務時，知道該檢索哪一段
你能做的具體事：
- 不用設計「多久忘一次」「最多存幾條」這種規則，改成定義：
- 什麼是成功回合（例如客服一次解決率）
- 什麼是失敗回合（例如用戶反覆問同一件事）
- 用 MemFactory 把這些 reward 寫進環境，讓 Agent 自己調整記憶策略
💡 關鍵： 只要設計好 reward，GRPO 會在真實任務中自動逼出更好的記憶策略，而不用人工調參「存幾條、多久忘」。

核心功能 3：直接套 SOTA 記憶 Agent 設計跑實驗

MemFactory 已經把幾個知名記憶 Agent 的架構變成可直接套用的配置：
- Memory-R1
- RMM（Reinforced Memory Management）
- MemAgent
你可以：
- 直接用官方提供的 config 跑 baseline
- 把你的任務資料接上去，再用同一組框架做微調
- 在同一個評測上，對比不同記憶架構的效果
你能做的具體事：
- 拿 MemAgent 官方釋出的 dataset，直接在本地跑一次論文裡的實驗流程
- 把自己的客服對話 log 換成環境，保留原本的 MemAgent 架構，重訓一個「專屬你公司的記憶策略」
適合誰用？三個典型場景

1. 客服 Bot / 企業 Copilot：需要記「客戶長期歷史」

需求：
- 認得老客戶、知道過去投訴內容、偏好設定
- 不要每次都叫客戶重講一遍
用法：
- 用 MemFactory 把「每次對話後的 summary」寫入客戶個人記憶
- 訓練 Agent 學會：什麼樣的歷史有助於降低重複提問率
2. 長期專案助理：跟著你跑一個月的專案

需求：
- 記得每次會議決議、待辦事項、誰負責什麼
- 自動形成「專案記憶庫」，幫你追蹤進度
用法：
- 把每次對話當作一個 episode
- 用 reward 指標：
- 助理能否從記憶中準確回顧前次決議
- 是否能串起跨週的任務
3. 學習／研究助教 Bot：跟著你讀一本書、做一個研究題目

需求：
- 記住你已經學過哪些章節、卡在哪些概念
- 適時用舊記憶幫你複習、舉例
用法：
- 設計「測驗」情境：Bot 如果能用過去筆記解出新題目 → 給高 reward
- 讓記憶策略學會：哪些摘要對長期解題幫助最大
怎麼開始：10 分鐘跑一個「多輪任務＋記憶回顧」 Demo

下面是一條最短路徑：從零到跑出一個會做記憶回顧的 Agent。具體指令以官方 Repo 為準，這裡給的是典型流程草稿。

1. 安裝 MemFactory

假設你已經有 Python 3.10+ 環境和 GPU：
```
# 建議先建虛擬環境
python -m venv .venv
source .venv/bin/activate  # Windows 用 .venv\Scripts\activate

pip install memfactory
```
如果官方是 GitHub Repo，可能會是：
```
git clone https://github.com/xxx/MemFactory.git
cd MemFactory
pip install -e .
```
行動：把這段指令貼進你的實驗機／本地環境，確認能 import memfactory 即可。

2. 選一個基礎 LLM：以 Llama / Qwen 為例

MemFactory 通常透過 Hugging Face 或本地後端調用模型，你可以先挑一個開源模型：
```
# 例：下載並準備一個 7B 等級模型
huggingface-cli download meta-llama/Meta-Llama-3-8B-Instruct
# 或
huggingface-cli download Qwen/Qwen2-7B-Instruct
```
在 MemFactory 的 config 裡指定：
```
model:
  name: "Qwen/Qwen2-7B-Instruct"  # 或 Llama 模型
  backend: "vllm"                  # 依你使用的推理後端調整
```
行動：先選一個你機器跑得動的模型（7B 左右），記下模型名稱，等下寫進 config。

3. 套官方 MemAgent 設定，跑一個多輪任務 Demo

大部分情況下，官方會提供類似：
```
# 使用內建 MemAgent 設定
memfactory run \
  --config configs/memagent_demo.yaml \
  --task multi_turn_todo_with_review
```
這類 demo 通常會做：
- 與 Agent 進行多輪對話（例如安排一週工作計畫）
- Agent 在過程中抽取「關鍵任務」寫進記憶
- 最後請它做「本週任務回顧」，看有沒有正確調出記憶
你可以觀察：
- 日誌裡每一步的「寫入」「壓縮」「遺忘」「檢索」行為
- 沒有記憶 vs. 開啟 MemAgent 記憶策略的表現差異
行動：先用官方 demo 跑一次，看 log 裡每個記憶操作的輸出，理解「記憶生命週期」是怎麼被拆開的。

4. 改成自己的 Domain：以客服為例

假設你有一批客服對話紀錄：
1. 把對話整理成 episode 格式（每個工單一個 episode）
2. 在 MemFactory 的任務設定裡換成你的 dataset：
3. env.dataset_path: data/your_customer_logs.jsonl
4. reward: 設計成：
  - 一次解決 → +1
  - 客戶重複追問同樣問題 → -1
5. 仍然沿用 MemAgent 的記憶架構，只是換成你的訓練環境：
```
memfactory train \
  --config configs/memagent_customer_service.yaml \
  --grpo  # 開啟 GRPO 訓練記憶策略
```
行動：先複製官方 MemAgent config，改 dataset 路徑與 reward 規則，試著在你的一小批真實對話上訓練一晚，觀察 Agent 對「老客戶」的記憶有沒有變好。

小結：把「記憶」當成可訓練的模組，而不是硬寫的規則

如果你現在的 Agent 記憶只是：
- 儲存所有對話
- 檢索前 N 句最近的內容
那你會遇到：成本爆炸、重要資訊被雜訊淹沒、長期任務斷線。

MemFactory 提供的是一個更實際的路線：
- 記憶生命週期 = 寫入 + 壓縮 + 遺忘 + 檢索 → 做成可插拔模組
- 用 GRPO 在真實任務上訓練「要記什麼、怎麼用」
- 直接復用 Memory-R1 / RMM / MemAgent 等架構，少走重造輪子的路
如果你手上已經有客服、Copilot、教學 Bot 類的專案，最直接的下一步是：
1. 拉一台可以跑 7B 模型的機器
2. 裝上 MemFactory，跑完官方 MemAgent demo
3. 把你的對話資料接進去，先做一個小規模試驗
從那一刻開始，你的 Agent 就不是只會「背稿子」，而是開始學會「怎麼整理自己的記憶」。
🚀 你現在可以做的事
- 在實驗機上安裝 memfactory 並確認可以 import memfactory
- 選一個你跑得動的 7B 模型，寫進 MemFactory 的 config 裡跑一次官方 MemAgent demo
- 把一小批真實對話整理成 episode，加上簡單 reward 規則，試著用 memfactory train 訓練一晚觀察效果
2026 年 4 月 8 日

標籤: 強化學習

RL 訓練版 Prompt Cache 7.5x 提速解析

重點說明

1. 為什麼 RL 訓練會浪費那麼多計算？

2. 把 KV/prefix cache 搬進訓練：核心思路

3. 什麼任務最吃紅利？

實作範例

1. 資料結構與 DataLoader 改寫

2. 模型 forward：拆成 prompt graph + response graph

3. Loss 計算與 RL head

4. 與 gradient checkpointing / mixed precision / DDP 整合

建議與注意事項

1. 常見坑

2. 什麼時候值得導入？

3. 實務指引（TL;DR）

MemFactory：把記憶型 Agent 變成一行模組

為什麼你現在的 Agent 記憶，其實很「陽春」？

核心功能 1：記憶生命週期標準化，像樂高一樣換零件

核心功能 2：用 GRPO 訓練「要記什麼、怎麼用」而不是手刻規則

核心功能 3：直接套 SOTA 記憶 Agent 設計跑實驗

適合誰用？三個典型場景

1. 客服 Bot / 企業 Copilot：需要記「客戶長期歷史」

2. 長期專案助理：跟著你跑一個月的專案

3. 學習／研究助教 Bot：跟著你讀一本書、做一個研究題目

怎麼開始：10 分鐘跑一個「多輪任務＋記憶回顧」 Demo

1. 安裝 MemFactory

2. 選一個基礎 LLM：以 Llama / Qwen 為例

3. 套官方 MemAgent 設定，跑一個多輪任務 Demo

4. 改成自己的 Domain：以客服為例

小結：把「記憶」當成可訓練的模組，而不是硬寫的規則