Foundation Models Use Cases: Wann spezialisieren und wann einfach prompten

Das On-Device-Modell in Foundation Models ist nicht eine einzelne Sache. Apple liefert ein standardmäßiges SystemLanguageModel für allgemeines Prompting und eine von Apple verwaltete Spezialisierung für Content Tagging.¹ Das Framework erlaubt Entwicklern zudem, eigene Adapter zu trainieren und zu laden.² Drei Schienen, ein Entscheidungsbaum und eine Dokumentationsseite, die genau zwei UseCase-Werte benennt.

Der frühere Beitrag zum Tool-Protokoll hat behandelt, wie Sie das Standardmodell zu nützlicher Arbeit bringen. Die Frage, die dieser Beitrag beantwortet, ist die nächste: Wann reicht das Standardmodell mit Prompting und Tools aus, und wann verdient sich Apples .contentTagging-Use-Case seinen Platz? Der Pfad eigener Adapter ist ein separater Beitrag; der entwicklergeführte Lifecycle hat zu viel Oberfläche, um ihn mit der Entscheidungsmatrix zu teilen.

TL;DR

• SystemLanguageModel.UseCase ist ein Struct mit zwei statischen Eigenschaften: .general und .contentTagging.³ Keine weiteren Use Cases sind dokumentiert.
• .general ist der Standard. Greifen Sie zuerst dazu. Prompting, Instructions, Guided Generation und Tool Calling leben alle auf .general; die Spezialisierung ist der letzte Hebel, den Sie ziehen sollten.
• .contentTagging ist für genau eine Aufgabe gebaut: Themen, Handlungen, Objekte und Emotionen in Eingabetext zu identifizieren und ein bis wenige kleingeschriebene Wörter als Tags zurückzugeben.⁴ Apples eigener Leitfaden sagt Ihnen, wann Sie stattdessen .general verwenden sollten.
• Die dritte Schiene (eigene Adapter, der Adapter-Typ, das Entitlement, das Toolkit) ist dort, wo die operative Komplexität liegt. Anderer Beitrag.

Was SystemLanguageModel tatsächlich ist

SystemLanguageModel ist eine final class im FoundationModels-Framework, verfügbar auf iOS 26.0+, iPadOS 26.0+, Mac Catalyst 26.0+, macOS 26.0+ und visionOS 26.0+.¹ Apple beschreibt es als „ein On-Device-Large-Language-Model, das zu Textgenerierungsaufgaben fähig ist”.

Zwei Tatsachen prägen den Einsatz. Erstens gibt SystemLanguageModel.default die Basisversion des Modells zurück.¹ Das ist der Einstiegspunkt für alles Nicht-Spezialisierte. Zweitens aktualisiert Apple das Modell in OS-Updates: Zum Zeitpunkt des Schreibens listet Apples Dokumentation zwei Modellversionen, eine für iOS, iPadOS, macOS und visionOS 26.0–26.3 und eine weitere für 26.4.¹ Apps fixieren keine bestimmte Version; das Framework gibt jeweils das Modell zurück, das das OS gerade ausführt.

Die Verfügbarkeit wird zur Laufzeit geprüft. SystemLanguageModel.availability ist ein Availability-Enum mit den folgenden Fällen, wie in Apples Beispielcode dokumentiert:¹

struct GenerativeView: View {
    private var model = SystemLanguageModel.default

    var body: some View {
        switch model.availability {
        case .available:
            // Show your intelligence UI.
        case .unavailable(.deviceNotEligible):
            // Show an alternative UI.
        case .unavailable(.appleIntelligenceNotEnabled):
            // Ask the person to turn on Apple Intelligence.
        case .unavailable(.modelNotReady):
            // The model isn't ready because it's downloading or because
            // of other system reasons.
        case .unavailable(let other):
            // The model is unavailable for an unknown reason.
        }
    }
}

isAvailable ist ein Convenience-Getter, der nur dann true zurückgibt, wenn das System vollständig bereit ist.¹ Prüfen Sie das immer, bevor Sie aufrufen.

Die erste Schiene: Das allgemeine Modell prompten

Apple positioniert das Standardmodell als das richtige Werkzeug für eine breite Palette von Aufgaben. Der allgemeine Leitfaden des Frameworks zählt Fähigkeiten auf, die laut Apple das On-Device-Modell gut beherrscht:⁴

Apple ist auch deutlich darüber, wofür das On-Device-Modell nicht geeignet ist:⁴

Beachten Sie, dass „generate tags from text” in der Gut-darin-Tabelle für das allgemeine Modell auftaucht. Das ist wichtiger Kontext für die untenstehende Spezialisierungsentscheidung.

