iOS 27 中的 Foundation Models 图像输入

iOS 26 让 App 拥有了一个能读文字、写文字的设备端大型语言模型。iOS 27 则为同一个模型装上了一双眼睛。在 WWDC26 上，Apple 确认设备端系统语言模型「同时获得了 Vision 能力，这解锁了全新的应用类别」，¹而要使用这些能力的方式几乎平淡无奇：把图像和文字并排放进提示中，作为附件，然后提出问题。没有独立的 vision 流程、无需更换模型、也没有新的会话类型。过去只承载字符串的提示，如今也承载一张图片，而模型会针对两者一并作答。

为何这么小的接触面才是真正的重点：图像输入并不是硬塞进 Foundation Models 的附加 API。Apple 将它描述为「对现有 prompt builder 的自然延伸」，¹也就是说，您在 iOS 26 中已学会的每一个概念（会话、guided generation、Tool 协议）在提示转为多模态的那一刻都原封不动地继续运作。⁴若您还没接触过 LanguageModelSession，请先阅读 Foundation Models 框架说明再回来。

要点速览

• iOS 27 的设备端模型接受图像输入。您将图像附件连同文字一起插入提示，模型便会回答关于该图像的问题¹²。
• 图像附件可由多种类型创建：UIImage、NSImage、CGImage、Core Image 类型、CoreVideo 像素缓冲区，以及文件 URL¹。
• 模型支持任何尺寸与宽高比的图像，因此您无需为了某种形状而裁剪或填充；但较大的图像会消耗更多 token，并带来更高的延迟¹。
• Foundation Models 赋予 LLM 处理图像时的广泛通用性；Vision 框架则提供固定、快速、经过微调的分析。Apple 的建议是通过 tool calling 将两者结合，而非二选一²。
• Private Cloud Compute 上的服务器模型同样支持图像输入，且具备 32K 的上下文窗口（设备端则为 4K），因此承载文字加上数张图像的多模态提示有足够的喘息空间³。

变化所在：提示长出了一张图片

在 session 241 中，Apple 的说法相当精确。设备端模型「更聪明了；在逻辑与 tool calling 上更出色」，而在这份智能之上，它如今又获得了 Vision。¹演示中向模型询问一张折纸的照片：「只需将图像附件连同文字插入您的提示。现在，模型就能回答关于该图像的问题。」¹顺序很重要。文字与图像同处于一份提示中，模型读取整份提示，而答案会对两者一并推理。

来源类型的集合足够广，您很少需要自行转换什么。Apple 列出了六种：图像附件「可由多种类型创建，包括 UIImage、NSImage、CGImage、Core Image 类型、CoreVideo 像素缓冲区，以及文件 URL」。¹直接从 PhotosPicker 取得的 UIImage、您已渲染好的 CGImage、从相机抓取为 CVPixelBuffer 的帧，或以 URL 指向磁盘上的文件，全都能成为有效的输入。文字记录点名了输入类型，却未说明附件初始化器的确切签名，因此请把这份类型清单当作契约，待您切到 iOS 27 SDK 后，让 Xcode 自动补全填妥调用处。

有一项约束您无需对抗：形状。「模型支持任何尺寸与宽高比的图像，因此您无需为了某种特定形状而裁剪或填充。」¹一张长型收据、一张宽幅全景，以及一张方形缩略图，全都能照原样接受。代价正是您对任何受 token 预算约束的模型所预期的：「允许任意图像尺寸，但请记住，较大的图像会消耗更多 token，并带来更高的延迟。」¹图像并非免费的上下文。它和您的文字耗用同一份预算，这是多模态强加给您的第一个设计决定，也是上下文大小（详见下文）变得至关重要的原因。

由于图像输入搭乘的是既有的 prompt builder，iOS 26 的整套机制得以完好无损。Guided generation 仍会把输出塑造成 @Generable 类型。Tool 协议仍让模型调用您的代码。流式传输仍会流式传输。模型多了一种感官，而非一套全新的编程模型。

与图像理解的衔接：Foundation Models 与 Vision 并非对手

