本博客介紹了五個基本概念,闡述了大語言模型如何處理上下文窗口中的輸入。通過明確的例子和實踐中獲得的見解,本文介紹了多個與上下文窗口有關的基本概念,如詞元化、序列長度和注意力等。本文的目標是幫助讀者深入了解 AI 應用程序中的上下文如何影響模型行為。我們還通過用于評估系統行為的分析模型展示了相關結果,以演示當改變輸入和輸出序列長度時,對應的響應時間如何改變。演示結果表明,解碼更長的輸出需要花費更多時間。這意味著,在執行大規模高效推理時,HBM 等高速內存系統至關重要。對于正在使用或設計生成式 AI 系統提示詞的人,這些概念都非常有幫助。
上下文窗口與上下文長度
使用大語言模型時,我們有必要了解上下文窗口、上下文長度和序列長度等概念之間的差別。這些術語經常被互換使用,可能會讓一些人感到迷惑。在本博客中,我們將把它們定義為不同的概念。
上下文窗口是模型的最大容量,也就是模型可以同時處理的詞元總數,包括您的輸入和模型的輸出。舉個簡單的例子:我們將下面的矩形大小定義為可容納 10 萬個詞元的上下文窗口。

圖 1:10 萬詞元上下文窗口的大小
上下文長度則是指您在該空間中放置了多少詞元,即您與模型對話期間當前實際使用過的詞元數量,包括輸入詞元(藍色)和輸出詞元(綠色)。例如,如果模型具有可容納 10 萬個詞元的上下文窗口,并且您的輸入使用了 7.5 萬個詞元,那么,只有 2.5 萬個詞元可用于模型的響應,繼續輸出便會超出窗口的上限。
序列長度通常是指上下文窗口內單個輸入或輸出序列的長度。這是一種更精細的測量方法,可在模型訓練和推理過程中跟蹤每個文本段的長度。

圖 2:7.5 萬個輸入詞元和 2.5 萬個輸出詞元
上下文窗口決定了模型可以處理的信息量上限,但它并不直接反映模型的智能水平。窗口越大,可容納的輸入信息就越多,但輸出質量往往取決于輸入信息的結構化程度與實際利用效率。一旦達到窗口的容量上限,模型在處理時可能會失去連貫性,進而導致不理想的結果(例如,AI 幻覺)。

圖 3:輸入和輸出序列長度
詞元不是單詞
如果上下文窗口由一個上限(例如 10 萬個)來定義,那么詞元就是衡量其容量的計量單位。重要的是,我們需要理解:詞元并非單詞。您在提示詞中輸入的單詞將首先進入一個“詞元分詞器”中,該分詞器將把文本分解為詞元。一個單詞可能會分解成幾個詞元。例如,“strawberry”會分解成三個詞元,“trifle”則會分解成兩個詞元。有時候,一個單詞可能只包含一個詞元,例如“cake”。

我們可以用簡·奧斯汀的小說《愛瑪》中的句子來測試單詞與詞元的關系。
“Seldom, very seldom, does complete truth belong to any human disclosure; seldom can it happen that something is not a little disguised or a little mistaken.”
這段文本包含 26 個單詞,當我們使用 lunary.ai1提供的 Mistral 語言模型來處理這段文本時,模型自帶的詞元分詞器將生成 36 個詞元。這個例子中,每個詞元大約對應 0.72 個單詞,或者說大約對應四分之三個單詞。

不同類型的文本中,詞元與單詞的比例各不相同。不過,就英語單詞而言,每個詞元平均對應大約 0.75 個單詞。因此,擁有 10 萬詞元上下文窗口(每用戶)的模型不一定能處理 10 萬個單詞。在實際應用中,該模型也許只能處理將近 7.5 萬個英語單詞,或者更少,具體取決于文本類型。
估計值詞元數≈單詞數?1.33
為進一步在更大規模上測試詞元與單詞的比率,我們使用了來自“古騰堡計劃”(Project Gutenberg,一個包含超過 7.5 萬本免費電子書的圖書館)的八部知名文學作品,對其中的文本進行了快速分析。首先,我們計算了每本書中的單詞數,然后通過詞元分詞器運行全部文本,以獲得詞元數。在對這些數字進行比較后,我們發現,每詞元平均對應大約 0.75 個單詞。

