Foundation Models LLM na urządzeniu: Tool Protocol

Gatunek: frontier-essay. Wpis nazywa kontrakt LLM na urządzeniu, który Apple udostępniło na WWDC 2025, i przeprowadza przez kwestię routingu: kiedy odpowiedzią jest LanguageModelSession, kiedy AppIntent, kiedy MCP, a kiedy żadne z powyższych.

iOS 26 udostępnia model językowy o 3 miliardach parametrów na każdym urządzeniu obsługującym Apple Intelligence.¹ Apple nazywa ten framework Foundation Models. Framework działa lokalnie. Inferencja jest zoptymalizowana pod Apple silicon i odbywa się na urządzeniu; sieć nie znajduje się na ścieżce wywołania. Model znajduje się pod SystemLanguageModel.default, aplikacja otrzymuje LanguageModelSession, a typowaną powierzchnią pozwalającą tej sesji wykonywać użyteczną pracę jest protokół Tool.

Protokół Tool jest częścią, która ma znaczenie dla deweloperów aplikacji. Bez niego LLM na urządzeniu jest punktem końcowym uzupełniania czatu bez połączenia z danymi aplikacji, danymi użytkownika ani resztą systemu. Z nim model może wywoływać typowane funkcje Swift, otrzymywać typowane wyniki z powrotem i rozumować na temat odpowiedzi w kolejnej turze. Generowanie na urządzeniu wzbogacone o narzędzia to faktyczna możliwość frameworka. Powierzchnia czatu to demonstracja.

TL;DR

• Foundation Models daje każdemu urządzeniu kwalifikującemu się do Apple Intelligence LLM o 3 miliardach parametrów pod SystemLanguageModel.default. Model jest lokalny; inferencja jest zoptymalizowana pod Apple silicon i odbywa się na urządzeniu; sieć znajduje się poza ścieżką wywołania.
• Protokół Tool to kontrakt między modelem a aplikacją. Narzędzie deklaruje typowane Arguments, zwraca typowane Output i zostaje powiązane z LanguageModelSession w momencie konstrukcji.
• Adnotacje Generable i Guide pozwalają modelowi produkować typowane wartości Swift bezpośrednio, a nie jedynie ciągi znaków. Dekoder jest częścią frameworka, a nie kodu aplikacji.
• Reguła routingu między Foundation Models, App Intents i MCP to kto uruchamia model i gdzie. Foundation Models = aplikacja uruchamia model na urządzeniu. App Intents = Apple Intelligence uruchamia model na urządzeniu i kieruje go do aplikacji. MCP = zewnętrzny host uruchamia model gdziekolwiek mu pasuje i sięga do aplikacji poprzez serwer narzędzi.

Co właściwie zapewnia framework

Framework opiera się na trzech prymitywach: modelu, sesji i narzędziu.²

SystemLanguageModel. Referencja do modelu fundamentu na urządzeniu. Domyślna instancja jest powiązana z urządzeniem użytkownika, dostępna na sprzęcie kwalifikującym się do Apple Intelligence i udostępnia kontrole możliwości, które aplikacja odczytuje w czasie wykonywania, aby zdecydować, czy model jest dostępny. Framework obsługuje konfigurację poprzez SystemLanguageModel(useCase:guardrails:), niestandardowe adaptery oraz GenerationOptions, ale nie wybiera się arbitralnych identyfikatorów modeli chmurowych w sposób, w jaki robi się to z OpenAI lub Anthropic; Apple dostarcza i aktualizuje model na urządzeniu wraz z każdym wydaniem OS i framework przekazuje aplikacji tę wersję, która jest aktualnie zainstalowana.

LanguageModelSession. Obiekt z zachowaniem stanu, który utrzymuje stan rozmowy między wywołaniami. Sesja przyjmuje prompt systemowy w momencie konstrukcji, akumuluje tury użytkownika/asystenta w czasie i udostępnia metody asynchroniczne do generowania odpowiedzi. Sesje są lekkie do utworzenia i jednorazowe; tworzy się jedną na zadanie, a nie jedną na aplikację. Aplikacja do medytacji tworzy sesję dla „podsumuj moje ostatnie 7 dni praktyki”; aplikacja kulinarna tworzy inną sesję dla „przelicz to na dwie osoby zamiast czterech”.

