Foundation Models On-Device LLM: Protokół Tool

Kontrakt LLM działającego on-device, który Apple wprowadziło na WWDC 2025, rodzi natychmiastowe pytanie o routing: kiedy właściwym wyborem jest LanguageModelSession, kiedy AppIntent, kiedy MCP, a kiedy żadne z powyższych.

iOS 26 dostarcza model językowy z 3 miliardami 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 kątem Apple silicon i wykonywana on-device; sieć nie znajduje się w ścieżce wywołania. Model rezyduje w SystemLanguageModel.default, aplikacja otrzymuje LanguageModelSession, a typowaną powierzchnią pozwalającą tej sesji wykonywać użyteczną pracę jest protokół Tool.

Protokół Tool to ta część, która ma znaczenie dla deweloperów aplikacji. Bez niego LLM działający on-device jest zwykłym endpointem dopełniania konwersacji 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 i wnioskować na ich podstawie w kolejnej turze. Generacja on-device wzbogacona o narzędzia stanowi rzeczywistą zdolność tego frameworku. Powierzchnia czatu to jedynie demo.

TL;DR

• Foundation Models udostępnia każdemu urządzeniu uprawnionemu do Apple Intelligence LLM z 3 miliardami parametrów pod adresem SystemLanguageModel.default. Model jest lokalny; inferencja jest zoptymalizowana pod Apple silicon i działa on-device; sieć pozostaje poza ścieżką wywołania.
• Protokół Tool to kontrakt między modelem a aplikacją. Narzędzie deklaruje typowane Arguments, zwraca typowany Output i jest powiązane z LanguageModelSession w momencie konstrukcji.
• Adnotacje Generable i Guide pozwalają modelowi produkować typowane wartości Swift bezpośrednio, a nie tylko ciągi znaków. Dekoder jest częścią frameworku, nie kodu aplikacji.
• Reguła routingu między Foundation Models, App Intents i MCP sprowadza się do pytania kto uruchamia model i gdzie. Foundation Models = aplikacja uruchamia model on-device. App Intents = Apple Intelligence uruchamia model on-device i kieruje go do aplikacji. MCP = zewnętrzny host uruchamia model gdziekolwiek chce 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 fundacyjnego działającego on-device. Domyślna instancja jest powiązana z urządzeniem użytkownika, dostępna na sprzęcie uprawnionym do Apple Intelligence i udostępnia kontrole zdolności, które aplikacja odczytuje w czasie wykonywania, by zdecydować, czy model jest dostępny. Framework wspiera konfigurację poprzez SystemLanguageModel(useCase:guardrails:), niestandardowe adaptery oraz GenerationOptions, ale nie można dowolnie wybierać identyfikatorów modeli chmurowych w sposób, w jaki robi się to w przypadku OpenAI czy Anthropic; Apple dostarcza i aktualizuje model on-device wraz z wydaniami systemu operacyjnego, a framework przekazuje aplikacji wersję aktualnie zainstalowaną.

LanguageModelSession. Stanowy obiekt przechowujący kontekst konwersacji 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 w tworzeniu i jednorazowe; tworzy się jedną sesję 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 ten przepis dla dwóch osób zamiast czterech”.

Tool (protokół). Protokół Swift, który deklaruje name, description, typ Arguments, typ Output oraz asynchroniczną funkcję call(arguments:). Narzędzia są powiązane z sesją w momencie konstrukcji (LanguageModelSession(tools: [...], instructions: ...)). Gdy model zdecyduje, że potrzebuje narzędzia, emituje ustrukturyzowane wywołanie; framework dekoduje argumenty, uruchamia narzędzie, koduje rezultat i przekazuje go z powrotem do sesji na potrzeby kolejnej tury. Model nie widzi Swifta; framework zajmuje się przekładem.

Pełne wymagania protokołu: name: String, description: String, powiązany typ Arguments zgodny z ConvertibleFromGeneratedContent, powiązany typ Output zgodny z PromptRepresentable oraz metoda asynchroniczna call(arguments:). Makro @Generable na strukturze Arguments generuje zgodność z ConvertibleFromGeneratedContent automatycznie; jeśli chodzi o Output, String i GeneratedContent już są z nim zgodne. Udokumentowane przez Apple przykłady zwracają String lub [String].

Skondensowany kształt protokołu Tool:

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 -> String {
        let entries = try store.entries(
            from: ISO8601DateFormatter().date(from: arguments.startDate) ?? .now,
            to: ISO8601DateFormatter().date(from: arguments.endDate) ?? .now
        )
        let totalMl = entries.reduce(0) { $0 + $1.amountMl }
        return "Found \(entries.count) entries totalling \(totalMl)ml."
    }
}

