Foundation Models z poziomu Pythona: narzędzie fm CLI

Przez rok duży model językowy Apple działający na urządzeniu pozostawał za murem: można go było osiągnąć wyłącznie z poziomu Swifta i tylko wewnątrz aplikacji zbudowanej w Xcode¹. macOS 27 burzy ten mur. Apple dostarcza teraz narzędzie wiersza poleceń o nazwie fm, preinstalowane wraz z systemem operacyjnym, oraz SDK Foundation Models dla Pythona, które instaluje się za pomocą pip¹. Model, który dawniej wymagał projektu, kompilacji i LanguageModelSession w skompilowanym Swifcie, dziś odpowiada na jednowierszowe polecenie powłoki i działa wewnątrz notatnika Jupyter. Eric Gourlaouen, inżynier z zespołu Foundation Models Framework, ujął tę zmianę wprost podczas sesji 334 na WWDC26: „do tej pory te modele były dostępne wyłącznie z poziomu kodu Swift”¹. Zmianą nie jest nowy model. Zmianą jest to, że ten sam model działający na urządzeniu nagle staje się skryptowalny, automatyzowalny i poddający się ewaluacji spoza aplikacji — bez klucza API i bez kosztów chmury¹.

W skrócie

• macOS 27 dostarcza fm, preinstalowane narzędzie wiersza poleceń dla działającego na urządzeniu Apple Foundation Model. Jego podpolecenia obejmują respond (pojedynczy prompt na stdout), chat (sesja interaktywna) oraz schema (definiowanie ustrukturyzowanego wyjścia)¹.
• fm respond udostępnia opcje dotyczące modelu (przełączenie na Private Cloud Compute), wejścia obrazu oraz schematu dla ustrukturyzowanego wyjścia; pozostałe wymienia --help¹.
• SDK dla Pythona sięga po ten sam model działający na urządzeniu z poziomu Pythona; wymaga Pythona 3.10 lub nowszego, zainstalowanego Xcode oraz Maca z Apple Silicon, a instaluje się go za pomocą pip lub innego menedżera pakietów¹.
• SDK odzwierciedla framework Swifta: LanguageModelSession, na którym wywołuje się respond, wywoływanie narzędzi oraz generowanie sterowane za pomocą dekoratora fm.generable przekazywanego do fm.respond jako argument generujący¹.
• Oba interfejsy domyślnie korzystają z zawsze dostępnego modelu działającego na urządzeniu i mogą przełączyć się na większy model Private Cloud Compute, który jest bardziej wydajny, lecz objęty limitami użycia¹.
• Korzyścią są prototypowanie i automatyzacja: skrypty powłoki sortujące pliki według znaczenia oraz potoki ewaluacyjne w Pythonie oceniające warianty promptów za pomocą Pandas i matplotlib¹.

Narzędzie wiersza poleceń fm

Otwórz Terminal w macOS 27 i wpisz fm, a narzędzie wypisze obsługiwane polecenia¹. Apple wyróżnia trzy z nich. fm respond wysyła do modelu prompt i zwraca odpowiedź. fm chat rozpoczyna interaktywną rozmowę. fm schema tworzy schemat dla ustrukturyzowanego wyjścia¹. Najprostszym możliwym zastosowaniem jest to, które Eric pokazał jako pierwsze: wpisz fm respond, wpisz prompt, naciśnij Enter i po chwili odczytaj odpowiedź modelu w terminalu¹.

Dwa polecenia najwyższego poziomu dzielą się wyraźną linią: eksploracja kontra skryptowanie. fm chat służy do wyczucia pierwszego pulsu modelu. Zadaje się pytanie, zadaje pytanie uzupełniające, a rozmowa jest podtrzymywana — z własnymi poleceniami ze slashem: /model przełącza rozmowę na model Private Cloud Compute, a /save zapisuje rozmowę, aby wznowić ją później¹. Gdy zamiast tego potrzebna jest odpowiedź w jednym ciągu, którą da się przechwycić, na przykład w skrypcie, sięga się po fm respond, które zapisuje wyjście modelu na stdout¹.

To w fm respond mieszczą się opcje. Eric wymienił trzy z nich wprost. Opcja modelu kieruje prompt do modelu Private Cloud Compute zamiast do domyślnego modelu działającego na urządzeniu. Opcja obrazu dołącza do promptu obraz. Z kolei opcja schematu współpracuje z fm schema object, ograniczając wyjście do zdefiniowanej przez użytkownika struktury¹. Zaznaczył, że jest ich więcej, i wskazał opcję pomocy, by wymienić je wszystkie¹. Transkrypcja nazywa opcje raczej według ich roli niż dokładnego zapisu każdej flagi (jedyną dosłowną formą pokazaną na ekranie jest fm schema object), więc tam, gdzie poniżej opisuję daną opcję, opisuję udokumentowane zachowanie, a nie zmyślam ciągu flagi.