Tool (protokół). Protokół Swift, który deklaruje typ Arguments, typ Output i asynchroniczną funkcję call(arguments:). Narzędzia są wiązane z sesją w momencie konstrukcji (LanguageModelSession(tools: [...], instructions: ...)). Gdy model zdecyduje, że potrzebuje narzędzia, emituje wywołanie strukturalne; framework dekoduje argumenty, wykonuje narzędzie, koduje wynik i podaje go z powrotem do sesji na kolejną turę. Model nie widzi Swifta; framework wykonuje marszalizację.

Kształt protokołu Tool, w skondensowanej formie:

import FoundationModels

struct WaterEntryLookup: Tool {
    let name = "lookup_water_entries"
    let description = "Look up water intake entries for a given date range."

    @Generable
    struct Arguments {
        @Guide(description: "Start date in ISO-8601 format")
        let startDate: String

        @Guide(description: "End date in ISO-8601 format")
        let endDate: String
    }

    func call(arguments: Arguments) async throws -> ToolOutput {
        let entries = try store.entries(
            from: ISO8601DateFormatter().date(from: arguments.startDate) ?? .now,
            to: ISO8601DateFormatter().date(from: arguments.endDate) ?? .now
        )
        return ToolOutput(GeneratedContent(properties: [
            "count": entries.count,
            "total_ml": entries.reduce(0) { $0 + $1.amountMl }
        ]))
    }
}

Model widzi opis narzędzia i schemat argumentów w kształcie JSON. Kod Swift widzi typowane wejście i typowane wyjście. Granica dekodowania/kodowania to ta część, którą zarządza Apple.

Generable i Guide: typowane wyjście bez parsera

Ten sam system adnotacji, który sprawia, że argumenty narzędzia są typowane, pozwala również modelowi produkować typowane wartości Swift bezpośrednio.³ Struktura @Generable deklaruje swój kształt; framework ogranicza wyjście modelu, by do niego pasowało.

@Generable
struct PracticeSummary {
    @Guide(description: "Single-sentence headline summarizing the user's week")
    let headline: String

    @Guide(description: "Total practice duration this week in minutes")
    let totalMinutes: Int

    @Guide(description: "Three short observations as bullet points")
    let observations: [String]
}

let session = LanguageModelSession(instructions: "You are a meditation coach.")
let summary = try await session.respond(
    to: "Summarize this week of practice given the entries.",
    generating: PracticeSummary.self
)

Model zwraca wartość PracticeSummary. Żadnego parsowania JSON w kodzie, żadnego dopasowywania ciągów dla „headline:”, żadnego fallbacku, gdy model zwrócił niepoprawnie sformatowany obiekt. Framework używa dekodowania z ograniczeniami, aby utrzymać wyjście modelu token po tokenie strukturalnie zgodne ze schematem, więc strukturalnie nieprawidłowe wyjście nie przemyka się przez granicę.

Powierzchnia typowana w Swift jest tym, co odróżnia ten framework od chmurowych SDK dla LLM. Chmurowe SDK (OpenAI Structured Outputs, użycie narzędzi Anthropic i inne) również obsługują dekodowanie z ograniczeniami, ale typowana wartość, którą otrzymuje deweloper, to obiekt JSON zwalidowany względem schematu, a następnie zdekodowany do typu Swift Codable jako oddzielny krok. Foundation Models łączy te kroki: makro @Generable i dekoder frameworka produkują typowaną wartość Swift jako bezpośrednie zwrócenie, a adnotacje @Guide na poziomie pól przenoszą intencję do ograniczenia generowania. Wyjście jest typowane, ponieważ generowanie zostało typowane względem schematu Swift, a nie względem specyfikacji JSON, którą deweloper zrekonstruował w Swift.

