91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認(rèn)識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

大語言模型如何處理上下文窗口中的輸入

Micron美光科技 ? 來源:Micron美光科技 ? 2025-12-03 13:48 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

本博客介紹了五個基本概念,闡述了大語言模型如何處理上下文窗口中的輸入。通過明確的例子和實(shí)踐中獲得的見解,本文介紹了多個與上下文窗口有關(guān)的基本概念,如詞元化、序列長度和注意力等。本文的目標(biāo)是幫助讀者深入了解 AI 應(yīng)用程序中的上下文如何影響模型行為。我們還通過用于評估系統(tǒng)行為的分析模型展示了相關(guān)結(jié)果,以演示當(dāng)改變輸入和輸出序列長度時,對應(yīng)的響應(yīng)時間如何改變。演示結(jié)果表明,解碼更長的輸出需要花費(fèi)更多時間。這意味著,在執(zhí)行大規(guī)模高效推理時,HBM 等高速內(nèi)存系統(tǒng)至關(guān)重要。對于正在使用或設(shè)計生成式 AI 系統(tǒng)提示詞的人,這些概念都非常有幫助。

上下文窗口與上下文長度

使用大語言模型時,我們有必要了解上下文窗口、上下文長度和序列長度等概念之間的差別。這些術(shù)語經(jīng)常被互換使用,可能會讓一些人感到迷惑。在本博客中,我們將把它們定義為不同的概念。

上下文窗口是模型的最大容量,也就是模型可以同時處理的詞元總數(shù),包括您的輸入和模型的輸出。舉個簡單的例子:我們將下面的矩形大小定義為可容納 10 萬個詞元的上下文窗口。

65daa2d0-cb3e-11f0-8c8f-92fbcf53809c.png

圖 1:10 萬詞元上下文窗口的大小

上下文長度則是指您在該空間中放置了多少詞元,即您與模型對話期間當(dāng)前實(shí)際使用過的詞元數(shù)量,包括輸入詞元(藍(lán)色)和輸出詞元(綠色)。例如,如果模型具有可容納 10 萬個詞元的上下文窗口,并且您的輸入使用了 7.5 萬個詞元,那么,只有 2.5 萬個詞元可用于模型的響應(yīng),繼續(xù)輸出便會超出窗口的上限。

序列長度通常是指上下文窗口內(nèi)單個輸入或輸出序列的長度。這是一種更精細(xì)的測量方法,可在模型訓(xùn)練和推理過程中跟蹤每個文本段的長度。

6632c492-cb3e-11f0-8c8f-92fbcf53809c.png

圖 2:7.5 萬個輸入詞元和 2.5 萬個輸出詞元

上下文窗口決定了模型可以處理的信息量上限,但它并不直接反映模型的智能水平。窗口越大,可容納的輸入信息就越多,但輸出質(zhì)量往往取決于輸入信息的結(jié)構(gòu)化程度與實(shí)際利用效率。一旦達(dá)到窗口的容量上限,模型在處理時可能會失去連貫性,進(jìn)而導(dǎo)致不理想的結(jié)果(例如,AI 幻覺)。

668e1572-cb3e-11f0-8c8f-92fbcf53809c.png

圖 3:輸入和輸出序列長度

詞元不是單詞

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

66e86fe0-cb3e-11f0-8c8f-92fbcf53809c.png

我們可以用簡·奧斯汀的小說《愛瑪》中的句子來測試單詞與詞元的關(guān)系。

“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 個單詞,當(dāng)我們使用 lunary.ai1提供的 Mistral 語言模型來處理這段文本時,模型自帶的詞元分詞器將生成 36 個詞元。這個例子中,每個詞元大約對應(yīng) 0.72 個單詞,或者說大約對應(yīng)四分之三個單詞。

67412f86-cb3e-11f0-8c8f-92fbcf53809c.png

不同類型的文本中,詞元與單詞的比例各不相同。不過,就英語單詞而言,每個詞元平均對應(yīng)大約 0.75 個單詞。因此,擁有 10 萬詞元上下文窗口(每用戶)的模型不一定能處理 10 萬個單詞。在實(shí)際應(yīng)用中,該模型也許只能處理將近 7.5 萬個英語單詞,或者更少,具體取決于文本類型。

估計值詞元數(shù)≈單詞數(shù)?1.33

