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)，因此可在所有支持该框架的旧系统版本上使用。
【声明：本文由 InfoQ 翻译，未经许可禁止转载。】
查看英文原文：https://www.infoq.com/news/2026/03/apple-foundation-models-context/