Adnotacje @Guide to sposób, w jaki komunikuje się modelowi intencję na poziomie pola bez wpisywania jej w prompt. Wygenerowany opis staje się częścią ograniczenia generowania. Przewodniki na poziomie pola utrzymują prompt w czystości, a schemat blisko danych.

Kwestia routingu na trzy sposoby

Apple oferuje teraz trzy powierzchnie protokołów, z których aplikacja może korzystać, aby udostępnić swoją domenę modelowi językowemu. Kierują one do różnych runnerów.

Foundation Models (LanguageModelSession). Aplikacja ładuje model na urządzeniu i wykonuje inferencję. Narzędzia, które sesja może wywoływać, to narzędzia zdefiniowane przez kod aplikacji. Model nigdy nie opuszcza urządzenia. Użytkownik nie wywołuje tego przez Siri; robi to kod aplikacji. Przypadek użycia jest wewnątrz aplikacji: aplikacja medytacyjna używająca LLM do podsumowania tygodnia, aplikacja kulinarna dostosowująca przepis do mniejszej liczby porcji, tracker wody, który zamienia „wypiłem szklankę przy obiedzie” w strukturalny wpis.

App Intents. Apple Intelligence uruchamia LLM w imieniu użytkownika (agent pierwszej strony Apple) i kieruje wywołania możliwości do typów AppIntent aplikacji. Aplikacja nie uruchamia modelu. Deklaruje się typowane akcje poprzez framework App Intents, a stos systemowy Apple decyduje, kiedy je wywołać na podstawie żądania użytkownika, zapytania Spotlight, wejścia z Siri lub orkiestracji Skrótów. Omówione szczegółowo w App Intents to nowe API Apple do Twojej aplikacji.⁴

MCP. Zewnętrzny host (Claude Desktop, Claude Code, Cursor, ChatGPT) uruchamia model wybrany przez dewelopera. Aplikacja udostępnia serwer, który model hosta może wywoływać. Model uruchamia się tam, gdzie host go uruchamia; wywołania narzędzi przekraczają transport JSON-RPC. Omówione w Dwa ekosystemy agentów, jedna lista zakupów oraz w syntezie kwestii routingu w App Intents vs MCP.⁵

Decyzja routingu sprowadza się do kto jest agentem.

                  ┌──────────────────────────────────┐
                  │  Who is the language model?       │
                  └────┬─────────────┬─────────────┬──┘
                       │             │             │
              ┌────────┴────┐ ┌──────┴──────┐ ┌────┴──────┐
              │ Your app's  │ │   Apple     │ │  External │
              │ own use of  │ │ Intelligence│ │   host's  │
              │   LLM       │ │   agent     │ │   agent   │
              └──────┬──────┘ └──────┬──────┘ └────┬──────┘
                     │               │             │
                     ▼               ▼             ▼
              Foundation Models  App Intents     MCP
              + Tool protocol   + AppEntity    + tools/list
              (on-device, your  (system runs   (host runs
               app runs model)   the model)     the model)

Aplikacja medytacyjna podsumowująca tydzień użytkownika korzysta z Foundation Models, ponieważ sama aplikacja chce wywołać model i zaprezentować wynik wewnątrz aplikacji. Możliwość „zaloguj 5-minutową sesję” tej samej aplikacji korzysta z App Intents, aby Siri mogła ją wywołać. Możliwość „pokaż mi moje ostatnie wpisy z dziennika medytacji” tej samej aplikacji używana przez sesję Claude Code korzysta z MCP. Trzy różne runnery, trzy różne zobowiązania, jedna współdzielona warstwa domenowa pod spodem.

Budżety inferencji: o co prosi framework

Uruchamianie LLM na urządzeniu nie jest darmowe. Apple silicon obsługuje inferencję, ale model wciąż ma okno kontekstowe, budżet tokenów i opóźnienie zegara ściennego, które zależy od urządzenia. Trzy ograniczenia kształtują projektowanie z tym frameworkiem:⁶