為進(jìn)一步在更大規(guī)模上測試詞元與單詞的比率,我們使用了來自“古騰堡計劃”(Project Gutenberg,一個包含超過 7.5 萬本免費(fèi)電子書的圖書館)的八部知名文學(xué)作品,對其中的文本進(jìn)行了快速分析。首先,我們計算了每本書中的單詞數(shù),然后通過詞元分詞器運(yùn)行全部文本,以獲得詞元數(shù)。在對這些數(shù)字進(jìn)行比較后,我們發(fā)現(xiàn),每詞元平均對應(yīng)大約 0.75 個單詞。

679b5524-cb3e-11f0-8c8f-92fbcf53809c.png

a數(shù)據(jù)來自于上列美國和英國文學(xué)作品的純文本版本(通過“古騰堡計劃”獲得)。詞元數(shù)通過 Lunary 公開提供的 OpenAI 詞元分詞器進(jìn)行計算1。詞元數(shù)與單詞數(shù)的平均比例(1 詞元 ≈ 0.75 單詞)通過八部文學(xué)作品得到了驗(yàn)證。

了解詞元數(shù)與單詞數(shù)的平均比例,可以讓經(jīng)常使用 AI 的用戶更有效地與 AI 互動。大多數(shù) AI 平臺(如 ChatGPT 或 Claude)在提供服務(wù)時都有詞元總數(shù)限制。也就是說,這些平臺使用詞元而非單詞來處理文本。這就導(dǎo)致用戶很容易誤判實(shí)際上可以輸入的提示詞單詞量,或者 AI 響應(yīng)時輸出的單詞數(shù)量。由于平臺通常以詞元而非單詞來衡量輸入輸出的內(nèi)容量,因此了解詞元與單詞的比率,可以讓您更好地理解平臺的限制,從而更巧妙地規(guī)劃您的輸入。例如,如果一個模型的輸入限制為 4,000 詞元,則大約對應(yīng) 3,000 單詞。在為模型提供長文檔或數(shù)據(jù)集時,最好了解這一點(diǎn),以便更有效地完成諸如查找關(guān)鍵見解或回答問題等任務(wù)。

67f64ed4-cb3e-11f0-8c8f-92fbcf53809c.png

圖 4:單詞與詞元的比率

注意力在上下文窗口內(nèi)并非均勻分布

人們經(jīng)常會誤解 AI 幻覺,將其視為模型的異常行為,或者將其作為語言模型存在問題以及不可靠的證據(jù)。但 AI 幻覺并非隨機(jī)產(chǎn)生的;它們往往源于模型如何處理信息以及優(yōu)先處理哪些信息,而這又取決于模型的訓(xùn)練效果、注意力分配機(jī)制等因素。在 GPT 或 Claude 等基于轉(zhuǎn)換器的模型中,注意力是一種機(jī)制,用來幫助模型決定上下文中的哪些部分與用戶的意圖最相關(guān),然后據(jù)此生成響應(yīng)。為了更好地理解注意力的概念,設(shè)想您現(xiàn)在正身處一個嘈雜的雞尾酒會上。如果旁邊有人叫您的名字,您會本能地集中注意力。

“Frodo! 來這里!”

但是,如果四個人從房間的不同角落同時叫您的名字,情況又如何呢?

“Frodo!我是 Sam!”

“Frodo!快過來!”

“Frodo!看這邊。”

“Frodo……啊,親愛的 Frodo……”

您聽到了所有這些招呼,但您的注意力現(xiàn)在被分散了。您可能更關(guān)注熟悉的聲音,或者距離您最近的聲音。每個聲音都讓您分出了一部分注意力,但這些部分的大小并不相同。這個例子并不完全貼切,但可以幫助我們理解大語言模型中注意力的運(yùn)作方式。模型會分配注意力給上下文窗口中的所有詞元,但其中一些詞元的權(quán)重高于其他詞元。這就是為什么大語言模型中的注意力通常被描述為“加權(quán)式”,這意味著并非所有詞元都獲得了同樣的注意力。這種不均勻分配是理解模型如何優(yōu)先處理信息,以及它們有時似乎會“走神”的關(guān)鍵。

更多上下文不一定意味著更好的答案

模型會掃描上下文窗口內(nèi)的所有詞元,但它不會為每個詞元分配相等的注意力。隨著窗口中的內(nèi)容越來越多(例如,多達(dá) 10 萬個詞元),模型的注意力會變得更加分散。模型試圖跟蹤所有詞元,這可能導(dǎo)致模型失去清晰的目標(biāo)。