Session 237「图像理解的新功能」正是 Apple 为分析图像的两条路径划清界线之处，而这项区分是两场演讲中最有助于决定要构建什么的内容。开场便是一个提示：演讲者的议程不见了，于是她拍下自己的便利贴，请「一个大型语言模型来生成议程。用 Foundation Models 框架做这件事相当容易。庆幸的是，今年 Foundation Models 开始支持图像输入。」²这正是多模态描述性那一面的完整卖点：为图像加上说明文字、从房间照片给出室内装修的调整建议、从冰箱照片生成食谱。演讲者对 LLM 何处出色的评判：「模型在描述性任务上通常表现良好。」²

接着是坦诚的比较。「Foundation Models 框架借助大型语言模型，几乎能做到您要求的任何事。相比之下，传统的图像处理框架，例如 Vision，使用的是一组固定的计算机视觉 API。Vision API 针对特定任务微调，并把那些任务做得非常好。而且 Vision 很快。往往快到足以实时分析视频帧。」²请把它读成一条路由规则。针对一张静态图像的开放式提问，而您想得到语言回复？Foundation Models。在视频帧速率下进行明确界定的特定任务（人脸检测、姿态、saliency、分割）？Vision。LLM 是会思考的通才；Vision API 是会运作的专才。

Apple 的妙语是您无需二选一：「分析图像时，您不必总是在 Vision 和 Foundation Models 之间做抉择。有一种方式可以通过 tool calling，借助 Vision 的专长搭配 Foundation Models 的通用性。」²iOS 27 的 tool calling 如今支持图像参数。当模型自己无法识别某物时（演讲以植物识别为例），它会调用一个工具，而「模型不会把整张图像作为参数传递，而是改传一个对图像的引用」。²这个引用，也就是 ImageReference，「必须是对当前聊天会话中已有图像的引用」，²工具会通过会话的历史记录把它解析回一个附件，以备分析。控制循环，以及内置的 OCRTool 与 BarcodeReaderTool，是姊妹篇 iOS 27 的 tool calling 控制的主题；此处的重点更为聚焦：图像输入与图像参数工具是同一个多模态堆栈的两层，且两者能彼此组合。

Private Cloud Compute 上的多模态：相同的提示，更大的空间

Session 319 一开场便同时确认了多模态故事的两个面向。设备端模型「现在已支持图像输入，它更擅长遵循指令并调用您的自定义工具」，³而对于较吃重的情况，Private Cloud Compute 上有一个新的服务器模型。多模态与 PCC 之所以该放在同一段对话里，原因在于上下文大小。Apple 把数字讲得明白：「设备端模型提供 4k，而通过 PCC 您能获得 32K。」³图像会耗用这份预算¹，因此承载文字加上数张图像的提示，正是那种会把 4K 撑到极限、却能舒适地装进 32K 的负载。

摘要器演示让这份契合变得具体。「这里我有一个用 PCC 模型为文章做摘要的 App。我可以选取一份 markdown 文件，我们取出其中的文字与图像，喂入 LanguageModelSession，并生成一份摘要。凭借 PCC 提供的庞大上下文，这运作得非常顺畅。」³文字与图像、一个会话、一份提示。从设备端迁移到服务器的成本只有一行：Apple 演示「只需改动 1 行代码，您就能切换到 PCC 上的全新服务器模型」，³因为「无论您对话的是哪个模型，Foundation Models 框架都提供统一的 Swift API」。³搭配 Generable 的 guided generation 以及 tool calling，「在 PCC 模型上的运作方式，和在设备端模型上完全相同」。³

PCC 增添了 reasoning，这是设备端所没有的，而 reasoning 带有一项与多模态相关的代价：「reasoning 是模型额外生成的文字。所以它会用掉 token。这会计入您的上下文大小上限。」³在同一份提示中，把深度 reasoning 与数张全分辨率图像配在一起，您就是从两端同时花掉这份 32K 预算。更深入的细节（三个 reasoning 级别、quotaUsage 与 isLimitReached 的每日上限处理、您要在开发者网站申请的授权）属于 Private Cloud Compute 深入解析；而多模态的心得是：同一份承载图像的提示能在两个模型上运作，而当提示成长到超出设备所能负荷时，服务器模型便有了存在的理由。

采用图像输入

