ICLR 2024：思維框架 原創
本工作旨在減少大型語言模型（LLMs）的端到端生成延遲。高生成延遲的主要原因之一是幾乎所有最先進的LLMs都采用了順序解碼方法。在這項工作中，受到人類思考和寫作過程的啟發，研究人員提出了思維框架（SoT），它首先指導LLMs生成答案的骨架，然后進行并行API調用或批處理解碼以并行完成每個骨架點的內容。SoT不僅可以顯著加速12個LLMs的速度，而且還可以潛在地提高幾個問題類別的答案質量。SoT是對推理效率進行數據中心優化的初步嘗試，進一步強調了將LLMs推向更像人類思考的潛力，以提高答案質量。
背景
大型語言模型（LLMs）的生成過程很慢。例如，Claude（于2023年7月中旬通過Slack訪問）回答“工作場所沖突解決最有效的策略是什么”問題需要22秒，Vicuna-33B V1.3（基于33B LLaMA模型，本地在一臺NVIDIA A100 GPU上運行）需要43秒。
LLM的慢推理問題有三個主要原因：
- （1）由大型模型大小引起的大內存、內存訪問和計算量；
- （2）流行的Transformer架構中注意力的二次內存和計算復雜度；
- （3）生成過程采用逐個生成標記的順序解碼方法。大量文獻已經通過壓縮/重新設計模型或重新設計服務系統和硬件來解決前兩個問題軸線。
能否加速現成的LLMs而不對它們的模型、系統或硬件進行任何更改？研究人員展示了對現成LLMs進行并行解碼的可行性！
方法
這個想法源于反思人類如何回答問題。人類不總是按順序思考問題并寫答案。相反，對于許多類型的問題，我們首先根據某些協議和策略導出骨架，然后添加證據和細節來完善和闡明每一點。在像提供咨詢、參加考試、寫論文等正式場合，尤其如此。我們能讓LLMs以同樣的方式思考嗎？為此，研究人員提出了思維框架（SoT）。具體來說，如下所示，首先引導LLMs自行導出一個骨架。基于骨架，LLMs可以并行完成每個點，從而獲得加速。請注意，SoT可以用于加速具有批處理解碼的開源模型和具有并行API調用的閉源模型。
（1）骨架階段
SoT首先使用骨架提示模板和原始問題組裝一個骨架請求。骨架提示模板編寫以指導LLMs輸出答案的簡明骨架。然后，從LLMs的骨架響應中提取B個點。
骨架提示模板：為了使輸出骨架簡短且格式一致，以提高效率和點提取的便利性，骨架提示模板（1）精確描述任務，（2）使用兩個簡單的演示，（3）提供部分答案“1.”供LLMs繼續寫作。研究人員發現，在大多數情況下，骨架響應都符合期望的格式。因此，可以簡單地使用正則表達式從骨架響應中提取點索引和點骨架。
（2）點擴展階段
根據骨架，研究人員使用點擴展提示模板組裝B個點擴展請求，并讓LLMs并行擴展每個點。對于僅具有API訪問權限的專有模型，可以發出多個并行API調用。對于開源模型，讓模型將點擴展請求作為批處理處理（在點擴展請求的左側添加填充）。最后，在完成所有點之后，連接點擴展響應以獲得最終答案。
點擴展提示模板：點擴展提示模板描述點擴展任務并提供部分答案。研究人員還提供了“非常簡短地寫”1～2句的指示，以便LLMs保持答案簡明。與骨架提示模板不同，研究人員發現不需要演示也可以獲得合理的結果。
具有路由器的SoT（SoT-R）：自適應觸發SoT
SoT進行獨立和并行的點擴展。因此，它不適用于以下類型的問題：（1）需要逐步推理的問題，（2）僅需要非常簡短答案的問題，以及（3）不能獨立解碼以保持連貫性的問題。因此，為了推動SoT的實際應用，研究人員探索了僅在合適時自適應觸發SoT的可能性。為實現這一目標，提出了一個路由器模塊，該模塊決定是否應用SoT進行用戶請求，并相應地調用SoT或普通解碼。為了實現路由器，研究人員探索了兩種選項：LLM提示作為路由器（無需模型訓練），以及在LIMA上進行訓練、在Vicuna-80和WizardLM上進行測試的RoBERTa作為路由器。研究人員將整體解決方案命名為帶有路由器的SoT（SoT-R）。
結果
數據集。使用了（1）包含80個問題的Vicuna-80數據集，涵蓋編碼、數學、寫作、角色扮演等九個類別，以及（2）包含218個問題的WizardLM數據集，涵蓋更多類別和不同難度。
模型。對12個最近發布的模型進行了SoT和SoT-R的測試，包括9個開源模型和3個基于API的模型，如下所示。
效率評估。使用time.time記錄API調用的延遲，使用torch.cuda.Events記錄本地模型運行的延遲。所有本地模型均使用FastChat - HuggingFace transformer - PyTorch庫堆棧運行，并采用FP16精度。
答案質量評估。遵循最近的做法，讓一個LLM判斷比較答案。研究人員使用FastChat和LLMZoo的評估提示，并詢問GPT-4對答案的偏好。
下圖左側顯示了整體解決方案SoT-R實現的答案質量和加速效果。SoT-R可以加速基于API和開源模型的生成。此外，SoT-R還可以改善許多模型的答案質量。這是因為SoT中的骨架階段鼓勵LLMs從圍繞問題的多個角度思考，提高了答案的多樣性和相關性。
對于SoT-R為何有所幫助的一些詳細信息，請參見下圖右側，該圖顯示SoT-R成功地針對適合的問題類別觸發SoT，并對其他問題類別進行正常生成，從而保持了這些類別的答案質量。
SoT與路由器（SoT-R）在Vicuna-80上與正常生成相比的凈勝率和加速比。凈勝率是SoT-R的答案優于或劣于正常生成的問題分數之差。加速比是正常生成和SoT-R生成的延遲比率。（1.0, 0.0）表示正常生成。在兩個軸上都更高更好。對于大多數模型來說，SoT-R不僅加速了生成，還提高了答案質量。
（上圖）SoT和SoT-R在Vicuna-80上不同問題類別的凈勝率。對于不適合SoT的問題類別，SoT-R學會了回退到正常生成模式。因此，SoT-R可以保持所有問題類別的良好答案質量。
（下圖）SoT和SoT-R在Vicuna-80上不同模型的加速比。SoT-R可以為大多數模型保持>1的加速比。
問題和展望
引導或提高LLMs的能力
SoT展示了提高答案質量的潛力。這是最近研究的一個更廣泛趨勢的一部分，例如CoT、ToT和ReAct等工作，這些工作共同證實了在語言中明確表達思維過程可以引出高質量的答案的觀點。這些發現類似于人類的思維：經常記錄逐步推理或思維組織，而不是僅依靠第一直覺或純粹的順序思維來獲得高質量的答案。這種有趣的類比促使進一步探索如何從人類的思維過程中汲取經驗，以促進更有效和高效的人工智能。
例如，SoT目前忽略了點之間的依賴關系。一個在概念上更好的方法是將這些點組織成思維圖，其中邊表示依賴關系，并且每個點的解碼是依賴于其祖先點的內容。此外，研究人員預期需要動態思維圖，而不是遵循靜態圖，其中高層思維結構由LLMs自己動態調整。這可能將SoT的效率和全局思維優勢與邏輯推理和即興思考等方法（例如CoT）的優勢結合起來。
此外，還存在自我改進的訓練管道，利用CoT生成的理由來微調LLMs，從而增強它們的推理能力。同樣，有趣的是調查來自SoT的更結構化答案如何用于微調LLMs，以增強它們生成井然有序和全面答案的能力。
不同情景下SoT的效率和開銷
服務系統通常采用批處理來處理并發查詢。這引發了一個擔憂，即SoT是否會由于并行請求而影響服務吞吐量。(1) 當存在未飽和的并發查詢數量時，SoT可以有效地減少延遲并提高GPU利用率。示例場景包括（a）具有單個用戶的邊緣應用；（b）在用戶請求未飽和且計算能力未充分利用的時期的集中式服務。有趣的是根據系統工作負載研究適當的SoT觸發條件。(2) 當存在飽和的并發查詢數量時，SoT仍然有助于提高答案質量。然而，在這種情況下，重要的是考慮來自SoT的計算開銷。
對于基于API的模型，存在一個顯著的問題，即填充令牌的數量增加。鑒于許多API收取令牌使用費，SoT可能導致更高的成本。為了解決這個問題，可以調整并行API請求的數量（通過在單個API調用中擴展多個點），或者使用提示調整來設計更短的SoT提示。
以數據為中心的效率優化
雖然以數據為中心的工程正在流行中用于提高答案質量，但其對推理效率的潛力尚未被充分探索。SoT是第一次嘗試。隨著LLM的能力和LLM生成的數據量迅速增長，未來數據為中心的技術可能變得更加有用。期待著更多的探索，以發掘數據為中心的效率優化的全部潛力。
譯自（有刪改）：https://sites.google.com/view/sot-llm
本文轉載自公眾號AIGC最前線