當(dāng)這種情況發(fā)生時,模型會逐漸偏離當(dāng)前對話,用戶可能會感覺到回應(yīng)變慢、不太連貫,甚至出現(xiàn)混淆對話前后內(nèi)容的情況。這個時候,AI 經(jīng)常會出現(xiàn)“幻覺”(Hallucinations,源自拉丁詞 hallucinat,原意為“思想進(jìn)入歧途”)。重要的是,我們要明白,這并不是模型出現(xiàn)故障的跡象。這實(shí)際上標(biāo)志著模型已接近其能力閾值,正在滿負(fù)荷運(yùn)行。在此節(jié)點(diǎn)上,模型可能難以在過長的輸入中保持連貫性或相關(guān)性。

從模型的角度來看,先前輸入的詞元仍然可見。但隨著窗口內(nèi)容的增加,注意力的分散,響應(yīng)的精度可能會降低。模型可能會將先前提示詞中提到的事實(shí)錯誤地放到當(dāng)前問題中,或者將不相關(guān)的想法融合到輸出中,使輸出看起來很連貫但卻毫無意義。在出現(xiàn)幻覺的情況下,模型不是在撒謊。它正在試圖從無法清晰區(qū)分的大量片段中得出合理的響應(yīng),在注意力不足的情況下進(jìn)行猜測。公允地說,模型其實(shí)是在基于現(xiàn)有信息努力運(yùn)作,試圖理解一段已超出其可靠處理能力的冗長對話。通過這種方式來理解注意力,有助于解釋為什么更多上下文并不一定意味著更好的答案。2

話雖如此,較長的上下文窗口(超過 20 萬詞元,目前已經(jīng)有模型支持 100 萬或更多詞元)也可能確實(shí)非常有用,特別是對于復(fù)雜的推理以及視頻處理等新興應(yīng)用。一些新模型正在接受訓(xùn)練,旨在更有效地處理更長的上下文。通過優(yōu)化架構(gòu)和訓(xùn)練,模型可以更有效地管理對輸入的注意力,減少幻覺,提高響應(yīng)的質(zhì)量。因此,盡管更多的上下文并不一定帶來更好的答案,但新模型在保持注意力方面表現(xiàn)得越來越好,即使在處理特別長的對話時也是如此。

序列長度影響響應(yīng)時間

在解析注意力機(jī)制之后,了解序列長度如何影響模型推理同樣很有幫助?,F(xiàn)在,我們可以問一個很實(shí)用的問題:當(dāng)我們改變序列長度時,會發(fā)生什么?

輸入序列長度會影響首詞元時延 (TTFT)——即從輸入請求到收到第一個輸出詞元的時間。TTFT 與 GPU 性能密切相關(guān),因?yàn)樗从沉?GPU 處理輸入、執(zhí)行計算,然后輸出第一個詞元的速度。而改變輸出序列長度會影響詞元間延遲 (ITL)——兩個相繼生成的詞元之間的時間。b該延遲與內(nèi)存的使用情況關(guān)系更大。

為進(jìn)一步探究這一點(diǎn),我們使用了一階分析模型,來估計大語言模型推理期間的端到端延遲。我們在單個 GPU 上使用 Llama 3 70B 來運(yùn)行該模型,該 GPU 帶有高帶寬內(nèi)存(HBM3E 12H,8 層堆疊,36GB 容量),模型的上下文窗口為 128,000 個詞元。c

b關(guān)鍵推理指標(biāo):首詞元時延 (TTFT):模型在收到輸入后到開始生成輸出所需的時間(預(yù)填充性能)。詞元間延遲 (ITL):兩個相繼生成的詞元之間的時間(解碼性能)。端到端延遲:從提交查詢到收到完整響應(yīng)所需的時間。3

c性能估算基于內(nèi)部分析模型,旨在近似模擬推理行為。本研究中構(gòu)建的系統(tǒng)基于估計的 GPU 配置,該配置反映了市售硬件平臺的一般特性。所選配置不代表任何特定產(chǎn)品,僅用于支持本分析中的技術(shù)目標(biāo)。這些估算值并不反映經(jīng)過優(yōu)化的軟件或硬件配置,因此可能與實(shí)際結(jié)果不同。

