EffOPD 是一個圍繞模型訓練流程改良的研究實作，重點不在做一個全新聊天產品，而是在訓練途中更有效率地挑選值得評估的候選參數。從儲存庫資訊可見，它建基於 verl 與 GOPD，並調整訓練器與工作流程相關檔案，屬於偏底層的優化工具。

實際使用時，做法是沿用原本 OPD 的訓練流程，再加入迭代測試相關設定，並準備一份 parquet 格式的輕量驗證資料。這種安排的意思很直接：模型訓練到某些檢查點時，系統會額外評估幾個外推候選，而不是每次都用完整驗證流程，從而加快判斷。

專案想解決的，是大模型強化學習或蒸餾訓練中，評估成本高、嘗試路線多的問題。它較特別的地方，在於把「外推搜尋」和「即時輕量驗證」結合，讓訓練期間可以更早篩走不理想方向；儲存庫亦提到可設定每次最多測試 5 個候選，反映它著重效率與可控性之間的平衡。

• 建基於 verl 與 GOPD，較適合已有相關訓練基礎的人
• 透過啟用迭代測試，在訓練中加入外推式候選搜尋
• 使用 parquet 驗證檔建立輕量驗證集，減少即時評估負擔
• 可調整每個檢查點評估的候選數量，預設實驗值為 5

適合主要作為研究實驗、訓練流程調校，以及想比較不同訓練決策成本的人。相關脈絡上，儲存庫明確提到 OPD、GOPD 和 EffOPD，而論文方向亦圍繞大型語言模型的強化學習動態與 on-policy distillation；對一般用家未必即插即用，但對做模型訓練研究的人有參考價值。

GitHub： https://github.com/caiyuchen-ustc/EffOPD

Paper： https://arxiv.org/pdf/2605.11739

如果你有留意近年大語言模型點樣練習數學題，NudgeRL算係一個幾有方向感的研究型專案。佢主要針對一個常見問題：模型唔係唔努力，而係好多時只會喺自己熟悉的解題路線入面打轉，結果要靠大量重複抽樣先撞到更好答案。

NudgeRL的做法唔係一味加大運算量，而係先提供較輕量的「策略層面背景」，引導模型用唔同思路展開推理，再將當中有效的行為學返去原本模型。簡單講，即係先畀方向去探索，再將成功經驗整理吸收，呢點比純粹盲試更有系統。

實際上手方面，呢個儲存庫已經分好幾部分：資料建立、訓練基線、NudgeRL訓練，同埋評估流程。較適合本身已經會用 Python、PyTorch、CUDA 同 vLLM 的研究者；如果你係一般開發者，都可以先由評估腳本、資料格式同設定檔入手，理解整體流程先。

• 針對數學推理中的探索不足，而唔係只求更大抽樣數量
• 內置 GRPO 同 POPE 風格基線，方便比較方法差異
• 提供 DAPO-Math-17k 相關資料建構工具，唔使由零砌流程
• 評估涵蓋 AIME、AMC23、MATH500、Apex Shortlist 等數學基準
• 核心特色係將多樣化策略探索同後續行為蒸餾結合

如果你想比較相關模型或訓練路線，呢個專案最直接涉及的包括以 GRPO 為代表的 RLVR 方法、POPE 風格 oracle-prefix 基線，以及可配合 Hugging Face 模型與 LoRA adapter 的訓練評估流程。整體而言，NudgeRL較適合做推理增強、數學能力研究、後訓練方法比較的人；對想了解「如何更有效探索」而唔係「如何堆更多算力」的讀者，尤其有參考價值。

網址： https://github.com/tally0818/NudgeRL

網址： https://arxiv.org/pdf/2605.15726

如果你有留意大型語言模型，應該知道文字愈長，運算成本往往升得愈快。Lighthouse Attention 針對的正正是這個痛點：在極長上下文訓練時，用分層挑選的方法，先縮細需要重點處理的內容，再交回現成的高效注意力流程處理。

這個儲存庫不是一個即開即用的聊天程式，而是建基於 PyTorch 的 torchtitan 訓練框架之上，以補丁形式整合。換句話說，較適合本身已經做模型訓練、想比較不同注意力機制的人；一般用家未必會直接跑起，但讀它的設計仍很有參考價值。

它較特別的地方，在於不是把稀疏機制硬塞進自訂核心，而是先做選擇，再沿用現有的 FlashAttention 密集計算路線。這樣的好處是較易受惠於上游優化，也減少為新方法重寫整套底層核心的負擔。資料顯示，它提供 norm、dilated 和 gla 三種評分變體，亦支援可選的 context parallel 路徑。

如果你想上手，較實際的做法是先把它當成研究原型：按版本要求準備好 torchtitan、對應提交版本、兩個額外原始檔及補丁，再用 configs 內不同設定比較 top-K、pool、大細層數與 scorer 差異。官方資訊亦提到，它曾在 530M Llama-3 規模、以及最高百萬 token 訓練情境下驗證。

