ms-ai-architect/skills/ms-ai-advisor/references/prompt-engineering/real-time-reasoning-performance.md

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):

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):

{
  "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 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.

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 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 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 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 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.
6. ⚠️ 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).