下圖顯示了輸入序列長度 (ISL) 和輸出序列長度 (OSL) 逐漸增加時對整個端到端延遲的影響。每次測量的批量大小為 1(即單個請求)。所需能耗較少。

68501dc4-cb3e-11f0-8c8f-92fbcf53809c.png

圖 5:不同輸出和輸入序列長度對應(yīng)的每用戶端到端延遲(秒)

關(guān)鍵要點(diǎn)

測量延遲時的一個重要結(jié)論是,模型生成長響應(yīng)所需的時間,要遠(yuǎn)遠(yuǎn)超過處理長提示詞時所需的時間。該模型能夠一次性讀取和理解輸入,即使是特別長的提示詞,處理速度也相對較快。但是,在模型生成響應(yīng)時,是逐詞元依次生成的,每個新詞元的生成,都取決于之前已經(jīng)生成的所有內(nèi)容。這需要更多的時間,因?yàn)槟P蜁?zhí)行自動回歸流程,這意味著每個新詞元都建立在之前生成的所有詞元基礎(chǔ)上。例如,將輸入序列長度 (ISL) 從 2,000 個詞元增加到 125,000 個詞元,僅導(dǎo)致延遲增加大約兩倍。相比之下,在同樣范圍內(nèi)增加輸出序列長度 (OSL),延遲將增加大約 68 倍。d之所以產(chǎn)生這種差異,是因?yàn)檩^長的輸入序列引發(fā)了更多預(yù)填充計算,可并行處理多個詞元。與之相反,解碼在本質(zhì)上是一個串行過程,只能依次生成每一個詞元,這需要耗費(fèi)更多時間,以及更多的內(nèi)存帶寬。

這意味著更長的輸出序列會導(dǎo)致更長的解碼時間,同時 GPU 和內(nèi)存子系統(tǒng)保持活躍狀態(tài)的時間也會變長。這種情況下,硬件級別的功效將會變得特別重要。類似美光 HBM3Ee 這樣的內(nèi)存設(shè)備,其運(yùn)行功耗比同類高帶寬內(nèi)存設(shè)備低得多,能夠以較少的能量完成相同的推理任務(wù)。

d此處給出的估計值來自未優(yōu)化的分析模型,因此它們僅用于說明一般趨勢,而非峰值性能。

e美光 HBM3E 的功耗比市場上同類高帶寬內(nèi)存設(shè)備低 30%。

對用戶而言,上述結(jié)論彰顯出優(yōu)化提示詞以及管理輸入長度(例如,精簡任何不必要的內(nèi)容)的重要性。如果您正在構(gòu)建實(shí)時應(yīng)用程序,您通??梢苑判奶幚砀L的輸入,不會有太多問題。而保持簡潔的輸出,可能有助于您的系統(tǒng)運(yùn)行更快,響應(yīng)更迅速。

內(nèi)存在處理更長上下文時的重要作用

推理延遲不僅取決于序列長度,還取決于系統(tǒng)在處理輸入和生成輸出時如何管理模型對計算和內(nèi)存的需求。許多近期發(fā)布的語言模型正在宣傳其超過百萬詞元的上下文窗口。這些較大的上下文窗口(當(dāng)完全利用時)將對內(nèi)存子系統(tǒng)產(chǎn)生更大的壓力,其后果在用戶看來可能包括執(zhí)行速度較慢、運(yùn)行時間增加等。新一代內(nèi)存技術(shù)將提供更高的帶寬和更大的容量,可支持這些更大的上下文窗口,幫助縮短響應(yīng)時間,提高整體吞吐量(每秒生成的詞元數(shù))。但是,伴隨著這些性能提升,也出現(xiàn)了系統(tǒng)能耗過大的問題。隨著推理工作負(fù)載擴(kuò)大到支持?jǐn)?shù)百萬個詞元,設(shè)計出能夠高效使用能源的系統(tǒng),變得越來越重要。長時間保持活動狀態(tài)的系統(tǒng)需要消耗更多能源,為解決這一挑戰(zhàn),需要同時具備高帶寬和低功耗特性的內(nèi)存設(shè)備。例如,美光 HBM3E 的功耗遠(yuǎn)低于市場上的同類高帶寬內(nèi)存設(shè)備。此類低功耗產(chǎn)品有助于減少 AI 在運(yùn)行推理工作負(fù)載(涉及數(shù)百萬詞元上下文窗口)期間所消耗的能量。展望未來,HBM4 和 HBM4E 等下一代內(nèi)存技術(shù)旨在提供更高的內(nèi)存帶寬和容量,同時提高能效。這些改進(jìn)源于工藝技術(shù)的進(jìn)步(美光使用 1-gamma DRAM),預(yù)計將以更低的能源成本實(shí)現(xiàn)更快的數(shù)據(jù)移動。此外,隨著這些技術(shù)的成熟,可能會進(jìn)一步減少延遲,提高大規(guī)模 AI 部署的吞吐量并節(jié)約能源。

