ms-ai-architect/skills/ms-ai-security/references/performance-scalability/latency-optimization-azure-openai.md

Latency Optimization for Azure OpenAI

Last updated: 2026-02 Status: GA Category: Performance & Scalability Type: reference

---

Innhold

• Introduksjon
• Forstaelse av latenskomponenter
• Request Pipeline-optimalisering
• Connection Pooling og gjenbruk
• Regional endepunktsvalg
• Time-to-First-Token-reduksjon
• Provisioned Throughput Units (PTU) for forutsigbar latens
• Overvaking og malinger
• Sjekkliste for latensoptimalisering
• For Cosmo

Introduksjon

Latens er en av de mest kritiske ytelsesparameterne for AI-applikasjoner i produksjon. For norsk offentlig sektor, der innbyggertjenester krever rask respons og interne saksbehandlingssystemer må operere effektivt, er optimalisering av Azure OpenAI-latens avgjorende. Høy latens kan direkte påvirke brukeropplevelsen og redusere adopsjonen av AI-drevne tjenester.

Azure OpenAI-latens bestemmes av flere faktorer: modellvalg, prompt-storrelse, genereringsstorrelse, nettverksavstand til endepunktet, og hvordan applikasjonen er konfigurert. Forstaelse av disse faktorene og systematisk optimalisering av hver komponent er nodvendig for a oppna akseptabel ytelse i produksjonsmiljoer.

Denne referansen dekker de viktigste teknikkene for a redusere latens i Azure OpenAI-baserte applikasjoner, fra request pipeline-optimalisering til regional endepunktsplassering, med spesielt fokus pa norske deployments i North Europe og Sweden Central-regionene.

Forstaelse av latenskomponenter

Request Pipeline Breakdown

En Azure OpenAI-request traverserer flere stadier, og hvert stadium bidrar til total latens:

Stadium	Beskrivelse	Typisk latens
DNS-oppslag	Resolusjon av Azure OpenAI-endepunkt	1-50 ms
TLS-handshake	Sikker forbindelse etableres	20-100 ms
Nettverkstransport	Data sendes til Azure-regionen	5-200 ms
Token-prosessering (input)	Prompt-tokens prosesseres	Varierer med storrelse
Token-generering (output)	Completion-tokens genereres sekvensielt	Storste latensbidraget
Content filtering	Sikkerhetsfiltrering av input/output	10-50 ms
Responstransport	Svar sendes tilbake til klient	5-200 ms

Latensmetrikker

For effektiv maling av latens bor du spore disse metrikkene:

For non-streaming requests:

• End-to-end Request Time: Total tid fra request sendt til komplett respons mottatt.

For streaming requests:

• Time to First Token (TTFT): Tid fra request sendt til forste token mottatt. Oker med prompt-storrelse.
• Average Token Generation Rate: Tid fra forste token til siste token, delt pa antall genererte tokens. Oker med systembelastning.

import time
from openai import AzureOpenAI

client = AzureOpenAI(
    azure_endpoint="https://your-resource.openai.azure.com/",
    api_key="your-api-key",
    api_version="2025-03-01-preview"
)

# Mal TTFT og total latens
start_time = time.perf_counter()
first_token_time = None

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hva er personopplysningsloven?"}],
    stream=True,
    max_tokens=200
)

for chunk in response:
    if first_token_time is None and chunk.choices[0].delta.content:
        first_token_time = time.perf_counter()
        ttft = first_token_time - start_time
        print(f"Time to First Token: {ttft:.3f}s")

total_time = time.perf_counter() - start_time
print(f"Total latens: {total_time:.3f}s")

Request Pipeline-optimalisering

Modellvalg for lav latens

Modellvalg har direkte innvirkning pa latens. For identiske requests varierer latens betydelig mellom modeller:

Modell	Relativ latens	Anbefalt bruk
GPT-4o mini	Lavest	Enkel klassifisering, rask sortering, chatbots
GPT-4o	Moderat	Generelt formalsbruk, RAG-svar
GPT-4.1	Moderat-hoy	Kompleks resonnering, kodeanalyse
o3-mini	Hoy	Avansert resonnering med lavere tokenbruk

Anbefaling for norsk offentlig sektor: Bruk GPT-4o mini for innbyggertjenester som krever rask respons (chatbots, FAQ-svar). Reserver GPT-4o og storre modeller for saksbehandlingsstotte der kvalitet er viktigere enn hastighet.

Max Tokens-optimalisering

max_tokens-parameteren pavirker latens betydelig. Azure OpenAI reserverer beregningskapasitet basert pa denne verdien ved request-start:

# DARLIG: For hoy max_tokens oker latens selv om faktisk output er kort
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Svar ja eller nei: Er dette en klage?"}],
    max_tokens=4096  # Reserverer kapasitet for 4096 tokens
)

# BRA: Tilpass max_tokens til forventet output-lengde
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Svar ja eller nei: Er dette en klage?"}],
    max_tokens=10  # Reserverer kun nodvendig kapasitet
)

Tommelregel: Sett max_tokens til 1.5x forventet output-lengde. For klassifiseringsoppgaver: 10-50 tokens. For korte svar: 100-300 tokens. For lengre generering: tilpass etter behov.

Stop Sequences

Bruk stop-parameteren for a avslutte generering tidlig nar onskede data er produsert:

# Stopp sa snart klassifiseringen er ferdig
response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Klassifiser henvendelsen. Svar med kun: KLAGE, SPORSMAL, eller TILBAKEMELDING"},
        {"role": "user", "content": user_input}
    ],
    max_tokens=20,
    stop=["\n", "."]  # Stopp etter forste linje/setning
)

Separasjon av arbeidslaster

Blanding av ulike arbeidslaster pa samme endepunkt pavirker latens negativt:

1. Batch-interferens: Korte og lange requests batches sammen under inferens, sa korte kall ma vente pa lange completions.
2. Cache-konkurranise: Ulike arbeidslaster konkurrerer om prompt cache-plass.

Anbefalt arkitektur:

Innbyggerportal (chatbot)  --> Deployment: gpt-4o-mini-chat (Standard, hoy TPM)
Saksbehandling (analyse)   --> Deployment: gpt-4o-analyse (Standard, moderat TPM)
Dokumentgenerering         --> Deployment: gpt-4o-dokument (Standard, lav TPM)
Batchprosessering          --> Deployment: gpt-4o-batch (Global Batch)

Connection Pooling og gjenbruk

HTTP Connection Reuse

Opprettelse av nye HTTP-forbindelser for hver request legger til DNS-oppslag og TLS-handshake. Gjenbruk av forbindelser eliminerer dette:

from openai import AzureOpenAI
import httpx

# Opprett klient EN gang og gjenbruk
# Python SDK bruker httpx med connection pooling automatisk
client = AzureOpenAI(
    azure_endpoint="https://your-resource.openai.azure.com/",
    api_key="your-api-key",
    api_version="2025-03-01-preview",
    http_client=httpx.Client(
        limits=httpx.Limits(
            max_connections=100,         # Maks samtidige forbindelser
            max_keepalive_connections=20, # Hold forbindelser levende
            keepalive_expiry=30          # Sekunder for keepalive
        )
    )
)

# DARLIG: Ny klient per request
def process_request_bad(prompt):
    client = AzureOpenAI(...)  # Ny TLS-handshake hver gang
    return client.chat.completions.create(...)

# BRA: Gjenbruk eksisterende klient
def process_request_good(prompt):
    return client.chat.completions.create(  # Gjenbruker forbindelse
        model="gpt-4o",
        messages=[{"role": "user", "content": prompt}]
    )

Async Connection Pooling

For hoy-throughput applikasjoner, bruk async-klienten:

from openai import AsyncAzureOpenAI
import asyncio

async_client = AsyncAzureOpenAI(
    azure_endpoint="https://your-resource.openai.azure.com/",
    api_key="your-api-key",
    api_version="2025-03-01-preview"
)

async def process_batch(prompts: list[str]) -> list:
    """Prosesser flere requests parallelt med connection pooling."""
    tasks = [
        async_client.chat.completions.create(
            model="gpt-4o-mini",
            messages=[{"role": "user", "content": p}],
            max_tokens=200
        )
        for p in prompts
    ]
    return await asyncio.gather(*tasks)

# Kjor 10 requests parallelt
results = asyncio.run(process_batch(prompts[:10]))

Retry-strategi med eksponentiell backoff

Azure OpenAI SDK har innebygd retry-logikk for 429-feil (rate limiting):

from openai import AzureOpenAI

# Konfigurer retry-oppforsel
client = AzureOpenAI(
    azure_endpoint="https://your-resource.openai.azure.com/",
    api_key="your-api-key",
    api_version="2025-03-01-preview",
    max_retries=5,     # Standard: 2
    timeout=60.0       # Standard: 10 minutter
)

# For PTU-deployments: Respekter retry-after header
# SDK gjor dette automatisk, men du kan tilpasse:
client_no_retry = AzureOpenAI(
    azure_endpoint="https://your-resource.openai.azure.com/",
    api_key="your-api-key",
    api_version="2025-03-01-preview",
    max_retries=0  # Deaktiver for a handtere selv
)

Regional endepunktsvalg

Azure-regioner for Norge

