# Real-Time Reasoning and Performance Optimization

**Last updated:** 2026-04 | Verified: MCP 2026-04
**Status:** GA (Realtime API: Public Preview)
**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 januar 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` (2025-12-15)

**Deployment regions:** East US 2, Sweden Central (global deployments).

**API version:** `2025-04-01-preview`

**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:** Middels (⚠️) — Realtime API er fortsatt i public preview (per januar 2026). Produksjonsbruk krever 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

### Azure AI 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 API regions (per januar 2026):** East US 2, Sweden Central.

**Konsekvens:**
- **Sweden Central:** EU-region, bedre for GDPR-compliance (men fortsatt USA-eid selskap).
- **East US 2:** USA-region, kan kreve DPIA for offentlig sektor.

**Anbefaling:** Vurder Sweden Central for norsk offentlig sektor hvis Realtime API er kritisk. For standard completions, bruk Norway East (GPT-4o/GPT-4o mini tilgjengelig der).

### 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 data residency-krav og kan ikke bruke East US 2 / Sweden Central.
- 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:** Public preview, ikke SLA.
- **Data residency:** Sweden Central er EU-region (bedre enn USA).
- **Anbefaling:** Pilot i ikke-kritiske tjenester først. Vent på GA for produksjonsbruk i kritiske systemer.

**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/ai-foundry/openai/how-to/latency](https://learn.microsoft.com/en-us/azure/ai-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/ai-foundry/openai/how-to/realtime-audio](https://learn.microsoft.com/en-us/azure/ai-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/ai-foundry/openai/realtime-audio-quickstart](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/realtime-audio-quickstart)
   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-4o-mini-realtime-preview` og `gpt-4o-realtime-preview` er tilgjengelige i East US 2 / Sweden Central.
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 og production-readiness av Realtime API (public preview).