重點可以這樣看：
– 主要用途是降低超長上下文訓練時的注意力成本
– 核心做法是分層挑選重要片段，再交由密集注意力計算
– 已列出多組可比較設定：top-K、pool、levels、scorer、CP
– 相關評分或路線包括 norm、dilated、gla
– 較適合模型研究、訓練基建開發及長文本實驗場景

只要是標準的 decoder-only Transformer / causal LM，基本都可以替換它的 Q/K/V self-attention 層。

判斷標準
只要模型滿足下面幾點，就通常能做這種替換：
有 self-attention 層，而不是依賴複雜的外部編碼器。
層裡能清楚找到 q_proj / k_proj / v_proj 或等價實現。
是 decoder-only 架構，使用 causal mask。
沒有把 attention 邏輯寫死成特別難拆的自定義模塊。

最適合的模型類型
Llama 系列：最常見，結構標準，Q/K/V 分明，最容易改。
Qwen 系列：也是標準 decoder-only 路線，通常同樣適合做 attention 替換。
Mistral 系列：同樣屬於 decoder-only LLM，理論上也適合。
GPT-style / LLaMA-style 自回歸模型：只要是單向 causal attention，一般都能改。

整體來說，Lighthouse Attention 最吸引之處，不只是追求更快，而是嘗試在訓練期保留與現有生態的相容性。對需要探索 98K、512K 甚至更長上下文訓練的人，它是一個值得細看、但明顯偏研究與工程用途的專案。

網址： https://github.com/ighoshsubho/lighthouse-attention

網址： https://nousresearch.com/lighthouse-attention

POISE 是一個用於語言模型強化學習的方法，重點是讓模型在生成答案時，直接利用自己已有的隱藏狀態與熵等訊號，估計回報基線。簡單來說，它希望模型「一邊作答，一邊判斷自己表現大概應該有幾好」，從而更有效更新訓練方向。

實際使用上，這類方法特別適合有可驗證結果的任務，例如數學題最終答案是否正確。傳統做法通常要額外訓練一個 critic 模型，或者對同一提示做多次 rollout 來估基線；POISE 則改為重用 actor 本身生成時已計算出的資訊，理論上可減少訓練成本。

它的主要創新，在於把模型內部表徵重新納入 RL 更新流程，而不是依賴獨立的大型評分器。網站內容指出，這個估值器會隨政策變化持續更新，配合當前及近期 rollout，目標是令線上學習更穩定。

• 以 actor 自身隱藏狀態做 value estimation
• 不需要獨立 critic 模型
• 減少同一 prompt 的額外取樣開銷
• 適合有明確對錯驗證的任務
• 著重更輕量與穩定的 RL 訓練流程

在初步評估方面，POISE 在 held-out 的 DAPO-Math rollouts 上，內部狀態探針的 Pearson r 為 0.870、MAE 為 0.141。對比一個由 Qwen3-4B 微調而成的 critic，其 r 為 0.676、MAE 為 0.262，顯示 actor 內部訊號至少在這項基準中具有不錯的預測能力。

受惠工作包括數學解題、可程式驗證推理，以及其他能以結果回饋作訓練的語言模型流程。不過目前頁面展示內容以方法概念與初步結果為主，較完整的泛化表現與不同任務上的最終效益，仍要留意論文後續公開分析。

實驗結果

POISE 在數學推理基準 (AMC23/24, AIME24/25/26, HMMT25, BRUMO25) 上達到與 DAPO 相當的性能，但計算成本更低 。

PAE 是一個為潛在擴散模型而設的自編碼器框架，重點不只是把圖片壓縮再還原，而是先把潛在空間整理成更適合擴散模型學習的形態。簡單講，它關心的不是「壓得靚唔靚」，而是「模型之後生圖時會唔會更順、更穩定」。

實際使用上，PAE 可理解為擴散模型前面的 tokenizer 或影像編碼模組：先把圖片轉成 latent，再交畀後續生成模型訓練。這種做法特別適合本身已在做 latent diffusion、但覺得收斂慢、訓練成本高，或者生成效果未夠穩定的研究與開發流程。

這個專案較有意思的地方，是它明確提出三個「對擴散友善」的潛在空間特質：空間結構一致性、局部流形連續性，以及全域語意組織。作者不是假設這些特質會自然出現，而是用三種 prior-alignment regularization 去主動約束，這比單靠重建誤差的傳統思路更進一步。

根據專案提供的結果，PAE 在 ImageNet 256×256 上做到 gFID 1.03，並且在相同 LightningDiT 設定下，收斂速度最高可比 RAE 快 13 倍。對非研究人員而言，這代表同樣資源下有機會更快見到可用成果；不過這些表現仍應視乎資料集、訓練設定與骨幹模型而定。

• 核心定位：為 latent diffusion 準備更易學的潛在表示
• 主要創新：把「擴散友善」拆成三個可優化的性質來訓練
• 實際價值：有機會縮短訓練週期，提升生成質素與少步數採樣表現
• 適合場景：影像生成研究、需要高效率訓練的生成系統、比較不同 tokenizer 設計
• 可配骨幹：支援多種編碼器方向，包括 DINOv2、SigLIP2、DINOv3、MAE