For norsk offentlig sektor er datasuverenitet og latens begge kritiske:

Region	Latens fra Norge	Datasuverenitet	Tilgjengelige modeller
Sweden Central	~10-20 ms	EU/EOS	Alle GPT-4o-modeller, PTU
North Europe (Irland)	~30-50 ms	EU/EOS	De fleste modeller
West Europe (Nederland)	~25-40 ms	EU/EOS	De fleste modeller
UK South	~30-50 ms	Utenfor EOS	Begrenset relevans

Anbefaling: Sweden Central som primaerregion for lavest latens og EU-datasuverenitet. North Europe som sekundaerregion for failover.

Multi-region arkitektur med prioritet

For a oppna bade lav latens og hoy tilgjengelighet:

# Prioritetsbasert lastbalansering med Azure API Management
# APIM-policy for smart routing:

<!-- Azure API Management policy for multi-region routing -->
<policies>
    <inbound>
        <set-variable name="primary-backend"
            value="https://aoai-sweden-central.openai.azure.com/" />
        <set-variable name="fallback-backend"
            value="https://aoai-north-europe.openai.azure.com/" />
    </inbound>
    <backend>
        <retry condition="@(context.Response.StatusCode == 429)"
               count="1"
               interval="0">
            <set-backend-service base-url="@((string)context.Variables["fallback-backend"])" />
            <forward-request buffer-response="false" />
        </retry>
    </backend>
</policies>

Global vs. Regional Deployment Types

Deployment Type	Databehandling	Latens	Bruksomrade
Regional Standard	Kun i valgt region	Lavest	Produksjon, compliance-kritisk
Data Zone Standard	Innenfor EU/US-sone	Lav	Generelt, fleksibel kapasitet
Global Standard	Enhver Azure-region	Variabel	Hoy throughput, tolererer variasjon
Regional PTU	Kun i valgt region	Lavest og mest forutsigbar	Misjonskritisk, stabile laster

Time-to-First-Token-reduksjon

Prompt Caching

Azure OpenAI prompt caching reduserer latens og kostnad for requests med identisk prefix:

# Prompt caching aktiveres automatisk for stottede modeller
# Krav: Minimum 1024 tokens, identisk prefix

# System prompt som gjenbrukes pa tvers av requests
SYSTEM_PROMPT = """Du er en saksbehandlingsassistent for Direktoratet for digital tjenesteutvikling.
Du hjelper med a analysere og klassifisere innkommende henvendelser
relatert til forerkort, kjoretoysregistrering og veiprosjekter.

Folg disse retningslinjene:
1. Klassifiser henvendelsen i riktig kategori
2. Identifiser relevante lovhjemler
3. Foresla videre behandling
... (lang systemprompt over 1024 tokens)
"""

# Forste request: Ingen caching (cold start)
response1 = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},
        {"role": "user", "content": "Henvendelse 1..."}
    ]
)
# usage.prompt_tokens_details.cached_tokens = 0

# Etterfølgende requests: Caching aktiv (redusert latens)
response2 = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": SYSTEM_PROMPT},  # Identisk prefix
        {"role": "user", "content": "Henvendelse 2..."}
    ]
)
# usage.prompt_tokens_details.cached_tokens = 1024+

Viktige regler for prompt caching:

• Minimum 1024 tokens i prompten
• De forste 1024 tokenene ma vaere identiske
• Etter forste 1024: cache hit for hver 128 identiske tokens
• Cache ryddes etter 5-10 minutter uten aktivitet, alltid innen 1 time
• Cacher deles IKKE mellom Azure-abonnementer
• Stottede modeller: GPT-4o, GPT-4o mini, o3-mini, GPT-4.1 og nyere

Prompt-optimalisering for hastighet

Teknikk	Beskrivelse	Latensreduksjon
Kompakt systemprompt	Fjern unodvendig tekst i systemprompt	5-15%
Strukturerte input	JSON fremfor fritekst	5-10%
Relevant kontekst	Kun relevante dokumenter i RAG	10-30%
Token-effektive formater	Korte variabelnavn, kompakt format	3-8%

# DARLIG: Verbose prompt
messages = [
    {"role": "system", "content": """
    Du er en hjelpesom assistent som jobber for norsk offentlig sektor.
    Nar du far et sporsmal, skal du tenke noye gjennom det og gi et
    grundig og gjennomtenkt svar som er presist og korrekt.
    Husk a vaere hoeflig og profesjonell i all kommunikasjon.
    """},
    {"role": "user", "content": f"Hele dokumentet pa 5000 ord: {document}\n\nSporsmal: Er dette en klage?"}
]

