Aufbau einer robusten Multi-Provider-KI-Routing-Schicht mit dem Vercel AI SDK
Erfahren Sie, wie Sie eine produktionsreife LLM-Routing-Schicht mit automatischer Ausfallsicherung (Failover), Backup-Modellen und strukturierten Zod-Ausgaben unter Verwendung des Vercel AI SDK erstellen.

Bei der Bereitstellung von Large Language Models (LLMs) in Produktionsumgebungen ist die Zuverlässigkeit oft der größte Engpass. Die Abhängigkeit von einem einzigen Modellanbieter birgt das Risiko eines Single Point of Failure: API-Ratenbegrenzungen (HTTP 429), vorübergehende Service-Ausfälle (HTTP 500/503) oder plötzliche Latenzspitzen.
Um Ausfallsicherheit und Kosteneffizienz zu gewährleisten, benötigen Teams eine dynamische Routing-Schicht, die basierend auf Eingabeparametern automatisch auf Backup-Modelle ausweichen oder den Anbieter wechseln kann.
In dieser Anleitung implementieren wir eine robuste, typsichere Multi-Provider-Routing-Schicht mit dem Vercel AI SDK und Zod.
Die Architektur von LLM-Resilienz
Eine robuste Routing-Schicht basiert auf drei Kernprinzipien:
- Sequentielle Ausfallsicherung (Failover): Schlägt der primäre Anbieter fehl, versucht das System die Anfrage automatisch über einen sekundären Anbieter erneut.
- Dynamische Auswahl: Kurze Prompts werden an schnelle, kostengünstige Modelle gesendet, während größere Eingaben an Modelle mit hohem Kontextfenster geleitet werden.
- Typsichere Validierung: Unabhängig davon, welches Modell die Anfrage verarbeitet, bleibt das Ausgabeschema identisch und validiert.
+-------------------+
| Incoming Request |
+-------------------+
|
v
+-----------------------+
| Dynamic Route Selector|
+-----------------------+
/ \
(Short Input) (Long Input)
/ \
v v
+-----------------+ +-----------------+
| Primary Model | | Primary Model |
| (OpenAI Luna) | | (Gemini-3.1-Pro)|
+-----------------+ +-----------------+
| |
(On Failure) (On Failure)
v v
+-----------------+ +-----------------+
| Fallback Model | | Fallback Model |
| (Gemini-3.5-Fl) | | (Claude-Sonnet5)|
+-----------------+ +-----------------+
\ /
\ /
v v
+-------------------------+
| Zod Schema Validation |
+-------------------------+
|
v
+-------------------+
| Validated Output |
+-------------------+Implementierung von Fallbacks mit dem Vercel AI SDK
Das Vercel AI SDK bietet einen integrierten fallback-Wrapper, mit dem Sie eine priorisierte Liste von Modellen definieren können. Schlägt ein Aufruf des ersten Modells fehl, versucht das SDK den Aufruf automatisch mit den nachfolgenden Modellen im Array.
So initialisieren Sie ein robustes Modell mit Backup-Anbietern:
import { fallback } from 'ai';
import { openai } from '@ai-sdk/openai';
import { google } from '@ai-sdk/google';
import { anthropic } from '@ai-sdk/anthropic';
// Initialize a resilient model that crosses three distinct providers
export const resilientModel = fallback([
openai('terra'),
anthropic('claude-sonnet-5'),
google('gemini-3.1-pro')
]);Wenn Sie generateText oder generateObject mit resilientModel aufrufen, übernimmt das SDK automatisch die Fehlerbehandlung, Timeouts und Wiederholungsversuche.
Lokale Fallbacks mit Ollama
Für die Offline-Verfügbarkeit, hybride Umgebungen oder eine kostenlose Ausführung während lokaler Tests können Sie lokal gehostete Modelle über Ollama integrieren. Das Vercel AI SDK behandelt Ollama-Modelle als erstklassige Anbieter, sodass Sie direkt von Cloud-APIs auf lokale Hardware (lokales Silizium) wechseln können.
So konfigurieren Sie einen hybriden Cloud-to-Local-Fallback:
import { fallback } from 'ai';
import { openai } from '@ai-sdk/openai';
import { ollama } from '@ai-sdk/ollama';
// Fallback to a locally hosted Llama 4 Scout model if the OpenAI API is unreachable
export const hybridModel = fallback([
openai('luna'),
ollama('llama4-scout')
]);Typsichere Extraktion strukturierter Daten
Eine der Herausforderungen beim Routing über mehrere Anbieter besteht darin, sicherzustellen, dass verschiedene Modelle genau dieselbe Ausgabestruktur einhalten. Die Verwendung von Zod with the generateObject-API löst dieses Problem.
Legen wir ein Schema fest, um strukturierte Metadaten aus unstrukturierten Entwicklerprofilen zu extrahieren:
import { generateObject } from 'ai';
import { z } from 'zod';
import { resilientModel } from './models';
const ProfileSchema = z.object({
fullName: z.string(),
skills: z.array(z.string()),
yearsOfExperience: z.number(),
certifications: z.array(
z.object({
name: z.string(),
issuer: z.string()
})
)
});
export async function extractProfile(text: string) {
try {
const { object } = await generateObject({
model: resilientModel,
schema: ProfileSchema,
prompt: `Extract structured profile details from the following resume text:\n\n${text}`
});
return object;
} catch (error) {
console.error('Failed to extract profile after exhausting all fallbacks:', error);
throw new Error('Profile extraction failed');
}
}Da die Ausgabe zur Laufzeit von Zod analysiert und validiert wird, kann Ihr Anwendungscode der zurückgegebenen Struktur vertrauen – unabhängig davon, welches Modell in der Fallback-Kette erfolgreich war.
Dynamisches Routing basierend auf der Kontextgröße
Sequentielle Fallbacks schützen zwar vor Totalausfällen, optimieren jedoch weder Kosten noch Token-Limits. Es ist beispielsweise kein Problem, ein Dokument mit 100.000 Tokens an ein Modell mit einem Limit von 128.000 Tokens zu senden. Der Versuch, dasselbe Dokument an ein Modell mit einem Limit von 16.000 Tokens zu schicken, führt jedoch sofort zu einem Fehler.
Wir können einen dynamischen Router bauen, der die Eingabegröße prüft, bevor er die passende Modellkette auswählt:
import { LanguageModel, generateText } from 'ai';
import { openai } from '@ai-sdk/openai';
import { google } from '@ai-sdk/google';
import { anthropic } from '@ai-sdk/anthropic';
// Define specialized model chains
const standardChain = fallback([
openai('luna'),
google('gemini-3.5-flash')
]);
const highContextChain = fallback([
google('gemini-3.1-pro'),
anthropic('claude-sonnet-5')
]);
// Estimate token count (simple word-count approximation for demo)
function estimateTokens(text: string): number {
return text.trim().split(/\s+/).length * 1.3;
}
export async function smartRouteRequest(promptText: string) {
const tokenEstimate = estimateTokens(promptText);
// Route to the appropriate chain based on input size
const model = tokenEstimate > 50000 ? highContextChain : standardChain;
return generateText({
model,
prompt: promptText
});
}Dieses Muster hält die Kosten niedrig, indem Standardaufgaben an günstige, schnelle Modelle geleitet werden, während Premium-Modelle mit größeren Kontextfenstern für rechenintensive Payloads reserviert bleiben.
Telemetrie und Observability
Um zu überwachen, wie oft Ihre Routing-Schicht auf Fallback-Modelle ausweicht, können Sie die experimentellen Telemetrie-Funktionen des Vercel AI SDK nutzen. Diese erfassen Metriken zu Token-Nutzung, Latenz und den Erfolgsraten der Anbieter:
import { generateText } from 'ai';
import { resilientModel } from './models';
const response = await generateText({
model: resilientModel,
prompt: 'Analyze this log output...',
experimental_telemetry: {
isEnabled: true,
functionId: 'analyze-logs',
metadata: {
environment: 'production'
}
}
});Diese Traces werden in standardmäßigen OpenTelemetry-Kollektoren zusammengeführt, sodass Ihr Team vollen Einblick in Ausfallsicherungen und die Stabilität der Anbieter erhält.
Fazit und Kompromisse
Eine Routing-Schicht über mehrere Anbieter hinweg erhöht die Zuverlässigkeit erheblich. Dennoch sollten folgende Aspekte berücksichtigt werden:
- Stilistische Unterschiede: Fallback-Modelle können andere Schreibstile, Formatierungsnuancen oder Compliance-Eigenschaften aufweisen.
- Kaltstarts: Das erneute Ausführen einer fehlgeschlagenen Anfrage auf einem Sekundärmodell erhöht die Latenz für den Benutzer.
- API-Schlüssel der Anbieter: Ihre Infrastruktur muss API-Schlüssel, Ratenbegrenzungsstufen und Abrechnungskonten für mehrere Anbieter verwalten.
Durch die Nutzung der vereinheitlichten APIs des Vercel AI SDK können Sie eine hochgradig robuste Routing-Architektur erstellen, die Ihre Produktionsanwendungen vor Ausfällen einzelner Anbieter schützt.