Model widzi opis narzędzia oraz kształt argumentu w schemacie generacji. Kod Swift widzi typowane wejście i typowane wyjście. Granica dekodowania/kodowania to część, którą Apple bierze na siebie. Wynik narzędzia może być obiektem String lub GeneratedContent; powyższy przykład zwraca String, ponieważ konsumentem jest następna tura wnioskowania modelu.

Generable i Guide: typowane wyjście bez parsera

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

@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
)

Wywołanie zwraca Response<PracticeSummary>, którego content jest typowanym PracticeSummary. Żadnego parsowania JSON w kodzie aplikacji, żadnego dopasowywania ciągów do „headline:”, żadnego fallbacku na wypadek, gdyby model zwrócił uszkodzony obiekt. Framework wykorzystuje ograniczone próbkowanie, aby zachować strukturalną zgodność wyjścia modelu (token po tokenie) ze schematem, dzięki czemu strukturalnie nieprawidłowe wyjście nie przedostaje się przez tę granicę. Powyższa sesja nie korzysta z żadnych narzędzi, ponieważ typowane wyjście i wywoływanie narzędzi to niezależne zdolności; sesja może używać @Generable dla kształtu odpowiedzi, narzędzi do uziemienia, obu, lub żadnego z tych mechanizmów.

To powierzchnia typowana w Swift odróżnia ten framework od chmurowych SDK dla LLM. Chmurowe SDK (OpenAI Structured Outputs, użycie narzędzi w Anthropic i inne) także wspierają ograniczone próbkowanie, ale typowana wartość, którą otrzymuje deweloper, to obiekt JSON walidowany względem schematu, a następnie dekodowany do typu Swift zgodnego z Codable jako oddzielny krok. Foundation Models scala te kroki: makro @Generable i dekoder frameworku produkują typowaną wartość Swift jako bezpośredni rezultat, przy czym adnotacje @Guide na poziomie pól przenoszą intencję do ograniczenia generacji. Wyjście jest typowane, ponieważ generacja była typowana względem schematu Swift, a nie względem specyfikacji JSON rekonstruowanej przez dewelopera w Swifcie.

Adnotacje @Guide to sposób na komunikowanie modelowi intencji dotyczącej poszczególnych pól bez wpisywania jej do promptu. Wygenerowany opis staje się częścią ograniczenia generacji. Wytyczne na poziomie pól zachowują czystość promptu i utrzymują schemat blisko danych.

Pytanie o routing — trzy odpowiedzi

Apple udostępnia teraz trzy powierzchnie protokołów, których aplikacja może użyć, aby wystawić swoją domenę modelowi językowemu. Kierują one wywołania do różnych wykonawców.

Foundation Models (LanguageModelSession). Aplikacja ładuje model on-device i uruchamia inferencję. Narzędzia, które sesja może wywoływać, to narzędzia zdefiniowane w kodzie aplikacji. Model nigdy nie opuszcza urządzenia. Użytkownik nie wywołuje tego przez Siri; wywołuje to kod aplikacji. Przypadek użycia znajduje się wewnątrz aplikacji: aplikacja medytacyjna wykorzystująca LLM do podsumowania tygodnia, aplikacja kulinarna adaptująca przepis do mniejszej liczby porcji, aplikacja śledząca nawodnienie zamieniająca „wypiłem szklankę przy obiedzie” w ustrukturyzowany wpis.

App Intents. Apple Intelligence uruchamia LLM w imieniu użytkownika (firmowy agent Apple) i kieruje wywołania zdolności do typów AppIntent należących do aplikacji. Aplikacja sama nie uruchamia modelu. Deklaruje się typowane akcje przez framework App Intents, a system Apple decyduje, kiedy je wywołać na podstawie żądania użytkownika, zapytania w Spotlight, polecenia Siri lub orkiestracji w Skrótach. Szczegółowo opisane w App Intents Are Apple’s New API to Your App.⁴

MCP. Zewnętrzny host (Claude Desktop, Claude Code, Cursor, ChatGPT) uruchamia model wybrany przez dewelopera. Aplikacja wystawia serwer, który model hosta może wywołać. Model działa tam, gdzie uruchomi go host; wywołania narzędzi przekraczają transport JSON-RPC. Omówione w Two Agent Ecosystems, One Shopping List oraz w syntezie pytania o routing w App Intents vs MCP.⁵

Decyzja o routingu sprowadza się do pytania 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ż to sama aplikacja chce wywołać model i zaprezentować rezultat wewnątrz siebie. Zdolność tej samej aplikacji „zaloguj 5-minutową sesję” korzysta z App Intents, aby Siri mogło ją wywołać. Zdolność tej samej aplikacji „pokaż moje ostatnie wpisy z dziennika medytacji” wykorzystywana przez sesję Claude Code używa MCP. Trzech różnych wykonawców, trzy różne zobowiązania, jedna wspólna warstwa domenowa pod spodem.