Dostępność jest specyficzna dla urządzenia. Nie każde urządzenie z iOS 26 ma Apple Intelligence. Starsze iPhone’y, urządzenia z ograniczeniami i urządzenia, na których użytkownik wyłączył Apple Intelligence, zwracają stan niedostępności z SystemLanguageModel.default.availability. Kod, który wywołuje LanguageModelSession bez sprawdzenia dostępności, ujawnia błąd generowania w czasie wykonywania; właściwym wzorcem jest rozgałęzienie UI w oparciu o stan dostępności z wyprzedzeniem i zaprezentowanie ścieżki bez LLM, gdy stan jest niedostępny. Należy traktować model jako flagę funkcji, a nie gwarancję.

Opóźnienie nie jest trywialne. Opóźnienie pierwszego tokenu na iPhone 16 Pro jest użyteczne dla interakcji wewnątrz aplikacji; dłuższe generowanie i łańcuchy wywołań narzędzi nie są natychmiastowe. Wzorce UI, które działają dla strumieniowania chmurowego LLM, działają również tutaj; nie wolno blokować głównego wątku, należy pokazywać progresywne wyjście i projektować z myślą o przypadku, gdy użytkownik opuszcza ekran w trakcie generowania.

Okna kontekstowe są mniejsze niż w chmurze. Model na urządzeniu ma mniejsze okno kontekstowe niż chmurowe modele klasy GPT-4. Długie dokumenty wymagają podsumowania lub fragmentacji. Długa historia rozmowy wymaga przycinania. Wyjścia narzędzi zwracające duże strukturalne ładunki powinny zwracać referencję (identyfikator, klucz), którą kolejna tura może ponownie pobrać na żądanie, a nie cały ładunek inline.

Zestaw ograniczeń jest podobny do projektowania dla niskiej klasy środowiska wykonawczego edge, a nie dla frontowego modelu chmurowego. Udogodnienia frameworka czynią to przyjemniejszym; podstawowe ograniczenia fizyczne się nie zmieniają.

Kiedy sięgnąć po Foundation Models

Najmocniejsze dopasowania frameworka to sytuacje, w których generowanie na urządzeniu z niskim tarciem stanowi produkt:

Reformatowanie i przepisywanie. Zamień swobodną notatkę użytkownika w strukturalny wpis, dopracuj wersję roboczą wiadomości, podsumuj przechwycony transkrypt. Tolerancja opóźnień jest umiarkowana; wrażliwość danych jest wysoka; inferencja w chmurze stanowi przesadę.

Lokalna synteza nad prywatnymi danymi. Aplikacja treningowa zamieniająca historię treningów użytkownika w podsumowanie „w tym tygodniu”. Aplikacja finansowa wyjaśniająca wzorzec wydatków użytkownika. Aplikacja dziennika ujawniająca tematy w wpisach z całego kwartału. Dane nie powinny opuszczać urządzenia; odpowiedź powinna pojawić się w aplikacji; prompt jest ograniczony.

Lekkie wywoływanie narzędzi do wewnętrznej automatyzacji aplikacji. Aplikacja, która pozwala użytkownikowi powiedzieć „pokaż mi dziennik medytacji ze wtorku” i używa narzędzia do pobrania bazowych rekordów, a następnie formatuje odpowiedź. Agentem jest aplikacja, narzędziem jest własna warstwa danych aplikacji, model jest lokalny.

Generowanie zgodne z typami. Wszędzie tam, gdzie aplikacja w przeciwnym razie ręcznie pisałaby parser JSON lub szablon ciągu znaków, @Generable plus @Guide to bardziej trwała powierzchnia.

Kiedy nie sięgać po Foundation Models

Framework jest niewłaściwą odpowiedzią w kilku typowych przypadkach:

Wszystko, o co użytkownik mógłby zapytać Siri. „Zaloguj 250 ml wody”, „Rozpocznij 5-minutową medytację”, „Dodaj banany do mojej listy” to App Intents. Apple Intelligence jest runnerem; aplikacja jest miejscem docelowym. Foundation Models służy do generowania wewnątrz aplikacji, a nie do akcji kierowanych przez Siri. Jeśli zbuduje się tę samą funkcjonalność dwukrotnie (App Intent + LanguageModelSession z narzędziem), App Intent wygrywa, ponieważ użytkownik wywołuje Siri, a nie ekran wewnątrz aplikacji.

Wszystko, czym powinien sterować zewnętrzny agent LLM. Sesja Claude Code sięgająca do domeny aplikacji należy do MCP. Aplikacja nie uruchamia LLM; robi to host; model żyje tam, gdzie umieścił go host. Foundation Models nie może obsługiwać zewnętrznych agentów.

Ciężkie rozumowanie nad dużymi dokumentami. Model na urządzeniu jest mały. Kontrakt na 200 stron, długi kontekst bazy kodu lub rozumowanie wieloobrazowe nad wieloma zdjęciami należą do inferencji w chmurze (własnej lub dostawcy), gdzie okno kontekstowe i liczba parametrów odpowiadają obciążeniu. Zadania przekraczające zakres frameworka produkują konkretne błędy: przekroczone okno kontekstowe, naruszenia barier ochronnych, nieobsługiwane lokalizacje. Należy ujawniać te błędy świadomie, zamiast projektować przepływy, które zależą od tego, że model obsłuży pracę poza zakresem.

Przepływy międzyurządzeniowe i międzyużytkownikowe. Model na urządzeniu ma dostęp tylko do tego, co aplikacja przekaże do sesji. Synchronizacja międzyurządzeniowa (stan timera z Watch do iPhone’a), współpraca międzyużytkownikowa (współdzielone listy, współdzielone dokumenty) i każdy przepływ, który korzysta z koordynacji po stronie serwera, wymaga serwera. Model nie jest prymitywem sieciowym.

Co zbudowałbym inaczej w moim stosie

Framework nagradza konkretny wybór architektoniczny, który łatwo pomylić przy pierwszym podejściu. Możliwości, które użytkownik wywołuje przez UI aplikacji i które LLM powinien konsumować jako narzędzia, a nie jako zduplikowane ścieżki prozaiczne.

Aplikacja medytacyjna może dodać panel „cotygodniowy przegląd” podsumowywany przez LLM. Naiwna implementacja to jeden prompt: „Oto wpisy użytkownika z tego tygodnia, napisz akapit”. Lepsza implementacja definiuje narzędzie WeeklyEntries, które model może wywołać, gdy potrzebuje wiedzieć, co było w danym tygodniu, oraz strukturalne wyjście WeeklySummary przez @Generable. Pierwsza implementacja jest krucha (model musi pochłaniać długą listę wpisów przy każdym wywołaniu), kosztowna w tokenach i produkuje niestrukturalną prozę. Druga jest trwała (wywołanie narzędzia oddziela „co się wydarzyło” od „jak o tym mówić”), tania (model pobiera tylko to, czego potrzebuje) i strukturalna (wynikiem jest typowana wartość Swift).

Wzorzec składa się z App Intents i MCP w czysty sposób. To samo zapytanie WeeklyEntries jest również ciałem resolwera parametrów AppIntent i obsługi narzędzia MCP. Jedna funkcja Swift; trzy powierzchnie. Model wywołuje tę samą funkcję, którą wywołuje użytkownik.

Inna decyzja architektoniczna: opisy narzędzi są częścią promptu. Model czyta Tool.description, aby zdecydować, czy i kiedy wywołać. Należy traktować opis jak docstring, którego rzeczywiście oczekuje się, że przyszły kontrybutor przeczyta; model jest tym przyszłym kontrybutorem.

Co ten wzorzec oznacza dla stosu Apple na iOS 26+

Trzy wnioski.

1. LLM na urządzeniu to funkcja czasu wykonywania, a nie backend. Należy traktować go jak framework systemowy z oknem kontekstowym i budżetem inferencji na urządzeniu, a nie jak usługę zdalną. Decyzje architektoniczne to dostępność, opóźnienie, dyscyplina okna kontekstowego i strukturalne wyjście.

