ms-ai-architect/skills/ms-ai-advisor/references/prompt-engineering/token-optimization-and-efficiency.md

Token Optimization and Cost Efficiency

Last updated: 2026-02 Status: GA Category: Prompt Engineering & LLM Optimization

---

Introduksjon

Token-optimalisering er kritisk for både kostnadseffektivitet og ytelse i Azure OpenAI-løsninger. Hver API-forespørsel koster basert på antall tokens prosessert (input + output), og ineffektiv token-bruk kan raskt eskalere både kostnader og responstider. Denne guiden dekker praktiske teknikker for å redusere token-forbruk, utnytte caching-mekanismer, og balansere kostnad mot ytelse.

Nøkkelkonsept: Azure OpenAI-modeller prosesserer tekst ved å dele den opp i tokens. Ett token er ca. 4 tegn for vanlig engelsk tekst. Både input (prompt) og output (completion) blir målt i tokens, og prisene varierer betydelig mellom modeller og deployment-typer.

---

Kjernekomponenter

Token-basert prismodell

Komponent	Beskrivelse	Kostnadsfaktor
Input tokens	Tokens i prompt (system message + user input + conversation history)	Lavest kostnad per token
Output tokens	Tokens generert av modellen som respons	2-4× høyere enn input
Cached tokens	Input tokens som matcher cached content	50-100% rabatt (avhenger av deployment-type)
Reasoning tokens	Ekstra tokens brukt av o-series modeller for resonnering	Egen prisstruktur (kun synlig i API-respons)

Eksempel GPT-4o-mini (standard deployment):

• Input: ~$0.15 per 1M tokens
• Output: ~$0.60 per 1M tokens
• Cached input: ~$0.075 per 1M tokens (50% rabatt)

Deployment-typer og token-optimalisering

Deployment Type	Token-strategi	Best For
Standard (pay-as-you-go)	Fokus på å redusere totale tokens; prompt caching gir moderat rabatt	Variabel last, utvikling, testing
Provisioned Throughput (PTU)	Optimalisere for throughput (tokens/min); cached tokens kan gi opptil 100% rabatt	Forutsigbar, høy last; latenskritiske workloads
Global Standard	Balansere token-effektivitet med geografisk fleksibilitet	Multi-region workloads uten data residency-krav
Batch	Maksimere token-volum; 50% kostnadsbesparing	Bulk-prosessering, ikke-sanntid (24t turnaround)

---

Token-optimaliserings-teknikker

1. Prompt Engineering for Token-effektivitet

Kortere prompts uten kvalitetstap

❌ Ineffektivt (150 tokens):
"You are an extremely helpful and knowledgeable assistant with expertise
in multiple domains. Please provide a comprehensive and detailed analysis
of the following situation, ensuring that you consider all relevant factors
and provide actionable recommendations..."

✅ Effektivt (25 tokens):
"You are an expert analyst. Analyze the situation and provide actionable
recommendations."

Teknikk: Few-shot vs. Zero-shot

• Few-shot bruker flere tokens (eksempler i prompt), men gir bedre output-kvalitet
• Zero-shot sparer input-tokens, men kan kreve regenerering hvis kvalitet er dårlig
• Trade-off: Evaluer om ekstra input-tokens er billigere enn å regenerere output

Strukturerte outputs reduserer output-tokens

# ❌ Ustrukturert output (400+ tokens)
"Explain the benefits of Azure OpenAI with examples and details..."

# ✅ Strukturert output (150 tokens)
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "List 3 Azure OpenAI benefits"}],
    response_format={
        "type": "json_schema",
        "json_schema": {
            "name": "benefits",
            "schema": {
                "type": "object",
                "properties": {
                    "benefits": {
                        "type": "array",
                        "items": {"type": "string"},
                        "maxItems": 3
                    }
                }
            }
        }
    }
)

2. Prompt Caching (automatisk funksjonalitet)

Status: GA for GPT-4o, GPT-4.1-serien, o-series (o1, o3-mini, o4-mini)

Prompt caching reduserer kostnader ved å cache de første 1024+ tokens i en prompt. Når identisk innhold gjentas, betaler du redusert pris for cached tokens.

Hvordan det fungerer

Faktor	Krav
Minimum prompt-lengde	1024 tokens
Cache-treff	Første 1024 tokens må være identiske
Granularitet	Cache-treff per 128 tokens etter første 1024
Cache-levetid	5-10 min inaktivitet (max 1 time for Microsoft Foundry; 24t for Foundry Models)
Deling	Ikke delt mellom Azure subscriptions