# BRA: Kompakt prompt med kun relevant kontekst
messages = [
    {"role": "system", "content": "Klassifiser henvendelse. Svar: KLAGE eller IKKE_KLAGE"},
    {"role": "user", "content": f"Sammendrag: {document_summary[:500]}\n\nKlassifiser:"}
]

Content Filtering-optimalisering

Content filtering legger til latens men er kritisk for sikkerhet. For lavrisiko-bruksomrader kan man vurdere tilpassede filterpolicyer:

Konfigurasjon	Latenspavirkning	Nar a bruke
Standard filter (default)	+10-50 ms	Alle innbyggertjenester
Tilpasset filter (redusert)	+5-20 ms	Interne analyser, lav risiko
Asynkron filter	Minimal	Batch-prosessering

Merk: I norsk offentlig sektor bor content filtering alltid vaere aktivert for innbyggerrettede tjenester. Vurder kun reduksjon for interne, kontrollerte miljoer.

Provisioned Throughput Units (PTU) for forutsigbar latens

Nar bruke PTU vs. Standard

PTU gir dedikert kapasitet og forutsigbar latens:

Aspekt	Standard	PTU
Latensgaranti	Ingen	Konsistent per-call latens
Throttling	429 ved kvotegrense	429 kun over 100% utnyttelse
Pris	Per token	Fast manedspris per PTU
Egnet for	Variabel last, utvikling	Produksjon, stabil last

PTU-kapasitetsplanlegging

Bruk Microsoft Foundry PTU-kalkulatoren:

1. Estimer input TPM (tokens per minutt) fra historiske data
2. Estimer output TPM fra historiske data
3. Beregn nodvendige PTUs via kalkulatoren
4. Legg til 20% buffer for trafikkvariasjon

PTU-utnyttelse = (PTUs forbrukt i perioden) / (PTUs deployet i perioden)

Mal: Hold utnyttelse under 80% for stabil latens
Over 100%: 429-feil returneres

Hybrid PTU + Standard-arkitektur

Basislast (forutsigbar)  --> PTU deployment (Sweden Central)
                              |
                              | (ved 429 / overflow)
                              v
Toppbelastning           --> Standard deployment (North Europe, fallback)

Overvaking og malinger

Viktige Azure Monitor-metrikker

Metrikk	Aggregering	Terskel
Azure OpenAI Requests	Count per minutt	Varsle ved >80% av kvote
Processed Inference Tokens	Sum per minutt	Spor mot TPM-grense
Provisioned-Managed Utilization V2	Gjennomsnitt	Varsle ved >80%
Time to Response (streaming)	P95	Varsle ved >2s TTFT
End-to-end Request Time	P95	Varsle ved >5s

KQL-query for latensanalyse

// Azure Monitor - Analyse av Azure OpenAI-latens
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.COGNITIVESERVICES"
| where Category == "RequestResponse"
| extend latency_ms = DurationMs
| summarize
    p50 = percentile(latency_ms, 50),
    p95 = percentile(latency_ms, 95),
    p99 = percentile(latency_ms, 99),
    avg_latency = avg(latency_ms),
    request_count = count()
    by bin(TimeGenerated, 5m), ModelDeploymentName_s
| order by TimeGenerated desc

Sjekkliste for latensoptimalisering

Prioritet	Tiltak	Forventet effekt
1	Velg riktig modell for oppgaven	30-70% reduksjon
2	Optimaliser max_tokens	10-30% reduksjon
3	Aktiver streaming for brukerrettede tjenester	Redusert opplevd latens
4	Gjenbruk HTTP-forbindelser	50-100 ms per request
5	Bruk naermeste Azure-region (Sweden Central)	10-40 ms reduksjon
6	Implementer prompt caching	10-30% reduksjon pa input
7	Separer arbeidslaster pa egne deployments	10-20% reduksjon
8	Vurder PTU for stabile produksjonslaster	Forutsigbar latens

For Cosmo

• Latens er sammensatt: Optimaliser hele pipelinen, ikke bare modellvalget. Max tokens, connection reuse, regionvalg og prompt caching bidrar alle.
• Sweden Central er forstevalg for norske deployments med lavest latens (~10-20 ms) og EU-datasuverenitet. North Europe som failover.
• PTU for produksjon: Nar arbeidslaster er forutsigbare og latens er kritisk, gir PTU garantert kapasitet. Hybrid PTU + Standard er kostnadseffektiv arkitektur.
• Prompt caching er gratis ytelse: Strukturer prompts med identisk prefix (system prompt over 1024 tokens) for automatisk caching. Ingen konfigurasjon nodvendig.
• Separasjon av arbeidslaster: Aldri bland chatbot-trafikk med batch-prosessering pa samme deployment. Bruk dedikerte deployments per bruksomrade.