Die Standardschiene hat das vollständige Toolkit zur Verfügung: Instructions, Prompts, Guided Generation über Generable, Tool Calling über das Tool-Protokoll, Generierungsoptionen wie Temperatur. Die meisten Apps, die Foundation Models einführen, werden auf dieser Schiene leben und nie einen Use-Case-Spezifizierer berühren.

Das Kontextfenster beträgt 4.096 Tokens für das Systemmodell.⁴ Apple weist darauf hin, dass ein Token in Sprachen wie Englisch, Spanisch oder Deutsch drei bis vier Zeichen entspricht und in Sprachen wie Japanisch, Chinesisch oder Koreanisch ein Token pro Zeichen. Instructions, Prompts und Ausgaben zählen alle auf das Limit. Wenn eine Session es überschreitet, wirft das Framework LanguageModelSession.GenerationError.exceededContextWindowSize(_:).⁴

Die zweite Schiene: .contentTagging

SystemLanguageModel.UseCase ist als struct (nicht als Enum) mit zwei statischen Eigenschaften dokumentiert:³

static let general: SystemLanguageModel.UseCase
static let contentTagging: SystemLanguageModel.UseCase

Es gibt keine weiteren dokumentierten Fälle. Wenn ein Artikel einen dritten Use Case nennt, erfindet der Artikel ihn.

.contentTagging hat eine andere Form als .general. Apples Leitfaden beschreibt das contentTagging-Modell als eines, das „Themen, Handlungen, Objekte und Emotionen in Eingabetext identifiziert” und Tags als „ein bis wenige kleingeschriebene Wörter” produziert.⁵ Das Modell ist darauf ausgelegt, Eingaben zu bewerten, statt konversationell zu antworten: „Es ist kein typisches Sprachmodell, das auf eine Anfrage einer Person antwortet: stattdessen bewertet und gruppiert es die Eingabe, die Sie bereitstellen.”⁵

Das Modell mit .contentTagging laden:

let model = SystemLanguageModel(useCase: .contentTagging)
let session = LanguageModelSession(
    model: model,
    instructions: """
        Provide the two tags that are most significant in the context of topics.
        """
)

Der dokumentierte Convenience-Initializer ist init(useCase:guardrails:).¹ Apples Beispielcode ruft ihn ohne das guardrails-Argument auf, was nahelegt, dass guardrails an der Aufrufstelle einen Standardwert mitbringt.

Das contentTagging-Modell integriert sich mit Generable, sodass Sie einen Swift-Typ definieren können, der die Form der gewünschten Tags erfasst:

@Generable
struct ContentTaggingResult {
    @Guide(
        description: "Most important actions in the input text.",
        .maximumCount(2)
    )
    let actions: [String]

    @Guide(
        description: "Most important emotions in the input text.",
        .maximumCount(3)
    )
    let emotions: [String]

    @Guide(
        description: "Most important objects in the input text.",
        .maximumCount(5)
    )
    let objects: [String]

    @Guide(
        description: "Most important topics in the input text.",
        .maximumCount(2)
    )
    let topics: [String]
}

let response = try await session.respond(
    to: prompt,
    generating: ContentTaggingResult.self
)

Apples Leitfaden enthält eine nützliche Verhaltensanmerkung: „Bei sehr kurzen Eingabeanfragen liefern Anweisungen zum Tagging von Themen und Emotionen die besten Ergebnisse. Listen von Handlungen oder Objekten werden zu spezifisch und können Wörter aus der Anfrage wiederholen.”⁵ Das contentTagging-Modell „respektiert zudem das gewünschte Ausgabeformat, selbst ohne Instructions”, sodass die Generable-Form mehr Gewicht trägt als ein langer System-Prompt es täte.

Der Entscheidungsbaum (Apples eigene Worte)

Der interessante Teil der Use-Case-API ist, dass Apples Dokumentation explizit ist, wann nicht zu spezialisieren ist. Aus dem contentTagging-Leitfaden:⁵

1. „Wenn Sie Inhalte taggen, die keine Handlung, kein Objekt, keine Emotion und kein Thema sind, verwenden Sie stattdessen general.”
2. „Verwenden Sie das allgemeine Modell, um Inhalte wie Hashtags für Social-Media-Posts zu generieren.”
3. „Wenn Sie die Tool-Calling-API einführen und Tags generieren möchten, verwenden Sie general und reichen Sie die Tool-Ausgabe an das contentTagging-Modell weiter.”
4. „Wenn Sie eine komplexe Menge an Tagging-Constraints haben, die komplizierter sind als die maximumCount-Unterstützung des Tagging-Modells, verwenden Sie stattdessen general.”