Design for cache-hits

# ✅ Strukturer prompts for caching-effektivitet
system_context = """You are a Norwegian public sector AI assistant.
[... 2000 tokens med policy-dokumenter, guidelines, etc. ...]
"""  # Dette blir cached

messages = [
    {"role": "system", "content": system_context},  # Cached
    {"role": "user", "content": user_query}         # Variabel (ikke cached)
]

# Cache-nøkkel (optional) for å forbedre hit rate
response = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    prompt_cache_key="public-sector-v1"  # Forbedrer routing
)

# Sjekk cache-hits i respons
cached = response.usage.prompt_tokens_details.cached_tokens
print(f"Cached tokens: {cached}/{response.usage.prompt_tokens}")

Konfidensmarkør: 🟢 Høy – Prompt caching er GA og godt dokumentert.

Best practices for caching

1. Plasser statisk innhold først: System messages, dokumenter, eksempler
2. Hold variabelt innhold sist: User queries, timestamps, session-spesifikk data
3. Bruk prompt_cache_key for workloads med mange parallelle requests (>15 req/min)
4. Overvåk cache hit rate: Sjekk cached_tokens i API-respons

Anti-pattern:

# ❌ Variabel innhold først = ingen cache hits
messages = [
    {"role": "user", "content": f"Timestamp: {now()} - {user_query}"},  # Endres hver gang
    {"role": "system", "content": long_static_context}  # For sent i token-sekvens
]

3. Max Tokens-kontroll

max_tokens-parameteren begrenser output-lengde. Dette påvirker ikke kvalitet, men hindrer unødvendig lange svar.

# ❌ Ukontrollert output (kan generere 4000+ tokens)
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Explain Microsoft Foundry"}]
)

# ✅ Kontrollert output
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Explain Microsoft Foundry in 3 sentences"}],
    max_tokens=150,
    stop=["\n\n"]  # Stopp ved double line break
)

Konfidensmarkør: 🟢 Høy – max_tokens er standard API-funksjonalitet.

4. Streaming for opplevd ytelse

Streaming reduserer ikke totale tokens eller totaltid, men forbedrer brukeropplevelse ved å vise output inkrementelt.

stream = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    stream=True
)

for chunk in stream:
    if chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end='')

Når å bruke streaming:

• Chatbots, conversational interfaces (brukeren ser respons umiddelbart)
• Lange genereringer (unngå client-side timeouts)

Når å ikke bruke streaming:

• Bulk-prosessering (sentiment analysis, oversettelse)
• Når du trenger hele responsen før videre prosessering

5. Batch API for massiv kostnadsbesparelse

Status: GA

Azure OpenAI Batch API gir 50% kostnadsrabatt for asynkrone workloads med 24-timers turnaround.

Fordel	Detalj
Kostnadsreduksjon	50% rabatt vs. global standard
Separat quota	Enqueued token quota påvirker ikke online workloads
Turnaround	24 timer (target), ikke garantert
Cancellation	Cancel jobb når som helst; betal kun for completed work

Use cases:

• Large-scale data analysis
• Content generation (bulk artikler, produktbeskrivelser)
• Dokumentrevidering og oppsummering
• NLP-tasks (sentiment analysis, translation på store datasett)

Konfidensmarkør: 🟢 Høy – Batch API er GA og anbefales av Microsoft for bulk-workloads.

6. Modellvalg for kostnad vs. ytelse

Modell	Input Cost	Output Cost	Best For
GPT-4.1-nano	Lavest	Lavest	Enkel klassifisering, routing, strukturert output
GPT-4.1-mini	Veldig lav	Lav	De fleste use cases; beste kostnad/ytelse-balanse
GPT-4.1 / GPT-4o	Moderat	Moderat	Kompleks resonnering, kreativt innhold
o3-mini	Høy	Høy (reasoning tokens)	Matematikk, kode, logisk resonnering
GPT-5	Høyest	Høyest	Mest krevende oppgaver (sjelden nødvendig)

Strategi: Start med GPT-4.1-mini, oppgrader kun hvis kvalitet er utilstrekkelig.

---

Arkitekturmønstre

Mønster 1: Multi-tier model cascade

Bruk billige modeller for routing/filtering, dyre modeller kun for komplekse oppgaver.

User Query
    ↓
[GPT-4.1-nano: Intent classification] (5 tokens output)
    ↓
    ├─→ [Simple query] → Cache lookup → Response
    └─→ [Complex query] → [GPT-4o: Full reasoning] → Response

ROI: 70-80% av queries kan håndteres av billigere modeller.

