# PTU vs Pay-as-You-Go: Economic Decision Framework

**Last updated:** 2026-02
**Status:** GA
**Category:** Cost Optimization & FinOps for AI

---

## Introduksjon

Valget mellom Provisioned Throughput Units (PTU) og Pay-as-You-Go (PayGo) for Azure OpenAI-deployments er en kritisk arkitektur- og økonomibeslutning som påvirker både kostnader, ytelse og operasjonell kompleksitet. PTU tilbyr forutsigbar kapasitet og kostnader mot en timebasert commitment, mens PayGo gir fleksibilitet med token-basert fakturering. Begge modellene har sine optimale bruksområder, og feilvalg kan raskt føre til enten overforbruk eller underutnyttelse av ressurser.

Azure OpenAI tilbyr nå tre deployment-typer for provisioned throughput: **Global Provisioned**, **Data Zone Provisioned** og **Regional Provisioned**. Alle tre faktureres per time basert på antall deployede PTUer, med betydelige rabatter tilgjengelig gjennom Azure Reservations (1 måned eller 1 år commitment). PayGo-modellen, derimot, fakturerer per token (både input og output tokens) og har ingen forhåndsforpliktelser.

En hybrid tilnærming, der man kombinerer PTU for stabil baseline-traffic og PayGo for burstiness, er ofte den mest kostnadseffektive løsningen for produksjonssystemer. Dette dokumentet gir arkitekten verktøyene for å navigere denne beslutningen med konfidensgradering basert på faktiske Microsoft Learn-data.

## Kjernekomponenter / Nøkkelegenskaper

### PTU-prismodell

| Komponent | Beskrivelse | Verified |
|-----------|-------------|----------|
| **Provisioned Throughput Unit (PTU)** | Generisk enhet for modellprosesseringskapasitet. Ikke modellspesifikk – samme PTU-quota kan brukes på tvers av Azure OpenAI-modeller og Foundry-modeller (DeepSeek, Llama, etc.). | ✅ Verified |
| **Hourly billing** | Faktureres per time: `$/PTU/hr × antall PTUer`. Proratert ved partial hours (15 min = 1/4 av time-rate). | ✅ Verified |
| **Azure Reservations** | 1-måned eller 1-år commitments gir betydelige rabatter (ofte 50%+). Reservasjoner kjøpes i Azure Portal, ikke AI Foundry. | ✅ Verified |
| **Deployment types** | Global Provisioned (multi-region), Data Zone Provisioned (data residency), Regional Provisioned (single-region). Hver type krever separat reservation. | ✅ Verified |
| **Minimum PTU** | Varierer per modell: GPT-4o (50 PTU regional, 15 PTU global), GPT-4o-mini (25 PTU regional, 15 PTU global), DeepSeek-R1 (100 PTU global, ingen regional). | ✅ Verified |
| **Throughput per PTU** | For nyere modeller (GPT-4.1+): Separate input/output TPM per PTU. Eksempel: GPT-5 har 4750 input TPM per PTU. Output tokens "koster" mer kapasitet enn input. | ✅ Verified |
| **Utilization metric** | Azure Monitor: `Provisioned-Managed Utilization V2` måler utnyttelse. Ved 100% returneres HTTP 429. | ✅ Verified |

### PayGo-prismodell

| Komponent | Beskrivelse | Verified |
|-----------|-------------|----------|
| **Token-based billing** | Faktureres per 1000 tokens (1K tokens). Input og output har ulike priser (output er dyrere). | ✅ Verified |
| **Dynamic quota (preview)** | Lar standard-deployments opportunistisk bruke mer quota når tilgjengelig, uten ekstra konfigurasjon. Faktureres fortsatt per token. | ✅ Verified |
| **TPM-quota** | Tokens Per Minute (TPM) quota definerer maks throughput. Kan økes via quota-request. | ✅ Verified |
| **Rate limiting** | Custom rate limiting basert på estimert traffic load. Kan gi HTTP 429 før quota nås hvis traffic er ujevnt distribuert. | ✅ Verified |
| **No minimum commitment** | Ingen forhåndskostnader eller minimum deployment-størrelse. Betaler kun for faktisk forbruk. | ✅ Verified |

### Breakeven-analyse

**Formel:** `Breakeven (tokens/måned) = (PTU hourly cost × 730 timer) / (PayGo token price)`