Wybór modelu to decyzja, która liczy się najbardziej. Domyślnie fm korzysta z modelu działającego na urządzeniu dostarczanego z macOS, który jest zawsze dostępny¹. Można przełączyć się na Apple Foundation Model w Private Cloud Compute, który Eric opisał jako „znacznie większy model niż model działający na urządzeniu, więc poradzi sobie lepiej ze złożonymi problemami”, przy czym wiąże się to z limitami użycia¹. Wartość domyślna to właściwy punkt wyjścia: jest darmowa, lokalna i bez limitu. Na Private Cloud Compute warto przejść wtedy, gdy zadanie jest naprawdę na tyle trudne, że tego wymaga.

Budowanie skryptu automatyzacji

Demonstracja sortowania plików to najczytelniejszy argument za tym, dlaczego CLI ma znaczenie. Eric miał folder projektu pełen roboczych i finalnych wersji zasobów i chciał powtarzalnego skryptu, który zachowa wersje finalne, utworzy ich kopię zapasową, a wersje robocze przeniesie na dysk archiwalny¹. Trudne nie jest przenoszenie plików. Trudne jest rozstrzygnięcie, który plik jest wersją roboczą, gdy nazwy są chaotyczne. Jak to ujął, wywołanie modelu językowego ze skryptu pozwala mu „posortować pliki robocze od finalnych” nawet wtedy, gdy „nazwy są chaotyczne i trudne do przewidywalnego posortowania”¹.

Ten kształt uogólnia się na dowolną automatyzację typu „osąd nad listą”. Skrypt wczytuje pliki z katalogu roboczego, a następnie za pośrednictwem fm respond prosi model, by posortował tę listę na dwie grupy: pliki finalne i pliki robocze¹. Aby wyjście dało się wykorzystać, skrypt z góry definiuje schemat za pomocą fm schema object, opisując dwa pola — listę wersji finalnych i listę wersji roboczych — i przekazuje ten schemat do fm respond poprzez opcję schematu¹. Model zwraca odpowiedź w formie JSON, a skrypt ją odczytuje, by skopiować wersje finalne do kopii zapasowej i przenieść wersje robocze do archiwum¹.

Krok ustrukturyzowanego wyjścia jest tym, który dźwiga całą konstrukcję. Odpowiedź w postaci dowolnego tekstu zmusiłaby skrypt do parsowania prozy — najbardziej kruchej części każdego potoku powłoki rozmawiającego z LLM. Deklarując schemat za pomocą fm schema object i otrzymując w zamian JSON, skrypt zyskuje kontrakt, na którym może działać bezpośrednio¹. To ten sam wzorzec, który deweloperzy Swifta znają jako generowanie sterowane, tu udostępniony jako opcja CLI¹. Każde zadanie kończące się słowami „zrób coś deterministycznego na podstawie decyzji modelu” potrzebuje dokładnie tego kształtu: prompt, schemat, JSON, działanie.

SDK dla Pythona

Drugi interfejs jest dla innej osoby w innej chwili. Jak ujął to Eric, „jeśli jesteś inżynierem uczenia maszynowego, być może używasz Pythona częściej niż Swifta”, a SDK „ułatwia korzystanie z modelu działającego na urządzeniu w kodzie Pythona”¹. Cała propozycja opiera się na ekosystemie Pythona: „Python ma bogaty ekosystem pakietów open source do uczenia maszynowego i nauki o danych”, co oznacza, że można pisać potoki ewaluacyjne i „wykorzystać te pakiety do ilościowego określenia jakości funkcji”¹.

Instalacja ma cztery wymagania, wszystkie podane w sesji. Potrzebny jest Python 3.10 lub nowszy, zainstalowany Xcode oraz Mac z Apple Silicon, a SDK instaluje się za pomocą pip lub dowolnego innego wybranego menedżera pakietów¹. Wymagania dotyczące Apple Silicon i Xcode to sygnał, że pakiet jest powiązaniem z tym samym modelem działającym na urządzeniu, który uruchamia system operacyjny, a nie hostowanym API.

To API wyda się znajome każdemu, kto korzystał z frameworka Swifta², i jest to zamierzone: „API i abstrakcje szybko wydadzą się znajome”¹. Prompt wysyła się, tworząc LanguageModelSession, opcjonalnie przekazując instrukcje, a następnie wywołując session.respond ze swoim promptem; wynik zawiera wyjście modelu¹. SDK przenosi podstawowe funkcje frameworka: wejścia tekstowe i obrazowe, odpowiedzi strumieniowe, wywoływanie narzędzi, aby model mógł wchodzić w interakcję z kodem, oraz generowanie sterowane dla ustrukturyzowanego wyjścia¹.

