Kjell Tore Guttormsen
ddce43d8b2
Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/ infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk (fra første ## seksjon), advisor urørt (0 endringer). To applier-fixes oppdaget under kjøring (TDD, RED→GREEN): - insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer 500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor scan-vinduet, applierens post-write-assertion fanget + restaurerte). - normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i 500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent utvidelse av carve-out; kun stray metadata-linjer, aldri prosa. test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet (fila bærer nå Source). Suite 728/728 grønn.
470 lines
24 KiB
Markdown
470 lines
24 KiB
Markdown
# PTU vs Pay-as-You-Go: Economic Decision Framework
|
||
|
||
**Last updated:** 2026-06
|
||
**Status:** GA
|
||
**Category:** Cost Optimization & FinOps for AI
|
||
**Source:** https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput
|
||
**Type:** reference
|
||
|
||
---
|
||
|
||
## Innhold
|
||
|
||
- [Introduksjon](#introduksjon)
|
||
- [Kjernekomponenter / Nøkkelegenskaper](#kjernekomponenter--nøkkelegenskaper)
|
||
- [Arkitekturmønstre](#arkitekturmønstre)
|
||
- [Beslutningsveiledning](#beslutningsveiledning)
|
||
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
|
||
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
|
||
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
|
||
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
|
||
- [Kilder og verifisering](#kilder-og-verifisering)
|
||
|
||
## 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.
|
||
|
||
Microsoft Foundry skiller nå mellom fire deployment-kategorier: **Standard** (pay-per-token, ingen latency-SLA), **Priority processing** (pay-per-token til priority-tier-rate, med definert latency-target per modell — et mellomalternativ for latency-sensitive workloads uten langsiktig commitment), **Provisioned** (per PTU/time eller reservation, garantert throughput) og **Batch** (rabattert pay-per-token, asynkront). Denne analysen fokuserer på PTU vs. standard PayGo, men `Priority processing` er verdt å vurdere når man trenger lav latency uten å committe til PTU.
|
||
|
||
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 | Documented |
|
||
|-----------|-------------|----------|
|
||
| **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.). | ✅ Documented |
|
||
| **Hourly billing** | Faktureres per time: `$/PTU/hr × antall PTUer`. Proratert ved partial hours (15 min = 1/4 av time-rate). | ✅ Documented |
|
||
| **Azure Reservations** | 1-måned eller 1-år commitments gir betydelige rabatter (ofte 50%+). Reservasjoner kjøpes i Azure Portal, ikke AI Foundry. | ✅ Documented |
|
||
| **Deployment types** | Global Provisioned (multi-region), Data Zone Provisioned (data residency), Regional Provisioned (single-region). Hver type krever separat reservation. | ✅ Documented |
|
||
| **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). | ✅ Documented |
|
||
| **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. | ✅ Documented |
|
||
| **Utilization metric** | Azure Monitor: `Provisioned-Managed Utilization V2` måler utnyttelse. Ved 100% returneres HTTP 429. | ✅ Documented |
|
||
|
||
### PayGo-prismodell
|
||
|
||
| Komponent | Beskrivelse | Documented |
|
||
|-----------|-------------|----------|
|
||
| **Token-based billing** | Faktureres per 1000 tokens (1K tokens). Input og output har ulike priser (output er dyrere). | ✅ Documented |
|
||
| **Dynamic quota (preview)** | Lar standard-deployments opportunistisk bruke mer quota når tilgjengelig, uten ekstra konfigurasjon. Faktureres fortsatt per token. | ✅ Documented |
|
||
| **TPM-quota** | Tokens Per Minute (TPM) quota definerer maks throughput. Kan økes via quota-request. | ✅ Documented |
|
||
| **Rate limiting** | Custom rate limiting basert på estimert traffic load. Kan gi HTTP 429 før quota nås hvis traffic er ujevnt distribuert. | ✅ Documented |
|
||
| **No minimum commitment** | Ingen forhåndskostnader eller minimum deployment-størrelse. Betaler kun for faktisk forbruk. | ✅ Documented |
|
||
|
||
### 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** (GA) for automatisk routing. Spillover støttes av alle Azure OpenAI-modeller med PTU, men ikke av Foundry-modeller fra andre leverandører (Azure DeepSeek, Meta Llama).
|
||
|
||
**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 (GA) – automatisk routing ved PTU=100% (429/500/503)
|
||
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; PTU-konsepter, spillover og sizing re-verifisert juni 2026):**
|
||
|
||
1. **Provisioned Throughput Concepts:**
|
||
https://learn.microsoft.com/en-us/azure/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/foundry/openai/concepts/provisioned-throughput-billing
|
||
*Confidence: Verified* – Detaljert prisinformasjon, hourly billing, reservations, capacity calculator.
|
||
|
||
3. **Provisioned Get Started Guide:**
|
||
https://learn.microsoft.com/en-us/azure/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/foundry-classic/openai/concepts/provisioned-migration
|
||
*Confidence: Verified* – Commitment vs. Reservation models, coexistence, best practices.
|
||
|
||
5. **Performance and Latency:**
|
||
https://learn.microsoft.com/en-us/azure/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/foundry-classic/openai/how-to/dynamic-quota
|
||
*Confidence: Verified* – PayGo deployment optimization, opportunistic quota increase.
|
||
|
||
9. **Spillover Traffic Management (GA):**
|
||
https://learn.microsoft.com/azure/foundry/openai/how-to/spillover-traffic-management
|
||
*Confidence: Verified (2026-06)* – Automatic routing fra PTU til standard-deployment ved capacity limit (429/500/503). Per-deployment eller per-request (`x-ms-spillover-deployment`).
|
||
|
||
**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).
|