**Eksempel (GPT-4o i NOK, forenklede tall):**
- PTU hourly rate (uten reservation): ~50 NOK/PTU/time
- PayGo input: ~0.50 NOK/1K tokens, output: ~1.50 NOK/1K tokens
- 100 PTU deployment: 50 × 100 × 730 = 3 650 000 NOK/måned
- Med 1-år reservation (50% rabatt): ~1 825 000 NOK/måned

**Breakeven-punkt (input-heavy workload, 80/20 input/output):**
- Gjennomsnittlig token-pris: (0.50 × 0.8) + (1.50 × 0.2) = 0.70 NOK/1K tokens
- Breakeven: 1 825 000 / 0.70 = ~2 607 millioner tokens/måned
- TPM ved jevn fordeling: ~59 600 TPM

**Tommelfingerregel:** PTU blir kostnadseffektivt ved consistent high-volume workloads (>50% utilization over tid). PayGo er bedre for bursty/unpredictable traffic.

## Arkitekturmønstre

### Mønster 1: Pure PTU

**Beskrivelse:** All trafikk går til provisioned deployment. Ingen PayGo-fallback.

**Fordeler:**
- Forutsigbare kostnader (fixed monthly bill)
- Garantert latency (SLA på latency targets per modell)
- Ingen rate limiting på token-basis (kun utilization-basert)
- Best TCO for høy, stabil throughput

**Ulemper:**
- Risiko for underutnyttelse ved variabel trafikk
- HTTP 429 ved traffic spikes over kapasitet
- Kapasitet må pre-allokeres (quota ≠ capacity guarantee)
- Mindre fleksibilitet for ad-hoc testing

**Bruk når:**
- Produksjonssystem med forutsigbar trafikk
- Real-time/latency-sensitive applikasjoner
- Kostnadsmodellering viser >60% utilization over tid
- Compliance krever dedikert kapasitet

### Mønster 2: Pure PayGo

**Beskrivelse:** All trafikk går til standard (token-based) deployment.

**Fordeler:**
- Ingen forhåndskostnader eller commitments
- Perfekt for variable/bursty workloads
- Enkel skalering (TPM quota økning)
- Lavest risiko for overprovisjonering

**Ulemper:**
- Uforutsigbare kostnader ved traffic spikes
- Mindre forutsigbar latency (ingen SLA)
- Høyere cost per token ved høy throughput
- Rate limiting kan være mer aggressiv

**Bruk når:**
- Utvikling, testing, prototyping
- Proof-of-Concept eller hackathon
- Traffic er høyst variabel (ukentlige/sesongmessige spikes)
- Lavt totalt volum (<30% av PTU breakeven)

### Mønster 3: Hybrid PTU + PayGo (anbefalt for produksjon)

**Beskrivelse:** PTU for baseline traffic + PayGo fallback for bursts. Kan bruke **spillover** feature (preview) for automatisk routing.

**Fordeler:**
- Optimalisert kostnad: PTU for baseline (med reservation), PayGo for peaks
- Ingen HTTP 429 tap ved spikes (fallback til PayGo)
- Fleksibilitet til å teste nye modeller/versjoner på PayGo
- Best practice ifølge Microsoft (ref: "not recommended to scale PTU with traffic")

**Ulemper:**
- Mer kompleks arkitektur (routing logic, monitoring to deployments)
- Krever monitoring av PTU utilization for å optimalisere sizing
- Må håndtere fallback-logikk (client retry eller API Management)

**Implementering:**
```
1. Deploy PTU for baseline (eksempel: 100 PTU)
2. Deploy PayGo for samme modell/versjon
3. Option A: Spillover feature (preview) – automatisk routing ved PTU=100%
4. Option B: Application-level routing – ved HTTP 429 fra PTU, retry til PayGo
5. Monitor: PTU utilization + PayGo token consumption
6. Optimize: Juster PTU sizing basert på faktisk baseline
```

**Bruk når:**
- Produksjonssystem med kjent baseline + variable peaks
- Kostnadsoptimalisering er kritisk
- Kan akseptere noe arkitekturkompleksitet
- Ønsker å minimere risiko for både under- og overprovisjonering

## Beslutningsveiledning

### Beslutningstabell