a數據來自于上列美國和英國文學作品的純文本版本(通過“古騰堡計劃”獲得)。詞元數通過 Lunary 公開提供的 OpenAI 詞元分詞器進行計算1。詞元數與單詞數的平均比例(1 詞元 ≈ 0.75 單詞)通過八部文學作品得到了驗證。
了解詞元數與單詞數的平均比例,可以讓經常使用 AI 的用戶更有效地與 AI 互動。大多數 AI 平臺(如 ChatGPT 或 Claude)在提供服務時都有詞元總數限制。也就是說,這些平臺使用詞元而非單詞來處理文本。這就導致用戶很容易誤判實際上可以輸入的提示詞單詞量,或者 AI 響應時輸出的單詞數量。由于平臺通常以詞元而非單詞來衡量輸入輸出的內容量,因此了解詞元與單詞的比率,可以讓您更好地理解平臺的限制,從而更巧妙地規劃您的輸入。例如,如果一個模型的輸入限制為 4,000 詞元,則大約對應 3,000 單詞。在為模型提供長文檔或數據集時,最好了解這一點,以便更有效地完成諸如查找關鍵見解或回答問題等任務。

圖 4:單詞與詞元的比率
注意力在上下文窗口內并非均勻分布
人們經常會誤解 AI 幻覺,將其視為模型的異常行為,或者將其作為語言模型存在問題以及不可靠的證據。但 AI 幻覺并非隨機產生的;它們往往源于模型如何處理信息以及優先處理哪些信息,而這又取決于模型的訓練效果、注意力分配機制等因素。在 GPT 或 Claude 等基于轉換器的模型中,注意力是一種機制,用來幫助模型決定上下文中的哪些部分與用戶的意圖最相關,然后據此生成響應。為了更好地理解注意力的概念,設想您現在正身處一個嘈雜的雞尾酒會上。如果旁邊有人叫您的名字,您會本能地集中注意力。
“Frodo! 來這里!”
但是,如果四個人從房間的不同角落同時叫您的名字,情況又如何呢?
“Frodo!我是 Sam!”
“Frodo!快過來!”
“Frodo!看這邊?!?/p>
“Frodo……啊,親愛的 Frodo……”
您聽到了所有這些招呼,但您的注意力現在被分散了。您可能更關注熟悉的聲音,或者距離您最近的聲音。每個聲音都讓您分出了一部分注意力,但這些部分的大小并不相同。這個例子并不完全貼切,但可以幫助我們理解大語言模型中注意力的運作方式。模型會分配注意力給上下文窗口中的所有詞元,但其中一些詞元的權重高于其他詞元。這就是為什么大語言模型中的注意力通常被描述為“加權式”,這意味著并非所有詞元都獲得了同樣的注意力。這種不均勻分配是理解模型如何優先處理信息,以及它們有時似乎會“走神”的關鍵。
更多上下文不一定意味著更好的答案
模型會掃描上下文窗口內的所有詞元,但它不會為每個詞元分配相等的注意力。隨著窗口中的內容越來越多(例如,多達 10 萬個詞元),模型的注意力會變得更加分散。模型試圖跟蹤所有詞元,這可能導致模型失去清晰的目標。
當這種情況發生時,模型會逐漸偏離當前對話,用戶可能會感覺到回應變慢、不太連貫,甚至出現混淆對話前后內容的情況。這個時候,AI 經常會出現“幻覺”(Hallucinations,源自拉丁詞 hallucinat,原意為“思想進入歧途”)。重要的是,我們要明白,這并不是模型出現故障的跡象。這實際上標志著模型已接近其能力閾值,正在滿負荷運行。在此節點上,模型可能難以在過長的輸入中保持連貫性或相關性。
從模型的角度來看,先前輸入的詞元仍然可見。但隨著窗口內容的增加,注意力的分散,響應的精度可能會降低。模型可能會將先前提示詞中提到的事實錯誤地放到當前問題中,或者將不相關的想法融合到輸出中,使輸出看起來很連貫但卻毫無意義。在出現幻覺的情況下,模型不是在撒謊。它正在試圖從無法清晰區分的大量片段中得出合理的響應,在注意力不足的情況下進行猜測。公允地說,模型其實是在基于現有信息努力運作,試圖理解一段已超出其可靠處理能力的冗長對話。通過這種方式來理解注意力,有助于解釋為什么更多上下文并不一定意味著更好的答案。2
話雖如此,較長的上下文窗口(超過 20 萬詞元,目前已經有模型支持 100 萬或更多詞元)也可能確實非常有用,特別是對于復雜的推理以及視頻處理等新興應用。一些新模型正在接受訓練,旨在更有效地處理更長的上下文。通過優化架構和訓練,模型可以更有效地管理對輸入的注意力,減少幻覺,提高響應的質量。因此,盡管更多的上下文并不一定帶來更好的答案,但新模型在保持注意力方面表現得越來越好,即使在處理特別長的對話時也是如此。
序列長度影響響應時間
在解析注意力機制之后,了解序列長度如何影響模型推理同樣很有幫助。現在,我們可以問一個很實用的問題:當我們改變序列長度時,會發生什么?
輸入序列長度會影響首詞元時延 (TTFT)——即從輸入請求到收到第一個輸出詞元的時間。TTFT 與 GPU 性能密切相關,因為它反映了 GPU 處理輸入、執行計算,然后輸出第一個詞元的速度。而改變輸出序列長度會影響詞元間延遲 (ITL)——兩個相繼生成的詞元之間的時間。b該延遲與內存的使用情況關系更大。
為進一步探究這一點,我們使用了一階分析模型,來估計大語言模型推理期間的端到端延遲。我們在單個 GPU 上使用 Llama 3 70B 來運行該模型,該 GPU 帶有高帶寬內存(HBM3E 12H,8 層堆疊,36GB 容量),模型的上下文窗口為 128,000 個詞元。c
b關鍵推理指標:首詞元時延 (TTFT):模型在收到輸入后到開始生成輸出所需的時間(預填充性能)。詞元間延遲 (ITL):兩個相繼生成的詞元之間的時間(解碼性能)。端到端延遲:從提交查詢到收到完整響應所需的時間。3
c性能估算基于內部分析模型,旨在近似模擬推理行為。本研究中構建的系統基于估計的 GPU 配置,該配置反映了市售硬件平臺的一般特性。所選配置不代表任何特定產品,僅用于支持本分析中的技術目標。這些估算值并不反映經過優化的軟件或硬件配置,因此可能與實際結果不同。
下圖顯示了輸入序列長度 (ISL) 和輸出序列長度 (OSL) 逐漸增加時對整個端到端延遲的影響。每次測量的批量大小為 1(即單個請求)。所需能耗較少。