如果你關心的是「如何令擴散模型學得更快，而唔係只換更大模型」，PAE 的切入點相當值得參考。它最適合有一定生成模型流程的人採用；對一般用家而言，未必是即裝即用工具，但作為下一代 latent tokenizer 的設計思路，含金量相當高。

Source: https://github.com/ZhengrongYue/PAE

GLM-V儲存庫提供了一系列視覺語言模型（VLMs），旨在應對複雜的人工智慧挑戰。研究人員、開發者和AI愛好者若想推動多模式推理的邊界，應該考慮使用GLM-4.6V、GLM-4.5V和GLM-4.1V進行實驗。這些模型在各種任務中表現出色，從圖像和視頻理解到GUI操作和文件分析。對於新手來說，最初專注於GLM-4.5V模型是明智的選擇，因為它具有穩健的性能和全面的文檔。這個模型作為一個堅實的基礎，在深入研究GLM-4.6V的更先進功能之前。

在實際應用中，GLM-V模型通過無縫整合視覺和文本數據來運行。它們可以解釋複雜的場景，理解複雜的文件，甚至協助處理GUI任務。例如，GLM-4.6V模型支持高達128k令牌的上下文窗口，使其能夠高效地處理廣泛的多模式輸入。這種能力使它特別適用於需要長上下文理解的任務，如分析研究報告或處理長篇文件。該模型的原生多模式函數調用功能進一步增強了其實用性，允許直接與視覺元素互動而不需要中間文本轉換。

開發者和企業最受益於這些模型自動化複雜任務和改進決策過程的能力。例如，GLM-4.5V的思考模式切換允許用戶在快速響應和深度推理之間切換，滿足多樣化的需求。這種靈活性在現實世界應用中非常寶貴，那裡速度和準確性必須平衡。此外，儲存庫中包含的桌面助手應用展示了實際用例，例如從PC螢幕捕捉視覺資訊並在各種場景中提供智能服務。

然而，也有一些權衡需要考慮。儘管GLM-V模型提供了令人印象深刻的性能，但它們需要大量的計算資源，特別是對於較大的GLM-4.6V模型。使用者應確保其硬體能夠應對這些模型的需求，以避免性能瓶頸。此外，這些模型的純文本QA能力仍有改進空間，因為目前的重點主要在視覺多模式場景上。開發者可能會遇到偶爾的問題，如重複的思考輸出或格式錯誤，這可能會影響用戶體驗。

為了最大化GLM-V模型的潛力，使用者應熟悉所提供的示例和文檔。儲存庫包括GUI代理和桌面助手的演示，提供關於提示構建和輸出處理的見解。這些示例作為優秀的起點，將GLM-V整合到現有工作流程或開發新應用中。藉助這些資源，開發者可以釋放GLM-V模型的全部潛力，並為推進智能系統領域做出貢獻。

無論你是研究人員探索最新的VLM技術，還是開發者尋求自動化複雜任務，GLM-V都提供了寶貴的解決方案。然而，使用者應當注意計算需求和當前限制。經過仔細考慮和策略應用，GLM-V模型可以顯著提升人工智慧驅動項目的性能和智慧水平。

Source: https://github.com/zai-org/GLM-V

tLLM 是 vLLM 推論引擎的運行時擴展層，提供生產者/消費者（Producer/Consumer）架構，能在生產環境中訓練和管理蒸餾器。

tLLM 的角色

• 生產者管道：從 vLLM 推論中即時捕捉 LLM 的深層隱藏狀態（latent representations）
• 消費者管道：非同步訓練輕量 MLP（~1M 參數），這就是 Latent Distiller（潛在蒸餾器）

tLLM 可應用於醫療問答系統中，提升 RAG 生成的多樣性與準確性，特別適合配合 MedGemma 專案。 透過 ESamp (Exploratory Sampling )方法，在高吞吐 vLLM 服務下動態訓練輕量蒸餾器，引導模型探索未見語義區域，避免重複答案。

案例：醫療 RAG 系統

假設您建置一個基於 MedGemma 的繁體中文醫療 RAG 系統，處理患者查詢如「糖尿病併發症預防」。

• 標準 vLLM：依賴檢索文件生成單一答案，易陷入常見模式，Pass@1 低於 60%。
• tLLM + ESamp：啟用生產者管道捕捉隱藏表示，消費者訓練 Latent Distiller（MLP，~1M 參數），使用預測誤差作為新穎度信號。
• 運行流程：批次 32 查詢並行生成，蒸餾器線上更新（<5% 開銷），重新取樣產生多樣候選（如生活調整、藥物、飲食多視角），Pass@k 提升 20-30%。

此案例在 RTX 4090 上吞吐 4000+ tokens/sec，適合部署於 WhatsApp 查詢閘道，提升 Cantonese/繁中醫療 NLP 效能。 程式碼範例：整合 tLLM 至 vLLM Engine，engine = TLlmEngine.from_engine_args(engine_args) 啟動生產者/消費者。