Symfony AI v0.8: Failover & 30+ Provider für PHP-Apps

Symfony AI v0.8: Failover und 30+ Provider für Production

Wenn OpenAI um 14:00 Uhr ausfällt und Ihr Kundenportal keine Zusammenfassungen mehr generieren kann, haben Sie ein Problem. Kein technisches, ein geschäftliches. Ihr Kunde sieht eine Fehlermeldung und fragt, warum er für ein Feature bezahlt, das nicht funktioniert.

Genau dieses Problem adressiert Symfony AI v0.8, erschienen am 20. April 2026. Keine spektakulären neuen KI-Features, aber etwas Wichtigeres: Production-Infrastruktur. Failover-Platforms, 30+ Provider-Bridges und die neue Models.dev-Bridge.

Die Zahlen untermauern das: symfony/ai-platform hat die Million-Downloads-Marke überschritten, mit 140.000 Downloads pro Monat.

Was bringt v0.8 konkret?

Warum ist Failover der entscheidende Unterschied?

Das FailoverPlatform-Pattern existiert seit v0.2 (Januar 2026), aber erst mit der Provider-Abdeckung von v0.8 wird es praktisch nutzbar.

Sie definieren eine primäre Platform (etwa OpenAI) und Backup-Platforms (Azure, Anthropic, Ollama). Wenn der primäre Provider nicht antwortet, wechselt Symfony AI automatisch zum nächsten in der Kette.

# config/packages/ai.yaml
ai:
platform:
primary:
openai:
api_key: '%env(OPENAI_API_KEY)%'
backup_azure:
azure:
gpt_deployment:
base_url: '%env(AZURE_BASE_URL)%'
deployment: 'gpt-4o-backup'
api_key: '%env(AZURE_KEY)%'
api_version: '2024-02-15-preview'
backup_local:
ollama:
base_url: 'http://localhost:11434'

# Failover-Chain: OpenAI → Azure → lokales Ollama
production:
failover:
platforms: ['primary', 'backup_azure', 'backup_local']

OpenAIs GPT-4o unterstützt Vision (Bildeingabe), Anthropic Claude ebenfalls, aber Ollama-Modelle je nach Modell nicht. Symfony AI prüft Capabilities über das Capability-Enum (Capability::INPUT_AUDIO, Capability::OUTPUT_IMAGE).

Alle Platforms in der Failover-Chain müssen die benötigten Capabilities unterstützen. Sonst bekommen Sie entweder einen Fehler oder ein degradiertes Ergebnis.

Warum gehören Rate-Limiting und Cost-Tracking dazu?

Symfony AI integriert das Rate-Limiting über Symfonys RateLimiter-Komponente. Das Event-System ermöglicht Cost-Tracking pro Request, pro Agent, pro Kunde.

# Rate-Limiting in der Failover-Konfiguration
$rateLimiter = new RateLimiterFactory([
'policy' => 'sliding_window',
'id' => 'ai_failover',
'interval' => '3 seconds',
'limit' => 1,
], new InMemoryStorage());

# Cost-Tracking über Events
$dispatcher->addListener(ResultEvent::class, function (ResultEvent $e) {
$usage = $e->getResult()->getUsage();
// $usage->inputTokens, $usage->outputTokens
// → In Datenbank loggen, Dashboard aktualisieren
});

Für Agenturen, die KI-Features für Kunden entwickeln: Sie müssen Ihrem Kunden sagen können, was das Feature monatlich kostet. Ohne Tracking ist das Rätselraten.

Welche Provider-Bridges sind für deutsche Agenturen relevant?

v0.8 deckt über 30 Provider ab. Für die Praxis relevant sind drei Gruppen:

Für Agenturen mit bestehenden Cloud-Verträgen (AWS, Azure, GCP) sind die Cloud-Provider interessant, weil die KI-Nutzung über vorhandene Billing-Strukturen abgerechnet wird.

Für deutsche KMU, die Datensouveränität ernst nehmen, sind Mistral und OVH die relevantesten Alternativen. Ollama als lokales Modell hat keine API-Kosten, dafür eigene Hardware-Anforderungen.

Was bringt die Models.dev-Bridge?