圖 5:不同輸出和輸入序列長度對應的每用戶端到端延遲(秒)
關鍵要點
測量延遲時的一個重要結論是,模型生成長響應所需的時間,要遠遠超過處理長提示詞時所需的時間。該模型能夠一次性讀取和理解輸入,即使是特別長的提示詞,處理速度也相對較快。但是,在模型生成響應時,是逐詞元依次生成的,每個新詞元的生成,都取決于之前已經生成的所有內容。這需要更多的時間,因為模型會執行自動回歸流程,這意味著每個新詞元都建立在之前生成的所有詞元基礎上。例如,將輸入序列長度 (ISL) 從 2,000 個詞元增加到 125,000 個詞元,僅導致延遲增加大約兩倍。相比之下,在同樣范圍內增加輸出序列長度 (OSL),延遲將增加大約 68 倍。d之所以產生這種差異,是因為較長的輸入序列引發了更多預填充計算,可并行處理多個詞元。與之相反,解碼在本質上是一個串行過程,只能依次生成每一個詞元,這需要耗費更多時間,以及更多的內存帶寬。
這意味著更長的輸出序列會導致更長的解碼時間,同時 GPU 和內存子系統保持活躍狀態的時間也會變長。這種情況下,硬件級別的功效將會變得特別重要。類似美光 HBM3Ee 這樣的內存設備,其運行功耗比同類高帶寬內存設備低得多,能夠以較少的能量完成相同的推理任務。
d此處給出的估計值來自未優化的分析模型,因此它們僅用于說明一般趨勢,而非峰值性能。
e美光 HBM3E 的功耗比市場上同類高帶寬內存設備低 30%。
對用戶而言,上述結論彰顯出優化提示詞以及管理輸入長度(例如,精簡任何不必要的內容)的重要性。如果您正在構建實時應用程序,您通常可以放心處理更長的輸入,不會有太多問題。而保持簡潔的輸出,可能有助于您的系統運行更快,響應更迅速。
內存在處理更長上下文時的重要作用
推理延遲不僅取決于序列長度,還取決于系統在處理輸入和生成輸出時如何管理模型對計算和內存的需求。許多近期發布的語言模型正在宣傳其超過百萬詞元的上下文窗口。這些較大的上下文窗口(當完全利用時)將對內存子系統產生更大的壓力,其后果在用戶看來可能包括執行速度較慢、運行時間增加等。新一代內存技術將提供更高的帶寬和更大的容量,可支持這些更大的上下文窗口,幫助縮短響應時間,提高整體吞吐量(每秒生成的詞元數)。但是,伴隨著這些性能提升,也出現了系統能耗過大的問題。隨著推理工作負載擴大到支持數百萬個詞元,設計出能夠高效使用能源的系統,變得越來越重要。長時間保持活動狀態的系統需要消耗更多能源,為解決這一挑戰,需要同時具備高帶寬和低功耗特性的內存設備。例如,美光 HBM3E 的功耗遠低于市場上的同類高帶寬內存設備。此類低功耗產品有助于減少 AI 在運行推理工作負載(涉及數百萬詞元上下文窗口)期間所消耗的能量。展望未來,HBM4 和 HBM4E 等下一代內存技術旨在提供更高的內存帶寬和容量,同時提高能效。這些改進源于工藝技術的進步(美光使用 1-gamma DRAM),預計將以更低的能源成本實現更快的數據移動。此外,隨著這些技術的成熟,可能會進一步減少延遲,提高大規模 AI 部署的吞吐量并節約能源。
技術貢獻者
Felippe Vieira Zacarias
系統性能工程師
Shanya Chaubey
生態系統開發經理
本文作者
Evelyn Grevelink
內容戰略營銷負責人
-
內存
+關注
關注
9文章
3209瀏覽量
76358 -
AI
+關注
關注
91文章
39763瀏覽量
301366 -
模型
+關注
關注
1文章
3751瀏覽量
52099
原文標題:大語言模型中與上下文窗口有關的五個基本概念
文章出處:【微信號:gh_195c6bf0b140,微信公眾號:Micron美光科技】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
關于進程上下文、中斷上下文及原子上下文的一些概念理解
進程上下文與中斷上下文的理解
中斷中的上下文切換詳解
基于多Agent的用戶上下文自適應站點構架
基于交互上下文的預測方法
終端業務上下文的定義方法及業務模型
基于Pocket PC的上下文菜單實現
基于Pocket PC的上下文菜單實現
基于上下文相似度的分解推薦算法
Web服務的上下文的訪問控制策略模型
初學OpenGL:什么是繪制上下文
如何分析Linux CPU上下文切換問題
我們能否擴展現有的預訓練 LLM 的上下文窗口
NVIDIA BlueField-4為推理上下文記憶存儲平臺提供強大支持
大語言模型如何處理上下文窗口中的輸入
評論