| Kriterium | PTU | PayGo | Hybrid |
|-----------|-----|-------|--------|
| **Traffic pattern** | Stabil, forutsigbar | Variabel, bursty | Kjent baseline + spikes |
| **Latency requirements** | Real-time (<100ms p99) | Best-effort | Mixed (PTU for critical, PayGo for bulk) |
| **Cost predictability** | Høy (fixed monthly) | Lav (variabel) | Middels (PTU fixed + PayGo variabel) |
| **TCO optimization** | Best ved >60% utilization | Best ved lav/variabel volum | Best for de fleste produksjonssystemer |
| **Operational complexity** | Lav (en deployment) | Lav (en deployment) | Middels-høy (to deployments + routing) |
| **Scale-up latency** | Ingen (kapasitet pre-allokert) | Umiddelbar (quota tillater) | Hybrid (PTU instant, PayGo instant) |
| **Commitment risk** | Høy (må forplikte PTU-antall) | Ingen | Lav-middels (kun baseline PTU) |

### Vanlige feil

1. **Feil 1: Kjøpe reservation før deployment**
   - **Problem:** Quota ≠ capacity. Man kan ha quota, men ingen tilgjengelig kapasitet i region.
   - **Fix:** Alltid deploy FØRST, deretter kjøp reservation som matcher deployed PTU.

2. **Feil 2: Scale PTU opp/ned basert på traffic**
   - **Problem:** a) Dyrere å betale hourly enn reservation, b) Ingen garanti for at capacity finnes når du scaler opp.
   - **Fix:** Bruk hybrid approach – fast PTU baseline (med reservation) + PayGo for peaks.

3. **Feil 3: Ikke spesifisere `max_tokens`**
   - **Problem:** Service estimerer generation size, kan føre til lavere concurrency enn forventet.
   - **Fix:** Alltid sett `max_tokens` så nært faktisk generation size som mulig.

4. **Feil 4: Blande reservation scopes**
   - **Problem:** Global/Data Zone/Regional reservations er IKKE interchangeable.
   - **Fix:** Kjøp separat reservation per deployment type.

5. **Feil 5: Ignorere utilization metrics**
   - **Problem:** PTU deployment kan være underutnyttet (sløsing) eller overutnyttet (HTTP 429).
   - **Fix:** Monitor `Provisioned-Managed Utilization V2` i Azure Monitor. Mål: 70-85% gjennomsnitt.

### Røde flagg (PTU er feil valg)

- Traffic er uforutsigbar og varierer >10x mellom peak/trough
- Proof-of-Concept eller testing (ikke produksjon)
- Totalt volum er <30% av PTU breakeven point
- Kan ikke committe til 1-måned eller 1-år (hourly PTU er ofte dyrere enn PayGo)
- Ingen monitorering/alerting på utilization

### Røde flagg (PayGo er feil valg)

- Real-time latency requirements (<100ms p99)
- Stabil, høy throughput (>50% av PTU breakeven)
- Kostnadsforutsigbarhet er kritisk (budsjettrestriksjoner)
- Compliance krever dedikert kapasitet (ikke delt infrastruktur)

## Integrasjon med Microsoft-stakken

### Azure Cost Management

- **Cost analysis:** Analyser PTU hourly charges vs. PayGo token charges per deployment.
- **Budgets & alerts:** Sett budsjetter per resource group. Alert ved 80% av monthly budget.
- **Reservations dashboard:** Monitor reservation utilization (mål: >80% utilization).
- **Anomaly detection:** Påslå for PayGo deployments – detect unforventede cost spikes.

### Azure API Management (APIM)

**Use case:** GenAI Gateway pattern for PTU + PayGo routing.

**Pattern:**
1. APIM som frontend for alle OpenAI-kall
2. High-priority requests → PTU deployment
3. Low-priority requests → Queue (processed kun hvis PTU <100%)
4. Ved PTU utilization >80% → Throttle low-priority, route til PayGo
5. Monitor PTU utilization via Azure Monitor eller custom events fra APIM