Budżety inferencji: czego framework od Pana/Pani wymaga

Uruchamianie LLM on-device nie jest darmowe. Apple silicon obsługuje inferencję, ale model wciąż ma okno kontekstowe, budżet tokenów oraz opóźnienie zegarowe zależne od urządzenia. Trzy ograniczenia kształtują projektowanie z użyciem tego frameworku:⁶

Dostępność jest per urządzenie. Nie każde urządzenie z iOS 26 ma Apple Intelligence. Starsze iPhone’y, urządzenia objęte ograniczeniami oraz urządzenia, na których użytkownik wyłączył Apple Intelligence, zwracają stan niedostępności z SystemLanguageModel.default.availability. Kod wywołujący LanguageModelSession bez sprawdzenia dostępności ujawnia błąd generacji w czasie wykonywania; właściwy wzorzec to wcześniejsze rozgałęzienie UI w oparciu o stan dostępności i prezentowanie ścieżki bez LLM, gdy stan jest niedostępny. Należy traktować model jak feature flag, nie jak gwarancję.

Opóźnienie nie jest pomijalne. Czas do pierwszego tokenu na sprzęcie iPhone 16 Pro jest użyteczny dla interakcji wewnątrz aplikacji w naszych testach na Return; dłuższe generacje i łańcuchy wywołań narzędzi nie są natychmiastowe. Wzorce UI, które działają dla streamingu chmurowego LLM, działają również tutaj; nie wolno blokować głównego wątku, należy pokazywać postępujące wyjście oraz projektować pod kątem przypadku, w którym użytkownik odchodzi w trakcie generacji.

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

Zestaw ograniczeń przypomina projektowanie pod niskoenergetyczne środowisko brzegowe, a nie pod chmurowy model frontier. Udogodnienia frameworku czynią to przyjemniejszym; bazowe ograniczenia fizyczne pozostają nieruszone.

Kiedy sięgać po Foundation Models

Najmocniejsze dopasowania frameworku to przypadki, w których generacja on-device, niskotarciowa, jest produktem:

Reformatowanie i przepisywanie. Zamiana swobodnej notatki użytkownika w ustrukturyzowany wpis, dopracowanie szkicu wiadomości, podsumowanie zarejestrowanej transkrypcji. Tolerancja na opóźnienia jest umiarkowana; wrażliwość danych wysoka; inferencja chmurowa byłaby nadmiarowa.

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

Lekkie wywołania narzędzi do automatyzacji wewnątrz aplikacji. Aplikacja, która pozwala użytkownikowi powiedzieć „pokaż mi log medytacji z wtorku” i używa narzędzia do pobrania bazowych rekordów, a następnie formatuje odpowiedź. Agentem jest aplikacja, narzędziem warstwa danych aplikacji, modelem instancja lokalna.

Generacja zgodna z typami. Wszędzie tam, gdzie aplikacja musiałaby ręcznie napisać parser JSON lub szablon ciągu, @Generable plus @Guide stanowi trwalszą powierzchnię.

Kiedy nie sięgać po Foundation Models

Framework jest niewłaściwą odpowiedzią w kilku częstych przypadkach:

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

Cokolwiek, co powinien obsługiwać zewnętrzny agent LLM. Sesja Claude Code sięgająca w domenę aplikacji należy do MCP. Aplikacja nie uruchamia LLM; robi to host; model rezyduje tam, gdzie umieścił go host. Foundation Models nie potrafi obsługiwać agentów zewnętrznych.

Ciężkie wnioskowanie nad dużymi dokumentami. Model on-device jest mały. 200-stronicowy kontrakt, długi kontekst bazy kodu lub wielobrazowe wnioskowanie nad wieloma zdjęciami należą do inferencji chmurowej (własnej lub dostawcy), gdzie okno kontekstowe i liczba parametrów odpowiadają obciążeniu. Zadania przekraczające zakres frameworku produkują konkretne błędy: przekroczone okno kontekstowe, naruszenia guardrails, nieobsługiwane lokalizacje. Należy te błędy świadomie ujawniać, zamiast projektować przepływy zależne od obsługi pracy poza zakresem przez model.

Przepływy międzyurządzeniowe i międzyużytkownikowe. Model on-device ma dostęp wyłącznie do tego, co aplikacja przekazuje do sesji. Synchronizacja między urządzeniami (stan timera z Watch do iPhone’a), współpraca między użytkownikami (wspólne listy, wspólne dokumenty) oraz każdy przepływ czerpiący korzyść z koordynacji po stronie serwera wymaga serwera. Model nie jest prymitywem sieciowym.

