蘋果優化其基礎模型的上下文窗口管理能力

作者 | Sergio De Simone

譯者 | 明知山

iOS 26.4 已推出候選版本，針對 Apple 基礎模型優化了上下文窗口管理能力，幫助開發者應對 4096 Token 的上下文限制。這要求開發者將上下文窗口視作一種受限資源，像在低資源環境中管理內存一樣進行主動管理，從而提升使用效率。

與大多數大語言模型一致，上下文窗口是承載系統指令、用戶提示詞與模型回復的核心資源。由于 Apple 基礎模型采用端側運行，其可用上下文窗口相對有限，極易被占滿；尤其在對話類會話場景中，用戶提問與模型回復會持續累積，進一步加劇資源占用。

在這種情況下，框架會拋出.exceededContextWindowSize錯誤，模型將無法在當前會話中繼續做出響應。若要恢復正常交互，開發者需要新建會話并重新初始化狀態，從而在不影響用戶體驗的前提下順暢延續原有工作流程。

在此前的 技術說明 中，Apple 梳理了開發者主動應對上下文窗口限制的實用策略，例如：將復雜任務拆分為多輪模型會話、引導模型生成更精簡的回復、通過摘要壓縮或保留核心對話輪次來精簡提示詞，以及高效合理地調用工具。

為便于開發者監控上下文窗口占用情況，iOS 26.4 在SystemLanguageModel中新增了 contextSize 屬性，用于返回可用上下文容量；同時提供了 tokenCount(for:)) 方法，可計算指定輸入所消耗的 Token 數量。盡管當前上限為 4096 Token，但contextSize可避免開發者硬編碼該上限，而tokenCount(for:)則提供了基礎的 Token 統計能力，讓應用能夠實現動態調整。

即便能夠獲知上下文窗口大小并統計 Token 消耗，仍無法完全解決開發中的痛點，因為精細化管理 Token 開銷并非易事。在一篇實操文章中，Artem Novichkov 提出了一套行之有效的解決方案。

Artem 指出，開發者需要考量構成上下文的所有組件，包括系統提示詞與用戶指令，同時還需要留意工具調用對上下文窗口占用帶來的影響——這一點往往容易被忽視：

調用工具時，工具定義（名稱、描述及參數結構）會被序列化，并隨指令一同傳入上下文，這會顯著增加 Token 消耗。

請注意，Artem 在文中提及的tokenUsage(for:)方法在最新候選版中已更名為tokenCount(for:)。他同時指出，基礎模型框架中的這些新增接口均標注了 @backDeployed(before: iOS 26.4, macOS 26.4, visionOS 26.4)，因此可在所有支持該框架的舊系統版本上使用。

查看英文原文：

https://www.infoq.com/news/2026/03/apple-foundation-models-context/

聲明：本文為 InfoQ 翻譯，未經許可禁止轉載。