从上述契约推导出的一份简短检查清单。

从设备端起步、测量，再做决定。 Apple 自己的建议是「依据数据来选择模型，而非仅凭感觉」，³并提醒「您可能会惊讶于设备端模型在某些任务上的表现有多好，尤其是今年更新后的模型」。³一段说明文字或一个「这是什么物体」的查询，或许永远用不上 PCC。当提示承载多张图像，或长文超出设备端 4K 窗口时，再去动用服务器模型³。

为您的流程挑选成本最低的来源类型。 您可以把 UIImage、NSImage、CGImage、Core Image 类型、CVPixelBuffer 或文件 URL 交给模型¹。如果某个帧已经以像素缓冲区形式来自相机，或已是磁盘上的文件，请直接传递它，不要绕道经过 UIImage。

把图像分辨率当作预算旋钮，而非质量刻度盘。 任何尺寸与宽高比都合法¹，所以别为了形状而过度裁剪。但因为较大的图像会花掉更多 token 与更多延迟¹，当任务（读这个标志、这是哪个房间）并不需要每一个像素时，就在图像进入提示前先把一张 4800 万像素的照片缩小。

依任务路由，而非凭反射动作。 描述性、开放式、输出语言的工作交给 Foundation Models；固定、快速、实时的计算机视觉工作交给 Vision；当您两者都需要时，从 Foundation Models 工具内部调用 Vision²。这两个框架是互补的层次，而图像参数工具正是接合它们的接缝。

保留可用性检查。 图像输入搭乘的是同一个模型，而该模型「仅在支持 Apple Intelligence 的设备上可用」。³请检查可用性 API，并在缺少 Apple Intelligence 之处优雅地降级³。

常见问题

在 iOS 27 中，我该如何把图像发给 Foundation Models 模型？

您使用既有的 prompt builder，把图像附件连同文字一起插入提示，然后请模型作答。Apple 将这个 API 描述为「对现有 prompt builder 的自然延伸」：创建一个会话，「只需将图像附件连同文字插入您的提示」，接着「模型就能回答关于该图像的问题」。¹其中不涉及独立的 vision 流程，也没有新的会话类型。

我能传给 Foundation Models 哪些图像类型？

图像附件可由 UIImage、NSImage、CGImage、Core Image 类型、CoreVideo 像素缓冲区，以及文件 URL 创建¹。文字记录列举了这些来源类型，却未详述每一个初始化器的签名，因此就让 iOS 27 SDK 来提供确切的调用处。

发送图像前，我需要调整大小或裁剪吗？

不需要。「模型支持任何尺寸与宽高比的图像，因此您无需为了某种特定形状而裁剪或填充。」¹取舍在于成本，而非合法性：「较大的图像会消耗更多 token，并带来更高的延迟」，¹因此当任务并不需要完整分辨率时，把一张非常大的照片缩小是一项预算决定。

对于图像，我何时该用 Vision 而非 Foundation Models？

固定、界定明确、对速度要求严苛的任务请用 Vision。Apple 指出 Vision「使用一组固定的计算机视觉 API」，「针对特定任务微调」，且「往往快到足以实时分析视频帧」，而 Foundation Models「几乎能做到您要求的任何事」，并在描述性任务上表现出色²。当您两者都想要时，通过 tool calling 从 Foundation Models 会话调用一个以 Vision 为后盾的工具²。

图像输入能搭配 Private Cloud Compute 服务器模型运作吗？

可以。Apple 确认设备端模型「现在已支持图像输入」，³而 PCC 演示会把一份文档的「文字与图像」喂入 LanguageModelSession 进行摘要³。同一套统一的 Swift API 在两个模型上都能运作，因此同一份承载图像的提示，只需一行改动，便能在设备端或服务器上运作。PCC 的 32K 上下文（相对于设备端的 4K）为多图像提示提供了更多空间³。

完整的 Apple Ecosystem 系列：Foundation Models 框架说明；设备端 LLM；iOS 27 的 tool calling 控制；以及 Private Cloud Compute 深入解析。中枢是 Apple Ecosystem 系列。如需更广泛的「iOS 搭配 AI agent」上下文，请参阅 iOS Agent 开发指南。