Mønster 2: Context compression med embeddings

Erstatt lange dokumenter med semantic search + RAG.

❌ Direkte document injection (10 000 tokens/request):
system_message = f"Context: {full_documents}"  # Dyrt hver gang

✅ RAG med embeddings (500 tokens/request):
1. Index documents med Azure AI Search (engangs-kostnad)
2. Query → embedding → semantic search → top 3 relevante chunks
3. Inject kun relevante chunks (500 tokens) i prompt

Besparelse: 95% reduksjon i input tokens (10k → 500).

Mønster 3: Fine-tuning for prompt-reduksjon

Fine-tune modeller for domene-spesifikke oppgaver → kortere prompts.

❌ Base model med lang prompt (2000 tokens instruction):
"You are a Norwegian legal expert. Follow these guidelines: [1800 tokens]"

✅ Fine-tuned model (50 tokens):
"Analyze contract" → Modellen har allerede lært domene-spesifikk kunnskap

Trade-off:

• Opfront kostnad: Training (token-basert) + hosting ($1.70/time for fine-tuned deployment)
• Løpende besparelse: 95% reduksjon i input tokens per request
• Break-even: Evaluer etter forventet request-volum (typisk >100k requests)

Konfidensmarkør: 🟡 Moderat – Fine-tuning kostnad/nytte varierer sterkt med use case.

---

Beslutningsveiledning

Når å prioritere token-optimalisering

Scenario	Prioritet	Teknikk
Høyt request-volum (>1M requests/måned)	🔴 Kritisk	Alle teknikker; vurder fine-tuning
Repetitive prompts (chatbot, support)	🔴 Kritisk	Prompt caching, RAG, model cascade
Lange dokumenter i context	🔴 Kritisk	RAG, context compression
Batch-prosessering	🟡 Viktig	Batch API (50% rabatt)
Prototyping, lav last	🟢 Lav	Fokus på funksjonalitet først

Decision tree: Kostnadsoptimalisering

Start: Høye token-kostnader?
    │
    ├─→ Høyt request-volum? (>100k/mnd)
    │   ├─→ Ja: Vurder Provisioned Throughput (PTU)
    │   └─→ Nei: Optimaliser per-request tokens
    │
    ├─→ Repetitive prompts? (>50% overlapp)
    │   └─→ Ja: Design for prompt caching (system message først)
    │
    ├─→ Lange dokumenter i context? (>5k tokens)
    │   └─→ Ja: Implementer RAG + Azure AI Search
    │
    ├─→ Bulk-prosessering? (ikke-sanntid OK)
    │   └─→ Ja: Bruk Batch API (50% rabatt)
    │
    └─→ Kompleks domene-logikk? (lang instruction prompt)
        └─→ Ja: Vurder fine-tuning (break-even >100k requests)

---

Integrasjon med Microsoft-stakken

Microsoft Foundry: Token monitoring

# Overvåk token-bruk i Azure Monitor
from azure.monitor.query import MetricsQueryClient

metrics_client = MetricsQueryClient(credential)

# Hent Processed Prompt Tokens (input TPM)
response = metrics_client.query_resource(
    resource_uri=f"/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{account}",
    metric_names=["ProcessedPromptTokens"],
    timespan=timedelta(days=7),
    granularity=timedelta(minutes=1),
    aggregations=["Average", "Maximum"]
)

# Hent Generated Completion Tokens (output TPM)
completion_response = metrics_client.query_resource(
    resource_uri=resource_uri,
    metric_names=["GeneratedCompletionTokens"],
    timespan=timedelta(days=7),
    granularity=timedelta(minutes=1),
    aggregations=["Average", "Maximum"]
)

Nøkkel-metrics:

• ProcessedPromptTokens: Input TPM (inkludert cached tokens)
• GeneratedCompletionTokens: Output TPM
• TokenTransaction: Total tokens prosessert

Azure API Management: Token rate limiting

Implementer token-baserte quotas per consumer/application.

<llm-token-limit
    counter-key="@(context.Subscription.Id)"
    tokens-per-minute="10000"
    estimate-prompt-tokens="true"
    remaining-tokens-variable-name="remainingTokens">
</llm-token-limit>

Fordeler:

• Forhindre at én app bruker all quota
• Pre-calculate prompt tokens → avvis requests før de når backend
• Rettferdig fordeling av TPM på tvers av apps

Copilot Studio: Token-bevissthet

Copilot Studio abstraherer token-håndtering, men:

• Lange conversation histories akkumulerer tokens (automatisk summarization etter 10-15 meldinger)
• Adaptive Cards og rich content legger til tokens
• Generative answers fra data sources kan bli dyre (hele documents injectes)