技術(shù)貢獻(xiàn)者

Felippe Vieira Zacarias

系統(tǒng)性能工程師

Shanya Chaubey

生態(tài)系統(tǒng)開發(fā)經(jīng)理

本文作者

Evelyn Grevelink

內(nèi)容戰(zhàn)略營銷負(fù)責(zé)人

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點(diǎn)僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 內(nèi)存
    +關(guān)注

    關(guān)注

    9

    文章

    3208

    瀏覽量

    76350
  • AI
    AI
    +關(guān)注

    關(guān)注

    91

    文章

    39697

    瀏覽量

    301297
  • 模型
    +關(guān)注

    關(guān)注

    1

    文章

    3749

    瀏覽量

    52091

原文標(biāo)題:大語言模型中與上下文窗口有關(guān)的五個基本概念

文章出處:【微信號:gh_195c6bf0b140,微信公眾號:Micron美光科技】歡迎添加關(guān)注!文章轉(zhuǎn)載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點(diǎn)推薦

    關(guān)于進(jìn)程上下文、中斷上下文及原子上下文的一些概念理解

    的地址空間。 其中處理器總處于以下狀態(tài)中的一種: 內(nèi)核態(tài),運(yùn)行于進(jìn)程上下文,內(nèi)核代表進(jìn)程運(yùn)行于內(nèi)核空間; 內(nèi)核態(tài),運(yùn)行于中斷上下文,內(nèi)核代表硬件運(yùn)行于內(nèi)核空間; 用戶態(tài),運(yùn)行于用戶空間。 系統(tǒng)的兩種
    發(fā)表于 09-06 09:58

    進(jìn)程上下文與中斷上下文的理解

    )進(jìn)程下文:其是指切換到內(nèi)核態(tài)后執(zhí)行的程序,即進(jìn)程運(yùn)行在內(nèi)核空間的部分。2.中斷上下文:(1)中斷上文:硬件通過中斷觸發(fā)信號,導(dǎo)致內(nèi)核調(diào)用中斷處理程序,進(jìn)入內(nèi)核空間。這個過程中,硬件的一些變量和參數(shù)也要
    發(fā)表于 12-11 19:45

    進(jìn)程上下文/中斷上下文及原子上下文的概念

    為什么會有上下文這種概念進(jìn)程上下文/中斷上下文及原子上下文的概念
    發(fā)表于 01-13 07:17

    中斷中的上下文切換詳解

    狀態(tài)(比如進(jìn)行信號量post),一定是走的SVC_Handler入口,RTX的任務(wù)上下文中的上下文切換,實(shí)際上是在SVC_Handler入口中統(tǒng)一實(shí)現(xiàn)的;而systick中斷的上下文
    發(fā)表于 03-23 17:18

    基于多Agent的用戶上下文自適應(yīng)站點(diǎn)構(gòu)架

    自適應(yīng)站點(diǎn)很少考慮對用戶環(huán)境的自適應(yīng)。為此,提出用戶上下文自適應(yīng)站點(diǎn)的概念,給出基于多Agent技術(shù)的用戶上下文自適應(yīng)站點(diǎn)構(gòu)架模型。闡述用戶上下文獲取、挖掘過程以及站
    發(fā)表于 04-11 08:49 ?13次下載

    基于交互上下文的預(yù)測方法

    傳統(tǒng)的上下文預(yù)測是在單用戶的上下文基礎(chǔ)上進(jìn)行的,忽視了實(shí)際普適計算環(huán)境中由于用戶交互活動導(dǎo)致的上下文變化因素。為了合理、有效地解決上述局限性問題,該文提出基
    發(fā)表于 10-04 14:08 ?7次下載

    終端業(yè)務(wù)上下文的定義方法及業(yè)務(wù)模型

    該文針對業(yè)務(wù)上下文僅關(guān)注業(yè)務(wù)質(zhì)量較少考慮用戶終端環(huán)境的現(xiàn)狀,提出終端業(yè)務(wù)上下文的概念,為普適業(yè)務(wù)的開展提供必要的信息支撐。給出一種終端業(yè)務(wù)上下文的通用定義方法
    發(fā)表于 03-06 11:06 ?11次下載

    基于Pocket PC的上下文菜單實(shí)現(xiàn)

    介紹了基于 Pocket PC 中的點(diǎn)按操作概念, 論述了在Pocket PC 中上下文菜單的實(shí)現(xiàn)原理及方法, 并給出了基于MFC 下的Windows CE 應(yīng)用程序?qū)崿F(xiàn)上下文菜單的步驟和代碼實(shí)例。
    發(fā)表于 07-25 18:26 ?17次下載

    基于Pocket PC的上下文菜單實(shí)現(xiàn)

    本文介紹了基于 Pocket PC 中的“點(diǎn)按”操作概念 論述了在 Pocket PC 中上下文菜單的實(shí)現(xiàn)原理及方法 并給出了基于 MFC 下的 Windows CE 應(yīng)用程序?qū)崿F(xiàn)上下文菜單的步驟和代碼實(shí)例 。
    發(fā)表于 04-18 10:46 ?0次下載

    基于上下文相似度的分解推薦算法

    模型,再對目標(biāo)用戶的K個鄰居用戶建立移動用戶一上下文一移動服務(wù)三維張量分解模型,獲得目標(biāo)用戶的移動服務(wù)預(yù)測值,生成移動推薦。實(shí)驗(yàn)結(jié)果顯示,與余弦相似性方法、Pearson相關(guān)系數(shù)方法和Cosinel改進(jìn)相似度
    發(fā)表于 11-27 17:42 ?0次下載

    Web服務(wù)的上下文的訪問控制策略模型

    的訪問控制策略模型模型的核心思想是將各種與訪問控制有關(guān)的信息統(tǒng)一抽象表示為一個上下文概念,以上下文為中心來制定和執(zhí)行訪問控制策略,上下文擔(dān)
    發(fā)表于 01-05 16:32 ?0次下載

    初學(xué)OpenGL:什么是繪制上下文

    ,每一個繪制上下文對應(yīng)于申請的一個客戶端,一個客戶端維護(hù)著一套狀態(tài)機(jī),如果兩個窗口分別對應(yīng)兩個不同的繪制上下文,則兩個窗口彼此狀態(tài)獨(dú)立。申請繪制上下
    發(fā)表于 04-28 11:47 ?2816次閱讀

    如何分析Linux CPU上下文切換問題

    在我的上一篇文章:《探討 Linux CPU 的上下文切換》中,我談到了 CPU 上下文切換的工作原理。快速回顧一下,CPU 上下文切換是保證 Linux 系統(tǒng)正常運(yùn)行的核心功能。可分為進(jìn)程
    的頭像 發(fā)表于 05-05 20:11 ?2787次閱讀

    我們能否擴(kuò)展現(xiàn)有的預(yù)訓(xùn)練 LLM 的上下文窗口

    50 頁的文字,意味著在對話或生成文本時,GPT-4 最多可以記住 50 頁左右內(nèi)容。? ? 一般來講,大語言模型處理上下文窗口大小的能力是預(yù)定好的。例
    的頭像 發(fā)表于 06-30 11:09 ?1402次閱讀
    我們能否擴(kuò)展現(xiàn)有的預(yù)訓(xùn)練 LLM 的<b class='flag-5'>上下文</b><b class='flag-5'>窗口</b>

    NVIDIA BlueField-4為推理上下文記憶存儲平臺提供強(qiáng)大支持

    隨著代理式 AI 工作流將上下文窗口擴(kuò)展到數(shù)百萬個 token,并將模型規(guī)模擴(kuò)展到數(shù)百萬億個參數(shù),AI 原生企業(yè)正面臨著越來越多的擴(kuò)展挑戰(zhàn)。這些系統(tǒng)目前依賴于智能體長期記憶來存儲跨多輪、工具和會話持續(xù)保存的
    的頭像 發(fā)表于 02-02 10:29 ?990次閱讀
    NVIDIA BlueField-4為推<b class='flag-5'>理上下文</b>記憶存儲平臺提供強(qiáng)大支持