Dwie z tych funkcji zostały omówione konkretnie. W przypadku wywoływania narzędzi Eric zdefiniował narzędzie, które model może wywołać, aby pobrać kilka ostatnich zamówień użytkownika, „tak aby mógł dostarczyć bardziej spersonalizowane informacje” — ten sam wzorzec co protokół Tool w frameworku Swifta¹. W przypadku generowania sterowanego użył dekoratora fm.generable, by zdefiniować pożądaną strukturę wyjścia, obiekt ItemsSuggestion, i przekazał go do fm.respond jako argument generujący¹. Dekorator jest pythonowym odpowiednikiem makra @Generable ze Swifta, a argument generujący to sposób, w jaki przekazuje się modelowi kształt, który chce się otrzymać z powrotem. Ponieważ transkrypcja pokazuje je poprzez rolę i nazwę obiektu, a nie poprzez wydrukowanie całego ciała klasy, potraktuj ItemsSuggestion jako nadaną w przykładzie nazwę struktury, którą zdefiniowałbyś samodzielnie.

Potoki ewaluacyjne: prawdziwy powód, by używać Pythona

Studium przypadku to moment, w którym SDK dla Pythona przestaje być wygodą, a staje się metodą. Eric budował funkcję przewidującą, co użytkownik chce dodać do koszyka spożywczego, i miał trzy różne implementacje promptu: minimalną, bardziej opisową oraz szczegółową, która rozpisywała pełną listę reguł¹. Pytanie, przed którym staje każdy prompt engineer, brzmi: który z nich jest naprawdę najlepszy — a uczciwa odpowiedź wymaga pomiaru, nie gustu.

Apple wyraźnie zaznacza, że deweloperzy Swifta mają tu własną odpowiedź. Framework Evaluations jest dostarczany z Xcode 27 i ułatwia tworzenie ewaluacji oraz śledzenie dokładności funkcji na przestrzeni kolejnych iteracji¹. SDK dla Pythona to równoległa ścieżka dla analityków danych, którzy żyją w notatnikach. Eric przeprowadził całą analizę z poziomu Jupytera¹.

Potok czyta się jak standardowa pętla ewaluacyjna ML wycelowana w model działający na urządzeniu. Najpierw za pomocą dużego modelu serwerowego wygenerował dane ewaluacyjne, uzyskując dla każdego przypadku wejścia oraz oczekiwane wyjście¹. Następnie dla każdego wejścia wygenerował wyjścia z każdej z trzech implementacji promptu i zapisał wejścia oraz wyjścia jako wiersze w ramce danych Pandas¹. Z kolei funkcje oceniające oparte na modelu serwerowym oceniły każde wyjście według wybranych przez niego kryteriów, a te metryki wróciły do ramki danych¹. Na koniec matplotlib zamienił oceny w wykresy¹.

Wykresy opowiedziały historię, której żadne wpatrywanie się w prompty by nie ujawniło: szczegółowy prompt osiągnął wysoki odsetek błędów generowania, co Eric przypisał osiągnięciu maksymalnego rozmiaru okna kontekstowego modelu; dwa mniej szczegółowe prompty dodawały do koszyka nadmiarowe pozycje, podczas gdy szczegółowy dodawał ich mniej; szczegółowy prompt pomijał więcej oczekiwanych pozycji; a minimalny prompt halucynował najwięcej pozycji¹. Każdy prompt miał inny tryb awarii, a ujawnił je dopiero pomiar. To właśnie argument przemawiający za całym podejściem. „Dzięki Pythonowi mogę przeprowadzać te iteracje szybko, prosto z notatnika, bez konieczności przebudowywania całego projektu” — powiedział Eric¹.

Po co sięgać po każde z nich

Z powyższych kontraktów wynika kilka reguł.

Po fm respond sięgaj wtedy, gdy skrypt powłoki potrzebuje osądu. Sortowanie chaotycznych nazw plików, klasyfikacja wiersza wejścia, wydobycie pola z nieustrukturyzowanego tekstu. Połącz to z fm schema object i opcją schematu, aby skrypt działał na JSON, zamiast parsować prozę¹.

Po fm chat sięgaj wtedy, gdy eksplorujesz, a nie skryptujesz. To najszybszy sposób na wyczucie pierwszego pulsu tego, jak model radzi sobie z Twoimi promptami, z /model do przejścia na Private Cloud Compute i /save do zachowania sesji¹.