Anbefaling: Bruk Generative Answers med Azure AI Search (semantic ranking) istedenfor full document injection.

---

Offentlig sektor (Norge)

Budsjettstyring og kostnadskontroll

Offentlige virksomheter må ha forutsigbare IT-kostnader. Token-optimalisering er kritisk for:

1. Årsbudsjett-compliance: Unngå overforbruk midt i budsjettåret
2. Anbud og kontrakter: Estimere token-kostnader for 3-5 års driftsperiode
3. Transparens: Kunne forklare kostnader til politisk ledelse

Praktisk tilnærming:

1. Baseline-måling (1 måned):
   - Mål faktisk token-bruk i pilot (Azure Monitor)
   - Identifiser kostnadsdrivere (store prompts? høyt volum?)

2. Optimaliser (2-4 uker):
   - Implementer prompt caching (rask win)
   - Evaluer modellvalg (GPT-4.1-mini vs. GPT-4o)
   - Vurder RAG hvis lange dokumenter brukes

3. Produksjon med budsjett-alerts:
   - Sett Azure Cost Management budgets
   - Alerts ved 80% / 100% av månedlig budsjett
   - Action groups for automatisk skalering/throttling

Data residency og token-kostnader

Krav	Deployment Type	Token-strategi
Data residency Norge	Standard (regional) eller Data Zone Standard	Må akseptere høyere kostnader; fokus på token-effektivitet
Ingen residency-krav	Global Standard	10-30% rabatt; kan bruke mer tokens innenfor samme budsjett

Anbefaling: For ikke-personopplysninger (FAQ, interne dokumenter), bruk Global Standard → mer rom for tokens.

Compliance og token-logging

GDPR/logging-krav: API requests logges i Azure Monitor, inkludert token-bruk. Sikre at:

• PII ikke injectes i prompts (kan logges)
• Stored Completions (hvis brukt) har data retention policies
• Token-bruk kan audits for kostnadskontroll

---

Kostnad og lisensiering

Azure OpenAI prismodell (per 1M tokens, Feb 2026)

Standard deployment (pay-as-you-go)

Modell	Input	Output	Cached Input
GPT-4.1-nano	$0.10	$0.40	$0.05
GPT-4.1-mini	$0.20	$0.80	$0.10
GPT-4.1	$2.50	$10.00	$1.25
GPT-4o	$2.50	$10.00	$1.25
GPT-4o-mini	$0.15	$0.60	$0.075
o3-mini	$1.10	$4.40	$0.55

Merk: Reasoning tokens (o-series) har separat pricing.

Batch API (50% rabatt)

Modell	Input	Output
GPT-4.1-mini	$0.10	$0.40
GPT-4o	$1.25	$5.00
o3-mini	$0.55	$2.20

Provisioned Throughput (PTU-basert)

PTU-prising er basert på kapasitet (PTUs), ikke tokens. Token-optimalisering påvirker:

• Hvor mange PTUs du trenger: Færre tokens → lavere PTU-krav
• Cached tokens: Opptil 100% rabatt (frigjør PTU-kapasitet)

Eksempel:

• Workload: 500k input TPM + 150k output TPM = 30 PTUs
• Med 50% cache hit rate: 250k input TPM (cached, gratis) + 250k input TPM + 150k output = 20 PTUs
• Besparelse: 33% reduksjon i PTU-kostnad

Konfidensmarkør: 🟢 Høy – Priser hentet fra offisiell Azure-dokumentasjon (Feb 2026).

Fine-tuning kostnader

Kostnadstype	Beregning	Eksempel (GPT-4.1)
Training	Tokens × epochs × training price	1M tokens × 2 epochs × $2/M = $4
Hosting	$1.70/time (standard deployment)	$1,224/måned (kontinuerlig)
Inference	Input + output tokens (samme som base + hosting)	20M input × $1.10 + 40M output × $4.40 = $198

Break-even analyse:

Besparelse per request (prompt-reduksjon): 1800 tokens × $0.20/1M = $0.00036
Månedlig hosting-kostnad: $1,224
Break-even requests/måned: $1,224 / $0.00036 = 3.4M requests

→ Kun lønnsomt ved **svært** høyt volum (>3M requests/måned)

ROI-kalkulator for token-optimalisering

Scenario: Chatbot for offentlig sektor (1M requests/måned)

