Per-kilde verifiserings-agenter (Opus xhigh, live microsoft_docs_fetch) bekreftet hver verdi mot kilden FOER endring; alle forekomster av samme gale fakta fikset fil-vidt (ikke bare sitert linje). - 37/38 confirm-fix anvendt; #8 (model-selection «Model Router GA») AVVIST: fila var allerede korrekt (Model Router GA siden 2025-11-18); den siterte model-choice-guide har utdatert «(preview)»-etikett. AA «fikse» ville innfoert en feil. - Tverteklynger reconciled til kilde-sann verdi: AI Search storage (S1 160/S2 512/S3 1024/L1 2048/L2 4096 GB; vektor 5/35/150/300), Quota Tiers (erstatter Default/Enterprise + «1 Unit Capacity»). - Hoey-innsats: realtime Schrems II omskrevet (global deployment != EU-residens, selv-verifisert mot kilde); Data Zone Norway East = gpt-5.4 OG gpt-5.5 (ikke kun 5.5); computer-use = gpt-5.4 + computer-tool (region flagget for verifisering). - Suite 552/552 groenn. Manifest oppdatert (fixed/verdict/verified per fiks). Spor 1-froe (cross-fil-gjentakelser i UBEROERTE filer): «DDoS Protection Standard» i ros-ai-threat-library.md + zero-trust-ai-services.md. Tilstoetende funn (ikke i de 38): se docs / STATE.
513 lines
23 KiB
Markdown
513 lines
23 KiB
Markdown
# Real-Time Reasoning and Performance Optimization
|
||
|
||
**Last updated:** 2026-06-24 | Verified: MCP 2026-06
|
||
**Status:** GA (`gpt-realtime` og `gpt-realtime-1.5` er GA-modeller; «preview»-suffikset gjelder nå kun de eldre `gpt-4o-realtime-preview`-modellene)
|
||
**Category:** Prompt Engineering & LLM Optimization
|
||
|
||
---
|
||
|
||
## Introduksjon
|
||
|
||
Real-time reasoning og performance optimization handler om å minimere latency og maksimere throughput i Azure OpenAI-løsninger — spesielt for interaktive applikasjoner som chatbots, stemmeassistenter og live-oversettelse. For Microsoft AI-stakken er dette kritisk for å levere responsiv brukeropplevelse samtidig som man optimaliserer kostnad og ressursbruk.
|
||
|
||
Denne filen dekker:
|
||
- **Latency vs throughput** — to grunnleggende konsepter for sizing
|
||
- **Streaming** — hvordan perceivd latency påvirkes av token-levering
|
||
- **Realtime API** — low-latency "speech in, speech out" for GPT-4o modeller
|
||
- **Token-optimalisering** — `max_tokens`, stop sequences, batching
|
||
- **Content filtering trade-offs** — sikkerhet vs ytelse
|
||
- **Workload separation** — hvordan man unngår cache-konkurranse
|
||
- **Måling og monitoring** — Azure Monitor metrics for TPM, RPM, TTFT
|
||
|
||
**Konfidensmarkering:** Høy (✅) — basert på offisiell Microsoft-dokumentasjon fra januar 2026, med særlig fokus på GPT-4o Realtime API og latency optimization-guider.
|
||
|
||
---
|
||
|
||
## Kjernekomponenter
|
||
|
||
| Komponent | Beskrivelse | Use case |
|
||
|-----------|-------------|----------|
|
||
| **Latency (per-call)** | Tid fra request sendes til svar mottas. Påvirkes av modell, prompt size, generation size, system load. | Chatbots, conversational interfaces |
|
||
| **Throughput (system-level)** | Tokens per minute (TPM) og requests per minute (RPM) som deployment håndterer. | Batch-prosessering, high-volume workloads |
|
||
| **Streaming** | Tokens returneres inkrementelt (`stream: true`) i stedet for å vente på full respons. Reduserer time-to-first-token (TTFT). | Forbedret perceivd latency for sluttbrukere |
|
||
| **Realtime API** | WebRTC/WebSocket/SIP-basert API for GPT-4o modeller. Low-latency audio-in/audio-out for sanntidssamtaler. | Stemmeassistenter, kundesupport, live-oversettelse |
|
||
| **Voice Activity Detection (VAD)** | Server-side eller semantic VAD for å detektere slutten på tale. Styrer når modellen starter respons-generering. | Push-to-talk apps, automatisk turn-taking |
|
||
| **Content filtering** | Azure OpenAI content filters kjører på både prompt og completion. Øker safety, men også latency. | Risk-basert: deaktiver for low-risk bruksområder |
|
||
| **Workload separation** | Separate deployments per workload-type. Unngår batching av korte/lange calls sammen, bedre cache hit rate. | Sentiment analysis (bulk) vs chatbot (real-time) |
|
||
|
||
### Latency-påvirkere (rangert)
|
||
|
||
1. **Generation size (max_tokens)** — største påvirkning. `n tokens = n iterations`.
|
||
2. **Model selection** — GPT-4o mini har lavest latency (anbefalt for latency-kritiske apps).
|
||
3. **Prompt size** — mindre påvirkning enn generation size, men øker med stor prompt.
|
||
4. **Content filtering** — øker latency for både input og output.
|
||
5. **System load** — deployment utilization påvirker responstid.
|
||
|
||
---
|
||
|
||
## Arkitekturmønstre
|
||
|
||
### 1. Streaming for Perceivd Latency Reduction
|
||
|
||
**Pattern:** Aktiver `stream: true` for chat completions.
|
||
|
||
**Fordeler:**
|
||
- **Time-to-first-token (TTFT)** reduseres drastisk. Brukere ser respons umiddelbart.
|
||
- **Timeout-håndtering** — lange calls unngår client-side timeout.
|
||
- **Brukeropplevelse** — føles raskere selv om total tid er lik.
|
||
|
||
**Når bruke:**
|
||
- Chatbots, conversational interfaces.
|
||
- Generative UI (text appears as typed).
|
||
|
||
**Når *ikke* bruke:**
|
||
- Sentiment analysis, batch translation (kun sluttresultat teller).
|
||
|
||
**Kode-eksempel (Python):**
|
||
|
||
```python
|
||
from openai import OpenAI
|
||
from azure.identity import DefaultAzureCredential, get_bearer_token_provider
|
||
|
||
token_provider = get_bearer_token_provider(
|
||
DefaultAzureCredential(), "https://cognitiveservices.azure.com/.default"
|
||
)
|
||
|
||
client = OpenAI(
|
||
base_url = "https://YOUR-RESOURCE-NAME.openai.azure.com/openai/v1/",
|
||
api_key=token_provider,
|
||
)
|
||
|
||
completion = client.chat.completions.create(
|
||
model="gpt-4o-mini",
|
||
messages=[
|
||
{"role": "system", "content": "You are a helpful assistant."},
|
||
{"role": "user", "content": "Explain quantum computing briefly."}
|
||
],
|
||
stream=True
|
||
)
|
||
|
||
for chunk in completion:
|
||
if chunk.choices and chunk.choices[0].delta.content is not None:
|
||
print(chunk.choices[0].delta.content, end='')
|
||
```
|
||
|
||
**Metrics å måle:**
|
||
- **Time to Response** (TTFT) — tid til første token i streaming-modus.
|
||
- **Average Token Generation Rate** — (siste token - første token) / antall tokens.
|
||
|
||
---
|
||
|
||
### 2. Realtime API for Low-Latency Audio
|
||
|
||
**Pattern:** Bruk GPT Realtime API via WebRTC (foretrukket) eller WebSocket for "speech in, speech out".
|
||
|
||
**Modeller (per juni 2026):**
|
||
- `gpt-4o-realtime-preview` (2024-12-17)
|
||
- `gpt-4o-mini-realtime-preview` (2024-12-17)
|
||
- `gpt-realtime` (2025-08-28)
|
||
- `gpt-realtime-mini` (2025-10-06)
|
||
- `gpt-realtime-mini` (2025-12-15)
|
||
- `gpt-realtime-1.5` (2026-02-23)
|
||
|
||
**Deployment:** Tilgjengelig for global deployments (ikke begrenset til East US 2 / Sweden Central; verifisert mot Microsoft Learn 2026-06).
|
||
|
||
**API-endepunkt:** Bruk GA-endepunktet med `/openai/v1` i URL-en. Realtime API bruker **ikke** lenger date-baserte `api-version`-verdier; eldre preview-endepunkter (`/openai/realtimeapi/sessions`) er erstattet av GA-stiene `/openai/v1/realtime/...`.
|
||
|
||
**Bruksområder:**
|
||
- Customer support agents med voice
|
||
- Real-time translators
|
||
- Voice assistants (Alexa-lignende)
|
||
|
||
**Arkitektur:**
|
||
|
||
```
|
||
[Client (browser/mobile)]
|
||
↕ WebRTC/WebSocket
|
||
[Azure OpenAI Realtime API endpoint]
|
||
↕
|
||
[GPT-4o model med audio modality]
|
||
```
|
||
|
||
**Session configuration (WebSocket):**
|
||
|
||
```json
|
||
{
|
||
"type": "session.update",
|
||
"session": {
|
||
"voice": "alloy",
|
||
"input_audio_transcription": {
|
||
"model": "whisper-1"
|
||
},
|
||
"turn_detection": {
|
||
"type": "server_vad",
|
||
"threshold": 0.5,
|
||
"prefix_padding_ms": 300,
|
||
"silence_duration_ms": 200,
|
||
"create_response": true
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
**VAD-modes:**
|
||
- **`server_vad`** — server detekterer silence, auto-committer audio buffer, starter respons.
|
||
- **`semantic_vad`** — detekterer når bruker er ferdig basert på *semantikk* (mindre sannsynlig å avbryte).
|
||
- **`none`** — push-to-talk. Client sender `input_audio_buffer.commit` manuelt.
|
||
|
||
**Fordel med semantic_vad:**
|
||
- Mindre sannsynlig å "chunke" transkripsjon før bruker er ferdig.
|
||
- Bedre for speech-to-speech samtaler (venter på naturlig pause).
|
||
|
||
**Konfidensmarkering:** Høy (✅) — Realtime API bruker GA-endepunktet, og GA-modellene `gpt-realtime` / `gpt-realtime-1.5` er tilgjengelige (kun de eldre `gpt-4o-realtime-preview`-modellene er preview). Produksjonsbruk krever fortsatt risikovurdering.
|
||
|
||
---
|
||
|
||
### 3. Token Optimization
|
||
|
||
**Pattern:** Minimer `max_tokens` og bruk stop sequences.
|
||
|
||
**Implementering:**
|
||
|
||
| Teknikk | Effekt | Eksempel |
|
||
|---------|--------|----------|
|
||
| **Sett `max_tokens` så lavt som mulig** | Reduserer reservert compute-tid. Færre iterasjoner. | `max_tokens=150` for kort svar |
|
||
| **Bruk stop sequences** | Forhindrer generering av ekstra innhold. | `stop=["\n\n", "###"]` |
|
||
| **Generer færre responses** | `best_of` og `n` > 1 øker latency dramatisk. | Sett `n=1` (default) |
|
||
|
||
**Viktig:** `max_tokens` påvirker *kun* lengde, ikke kvalitet. Ikke sett lavere enn nødvendig for oppgaven.
|
||
|
||
**Kostnadseffekt:** Færre output tokens = lavere kostnad (output tokens er dyrere enn input tokens).
|
||
|
||
---
|
||
|
||
### 4. Content Filtering Trade-Offs
|
||
|
||
**Pattern:** Evaluer om workload har lavt nok risiko til å deaktivere content filters.
|
||
|
||
**Default:** Azure OpenAI kjører content filters på både prompt og completion (ensemble av klassifiseringsmodeller).
|
||
|
||
**Trade-off:**
|
||
- **Med filters:** Høyere sikkerhet, men økt latency.
|
||
- **Uten filters:** Lavere latency, men risiko for skadelig innhold.
|
||
|
||
**Når vurdere deaktivering:**
|
||
- Internt verktøy (ikke eksponert for sluttbrukere).
|
||
- Pre-moderert innhold (input allerede validert).
|
||
- Non-public-facing applikasjoner.
|
||
|
||
**Prosess:** Søk om modifisert content filtering policy via Azure Portal.
|
||
|
||
**Konfidensmarkering:** Høy (✅) — men krever business decision om risiko.
|
||
|
||
---
|
||
|
||
### 5. Workload Separation
|
||
|
||
**Pattern:** Separate deployments per workload-type (short vs long completions).
|
||
|
||
**Problem:**
|
||
- Mixing kort sentiment analysis (10 tokens output) med long-form content generation (500 tokens) på samme deployment:
|
||
- Batching: Korte calls venter på lange.
|
||
- Cache hit rate reduseres (konkurranse om cache space).
|
||
|
||
**Løsning:**
|
||
|
||
```
|
||
Deployment A: Sentiment analysis (kort prompt, kort output)
|
||
Deployment B: Content generation (medium prompt, lang output)
|
||
Deployment C: Chatbot (variabel prompt, medium output)
|
||
```
|
||
|
||
**Fordeler:**
|
||
- Bedre latency for korte calls.
|
||
- Høyere cache hit rate (liknende prompts groupes sammen).
|
||
- Lettere å måle per-workload performance.
|
||
|
||
---
|
||
|
||
### 6. Batching (når relevant)
|
||
|
||
**Pattern:** Batch multiple requests i én API call (hvis API støtter det).
|
||
|
||
**Fordeler:**
|
||
- Reduserer antall HTTP requests.
|
||
- Kan forbedre total responstid (avhengig av scenario).
|
||
|
||
**Når bruke:**
|
||
- Bulk sentiment analysis (100+ tekster).
|
||
- Batch translation.
|
||
|
||
**Når *ikke* bruke:**
|
||
- Real-time chatbots (brukere forventer umiddelbar respons).
|
||
|
||
**Test først:** Effekten varierer. Bruk Azure Monitor for å sammenligne.
|
||
|
||
---
|
||
|
||
## Beslutningsveiledning
|
||
|
||
### Når bruke Streaming vs Realtime API vs Standard Completion
|
||
|
||
| Scenario | Anbefaling | Begrunnelse |
|
||
|----------|------------|-------------|
|
||
| **Text-based chatbot (web)** | Streaming (`stream: true`) | TTFT < 1s, god brukeropplevelse, enkelt å implementere |
|
||
| **Voice assistant (speech in/out)** | Realtime API (WebRTC) | Low-latency audio processing, VAD, native audio modality |
|
||
| **Bulk sentiment analysis** | Standard completion (no streaming) | Kun sluttresultat teller, latency ikke kritisk |
|
||
| **Live translation (text)** | Streaming | Inkrementell visning av oversettelse |
|
||
| **Customer support (voice)** | Realtime API (WebRTC/SIP) | Speech-to-speech, sub-second latency kritisk |
|
||
| **Content generation (blog posts)** | Standard completion | Lang output, bruker venter uansett |
|
||
|
||
### Modellvalg for Latency
|
||
|
||
| Bruksområde | Modell | Latency | Kvalitet |
|
||
|-------------|--------|---------|----------|
|
||
| **Lavest latency** | GPT-4o mini | ⚡ Raskest | God for de fleste use cases |
|
||
| **Balansert** | GPT-4o | ⚡⚡ Middels | Høy kvalitet |
|
||
| **Høyest kvalitet** | GPT-4 Turbo | ⚡⚡⚡ Tregere | Best reasoning |
|
||
|
||
**Anbefaling:** Start med GPT-4o mini for latency-kritiske apps. Oppgrader til GPT-4o/GPT-4 Turbo kun hvis kvalitet er utilstrekkelig.
|
||
|
||
### Deployment Type: Standard vs Provisioned (PTU)
|
||
|
||
| Metric | Standard | Provisioned (PTU) |
|
||
|--------|----------|-------------------|
|
||
| **Throughput** | Bestemt av quota (TPM) | Bestemt av PTU-count (forutsigbar kapasitet) |
|
||
| **Latency** | Variabel (avhenger av load) | Mer stabil (dedikert kapasitet) |
|
||
| **Kostnad** | Pay-per-token | Upfront reservation (time-basert) |
|
||
| **Bruksområde** | Variable workloads | High-volume, forutsigbar trafikk |
|
||
|
||
**Throughput-estimat (GPT-4o mini):**
|
||
|
||
| Prompt | Generation | RPM | Input TPM | Output TPM | Total TPM | PTUs |
|
||
|--------|------------|-----|-----------|------------|-----------|------|
|
||
| 800 | 150 | 30 | 24,000 | 4,500 | 28,500 | 15 |
|
||
| 5,000 | 50 | 1,000 | 5M | 50K | 5.05M | 140 |
|
||
| 1,000 | 300 | 500 | 500K | 150K | 650K | 30 |
|
||
|
||
**Kilde:** Azure OpenAI latency-dokumentasjon (januar 2026).
|
||
|
||
---
|
||
|
||
## Integrasjon med Microsoft-stakken
|
||
|
||
### Microsoft Foundry
|
||
|
||
**Realtime Audio Playground:**
|
||
- Deploy `gpt-4o-mini-realtime-preview` i Foundry.
|
||
- Gå til **Playgrounds > Audio playground** (ikke Chat playground).
|
||
- Test VAD settings (threshold, silence duration, prefix padding).
|
||
- Eksporter konfigurasjon til kode.
|
||
|
||
**Monitoring:**
|
||
- **Azure Monitor metrics:**
|
||
- `Processed Prompt Tokens` (input TPM)
|
||
- `Generated Completion Tokens` (output TPM)
|
||
- `Azure OpenAI Requests` (RPM, split by `ModelDeploymentName`)
|
||
- **Latency metrics:**
|
||
- **Non-streaming:** End-to-end Request Time
|
||
- **Streaming:** Time to Response (TTFT), Average Token Generation Rate
|
||
|
||
### Azure Speech Service (TTS Latency)
|
||
|
||
**Teknikker for å redusere speech synthesis latency (Verified MCP 2026-04):**
|
||
|
||
| Teknikk | Effekt |
|
||
|---------|--------|
|
||
| **Streaming (AudioDataStream)** | Start avspilling ved første audio-chunk; ikke vent på komplett audio |
|
||
| **Pre-connect** | Åpne WebSocket-forbindelsen proaktivt mens bruker snakker; kall `SpeakTextAsync` når svar er klart |
|
||
| **Gjenbruk SpeechSynthesizer** | Unngå ny TCP/SSL/HTTP-handshake per request; bruk object pool |
|
||
| **Komprimert lyd** | MP3 (48kbps) vs PCM (384kbps) — 87% lavere nettverkspayload for mobil/ustabile nettverk |
|
||
| **Text streaming (WebSocket v2)** | Send GPT-output til TTS chunk for chunk via `wss://{region}.tts.speech.microsoft.com/cognitiveservices/websocket/v2`. Ideelt for real-time AI-dialoger. |
|
||
|
||
**Latency-metrikker fra Speech SDK:**
|
||
- `first byte client latency` — fra syntese starter til første audio-chunk mottas (inkl. nettverks-RTT)
|
||
- `finish client latency` — fra syntese starter til all lyd er mottatt
|
||
- `first byte service latency` — behandlingstid på Azure TTS-siden
|
||
|
||
**Anbefaling:** For sanntids AI-dialoger (GPT + TTS), kombiner Realtime API (audio in/out) med Speech SDK text streaming for hybrid norsk/engelsk-løsninger.
|
||
|
||
### Copilot Studio
|
||
|
||
**Relevans:** Copilot Studio kan integrere Azure OpenAI custom models via Power Platform connectors.
|
||
|
||
**Optimalisering:**
|
||
- Bruk streaming for Copilot chat-grensesnitt (bedre UX).
|
||
- Separate deployments for Copilot (FAQ-bots) vs generative AI (long-form content).
|
||
|
||
### Power Automate + Azure OpenAI
|
||
|
||
**Pattern:** Batch-prosessering av dokumenter/epost via Power Automate.
|
||
|
||
**Tips:**
|
||
- Bruk standard completion (ikke streaming) for bulk operations.
|
||
- Implementer retry-logic for rate limit errors (429).
|
||
- Overvåk TPM via Azure Monitor, juster quota ved behov.
|
||
|
||
### Microsoft Agent Framework
|
||
|
||
**Relevans:** Agent Framework kan bruke Realtime API for multi-modal agents (voice + text).
|
||
|
||
**Anbefaling:** Bruk WebRTC-transport for client-side apps, WebSocket for server-to-server.
|
||
|
||
---
|
||
|
||
## Offentlig sektor (Norge)
|
||
|
||
### Personvern og Latency Trade-Offs
|
||
|
||
**Utfordring:** Content filtering kan detektere PII (personally identifiable information). Deaktivering av filters for ytelse kan kompromittere personvern.
|
||
|
||
**Løsning:**
|
||
- **Ikke deaktiver content filters** for public-facing tjenester (NAV, Skatteetaten).
|
||
- Bruk **server-side pre-processing** for å fjerne PII før Azure OpenAI call (reduserer latency-påvirkning).
|
||
- Implementer **caching** av frequent queries (Redis, Azure Cache for Redis).
|
||
|
||
### Schrems II og Data Residency
|
||
|
||
**Realtime-modellenes deployment (verifisert mot Microsoft Learn 2026-06):** GPT realtime-modeller tilbys som **global deployments** («The GPT real-time models are available for global deployments»). De er altså ikke begrenset til East US 2 / Sweden Central, men global deployment innebærer at inferens kan rutes til Azure-kapasitet utenfor EU.
|
||
|
||
**Konsekvens:**
|
||
- **Global deployment gir ikke EU-dataresidens i seg selv** — data kan behandles utenfor EU/EØS. For norsk offentlig sektor utløser dette en Schrems II-/overføringsvurdering (TIA) og som regel DPIA.
|
||
- Den tidligere antakelsen om å «pinne» realtime til Sweden Central for EU-residens holder ikke for en global deployment. Sjekk audio-modellenes deployment-type/region i [region-availability-kilden](https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure-region-availability) før en residens-konklusjon trekkes.
|
||
|
||
**Anbefaling:** Avklar faktisk dataresidens for de spesifikke realtime-modellene mot region-availability-kilden FØR produksjonsbruk i offentlig sektor; behandle realtime som global deployment i risikovurderingen. For standard completions er regionale deployments (f.eks. Norway East, GPT-4o/GPT-4o mini) tilgjengelig.
|
||
|
||
### Accessibility (Universell Utforming)
|
||
|
||
**Realtime API voice output:**
|
||
- **Positive:** Voice assistants kan gjøre tjenester mer tilgjengelige for synshemmede/dysleksi.
|
||
- **Utfordring:** Stemme-kvalitet og norsk aksent (Realtime API støtter multilingual voices, men ikke norsk-spesifikk).
|
||
|
||
**Løsning:** Kombiner Realtime API (engelsk) med Azure Speech Service (norsk TTS) for hybrid approach.
|
||
|
||
---
|
||
|
||
## Kostnad og lisensiering
|
||
|
||
### Realtime API Pricing (GPT-4o models)
|
||
|
||
**Audio tokens vs text tokens:**
|
||
- **Audio input:** Dyrere enn text input (encoding overhead).
|
||
- **Audio output:** Dyrere enn text output.
|
||
|
||
**Eksempel (GPT-4o-realtime-preview, per januar 2026):**
|
||
- Input text tokens: $2.50 / 1M tokens
|
||
- Output text tokens: $10.00 / 1M tokens
|
||
- Input audio tokens: $100.00 / 1M tokens
|
||
- Output audio tokens: $200.00 / 1M tokens
|
||
|
||
**Konfidensmarkering:** Middels (⚠️) — priser kan endre seg. Sjekk [Azure OpenAI pricing page](https://azure.microsoft.com/en-us/pricing/details/cognitive-services/openai-service/).
|
||
|
||
**Kostnad-optimalisering:**
|
||
- **Bruk GPT-4o mini Realtime** for lavere cost (per token).
|
||
- **Minimer audio tokens:** Bruk text input hvor mulig, kun audio output ved behov.
|
||
- **Implementer VAD-tuning:** Reduser "silence padding" for å unngå unødvendige audio tokens.
|
||
|
||
### Latency vs Kostnad Trade-Off
|
||
|
||
| Optimalisering | Latency | Kostnad | Kompleksitet |
|
||
|----------------|---------|---------|--------------|
|
||
| **Streaming** | ✅ Bedre TTFT | ➖ Ingen endring | Lav |
|
||
| **GPT-4o mini** | ✅ Raskest | ✅ 80% billigere enn GPT-4 Turbo | Lav |
|
||
| **Deaktiver content filters** | ✅ 10-20% raskere | ➖ Ingen endring | Middels (krever policy request) |
|
||
| **Provisioned (PTU)** | ✅ Mer stabil | ⚠️ Høyere upfront (men kan være billigere ved høy volume) | Høy (capacity planning) |
|
||
| **Workload separation** | ✅ Bedre for korte calls | ➖ Ingen direkte kostnad, men krever flere deployments | Middels |
|
||
|
||
---
|
||
|
||
## For arkitekten (Cosmo)
|
||
|
||
### Når anbefale Realtime API
|
||
|
||
**✅ Anbefal hvis:**
|
||
- Klient trenger "speech in, speech out" (voice assistants, customer support).
|
||
- Latency < 500ms er kritisk (conversational feel).
|
||
- Budsjettet tillater høyere kostnad for audio tokens.
|
||
|
||
**❌ Ikke anbefal hvis:**
|
||
- Kun text-basert chatbot (bruk standard streaming i stedet).
|
||
- Klient har strenge dataresidens-krav som global deployment ikke oppfyller (realtime tilbys som global deployment — se Schrems II-seksjonen).
|
||
- Budsjett er begrenset (audio tokens er 10-40x dyrere enn text).
|
||
|
||
### Typiske Spørsmål fra Klienter
|
||
|
||
**Q: "Hvordan redusere latency i chatbot uten å øke kostnad?"**
|
||
|
||
**A:**
|
||
1. Aktiver streaming (`stream: true`) — ingen kostnad, stor UX-forbedring.
|
||
2. Sett `max_tokens` lavest mulig for use case.
|
||
3. Bruk GPT-4o mini i stedet for GPT-4 Turbo.
|
||
4. Separate deployments for ulike workloads (unngå batching av korte/lange calls).
|
||
|
||
**Q: "Er Realtime API production-ready for offentlig sektor?"**
|
||
|
||
**A (per januar 2026):**
|
||
- **Teknisk:** GA-endepunkt og GA-modeller (`gpt-realtime`, `gpt-realtime-1.5`); kun de eldre `gpt-4o-realtime-preview`-modellene er preview.
|
||
- **Data residency:** Realtime tilbys som global deployment — avklar faktisk dataresidens mot region-availability-kilden før produksjon (se Schrems II-seksjonen).
|
||
- **Anbefaling:** Risikovurdering og DPIA før produksjonsbruk i offentlig sektor; pilot i ikke-kritiske tjenester først.
|
||
|
||
**Q: "Hvordan måle om streaming faktisk hjelper?"**
|
||
|
||
**A:**
|
||
- Mål **Time to First Token (TTFT)** i Azure Monitor.
|
||
- Før streaming: TTFT ≈ total request time.
|
||
- Etter streaming: TTFT < 1s (typisk), total time uendret.
|
||
- Brukeropplevelse: A/B-test med faktiske brukere.
|
||
|
||
### Arkitektur Checklist: Latency Optimization
|
||
|
||
- [ ] **Modellvalg:** GPT-4o mini for latency-kritiske apps?
|
||
- [ ] **Streaming aktivert** for text-basert chat?
|
||
- [ ] **Realtime API** vurdert for voice use cases?
|
||
- [ ] **VAD-modus** valgt (server_vad vs semantic_vad vs none)?
|
||
- [ ] **`max_tokens`** satt til minimum nødvendig?
|
||
- [ ] **Stop sequences** implementert?
|
||
- [ ] **Content filtering** evaluert (trade-off sikkerhet vs ytelse)?
|
||
- [ ] **Workload separation:** Separate deployments for ulike use cases?
|
||
- [ ] **Azure Monitor alerts** konfigurert for TPM, RPM, latency?
|
||
- [ ] **Deployment type:** Standard vs Provisioned (PTU) vurdert?
|
||
- [ ] **Caching-strategi** for frequent queries?
|
||
|
||
### Vanlige Anti-Patterns
|
||
|
||
❌ **"Vi bruker GPT-4 Turbo for chatbot fordi kvalitet"** → Start med GPT-4o mini, oppgrader kun hvis kvalitet er utilstrekkelig.
|
||
|
||
❌ **"Vi setter `max_tokens=4096` som default"** → Unødvendig latency. Sett lavere (150-300 for chat, 50 for FAQ).
|
||
|
||
❌ **"Vi blander sentiment analysis og content generation på samme deployment"** → Workload separation reduserer latency for begge.
|
||
|
||
❌ **"Vi bruker Realtime API for text-only chatbot"** → Overkill. Bruk standard streaming i stedet.
|
||
|
||
---
|
||
|
||
## Kilder og verifisering
|
||
|
||
**Primary sources:**
|
||
|
||
1. **Performance and latency** (Azure OpenAI)
|
||
[https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/latency)
|
||
Hentet: januar 2026. Dekker streaming, max_tokens, content filtering, workload separation, metrics.
|
||
|
||
2. **GPT Realtime API for speech and audio**
|
||
[https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/realtime-audio](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/realtime-audio)
|
||
Hentet: januar 2026. Dekker WebRTC/WebSocket, VAD modes, session configuration, supported models.
|
||
|
||
3. **GPT-4o Realtime API quickstart**
|
||
[https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/realtime-audio](https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/realtime-audio)
|
||
Hentet: januar 2026. Kode-eksempler for Python, JavaScript, deployment steps.
|
||
|
||
4. **Lower speech synthesis latency using Speech SDK** (Re-verified MCP 2026-04)
|
||
[https://learn.microsoft.com/en-us/azure/ai-services/speech-service/how-to-lower-speech-synthesis-latency](https://learn.microsoft.com/en-us/azure/ai-services/speech-service/how-to-lower-speech-synthesis-latency)
|
||
Hentet: januar 2026, re-verified april 2026. Dekker: first byte latency vs finish latency, streaming via AudioDataStream, pre-connect og SpeechSynthesizer-gjenbruk (object pool), komprimert lyd (MP3 48kbps vs PCM 384kbps), text streaming via WebSocket v2 (wss endpoint) for real-time GPT-output vocalization.
|
||
|
||
**Verification steps:**
|
||
|
||
1. ✅ **Streaming impact:** Bekreftet at `stream: true` reduserer TTFT men ikke total tid (dokumentasjon + code samples).
|
||
2. ✅ **Realtime API models:** Bekreftet at GPT realtime-modeller tilbys for global deployments (ikke begrenset til East US 2 / Sweden Central); GA-modeller `gpt-realtime` / `gpt-realtime-1.5` i tillegg til eldre `gpt-4o-realtime-preview`.
|
||
3. ✅ **VAD modes:** Bekreftet at `server_vad`, `semantic_vad`, og `none` er supported turn detection types.
|
||
4. ✅ **Latency metrics:** Bekreftet at Time to Response (TTFT) og Average Token Generation Rate er recommended metrics for streaming.
|
||
5. ✅ **Speech latency:** first byte client latency og AudioDataStream-streaming bekreftet. Text streaming via WebSocket v2 bekreftet for C#, Python.
|
||
5. ⚠️ **Pricing:** Audio token pricing ikke eksplisitt i dokumentasjon per januar 2026. Brukt representative estimates basert på historisk OpenAI pricing structure.
|
||
|
||
**Confidence level:** Høy (✅) for tekniske detaljer, Middels (⚠️) for pricing. Realtime API bruker GA-endepunkt/GA-modeller (ikke lenger public preview).
|