**Referanse:** [Maximize PTU utilization with APIM](https://learn.microsoft.com/en-us/ai/playbook/solutions/genai-gateway/reference-architectures/maximise-ptu-utilization)

### Azure Monitor

**Metrics:**
- `Provisioned-Managed Utilization V2` (PTU) – Split by deployment name
- `Processed Prompt Tokens` (PTU & PayGo)
- `Generated Completion Tokens` (PTU & PayGo)
- `Azure OpenAI Requests` (count, status codes)

**Alerts:**
- PTU utilization >90% sustained for 5 min → Consider scaling or routing to PayGo
- PTU utilization <40% sustained for 1 week → Consider downsizing PTU
- HTTP 429 count >100/min → Capacity issue or routing failure

### Capacity Calculator

**Tool:** [AI Foundry PTU Calculator](https://ai.azure.com/resource/calculator)

**Inputs:**
- Model & version
- Peak calls per minute (RPM)
- Tokens in prompt call (average)
- Tokens in model response (average)

**Output:**
- Estimated PTU required (rounded to deployment increment)
- Raw PTU estimate (before rounding)

**Best practice:** Benchmark med real traffic (ikke kun calculator). Calculator er estimat, faktisk utilization avhenger av call distribution.

## Offentlig sektor (Norge)

### GDPR og Schrems II

- **Regional Provisioned:** Data residency i valgt region (eksempel: Norway East, West Europe). Best for GDPR compliance.
- **Data Zone Provisioned:** Data residency i EU data zone (12 regioner). Backup for Regional hvis capacity mangler.
- **Global Provisioned:** Multi-region routing, ingen data residency garanti. **Ikke anbefalt for persondata** uten grundig risikovurdering.

**Anbefaling for offentlig sektor:** Bruk Regional eller Data Zone. Verifiser data residency requirements med DPO.

### AI Act (EU AI Act)

- **High-risk AI systems:** Krever dokumentasjon av modellvalg, deployment type, capacity planning.
- **PTU advantage:** Forutsigbar ytelse og kapasitet letter compliance-dokumentasjon.
- **PayGo risk:** Variabel latency kan være utfordrende å dokumentere for real-time high-risk systemer.

### Forvaltningsloven (transparens)

- **Vedtakssystemer:** Krever transparens i hvordan AI-modellen brukes. PTU gir forutsigbar responstid, enklere å dokumentere.
- **Logging:** Både PTU og PayGo støtter same logging/tracing. Ingen forskjell i transparens-compliance.

### Datasuverenitet

- **Regional Provisioned:** Best for datasuverenitet (Norge, EU-regioner).
- **Global/Data Zone:** Akseptabelt hvis DPO godkjenner.
- **Reservations:** Kan kjøpes i hvilken som helst region/subscription scope – påvirker ikke data residency.

### Budsjettprosesser

- **PTU:** Fixed monthly cost → Enklere budsjettplanlegging. Anbefalt for offentlig sektor.
- **PayGo:** Variable cost → Krever buffers (20-30% margin). Risiko for budsjettoverskridelse.
- **Hybrid:** PTU baseline (fast) + PayGo (variabel) → Kombiner fast baseline med controlled variable.

**Best practice:** Bruk PTU med 1-års reservation for produksjonssystemer. Sett PayGo-deployment med spending cap (Azure Cost Management alert) for peaks.

## Kostnad og lisensiering

### Prismodell-oversikt (forenklede NOK-tall, februar 2026)

**Disclaimer:** Priser varierer per region og endres jevnlig. Bruk [Azure Pricing Calculator](https://azure.microsoft.com/pricing/calculator/) for eksakte tall.

| Modell | PTU Hourly (Regional) | PTU 1-år Reservation | PayGo Input | PayGo Output |
|--------|----------------------|----------------------|-------------|--------------|
| GPT-4o | ~50 NOK/PTU/time | ~25 NOK/PTU/time (50% rabatt) | ~0.50 NOK/1K | ~1.50 NOK/1K |
| GPT-4o-mini | ~12 NOK/PTU/time | ~6 NOK/PTU/time | ~0.15 NOK/1K | ~0.60 NOK/1K |
| GPT-5 | ~80 NOK/PTU/time | ~40 NOK/PTU/time | ~1.00 NOK/1K | ~3.00 NOK/1K |
| DeepSeek-R1 (Global) | ~60 NOK/PTU/time | ~30 NOK/PTU/time | ~0.80 NOK/1K | ~2.40 NOK/1K |

**Note:** Global/Data Zone Provisioned ofte har ulike priser enn Regional. Sjekk pricing calculator.

### Optimaliseringstips

1. **Bruk reservations for produksjon:** 40-50% kostnadsbesparelse på PTU.
2. **Right-size PTU deployment:**
   - Start med capacity calculator estimate
   - Deploy og benchmark med real traffic
   - Juster basert på utilization metrics (mål: 70-85%)
3. **Leveraged shared PTU reservations:**
   - Kjøp reservation på subscription/management group level
   - Del kapasitet på tvers av prosjekter/teams
   - Monitor per-deployment utilization
4. **Prompt caching:** PTU får 100% rabatt på cached tokens i utilization. Optimaliserer prompts for cache-hits.
5. **Batch processing på PayGo:** For non-real-time workloads, bruk PayGo batch processing (lavere prioritet, lavere cost).
6. **Monitor spillover:** Hvis hybrid, track hvor mye traffic går til PayGo vs. PTU. Juster PTU sizing for å minimere PayGo overspill.

### Konkrete priseksempler (monthly TCO)

**Scenario 1: Høy, stabil throughput (kundeservice chatbot)**
- Traffic: 100M tokens/måned (80% input, 20% output)
- Modell: GPT-4o

**PayGo:**
- Input: 80M × 0.50/1K = 40 000 NOK
- Output: 20M × 1.50/1K = 30 000 NOK
- **Total: 70 000 NOK/måned**

**PTU (100 PTU, 1-år reservation):**
- 100 PTU × 25 NOK/time × 730 timer = 1 825 000 NOK/måned
- **Total: 1 825 000 NOK/måned**

**Konklusjon:** PayGo er klart billigst for dette volumet. PTU krever ~2.6 milliarder tokens/måned for breakeven.

---

**Scenario 2: Meget høy throughput (enterprise search)**
- Traffic: 5 milliarder tokens/måned (70% input, 30% output)
- Modell: GPT-4o-mini

**PayGo:**
- Input: 3.5B × 0.15/1K = 525 000 NOK
- Output: 1.5B × 0.60/1K = 900 000 NOK
- **Total: 1 425 000 NOK/måned**

**PTU (200 PTU, 1-år reservation):**
- 200 PTU × 6 NOK/time × 730 timer = 876 000 NOK/måned
- **Total: 876 000 NOK/måned**

**Konklusjon:** PTU er 39% billigere. Hybrid kan være enda bedre (150 PTU baseline + PayGo for peaks).

---

**Scenario 3: Hybrid (variable workload)**
- Baseline: 2 milliarder tokens/måned
- Peaks: +1 milliard tokens/måned (sporadisk)
- Modell: GPT-4o

**Hybrid (100 PTU + PayGo spillover):**
- PTU: 100 PTU × 25 NOK/time × 730 = 1 825 000 NOK/måned
- PayGo (peaks, 30% av total): 1B × ((0.50×0.8)+(1.50×0.2))/1K = 700 000 NOK
- **Total: 2 525 000 NOK/måned**

**Pure PayGo (samme volum):**
- 3B × ((0.50×0.8)+(1.50×0.2))/1K = 2 100 000 NOK/måned

**Konklusjon:** Hybrid er dyrere i dette tilfellet. Pure PayGo eller større PTU (200 PTU) ville vært bedre.

## For arkitekten (Cosmo)

### 5-8 spørsmål å stille kunden

1. **Traffic pattern:** Har dere historisk data på tokens per time/dag/måned? Hvor stor variasjon er det mellom peak og gjennomsnitt?
2. **Latency requirements:** Har dere SLA-krav på responstid? Er systemet real-time (chatbot) eller batch (rapport-generering)?
3. **Budget constraints:** Forutsigbar monthly cost eller akseptabel variance? Hva er maksimal akseptabel cost spike?
4. **Compliance/data residency:** Krav til data residency (Norge, EU)? GDPR/AI Act compliance-dokumentasjon nødvendig?
5. **Modenhet:** Proof-of-Concept, pilot eller produksjon? Kan dere committe til 1-års reservation?
6. **Monitoring capability:** Har dere kapasitet til å monitore PTU utilization og optimalisere sizing?
7. **Failover/redundancy:** Akseptabelt med HTTP 429 ved spikes, eller kreves garantert capacity?
8. **Model switching:** Planlegger dere å teste flere modeller/versjoner? (PTU er model-independent, kan bytte innenfor samme deployment type)

### Fallgruver å unngå

1. **Quota ≠ Capacity:** Ikke anta at quota garanterer deployment-capacity. Test i target region først.
2. **Reservation timing:** IKKE kjøp reservation før deployment er bekreftet fungerende.
3. **Scope mismatch:** Global/Data Zone/Regional reservations matcher IKKE på tvers. Separat reservation per type.
4. **Underestimere variability:** Hvis traffic varierer >5x, er pure PTU risikabelt. Vurder hybrid.
5. **Overfokus på unit cost:** Total Cost of Ownership (TCO) inkluderer overhead for monitoring, routing logic (hybrid), samt risiko for underutnyttelse (PTU) eller cost spikes (PayGo).

### Anbefalinger per modenhetsnivå

**Level 1: Proof-of-Concept / Utforskning**
- **Anbefaling:** Pure PayGo
- **Hvorfor:** Ingen commitment, fleksibilitet til å teste modeller, lav risiko.
- **Watch out:** Sett spending cap for å unngå ukontrollerte kostnader.

**Level 2: Pilot / Begrenset produksjon**
- **Anbefaling:** PayGo med overvåking, vurder PTU hvis volumet vokser.
- **Hvorfor:** PayGo gir fortsatt fleksibilitet, men start monitoring av token consumption for breakeven-analyse.
- **Watch out:** Hvis throughput blir forutsigbart høy (>60% av PTU breakeven), planlegg migrering til PTU.

**Level 3: Produksjon (stabil traffic)**
- **Anbefaling:** PTU med 1-års reservation
- **Hvorfor:** Best TCO, forutsigbar cost, latency SLA.
- **Watch out:** Monitor utilization (70-85%). Hvis <50%, downsize PTU. Hvis >90%, vurder hybrid med PayGo fallback.

**Level 4: Produksjon (variable traffic)**
- **Anbefaling:** Hybrid (PTU baseline + PayGo spillover)
- **Hvorfor:** Optimaliserer cost (PTU for baseline med reservation) og resilience (PayGo for peaks).
- **Watch out:** Krever arkitekturkompleksitet (routing, monitoring). Vurder APIM GenAI Gateway pattern.

**Level 5: Enterprise-scale (multi-workload)**
- **Anbefaling:** Shared PTU reservations (management group scope) + PayGo per workload
- **Hvorfor:** Maksimer reservation utilization på tvers av teams, gi fleksibilitet til individuelle workloads.
- **Watch out:** Krever governance for PTU allocation og chargeback-modell for teams.

## Kilder og verifisering

**Microsoft Learn-ressurser (MCP-verified, februar 2026):**

1. **Provisioned Throughput Concepts:**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/provisioned-throughput
   *Confidence: Verified* – Offisiell kilde på PTU-konsepter, deployment types, benefits.

2. **PTU Cost Management:**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/provisioned-throughput-onboarding
   *Confidence: Verified* – Detaljert prisinformasjon, hourly billing, reservations, capacity calculator.

3. **Provisioned Get Started Guide:**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/provisioned-get-started
   *Confidence: Verified* – Deployment workflow, quota vs. capacity, utilization monitoring.

4. **Provisioned Migration (Payment Model Framework):**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/provisioned-migration
   *Confidence: Verified* – Commitment vs. Reservation models, coexistence, best practices.

5. **Performance and Latency:**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/latency
   *Confidence: Verified* – Throughput vs. latency, TPM estimation, monitoring metrics.

6. **GenAI Gateway (APIM + PTU Optimization):**
   https://learn.microsoft.com/en-us/ai/playbook/solutions/genai-gateway/reference-architectures/maximise-ptu-utilization
   *Confidence: Verified* – Hybrid architecture pattern for maximizing PTU utilization.

7. **Azure Reservations for Azure OpenAI:**
   https://learn.microsoft.com/en-us/azure/cost-management-billing/reservations/azure-openai
   *Confidence: Verified* – Reservation purchase, scope, discounts, management.

8. **Dynamic Quota (Preview):**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/dynamic-quota
   *Confidence: Verified* – PayGo deployment optimization, opportunistic quota increase.

9. **Spillover Traffic Management (Preview):**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/spillover-traffic-management
   *Confidence: Verified* – Automatic routing fra PTU til PayGo ved capacity limit.

**Code samples (MCP-verified):**
- Python deployment examples for PTU/PayGo
- Azure CLI commands for provisioned deployments
- REST API examples for deployment management

**Konfidensnivå per seksjon:**
- Prismodell (PTU & PayGo): **Verified** (direkte fra Microsoft Learn + pricing calculator)
- Breakeven-analyse: **Baseline** (formel er standard, men eksakte tall varierer per region/tid)
- Arkitekturmønstre: **Verified** (APIM GenAI Gateway pattern fra Microsoft docs)
- Offentlig sektor Norge: **Baseline** (GDPR/AI Act er faktisk, men norske tolkninger er baseline knowledge)
- Kostnadseksempler: **Baseline** (basert på forenklede NOK-konverteringer, må verifiseres i pricing calculator)
- Beslutningstabell: **Verified** (synthesis av Microsoft best practices)

**Oppdateringsfrekvens:** Dette dokumentet bør oppdateres hver 3. måned (pricing changes, nye deployment types, preview features blir GA).