2. Protokół Tool to powierzchnia. Bez narzędzi model jest punktem końcowym uzupełniania czatu bez połączenia z domeną. Z narzędziami model staje się strukturalną warstwą zapytań nad danymi aplikacji.

3. Reguła routingu między Foundation Models, App Intents i MCP to „kto uruchamia model”. Generowanie wewnątrz aplikacji idzie do Foundation Models. Możliwości kierowane przez Apple Intelligence idą do App Intents. Możliwości zewnętrznych agentów idą do MCP. Ta sama funkcja domenowa Swift może być wywoływana przez wszystkie trzy powierzchnie.

Pełny klaster ekosystemu Apple: typowane App Intents dla Apple Intelligence; serwery MCP dla agentów między LLM; kwestia routingu między tymi dwoma; Live Activities dla maszyny stanów ekranu blokady; wzorce Liquid Glass dla warstwy wizualnej; wieloplatformowa dystrybucja dla zasięgu między urządzeniami. Hub znajduje się pod Apple Ecosystem Series. Szerszy kontekst iOS z agentami AI znaleźć można w przewodniku iOS Agent Development.

FAQ

Czym jest framework Foundation Models w iOS 26?

Foundation Models to framework Apple do dostępu do modelu językowego na urządzeniu, który dostarczany jest z urządzeniami kwalifikującymi się do Apple Intelligence w iOS 26 (oraz iPadOS 26, macOS 26, visionOS 26). Framework udostępnia SystemLanguageModel, LanguageModelSession oraz protokół Tool, dzięki czemu aplikacje mogą wykonywać typowane wywołania LLM na urządzeniu bez dostępu do sieci.

Jak działa protokół Tool?

Tool to typ Swift, który deklaruje strukturę Arguments (z adnotacjami @Generable i @Guide), asynchroniczną metodę call(arguments:) oraz nazwę i opis, których model używa, aby zdecydować, kiedy wywołać. Narzędzia są wiązane z LanguageModelSession w momencie konstrukcji. Gdy model zdecyduje, że potrzebuje narzędzia, framework dekoduje argumenty, wykonuje wywołanie i podaje typowane wyjście z powrotem do sesji.

Jaka jest różnica między Foundation Models, App Intents a MCP?

Foundation Models służy aplikacji do uruchamiania LLM na urządzeniu w celu generowania wewnątrz aplikacji. App Intents służy Apple Intelligence (agentowi systemowemu) do wywoływania typowanych możliwości aplikacji. MCP służy zewnętrznym hostom LLM (Claude, ChatGPT itd.) do wywoływania typowanych narzędzi aplikacji przez transport JSON-RPC. Te trzy protokoły różnią się tym, kto uruchamia model. Ta sama funkcja domenowa Swift może obsługiwać wszystkie trzy.

Czy Foundation Models może wywoływać narzędzia MCP?

Nie. LanguageModelSession.tools przyjmuje typy zgodne z protokołem Tool Apple, a nie serwery narzędzi MCP. Aby je połączyć, należałoby napisać Tool Foundation Models, którego metoda call wywołuje klienta MCP. Apple nie dostarczyło wbudowanego adaptera; mostek byłby kodem po stronie aplikacji.

Czy model na urządzeniu jest wystarczająco dobry do produkcji?

Dla przypadków użycia, do których framework jest przeznaczony (reformatowanie, podsumowywanie, generowanie strukturalne nad lokalnymi danymi, lekkie wywoływanie narzędzi), tak. Dla rozumowania frontowego nad dużymi kontekstami, rozumienia multimodalnego na dużą skalę lub rozumowania międzydokumentowego, nie. Model na urządzeniu to model o 3 miliardach parametrów z mniejszym oknem kontekstowym niż chmurowe LLM; należy wybierać obciążenia, które mieszczą się w tym zakresie.

Bibliografia