Lesen Sie diese vier zusammen. Das contentTagging-Modell ist eng abgegrenzt: Themen, Handlungen, Objekte, Emotionen. Alles andere (Hashtag-Generierung, Tagging-Pipelines mit Tool Calls, Tag-Ausgabe mit reichhaltigeren Constraints als maximumCount) gehört auf das allgemeine Modell.

Die pragmatische Entscheidungsmatrix für eine App, die meint, sie wolle Tagging:

Standardmäßig .general. Es bewältigt die breite Palette an Generierungsaufgaben, die Apples Tabelle beschreibt, einschließlich „generate tags from text”. Die meisten Apps hören hier auf.

Greifen Sie nur dann zu .contentTagging, wenn die Eingabe textförmig ist, die Ausgabe ein kleines Set von einzelnen oder wenigen Wörtern als Tags ist, das sauber in Apples vier Kategorien fällt (Themen/Handlungen/Objekte/Emotionen), und die Constraints zu maximumCount passen. Das Beispiel, das Apple gibt, ist das Muster: eine Social-App, die Tags pro Post will, um ein Themen-Dashboard anzutreiben, ein E-Mail-Client, der Auto-Labeling will, ein Content-Store, der aggregierte Trendsignale will.

Auf einen eigenen Adapter ausweichen sollten Sie nur, wenn keine der beiden Schienen passt und der Use Case wertvoll genug ist, um die operativen Kosten für Training und Auslieferung eines an eine bestimmte Systemmodellversion gebundenen Adapters zu absorbieren. Der Pfad eigener Adapter ist separat dokumentiert; die Lifecycle-Komplexität (Toolkit-Version, Retraining-Zyklus, Verteilung) verdient eine eigene Behandlung.

Was Apple nicht veröffentlicht hat

Einige Dinge, über die Sie spekulieren sehen werden, die nicht zur dokumentierten Oberfläche gehören:

• Der Mechanismus, mit dem Apple das Modell für .contentTagging spezialisiert. Apples contentTagging-Leitfaden beschreibt das Framework als eines, das „ein angepasstes On-Device-Systemsprachmodell bereitstellt, das auf Content Tagging spezialisiert ist.”⁵ Apple veröffentlicht den Spezialisierungsmechanismus nicht, und das Verb „angepasst” in diesem Satz sollte nicht mit dem entwicklergeführten SystemLanguageModel.Adapter-Typ verwechselt werden, der eine separate Schiene ist.
• Weitere Use-Case-Werte. Das Struct hat zum Stand der aktuellen Dokumentation zwei statische Eigenschaften; jeder dritte Fall müsste in einem zukünftigen OS-Update ausgeliefert werden.
• Eine Garantie, dass .general und .contentTagging immer koexistieren werden. Apple sagt: „Apple will periodically update SystemLanguageModel in routine OS updates to improve the on-device model’s abilities and performance.”¹ Behandeln Sie die Oberfläche als versioniert.
• Konkrete Qualitätszahlen für .contentTagging gegenüber .general auf Tagging-Benchmarks. Apple positioniert die Wahl als passgenau für die Aufgabe, nicht als Qualitätsrangliste.

Wenn ein Beitrag (dieser oder ein anderer) eine quantitative Aussage über Adapter-Mechaniken macht, die nicht auf developer.apple.com steht, behandeln Sie die Aussage standardmäßig als falsch.

Was die zwei Schienen tatsächlich kaufen

Die zweite Schiene heißt nicht „das Modell wird besser”. Sie heißt „das Modell ist für eine Aufgabe gebaut und Apple hat dokumentiert, wann man es wählt.” Das verändert die Ökonomie:

1. Geringere Prompt-Engineering-Oberfläche für Tagging-Aufgaben. Das contentTagging-Modell „respektiert das gewünschte Ausgabeformat, selbst ohne Instructions.”⁵ Sie können sich auf @Generable und maximumCount stützen, statt auf einen mehrabsätzigen Prompt, den das allgemeine Modell brauchen würde.
2. Eingegrenzte semantische Form. Das Modell findet Ähnlichkeit über Eingabebegriffe hinweg und produziert semantisch konsistente Tags (Apples Beispiel: „greet” ergibt sich als Themen-Tag für „hi”, „hello”, „yo”).⁵ Genau das brauchen aggregierte Analytics über benutzergenerierte Inhalte.
3. Eine dokumentierte Entscheidungsmatrix. Apple sagt Ihnen, wann ihre Spezialisierung passt und wann zurückgefallen werden soll. Diese Matrix ist der wertvollste Teil der Use-Case-API: Sie ist eine meinungsstarke Antwort auf eine Frage, die App-Entwickler sonst aus ersten Prinzipien verhandeln müssten.

