Bouwen van een veerkrachtige multi-provider AI-routinglaag met Vercel AI SDK
Een praktische handleiding voor het bouwen van een productie-grade LLM-routinglaag met automatische failover, back-upmodellen en gestructureerde Zod-outputs met Vercel AI SDK.

Bij het uitrollen van Large Language Models (LLMs) in productie is betrouwbaarheid vaak het grootste knelpunt. Vertrouwen op één enkele modelprovider brengt risico's met zich mee van een single-point-of-failure: API-snelheidslimieten (HTTP 429), tijdelijke uitval van services (HTTP 500/503) of plotselinge latentiepieken.
Om uptime en kostenefficiëntie te garanderen, hebben teams een dynamic routinglaag nodig die automatisch kan overschakelen naar back-upmodellen of van provider kan wisselen op basis van invoerparameters.
In deze handleiding implementeren we een veerkrachtige, type-safe multi-provider routinglaag met behulp van de Vercel AI SDK und Zod.
De architectuur van LLM-veerkracht
Een veerkrachtige routinglaag werkt op basis van drie kernprincipen:
- Sequentiële failovers: Als de primaire provider faalt, probeert het systeem de aanvraag automatisch opnieuw met een secundaire provider.
- Dynamische selectie: Korte prompts gaan naar snelle, goedkope modellen, terwijl grotere invoer naar modellen met een hoge context wordt geleid.
- Type-safe validatie: Ongeacht welk model de aanvraag afhandelt, het uitvoerschema blijft identiek en gevalideerd.
+-------------------+
| 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 |
+-------------------+Fallbacks implementeren met Vercel AI SDK
De Vercel AI SDK biedt een ingebouwde fallback-wrapper waarmee u een geprioriteerde lijst met modellen kunt specificeren. Als een aanroep naar het eerste model faalt, probeert de SDK het automatisch opnieuw met de volgende modellen in de array.
Hier leest u hoe u een veerkrachtig model met back-upproviders initialiseert:
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')
]);Wanneer u generateText of generateObject aanroept met resilientModel, handelt de SDK automatisch fouten, time-outs en nieuwe pogingen af.
Lokale fallbacks met Ollama
Voor offline beschikbaarheid, hybride omgevingen of kosteloze uitvoering tijdens lokale tests, kunt u lokaal gehoste modellen via Ollama integreren. De Vercel AI SDK behandelt Ollama-modellen als eersteklas providers, waardoor u direct kunt overstappen van cloud-API's naar lokale hardware (lokaal silicium).
Hier leest u hoe u een hybride cloud-naar-lokaal fallback configureert:
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')
]);Type-Safe gestructureerde gegevensextractie
Een van de uitdagingen van routing tussen meerdere providers is ervoor te zorgen dat verschillende modellen zich aan exact dezelfde uitvoerstructuur houden. Het gebruik van Zod met de generateObject-API lost dit op.
Laten we een schema definiëren om gestructureerde metadata te extraheren uit onbewerkte ontwikkelaarsprofielen:
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');
}
}Omdat de uitvoer tijdens runtime door Zod wordt geparseerd en gevalideerd, kan uw applicatiecode vol vertrouwen vertrouwen op de geretourneerde structuur, ongeacht welk model in de fallback-keten is geslaagd.
Dynamische routing op basis van contextgrootte
Hoewel sequentiële fallbacks beschermen tegen volledige downtime, optimiseren ze de kosten of tokenlimieten niet. Het verzenden van een document van 100.000 tokens naar een model met een limiet van 128.000 tokens is bijvoorbeeld prima, maar het verzenden naar een model met een limiet van 16.000 tokens zal onmiddellijk een fout veroorzaken.
We kunnen een dynamische router bouwen die de invoergrootte inspecteert voordat de modelketen wordt gekozen:
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
});
}Dit patroon houdt de kosten laag door standaardtaken naar goedkope, snelle modellen te leiden, terwijl premiummodellen met grotere contextvensters worden gereserveerd voor zware payloads.
Telemetrie en observatie
Om te monitoren hoe vaak uw routinglaag fallback-modellen activeert, kunt u gebruikmaken van de experimentele telemetriefuncties van de Vercel AI SDK. Dit verzamelt statistieken over tokengebruik, latentie en succespercentages van providers:
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'
}
}
});Deze traces worden verzameld in standaard OpenTelemetry-collectors, waardoor uw team volledig inzicht krijgt in failovers en de gezondheid van providers.
Conclusie en afwegingen
Een multi-provider routinglaag verhoogt de betrouwbaarheid. Het is echter belangrijk om de afwegingen te overwegen:
- Stijlverschillen: Back-upmodellen kunnen verschillende schrijfstijlen, opmaaknuances of nalevingskenmerken vertonen.
- Koude starts: Het opnieuw proberen van een mislukte aanvraag met een secundair model voegt latentie toe aan de gebruikerservaring.
- API-sleutels van providers: Uw infrastructuur moet API-sleutels, limietniveaus en factureringsaccounts voor meerdere providers configureren en onderhouden.
Door de geünificeerde API-interfaces van de Vercel AI SDK te gebruiken, kunt u een uiterst veerkrachtige routingarchitectuur bouwen die uw productieapplicaties beschermt tegen uitval van individuele providers.