Co bym zbudował inaczej w moim stosie

Framework nagradza określoną decyzję architektoniczną, którą łatwo źle ułożyć za pierwszym podejściem. Zdolności wywoływane przez użytkownika przez UI aplikacji oraz LLM powinny konsumować je jako narzędzia, a nie jako zduplikowane ścieżki tekstowe.

Aplikacja medytacyjna mogłaby dodać panel „cotygodniowego przeglądu” podsumowanego przez LLM. Naiwna budowa to jeden prompt: „Oto wpisy użytkownika z tego tygodnia, napisz akapit”. Lepsza budowa definiuje narzędzie WeeklyEntries, które model może wywołać, gdy potrzebuje wiedzieć, co znalazło się w tygodniu, plus ustrukturyzowany wynik WeeklySummary poprzez @Generable. Pierwsza budowa jest krucha (model musi wczytywać długą listę wpisów przy każdym wywołaniu), kosztowna w tokenach i produkuje nieustrukturyzowaną 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 ustrukturyzowana (rezultatem jest typowana wartość Swift).

Wzorzec elegancko komponuje się z App Intents i MCP. To samo zapytanie WeeklyEntries jest również ciałem resolvera parametrów AppIntent oraz handlera narzędzia MCP. Jedna funkcja Swift; trzy powierzchnie. Model wywołuje tę samą funkcję, którą wywołuje użytkownik.

Druga 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óry ma przeczytać przyszły kontrybutor; modelem jest ten przyszły kontrybutor.

Co ten wzorzec oznacza dla stosu Apple na iOS 26+

Trzy wnioski.

1. LLM on-device to funkcja środowiska wykonawczego, nie backend. Należy go traktować jak framework systemowy z oknem kontekstowym i budżetem inferencji on-device, a nie jak usługę zdalną. Decyzje architektoniczne dotyczą dostępności, opóźnienia, dyscypliny okna kontekstowego oraz ustrukturyzowanego wyjścia.

2. Protokół Tool to powierzchnia. Bez narzędzi model jest endpointem dopełniania konwersacji bez połączenia z domeną. Z narzędziami model staje się ustrukturyzowaną warstwą zapytań nad danymi aplikacji.

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

Trzy posty siostrzane idą głębiej w framework Foundation Models: Foundation Models use cases dla decyzji o dopasowaniu obciążeń, custom adapters dla dostrajania modelu on-device na danych aplikacji oraz the agentic workflow dla podziału LLM wewnątrz aplikacji vs jako narzędzia.

Pełny klaster Apple Ecosystem: typowane App Intents dla Apple Intelligence; serwery MCP dla agentów LLM między platformami; pytanie o routing między tymi dwoma; Live Activities dla maszyny stanów na ekranie blokady; wzorce Liquid Glass dla warstwy wizualnej; wieloplatformowe wydawanie dla zasięgu między urządzeniami. Centrum znajduje się na stronie Apple Ecosystem Series. Szerszy kontekst iOS z agentami AI znajduje się w przewodniku iOS Agent Development guide.

FAQ

Czym jest framework Foundation Models w iOS 26?

Foundation Models to framework Apple do uzyskiwania dostępu do modelu językowego on-device, który dostarczany jest na urządzeniach uprawnionych 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 on-device 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, by zdecydować, kiedy wywołać. Narzędzia są powiązane z LanguageModelSession w momencie konstrukcji. Gdy model zdecyduje, że potrzebuje narzędzia, framework dekoduje argumenty, uruchamia wywołanie i przekazuje 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 on-device w celu generacji wewnątrz aplikacji. App Intents pozwala Apple Intelligence (agentowi systemowemu) wywoływać typowane zdolności aplikacji. MCP pozwala zewnętrznym hostom LLM (Claude, ChatGPT itp.) wywoływać typowane narzędzia aplikacji przez transport JSON-RPC. 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 zbudować most między tymi dwoma, należałoby napisać narzędzie Foundation Models Tool, którego metoda call wywołuje klienta MCP. Apple nie dostarczyło wbudowanego adaptera; most musiałby być kodem po stronie aplikacji.

Czy model on-device jest wystarczająco dobry do produkcji?

Dla przypadków użycia, do których framework został zaprojektowany (reformatowanie, podsumowanie, ustrukturyzowana generacja nad lokalnymi danymi, lekkie wywoływanie narzędzi), tak. Dla wnioskowania frontier nad dużymi kontekstami, multimodalnego rozumienia w skali lub wnioskowania międzydokumentowego — nie. Model on-device to model z 3 miliardami parametrów z mniejszym oknem kontekstowym niż chmurowe LLM; należy wybierać obciążenia, które mieszczą się w tym zakresie.

Bibliografia