Die Kosten sind ebenfalls klar: .contentTagging ist an eine Aufgabenform gebunden. Alles außerhalb dieser Form geht zurück zu .general und steht und fällt mit Prompt- und Generable-Design.

Erkenntnisse

1. Heute zwei Schienen, möglicherweise später mehr. .general und .contentTagging sind die einzigen zwei statischen UseCase-Eigenschaften, die Apple dokumentiert hat. Schreiben Sie keinen Code, der weitere annimmt.
2. Standardmäßig .general. Prompting + Tools + Guided Generation deckt die meisten Use Cases ab, für die das On-Device-Modell entwickelt wurde. Die Spezialisierung ist der letzte Hebel, nicht der erste.
3. Wählen Sie .contentTagging nur, wenn Apples dokumentierte Form passt. Themen, Handlungen, Objekte, Emotionen. Ein bis wenige kleingeschriebene Wörter als Tags. Constraints auf maximumCount-Niveau. Alles darüber hinaus, fallen Sie zurück.
4. Lesen Sie Apples „use general instead”-Regeln. Es sind vier konkrete Sätze im contentTagging-Leitfaden.⁵ Jeder davon ist eine echte Grenze.
5. Der Pfad eigener Adapter ist eine separate Entscheidung. Andere Oberfläche, anderer Lifecycle, anderer Beitrag.

Der vollständige Apple-Ecosystem-Cluster: das On-Device-LLM und Tool-Protokoll für die Primitiven des Frameworks; die Aufteilung des agentischen Workflows zwischen In-App- und Entwicklerwerkzeug-LLMs; App Intents vs MCP für die Routing-Frage über alle drei. Der Hub findet sich in der Apple Ecosystem Series. Für breiteren Kontext zu iOS mit AI-Agenten siehe den iOS Agent Development Guide.

FAQ

Wie viele SystemLanguageModel.UseCase-Werte gibt es?

Zwei statische Eigenschaften, wie aktuell dokumentiert: .general und .contentTagging.³ Wenn Sie einen dritten Wert in einem Tutorial oder einer LLM-generierten Antwort referenziert sehen, verifizieren Sie ihn gegen developer.apple.com, bevor Sie ihn übernehmen.

Wann sollte ich .contentTagging verwenden, statt einfach .general zu prompten?

Verwenden Sie .contentTagging, wenn die Aufgabe darin besteht, Themen, Handlungen, Objekte oder Emotionen in Eingabetext zu identifizieren und kurze kleingeschriebene Tags zurückzugeben. Apples Leitfaden listet vier Szenarien auf, in denen stattdessen .general die richtige Antwort ist: Tagging, das nicht in diese vier Kategorien passt, Hashtag-Generierung, Tagging-Pipelines, die über Tool Calls geroutet werden, und Tagging-Constraints, die reichhaltiger sind als maximumCount.⁵

Akzeptiert das contentTagging-Modell beliebige Instructions wie das allgemeine Modell?

Es akzeptiert Instructions, aber das Design des Modells besteht darin, Eingaben zu bewerten, statt auf benutzerstilartige Anfragen zu antworten. Apples Leitfaden weist darauf hin, dass das contentTagging-Modell „das gewünschte Ausgabeformat respektiert, selbst ohne Instructions”, sodass eine @Generable-Form mit @Guide-Annotationen die Constraints trägt, nicht ein langer Prompt.⁵

Wie groß ist das Kontextfenster für das On-Device-Modell?

4.096 Tokens für das Systemmodell.⁴ Das Token-zu-Zeichen-Verhältnis liegt bei etwa drei bis vier Zeichen pro Token in Englisch/Spanisch/Deutsch und einem Token pro Zeichen in Japanisch/Chinesisch/Koreanisch. Das Framework wirft LanguageModelSession.GenerationError.exceededContextWindowSize(_:), wenn die Session das Limit überschreitet.

Warum ruft Apples Beispielcode SystemLanguageModel(useCase:) ohne guardrails: auf?

Der dokumentierte Convenience-Initializer ist init(useCase:guardrails:).¹ Apples contentTagging-Leitfaden ruft ihn ohne das guardrails-Argument auf, was nahelegt, dass guardrails an der Aufrufstelle einen Standardwert mitbringt. Die Form mit zwei Argumenten ist die dokumentierte Oberfläche; die Form mit einem Argument ist das, was Apples veröffentlichter Beispielcode zeigt.

Quellen