docs(ms-ai-architect): KB-refresh critical cost 1/8 — ptu-vs-paygo verifisert mot Foundry PTU-docs

Kalibreringsfil (7 kilder flagget). Verifisert mot live Microsoft Learn (provisioned-throughput,
spillover-traffic-management, provisioned-throughput-sizing):
- KVANTITATIV KJERNE CURRENT: PTU-minimums (GPT-4o 50/15, 4o-mini 25/15, DeepSeek-R1 100/NA),
  «GPT-5 4750 input TPM per PTU», prompt-cache 100%-rabatt — alle bekreftet eksakt korrekte.
- DRIFT (kirurgisk): spillover (preview)→GA (3 steder) + DeepSeek/Llama-unntak; ny «Priority
  processing» deployment-kategori lagt til; kilde-stempel re-verifisert juni 2026.
- Priser urørt (eksplisitt disclaimed illustrative NOK, feb-2026-stemplet).
- Header 2026-02→2026-06 + Source-backfill. validate 239/0.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

skills/ms-ai-security/references/cost-optimization/ptu-vs-paygo-economics.md

@@ -1,8 +1,9 @@
 # PTU vs Pay-as-You-Go: Economic Decision Framework
 
-**Last updated:** 2026-02
+**Last updated:** 2026-06
 **Status:** GA
 **Category:** Cost Optimization & FinOps for AI
+**Source:** https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput
 
 ---
 
@@ -12,6 +13,8 @@ Valget mellom Provisioned Throughput Units (PTU) og Pay-as-You-Go (PayGo) for Az
 
 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
@@ -103,7 +106,7 @@ En hybrid tilnærming, der man kombinerer PTU for stabil baseline-traffic og Pay
 
 ### 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.
+**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
@@ -120,7 +123,7 @@ En hybrid tilnærming, der man kombinerer PTU for stabil baseline-traffic og Pay
 ```
 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%
+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
@@ -400,7 +403,7 @@ En hybrid tilnærming, der man kombinerer PTU for stabil baseline-traffic og Pay
 
 ## Kilder og verifisering
 
-**Microsoft Learn-ressurser (MCP-verified, februar 2026):**
+**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
@@ -434,9 +437,9 @@ En hybrid tilnærming, der man kombinerer PTU for stabil baseline-traffic og Pay
    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 (Preview):**
-   https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/spillover-traffic-management
-   *Confidence: Verified* – Automatic routing fra PTU til PayGo ved capacity limit.
+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