Die symfony/ai-models-dev-platform-Bridge (neu in v0.8) aggregiert Modell-Metadaten von Models.dev: Capabilities, Pricing, API-Anforderungen. Die Bridge routet automatisch zum richtigen Provider-Adapter.

In der Praxis: Modell-Name angeben ("claude-4-sonnet"), die Bridge routet zur Anthropic-Platform. Für OpenAI-kompatible Provider out-of-the-box.

Was die Dokumentation nicht erwähnt: Aktuell erst 12 Downloads. Für Production empfehle ich die spezifischen Provider-Bridges. Models.dev ist spannend für Prototyping.

Ist Symfony AI production-ready?

Die ehrliche Antwort: Teils, teils. Wie ich im SymfonyLive Berlin Recap beschrieben habe, hat die Konferenz bestätigt, dass die Platform-Schicht stabil ist.

Production-ready: Platform-Komponente mit Provider-Abstraktion, Failover, Structured Output und Event-System. Für einfache Use-Cases (Content zusammenfassen, klassifizieren, extrahieren) zuverlässig.

Experimental: Agent-Komponente für Tool-Calling. Architektonisch sauber, aber ohne BC-Promise. Breaking Changes zwischen Minor-Versionen möglich.

Early Stage: Store (RAG), Chat (Konversations-Persistenz), Models.dev-Bridge. Viel manuelle Integrationsarbeit nötig.

Warum ist Structured Output das unterschätzte Killer-Feature?

Was in der Provider-Diskussion oft untergeht: Structured Output liefert KI-Antworten direkt als typisierte PHP-Objekte. Kein JSON-Parsing, kein String-Matching.

# Structured Output: JSON-Schema → PHP-Objekt
class ProductClassification {
public string $category;
public float $confidence;
public array $tags;
}

$result = $platform->request(
new MessageBag(Message::ofUser('Klassifiziere: Ergonomischer Bürostuhl...')),
new StructuredOutput(ProductClassification::class)
);
# $result->category = "Büromöbel"
# $result->confidence = 0.94
# $result->tags = ["Ergonomie", "Büro", "Gesundheit"]

In der Praxis scheitert das oft an der Schema-Definition. Was passiert, wenn das KI-Modell ein Feld nicht befüllen kann? Symfony AI handelt viele Edge Cases, aber projektspezifische Validierung bleibt notwendig.

Symfony AI oder direkte OpenAI-Integration?

Für ein einzelnes Projekt mit einem festen Provider kann die direkte SDK-Integration pragmatischer sein. Für Agenturen mit mehreren Projekten und verschiedenen Providern ist Symfony AI die bessere Wahl.

Welcher Einstieg ist der richtige?

Konkreter Use-Case (Content, Klassifizierung): symfony/ai-bundle + Provider-Bridge + Failover. In wenigen Stunden machbar.

DSGVO-sensitive Projekte: Mistral oder Ollama priorisieren. Symfony AI behandelt alle Provider gleich.

Bestehende OpenAI-Integration: Migration lohnt sich bei Bedarf für Failover oder Provider-Flexibilität. Ohne Bedarf: Kein akuter Handlungsdruck.

Projekte auf v0.6 oder früher: Upgrade auf v0.8. Breaking Changes möglich (kein BC-Promise). Changelog prüfen.

Als Symfony-Entwickler mit Fokus auf KMU-Projekte sehe ich den sinnvollsten Einstieg über einen konkreten, begrenzten Use-Case. Nicht über ein großes "KI-Strategie-Projekt".

Zusammenfassung und Ausblick

Failover-Platforms ermöglichen hochverfügbare KI-Features. Primärer Provider + Backup-Chain = kein Single Point of Failure.

30+ Provider-Bridges decken alle relevanten Anbieter ab. Für den deutschen Markt: Mistral (EU), OVH (EU), Ollama (lokal).

Structured Output liefert typisierte PHP-Objekte statt unstrukturiertem Text.

1 Million Downloads bei 140.000/Monat. Das BC-Promise fehlt noch, aber die Platform-Schicht ist stabil.

In den kommenden Monaten erwarte ich eine API-Stabilisierung (möglicherweise 1.0-Release in H2 2026). Wie ich im SymfonyLive-Recap beschrieben habe, ist die Roadmap ambitioniert. Wer jetzt startet, ist bereit.