Po SDK dla Pythona sięgaj wtedy, gdy chcesz mierzyć, a nie tylko wywoływać. W chwili gdy masz więcej niż jeden prompt i musisz wiedzieć, który jest lepszy, narzędziem jest pętla notatnik plus Pandas plus matplotlib — model działający na urządzeniu jest bowiem na tyle darmowy i lokalny, że można uruchomić cały zestaw ewaluacyjny bez rachunku¹.

Domyślnie korzystaj z modelu działającego na urządzeniu; na Private Cloud Compute przechodź świadomie. Model działający na urządzeniu jest zawsze dostępny i nie ma limitu użycia. Private Cloud Compute jest większy i lepszy w złożonych problemach, ale wiąże się z limitami użycia, więc zachowaj go dla zadań, które na to zasługują¹.

Prototypuj tutaj, wdrażaj w Swifcie. Sam Eric ujmuje to tak, że tych narzędzi można używać „obok projektu Xcode, jako sposobu na prototypowanie i ewaluację promptów” albo „samodzielnie, by używać modelu w nowatorski sposób”¹. Przykład aplikacji zakupowej prototypuje prompty w Pythonie „przed wdrożeniem ich w Swifcie”¹. CLI i SDK skracają pętlę między pomysłem a dowodem; aplikacja wciąż pozostaje miejscem, w którym ląduje funkcja.

FAQ

Czym jest narzędzie wiersza poleceń fm?

fm to narzędzie wiersza poleceń preinstalowane wraz z macOS 27, które sięga po działający na urządzeniu Apple Foundation Model z poziomu aplikacji Terminal¹. Jego podpolecenia obejmują respond do wysłania promptu do modelu i wypisania odpowiedzi, chat do rozpoczęcia interaktywnej rozmowy oraz schema do zdefiniowania ustrukturyzowanego wyjścia. Uruchamia się je bez klucza API i bez kosztów chmury, ponieważ domyślny model działa na urządzeniu¹.

Jak uzyskać z fm ustrukturyzowany JSON?

Zdefiniuj schemat za pomocą fm schema object, a następnie przekaż ten schemat do fm respond poprzez jego opcję schematu. Model zwraca odpowiedź w postaci JSON zgodnego ze schematem, na którym skrypt może działać bezpośrednio, zamiast parsować dowolny tekst¹. Mechanizm ten to wersja CLI generowania sterowanego znanego z frameworka¹.

Czego wymaga SDK Foundation Models dla Pythona?

Pythona 3.10 lub nowszego, zainstalowanego Xcode oraz Maca z Apple Silicon¹. Instaluje się go za pomocą pip lub innego wybranego menedżera pakietów. Wymagania dotyczące Apple Silicon i Xcode odzwierciedlają fakt, że SDK wiąże się z tym samym modelem działającym na urządzeniu, który uruchamia system operacyjny, a nie wywołuje hostowanego API¹.

Czym SDK dla Pythona różni się od frameworka Swifta?

To ten sam model i celowo znajome API w innym języku. Tworzy się LanguageModelSession, wywołuje respond, udostępnia narzędzia i korzysta z generowania sterowanego poprzez dekorator fm.generable przekazywany do fm.respond jako argument generujący¹. Powodem, by wybrać Pythona, jest ekosystem: Pandas, matplotlib, Jupyter i reszta stosu do nauki o danych, służące do potoków ewaluacyjnych, których Swift nie osiąga równie bezpośrednio¹.

Kiedy powinno się używać Private Cloud Compute zamiast modelu działającego na urządzeniu?

Zarówno fm, jak i SDK domyślnie korzystają z modelu działającego na urządzeniu, który jest zawsze dostępny i nie ma limitu użycia¹. Na Private Cloud Compute przełącz się — poprzez opcję modelu w fm respond lub polecenie /model w fm chat — gdy problem jest na tyle złożony, że wymaga większego modelu, godząc się na to, że wiąże się on z limitami użycia¹.

Pełny klaster Apple Ecosystem: omówienie frameworka Foundation Models jako swiftowy fundament, który te narzędzia odzwierciedlają; mechanizmy kontroli wywoływania narzędzi w iOS 27 opisujące, jak model używa narzędzi; agentowy przepływ pracy Foundation Models dotyczący wyboru między modelem działającym na urządzeniu a większym modelem; oraz agenty kodujące Xcode 27 ukazujące stronę przepływu pracy skoncentrowanego na agentach wewnątrz IDE. Centrum znajduje się w serii Apple Ecosystem. Szerszy obraz budowania iOS z agentami przedstawia przewodnik po tworzeniu agentów dla iOS.