feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,509 @@
|
|||
# Circuit Breaker Patterns for AI Models
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** API Management & AI Gateway
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Circuit breaker-mønsteret er en grunnleggende resiliensmekanisme for AI-applikasjoner som kommuniserer med Azure OpenAI og andre LLM-backends. Når en backend-tjeneste blir overbelastet eller utilgjengelig, forhindrer circuit breaker at applikasjonen fortsetter å sende forespørsler som uansett vil feile. I stedet "bryter kretsen" og returnerer en feilmelding umiddelbart, slik at backend-tjenesten får tid til å gjenopprette seg.
|
||||
|
||||
For Azure AI-tjenester er circuit breaker spesielt viktig fordi Azure OpenAI returnerer 429 (Too Many Requests) med en `Retry-After`-header som kan ha verdier opp til 24 timer. Uten circuit breaker vil applikasjoner fortsette å hamre på en throttlet tjeneste, noe som forverrer situasjonen og kaster bort gateway-ressurser. APIMsintegrerte circuit breaker håndterer dette automatisk ved å respektere `Retry-After`-headeren.
|
||||
|
||||
I kombinasjon med backend pools og lastbalansering utgjør circuit breaker selve nervesystemet i en intelligent AI-gateway: den detekterer problemer, isolerer feilende backends, ruter trafikk til friske alternativer, og gjenoppretter normal drift automatisk når backend er tilbake.
|
||||
|
||||
---
|
||||
|
||||
## Circuit Breaker State Machine
|
||||
|
||||
### Tre tilstander
|
||||
|
||||
Circuit breaker opererer som en tilstandsmaskin med tre tilstander:
|
||||
|
||||
```
|
||||
Feil > threshold
|
||||
┌─────────┐ ───────────────► ┌──────────┐
|
||||
│ CLOSED │ │ OPEN │
|
||||
│ (normal)│ ◄────────────── │ (trip) │
|
||||
└─────────┘ Alle OK i └──────────┘
|
||||
│ half-open │
|
||||
│ │ Trip duration
|
||||
│ │ utløpt
|
||||
│ ┌──────────────┐ │
|
||||
│ │ HALF-OPEN │◄───┘
|
||||
│ │ (test) │
|
||||
│ └──────────────┘
|
||||
│ │
|
||||
│ Suksess │ Feil
|
||||
◄──────────────┘───────────► OPEN
|
||||
```
|
||||
|
||||
| Tilstand | Oppførsel | Varighet |
|
||||
|----------|-----------|----------|
|
||||
| **Closed** | Normal drift, alle requests videresendes til backend | Ubegrenset (til feilbetingelse oppstår) |
|
||||
| **Open** | Alle requests avvises umiddelbart med 503 | Trip duration (konfigurerbar, eller fra Retry-After) |
|
||||
| **Half-Open** | Et begrenset antall test-requests sendes til backend | Til nok suksesser ELLER ny feil |
|
||||
|
||||
### APIM-spesifikk oppførsel
|
||||
|
||||
APIMcircuit breaker har noen viktige forskjeller fra den generelle circuit breaker-mønsteret:
|
||||
|
||||
| Egenskap | APIM Circuit Breaker |
|
||||
|----------|---------------------|
|
||||
| **Konfigurasjons-scope** | Per backend (ikke per API eller policy) |
|
||||
| **Antall regler** | Kun én regel per backend (p.t.) |
|
||||
| **Synkronisering** | Ingen mellom gateway-instanser (approksimasjon) |
|
||||
| **Retry-After respekt** | Ja, dynamisk trip duration basert på backend-respons |
|
||||
| **Støttede tiers** | Alle unntatt Consumption |
|
||||
| **Respons ved Open** | 503 Service Unavailable |
|
||||
|
||||
---
|
||||
|
||||
## Konfigurasjon
|
||||
|
||||
### Grunnleggende circuit breaker for Azure OpenAI
|
||||
|
||||
```bicep
|
||||
resource openaiBackend 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
|
||||
parent: apim
|
||||
name: 'openai-norwayeast'
|
||||
properties: {
|
||||
url: 'https://aoai-norwayeast.openai.azure.com/openai'
|
||||
protocol: 'http'
|
||||
circuitBreaker: {
|
||||
rules: [
|
||||
{
|
||||
name: 'ai-resilience-rule'
|
||||
failureCondition: {
|
||||
count: 3
|
||||
interval: 'PT1M'
|
||||
statusCodeRanges: [
|
||||
{ min: 429, max: 429 }
|
||||
{ min: 500, max: 599 }
|
||||
]
|
||||
}
|
||||
tripDuration: 'PT10S'
|
||||
acceptRetryAfter: true
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Attributter forklart
|
||||
|
||||
| Attributt | Type | Beskrivelse | Anbefalt verdi for AI |
|
||||
|-----------|------|-------------|----------------------|
|
||||
| `failureCondition.count` | int | Antall feil som trigger trip | 3-5 |
|
||||
| `failureCondition.interval` | duration | Tidsvindu for feil-telling | PT1M (1 minutt) |
|
||||
| `failureCondition.statusCodeRanges` | array | HTTP-koder som teller som feil | 429 + 500-599 |
|
||||
| `tripDuration` | duration | Hvor lenge circuit er åpent | PT10S - PT1M |
|
||||
| `acceptRetryAfter` | bool | Bruk Retry-After header som trip duration | **true** (alltid for AI) |
|
||||
|
||||
### Prosentbasert vs. count-basert triggering
|
||||
|
||||
APIM støtter to modeller for feil-deteksjon:
|
||||
|
||||
**Count-basert (anbefalt for AI):**
|
||||
```json
|
||||
{
|
||||
"failureCondition": {
|
||||
"count": 3,
|
||||
"interval": "PT1M",
|
||||
"statusCodeRanges": [{"min": 429, "max": 429}]
|
||||
}
|
||||
}
|
||||
```
|
||||
Trigger: 3 eller flere 429-responser innen 1 minutt.
|
||||
|
||||
**Prosentbasert:**
|
||||
```json
|
||||
{
|
||||
"failureCondition": {
|
||||
"percentage": 50,
|
||||
"interval": "PT1M",
|
||||
"statusCodeRanges": [{"min": 429, "max": 429}]
|
||||
}
|
||||
}
|
||||
```
|
||||
Trigger: 50% eller mer av requests feiler innen 1 minutt.
|
||||
|
||||
**Anbefaling:** Count-basert er mer forutsigbar for AI-workloads. Prosentbasert kan gi falske positiver ved lav trafikk (2 av 3 requests feiler = 66%).
|
||||
|
||||
---
|
||||
|
||||
## Failure Threshold Tuning
|
||||
|
||||
### Faktorene som påvirker threshold
|
||||
|
||||
| Faktor | Lav threshold (1-2) | Høy threshold (5-10) |
|
||||
|--------|---------------------|---------------------|
|
||||
| **Reaksjonstid** | Rask, reagerer umiddelbart | Tregere, tolererer noen feil |
|
||||
| **Falske positiver** | Høy risiko | Lav risiko |
|
||||
| **Backend-beskyttelse** | Sterk, minimal ekstra belastning | Svakere, flere feil-requests |
|
||||
| **Anbefalt for** | Kritiske, kapasitetsbegrensede backends | Robuste backends med transiente feil |
|
||||
|
||||
### Anbefalte innstillinger per scenario
|
||||
|
||||
| Scenario | count | interval | tripDuration | acceptRetryAfter |
|
||||
|----------|-------|----------|--------------|-----------------|
|
||||
| **PTU-instans (high priority)** | 3 | PT1M | PT10S | true |
|
||||
| **PAYGO-instans (fallback)** | 5 | PT2M | PT30S | true |
|
||||
| **Dev/test** | 2 | PT30S | PT5S | true |
|
||||
| **Business-critical** | 3 | PT1M | PT10S | true |
|
||||
| **Batch processing** | 10 | PT5M | PT1M | true |
|
||||
|
||||
### Dynamisk trip duration med Retry-After
|
||||
|
||||
Når `acceptRetryAfter: true` er satt, overstyrer Azure OpenAIs `Retry-After`-header den konfigurerte `tripDuration`:
|
||||
|
||||
```
|
||||
Scenario: OpenAI returnerer 429 med Retry-After: 30
|
||||
→ Circuit breaker åpner i 30 sekunder (ikke konfiguert tripDuration)
|
||||
→ Etter 30 sekunder: half-open → test request
|
||||
→ Suksess: circuit lukkes
|
||||
→ Feil: circuit åpner igjen med ny Retry-After
|
||||
|
||||
Scenario: OpenAI returnerer 429 med Retry-After: 86400 (1 dag!)
|
||||
→ Circuit breaker åpner i 24 timer
|
||||
→ All trafikk rutes til andre backends i poolen
|
||||
```
|
||||
|
||||
> **Viktig advarsel:** Azure OpenAI kan returnere Retry-After verdier opp til 1 dag (86400 sekunder). Med `acceptRetryAfter: true` vil dette bety at backend er utilgjengelig i 24 timer. Sørg for at backend-poolen har nok kapasitet i andre backends til å håndtere dette.
|
||||
|
||||
---
|
||||
|
||||
## Fallback-policies
|
||||
|
||||
### Mønster 1: Backend Pool med automatisk failover
|
||||
|
||||
Den enkleste og mest robuste tilnærmingen:
|
||||
|
||||
```xml
|
||||
<policies>
|
||||
<inbound>
|
||||
<!-- Backend pool håndterer failover automatisk -->
|
||||
<set-backend-service backend-id="openai-pool-priority" />
|
||||
<authentication-managed-identity
|
||||
resource="https://cognitiveservices.azure.com/" />
|
||||
</inbound>
|
||||
</policies>
|
||||
```
|
||||
|
||||
Når circuit breaker utløses på Priority 1-backends, ruter APIM automatisk til Priority 2, osv.
|
||||
|
||||
### Mønster 2: Retry med backend-bytte
|
||||
|
||||
Eksplisitt retry-logikk som bytter backend ved 429:
|
||||
|
||||
```xml
|
||||
<policies>
|
||||
<backend>
|
||||
<retry condition="@(context.Response.StatusCode == 429)"
|
||||
count="3"
|
||||
interval="0"
|
||||
first-fast-retry="true">
|
||||
<set-backend-service backend-id="openai-pool-priority" />
|
||||
</retry>
|
||||
</backend>
|
||||
</policies>
|
||||
```
|
||||
|
||||
**Viktig:** `interval="0"` betyr umiddelbar retry til neste backend, IKKE ventetid. Server-side retries bør aldri ha delay — det holder opp klienten og bruker gateway-ressurser.
|
||||
|
||||
### Mønster 3: Graceful Degradation med cache-fallback
|
||||
|
||||
```xml
|
||||
<policies>
|
||||
<inbound>
|
||||
<!-- Prøv semantic cache først -->
|
||||
<azure-openai-semantic-cache-lookup
|
||||
score-threshold="0.20"
|
||||
embeddings-backend-id="embeddings-backend"
|
||||
embeddings-backend-auth="system-assigned" />
|
||||
|
||||
<set-backend-service backend-id="openai-pool-priority" />
|
||||
</inbound>
|
||||
|
||||
<on-error>
|
||||
<choose>
|
||||
<!-- Alle backends utilgjengelige -->
|
||||
<when condition="@(context.Response.StatusCode == 503)">
|
||||
<return-response>
|
||||
<set-status code="503" reason="AI Service Temporarily Unavailable" />
|
||||
<set-header name="Retry-After" exists-action="override">
|
||||
<value>60</value>
|
||||
</set-header>
|
||||
<set-body>@{
|
||||
return new JObject(
|
||||
new JProperty("error", new JObject(
|
||||
new JProperty("code", "service_unavailable"),
|
||||
new JProperty("message", "AI-tjenesten er midlertidig utilgjengelig. Prøv igjen om 60 sekunder."),
|
||||
new JProperty("type", "circuit_breaker_open")
|
||||
))
|
||||
).ToString();
|
||||
}</set-body>
|
||||
</return-response>
|
||||
</when>
|
||||
</choose>
|
||||
</on-error>
|
||||
</policies>
|
||||
```
|
||||
|
||||
### Mønster 4: Fallback til enklere modell
|
||||
|
||||
```xml
|
||||
<policies>
|
||||
<backend>
|
||||
<retry condition="@(context.Response.StatusCode == 429 || context.Response.StatusCode == 503)"
|
||||
count="1"
|
||||
interval="0"
|
||||
first-fast-retry="true">
|
||||
<!-- Fallback til mindre modell -->
|
||||
<set-backend-service backend-id="openai-gpt4o-mini-backend" />
|
||||
<rewrite-uri template="/deployments/gpt-4o-mini/chat/completions" />
|
||||
</retry>
|
||||
</backend>
|
||||
</policies>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Recovery-mekanismer
|
||||
|
||||
### Automatisk recovery
|
||||
|
||||
Circuit breaker håndterer recovery automatisk:
|
||||
|
||||
```
|
||||
1. Trip: Circuit åpner (503 til klienter)
|
||||
2. Wait: tripDuration utløper (eller Retry-After)
|
||||
3. Half-Open: Test-request sendes til backend
|
||||
4. Success: Circuit lukkes, normal drift gjenopptas
|
||||
5. Failure: Circuit åpner igjen, ny tripDuration starter
|
||||
```
|
||||
|
||||
### Recovery-timing
|
||||
|
||||
| Kilde | Prioritet | Typisk verdi |
|
||||
|-------|-----------|--------------|
|
||||
| `Retry-After` header (når `acceptRetryAfter: true`) | Høyest | 1-86400 sekunder |
|
||||
| Konfigurert `tripDuration` | Fallback | PT10S - PT1M |
|
||||
| Default (uten konfigurasjon) | Lavest | PT1M |
|
||||
|
||||
### Overvåking av circuit breaker-tilstand
|
||||
|
||||
```xml
|
||||
<outbound>
|
||||
<!-- Log circuit breaker state -->
|
||||
<trace source="circuit-breaker" severity="information">
|
||||
<message>@{
|
||||
var backendId = context.Backend?.Id ?? "unknown";
|
||||
var statusCode = context.Response.StatusCode;
|
||||
return $"Backend: {backendId}, Status: {statusCode}";
|
||||
}</message>
|
||||
</trace>
|
||||
</outbound>
|
||||
```
|
||||
|
||||
**KQL for circuit breaker-hendelser:**
|
||||
|
||||
```kusto
|
||||
ApiManagementGatewayLogs
|
||||
| where ResponseCode == 503
|
||||
| extend backendId = tostring(parse_json(BackendResponseBody).backendId)
|
||||
| summarize CircuitBreakerTrips = count() by backendId, bin(TimeGenerated, 5m)
|
||||
| render timechart
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Timeout-konfigurasjon
|
||||
|
||||
### Forward-request timeout
|
||||
|
||||
Kontroller hvor lenge APIM venter på backend-respons:
|
||||
|
||||
```xml
|
||||
<policies>
|
||||
<backend>
|
||||
<forward-request timeout="120" />
|
||||
</backend>
|
||||
</policies>
|
||||
```
|
||||
|
||||
**Anbefalte timeouts for AI-workloads:**
|
||||
|
||||
| Operasjon | Anbefalt timeout | Begrunnelse |
|
||||
|-----------|------------------|-------------|
|
||||
| Chat Completion (standard) | 60-120 sek | GPT-4o kan bruke tid på komplekse prompts |
|
||||
| Chat Completion (streaming) | 120-180 sek | Streaming starter raskt, men kan vare lenge |
|
||||
| Embeddings | 30-60 sek | Raskere operasjon, typisk < 10 sek |
|
||||
| Image Generation (DALL-E) | 120-180 sek | Bildegenerering er CPU-intensivt |
|
||||
| Assistants API | 180-300 sek | Multi-step agent workflows |
|
||||
| Batch API | 300-600 sek | Store batch-operasjoner |
|
||||
|
||||
### Timeout + Circuit Breaker interaksjon
|
||||
|
||||
```
|
||||
Timeout utløper (120 sek)
|
||||
→ APIM registrerer det som feil
|
||||
→ Teller mot circuit breaker threshold
|
||||
→ Etter N timeouts → Circuit breaker trip
|
||||
→ Backend fjernes fra pool → Trafikk til alternativer
|
||||
```
|
||||
|
||||
> **Best practice:** Sett timeout lavere enn det du tror er nødvendig. Bedre å få rask feil og retry til annen backend enn å vente 120 sekunder på en hengende request.
|
||||
|
||||
---
|
||||
|
||||
## Avanserte mønstre
|
||||
|
||||
### Mønster: Cascading Circuit Breakers
|
||||
|
||||
For multi-tier arkitekturer der APIM ruter til mellomtjenester som igjen kaller Azure OpenAI:
|
||||
|
||||
```
|
||||
Client → APIM [CB-1] → Custom Service [CB-2] → Azure OpenAI
|
||||
```
|
||||
|
||||
```bicep
|
||||
// CB-1: APIM → Custom Service
|
||||
resource customServiceBackend 'Microsoft.ApiManagement/service/backends@2023-09-01-preview' = {
|
||||
properties: {
|
||||
circuitBreaker: {
|
||||
rules: [{
|
||||
failureCondition: {
|
||||
count: 5
|
||||
interval: 'PT2M'
|
||||
statusCodeRanges: [
|
||||
{ min: 502, max: 504 }
|
||||
]
|
||||
}
|
||||
tripDuration: 'PT30S'
|
||||
}]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Applikasjons-nivå CB-2 implementeres med Polly (.NET), resilience4j (Java), eller tilsvarende.
|
||||
|
||||
### Mønster: Health Endpoint Monitoring
|
||||
|
||||
Kombiner circuit breaker med aktiv health checking:
|
||||
|
||||
```xml
|
||||
<policies>
|
||||
<inbound>
|
||||
<!-- Sjekk health endpoint før ruting -->
|
||||
<send-request mode="new"
|
||||
response-variable-name="healthCheck"
|
||||
timeout="5"
|
||||
ignore-error="true">
|
||||
<set-url>@("https://aoai-norwayeast.openai.azure.com/openai/models?api-version=2024-10-21")</set-url>
|
||||
<set-method>GET</set-method>
|
||||
<authentication-managed-identity
|
||||
resource="https://cognitiveservices.azure.com/" />
|
||||
</send-request>
|
||||
|
||||
<choose>
|
||||
<when condition="@(((IResponse)context.Variables["healthCheck"]).StatusCode != 200)">
|
||||
<!-- Backend er nede, bruk fallback direkte -->
|
||||
<set-backend-service backend-id="openai-fallback-pool" />
|
||||
</when>
|
||||
<otherwise>
|
||||
<set-backend-service backend-id="openai-primary-pool" />
|
||||
</otherwise>
|
||||
</choose>
|
||||
</inbound>
|
||||
</policies>
|
||||
```
|
||||
|
||||
> **Merk:** Health endpoint monitoring legger til latens og backend-belastning. Bruk det kun for scenarier der circuit breaker alene ikke gir rask nok failover.
|
||||
|
||||
---
|
||||
|
||||
## Anti-mønstre
|
||||
|
||||
| Anti-mønster | Problem | Løsning |
|
||||
|--------------|---------|---------|
|
||||
| **Ingen circuit breaker** | Backend overbelastes, cascading failure | Aktiver circuit breaker på alle AI-backends |
|
||||
| **For lav threshold (count=1)** | Falske positiver ved transiente feil | Bruk count=3-5 for produksjon |
|
||||
| **For lang tripDuration** | Backend er unødvendig utilgjengelig | Bruk `acceptRetryAfter: true` |
|
||||
| **Ignorere Retry-After** | Hammer backend som eksplisitt ber om pause | Sett `acceptRetryAfter: true` alltid |
|
||||
| **Server-side delay** | Retry med sleep/delay holder opp klienter | Bruk `interval="0"` med backend pool failover |
|
||||
| **Timeout for lang** | Gateway-ressurser brukt opp på hengende requests | Sett realistiske timeouts per operasjonstype |
|
||||
| **Mangle monitoring** | Ingen innsikt i circuit breaker-oppførsel | Emit metrikk + KQL dashboards |
|
||||
|
||||
---
|
||||
|
||||
## Komplett resiliens-policy
|
||||
|
||||
```xml
|
||||
<policies>
|
||||
<inbound>
|
||||
<!-- 1. Token rate limiting -->
|
||||
<llm-token-limit
|
||||
counter-key="@(context.Subscription.Id)"
|
||||
tokens-per-minute="50000"
|
||||
estimate-prompt-tokens="true" />
|
||||
|
||||
<!-- 2. Backend pool med circuit breaker -->
|
||||
<set-backend-service backend-id="openai-pool-priority" />
|
||||
|
||||
<!-- 3. Managed Identity auth -->
|
||||
<authentication-managed-identity
|
||||
resource="https://cognitiveservices.azure.com/" />
|
||||
</inbound>
|
||||
|
||||
<backend>
|
||||
<!-- 4. Retry til annen backend ved 429 -->
|
||||
<retry condition="@(context.Response.StatusCode == 429)"
|
||||
count="3"
|
||||
interval="0"
|
||||
first-fast-retry="true">
|
||||
<set-backend-service backend-id="openai-pool-priority" />
|
||||
</retry>
|
||||
|
||||
<!-- 5. Timeout -->
|
||||
<forward-request timeout="120" />
|
||||
</backend>
|
||||
|
||||
<outbound>
|
||||
<!-- 6. Token metrikk -->
|
||||
<llm-emit-token-metric namespace="ai-gateway">
|
||||
<dimension name="Backend" value="@(context.Backend?.Id ?? "unknown")" />
|
||||
<dimension name="StatusCode" value="@(context.Response.StatusCode.ToString())" />
|
||||
</llm-emit-token-metric>
|
||||
</outbound>
|
||||
|
||||
<on-error>
|
||||
<!-- 7. Graceful degradation -->
|
||||
<choose>
|
||||
<when condition="@(context.Response.StatusCode == 503)">
|
||||
<return-response>
|
||||
<set-status code="503" reason="AI Service Unavailable" />
|
||||
<set-header name="Retry-After" exists-action="override">
|
||||
<value>60</value>
|
||||
</set-header>
|
||||
<set-body>{"error":{"code":"all_backends_unavailable","message":"Alle AI-backends er midlertidig utilgjengelige"}}</set-body>
|
||||
</return-response>
|
||||
</when>
|
||||
</choose>
|
||||
</on-error>
|
||||
</policies>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## For Cosmo
|
||||
|
||||
- Circuit breaker er obligatorisk for alle Azure OpenAI backends i produksjon -- uten det risikerer du cascading failures og bortkastet gateway-kapasitet mot throttlede backends.
|
||||
- Sett ALLTID `acceptRetryAfter: true` for Azure OpenAI backends. Azure OpenAI returnerer presise Retry-After verdier som gir optimal recovery-timing. Uten dette bruker du den statiske tripDuration som kan være for kort eller for lang.
|
||||
- Anbefalt baseline: `count: 3`, `interval: PT1M`, `tripDuration: PT10S`, `acceptRetryAfter: true`. Juster count opp for PAYGO-backends med mer toleranse.
|
||||
- Kombiner circuit breaker med backend pools for automatisk failover: når PTU-backend tripper, ruter APIM automatisk til PAYGO-backends uten klient-endringer.
|
||||
- Advarsler: Azure OpenAI kan returnere Retry-After opp til 86400 sekunder (1 dag). Sørg for at arkitekturen har nok alternative backends til å håndtere langvarige circuit breaks.
|
||||
Loading…
Add table
Add a link
Reference in a new issue