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 開發指南。