ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-security/references/cost-optimization/ptu-vs-paygo-economics.md

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

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

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 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).