Tiltak	Token-reduksjon	Månedlig besparelse (NOK)
Baseline (ingen optimalisering)	-	Kostnad: 15 000 kr
Prompt caching (50% cache hit)	50% input	Sparer: 3 750 kr (25%)
Kortere prompts (-30% input)	30% input	Sparer: 2 250 kr (15%)
Strukturerte outputs (-20% output)	20% output	Sparer: 2 400 kr (16%)
Bytt til GPT-4.1-mini fra GPT-4o	-	Sparer: 10 500 kr (70%)
Total optimalisering	Kombinert	Sparer: 12 000 kr/måned (80%)

Konfidensmarkør: 🟡 Moderat – Besparelser varierer med workload; disse er representative estimater.

---

For arkitekten (Cosmo)

Praktiske spørsmål under arkitekturrådgivning

1. "Hvor mange requests forventer dere per måned?"

   • <100k: Standard deployment, fokus på funksjonalitet
   • 100k-1M: Optimaliser tokens (caching, compression)

   • 1M: Vurder PTU, Batch API, fine-tuning

2. "Har dere repetitive prompts (chatbot, FAQ, support)?"

   • Ja → Design for prompt caching (system message først)
   • Nei → Fokus på andre optimaliseringsteknikker

3. "Bruker dere lange dokumenter som context?"

   • Ja → Implementer RAG + Azure AI Search (95% token-reduksjon)
   • Nei → Standard prompt engineering

4. "Har dere budsjettbegrensninger eller årsbudsjett?"

   • Ja → Sett Azure Cost Management budgets + alerts
   • Implementer token rate limiting i API Management

5. "Er sanntids-respons kritisk?"

   • Ja → Standard/PTU + streaming
   • Nei → Vurder Batch API (50% rabatt)

Red flags for kostnadsfeller

🚩 "Vi sender hele PDF-filer (100+ sider) som context" → RAG er obligatorisk; ellers 50k+ tokens per request

🚩 "Fine-tuned modell har vært deployed i 6 måneder uten bruk" → $1.70/time × 24 × 180 dager = $7,344 hosting-kostnad uten verdi

🚩 "Vi bruker GPT-4o for alt" → 80% av use cases kan bruke GPT-4.1-mini (5× billigere)

🚩 "Vi har ikke monitoring på token-bruk" → Kostnader kan eskalere ukontrollert; sett opp Azure Monitor metrics

Anbefalte arkitekturmønstre per scenario

Scenario	Anbefalt mønster	Estimert besparelse
Kundeservice chatbot (repetitive spørsmål)	Prompt caching + model cascade (nano for routing)	60-70%
Dokumentanalyse (lange PDF-er)	RAG + Azure AI Search + GPT-4.1-mini	80-90%
Bulk content generation (ikke-sanntid)	Batch API + strukturerte outputs	50-60%
Kompleks resonnering (kode, matematikk)	o3-mini (kun når nødvendig) + caching	30-40%
Intern FAQ (lavt volum)	Standard deployment + GPT-4.1-mini	70% (vs. GPT-4o)

Validering av løsning: Token-effektivitets-checklist

✅ Prompt design:

• Statisk innhold (system message, dokumenter) plassert først?
• max_tokens satt til minimum nødvendig?
• Stop sequences definert for å hindre overgenerering?

✅ Caching:

• Prompts >1024 tokens har statisk prefix?
• prompt_cache_key brukt for high-frequency workloads?
• Cache hit rate monitores i Azure Monitor?

✅ Modellvalg:

• Bruker GPT-4.1-mini som default (oppgrader kun hvis nødvendig)?
• Model cascade implementert (billig modell for routing)?

✅ Kostnadsovervåking:

• Azure Cost Management budgets satt opp?
• Alerts ved 80%/100% av budsjett?
• Token-metrics logges og analyseres månedlig?

✅ Arkitektur:

• RAG implementert for lange dokumenter?
• Batch API vurdert for bulk-workloads?
• Content filtering justert (hvis lavrisiko use case)?

---

Kilder og verifisering

Offisiell Microsoft-dokumentasjon:

1. Prompt caching for Azure OpenAI
2. Plan and manage costs for Azure OpenAI
3. Performance and latency optimization
4. Batch API for Azure OpenAI
5. Azure OpenAI pricing

Verifisert: Februar 2026 via microsoft-learn MCP-server

Confidence level: 🟢 Høy for GA-funksjoner (prompt caching, batch API, standard pricing), 🟡 Moderat for ROI-estimater (workload-avhengige).

---

Sist oppdatert av Cosmo Skyberg, Microsoft AI Solution Architect For spørsmål om token-optimalisering i din løsning, start en arkitektursesjon med /architect.