# Managed Inference Endpoints: Cost Optimization

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

---

## Introduksjon

Managed inference endpoints i Azure Machine Learning og Azure AI Foundry representerer en betydelig kostnadsfaktor i AI-prosjekter, men de tilbyr også omfattende muligheter for kostnadsoptimalisering gjennom riktig konfigurasjon og strategisk ressursforvaltning. Denne kunnskapsreferansen dekker både managed compute endpoints (Azure ML) og serverless API endpoints (Azure AI Foundry), med fokus på praktiske optimaliseringsstrategier som kan redusere Total Cost of Ownership (TCO) uten å kompromittere på ytelse eller tilgjengelighet.

Forskjellen mellom deployment-typer er vesentlig for kostnadsoptimalisering: Managed compute endpoints krever at du betaler for provisjonerte VM-instanser per time uavhengig av bruk, mens serverless endpoints (pay-as-you-go) belaster per token og request. Å velge riktig deployment-modell basert på trafikkprofil, konsistens og modellkrav er første skritt mot kostnadseffektiv inferencing.

Hovedutfordringen for de fleste organisasjoner er å balansere tre faktorer: kostnader (compute-timer, token-forbruk), ytelse (latency, throughput) og tilgjengelighet (SLA-krav). Autoscaling, instance-sizing, idle-capacity management og endpoint-consolidering er kjernestrategier som adresserer denne balansen direkte.

## Kjernekomponenter

### Deployment-typer og kostnadsmodeller

| Deployment Type | Prismodell | Best for | Kostnadsprofil |
|----------------|------------|----------|----------------|
| **Managed Online Endpoint** | VM-timer (per instance, per hour) | Konsistent, forutsigbar trafikk | Fast timekostnad uavhengig av requests |
| **Serverless API Endpoint** | Pay-per-token + pay-per-request | Variabel, uforutsigbar trafikk | Kun kostnad ved faktisk bruk |
| **Provisioned Throughput (PTU)** | Fast månedskostnad for reservert kapasitet | Stable workloads med høy throughput | Lavere enhetskostnad for høy bruk |
| **Low-Priority VMs** | 50-80% rabatt vs. dedicated VMs | Batch inference, ikke-kritiske workloads | Betydelig kostnadsbesparing med preemption-risiko |

### Autoscaling-konfigurasjonskomponenter

| Parameter | Beskrivelse | Kostnadspåvirkning |
|-----------|-------------|---------------------|
| **Minimum instances** | Laveste antall instanser som alltid kjører | Sett til 0 for non-prod for å unngå idle-kostnader |
| **Maximum instances** | Øvre grense for skalering | Beskytter mot ukontrollert kostnadsøkning |
| **Default instances** | Starttilstand ved deployment | Bør matche forventet base load |
| **Scale-out threshold** | Metric-verdi som trigger scale-out (f.eks. CPU > 70%) | Lavere threshold = mer proaktiv (dyrere), høyere = mer reaktiv |
| **Scale-in threshold** | Metric-verdi som trigger scale-in (f.eks. CPU < 30%) | Høyere threshold = raskere scale-down (billigere) |
| **Cooldown period** | Ventetid etter scale-action før ny action tillates | Forhindrer "flapping" som gir unødvendige compute-timer |
| **Idle time before scale-down** | Sekunder før idle node frigjøres (default: 120s) | Lavere = raskere kostnadsbesparing, men mer hyppig re-provisioning |

### Instance-størrelser og kostnad per time (estimat NOK)

| VM Series | vCPU | RAM (GB) | GPU | Pris ca. NOK/time | Use Case |
|-----------|------|----------|-----|-------------------|----------|
| **Standard_DS2_v2** | 2 | 7 | - | ~10 kr | Små modeller, dev/test |
| **Standard_DS3_v2** | 4 | 14 | - | ~20 kr | Mellomstore modeller |
| **Standard_F2s_v2** | 2 | 4 | - | ~8 kr | Compute-optimized, lav minne |
| **Standard_NC4as_T4_v3** | 4 | 28 | T4 | ~80 kr | GPU inference for DNN |
| **Standard_NC6s_v3** | 6 | 112 | V100 | ~300 kr | Høy-ytelse GPU inference |

*Priser er estimert (2026) og varierer per region. Sjekk alltid Azure Pricing Calculator for oppdaterte priser.*

### Metrics for autoscaling

| Metric | Scope | Threshold-anbefaling | Brukstilfelle |
|--------|-------|----------------------|---------------|
| **CpuUtilizationPercentage** | Deployment | Scale-out: >70%, Scale-in: <30% | Generell last-basert scaling |
| **RequestLatency** | Endpoint | Scale-out: >70ms avg 5 min | Latency-sensitiv applikasjoner |
| **RequestsPerMinute** | Endpoint | Basert på SLA-krav | Throughput-basert scaling |
| **GpuUtilizationPercentage** | Deployment (GPU) | Scale-out: >80%, Scale-in: <40% | GPU-intensive modeller |
| **MemoryUtilizationPercentage** | Deployment | Scale-out: >85%, Scale-in: <50% | Modeller med høyt minneforbruk |

## Arkitekturmønstre

### Mønster 1: Hybrid Serverless + Managed Compute

**Scenario:** Organisasjonen har stabil base load med sporadiske trafikk-spikes (f.eks. morgen-rush, kampanjeperioder).

**Løsning:**
- **Managed compute endpoint** med autoscaling for base load (2-4 instances)
- **Serverless endpoint** for overflow-trafikk via API Management routing
- Gateway-logikk som ruter overflow til serverless ved høy last

**Kostnadsfordel:**
- Base load håndteres av kostnadseffektiv dedicated compute
- Spikes håndteres av serverless uten å over-provisjonere managed instances
- Typisk besparelse: 30-50% vs. ren managed compute med peak-dimensjonering

**Implementering:**
```python
# Managed endpoint med autoscaling (base load)
from azure.mgmt.monitor.models import AutoscaleProfile, ScaleRule, MetricTrigger, ScaleAction

base_profile = AutoscaleProfile(
    name="base-load-profile",
    capacity={"minimum": 2, "maximum": 4, "default": 2},
    rules=[
        ScaleRule(
            metric_trigger=MetricTrigger(
                metric_name="CpuUtilizationPercentage",
                metric_resource_uri=deployment.id,
                time_window=datetime.timedelta(minutes=5),
                statistic="Average",
                operator="GreaterThan",
                threshold=70
            ),
            scale_action=ScaleAction(
                direction="Increase",
                type="ChangeCount",
                value=1,
                cooldown=datetime.timedelta(minutes=10)
            )
        )
    ]
)

# API Management routing-policy for overflow til serverless
# (defineres i APIM policy-XML)
```

**Trade-offs:**
- Økt kompleksitet i routing-logikk
- Behov for API Management (tilleggskostnad)
- Latency-variasjon mellom managed/serverless

---

### Mønster 2: Schedule-Based Scaling for Forutsigbare Mønstre

**Scenario:** Offentlig sektor-applikasjon med tydelig dag/natt og helge-mønster (f.eks. saksbehandlingssystemer).

**Løsning:**
- Schedule-basert autoscaling med ulike profiler for arbeidstid, natt og helg
- Aggressiv scale-down til 0 instances utenfor arbeidstid (non-prod)
- Prod: minimum 1 instance for tilgjengelighet, resten schedule-basert

**Kostnadsfordel:**
- Eliminerer idle-kostnader utenfor arbeidstid (50-70% av døgnet)
- Typisk besparelse: 40-60% for workloads med tydelig mønster

**Implementering:**
```python
# Arbeidstid-profil (man-fre 07:00-17:00)
workday_profile = AutoscaleProfile(
    name="workday-hours",
    capacity={"minimum": 3, "maximum": 10, "default": 3},
    recurrence=Recurrence(
        frequency="Week",
        schedule=RecurrentSchedule(
            time_zone="W. Europe Standard Time",
            days=["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
            hours=[7],
            minutes=[0]
        )
    )
)

# Natt/helg-profil
offhours_profile = AutoscaleProfile(
    name="offhours-minimum",
    capacity={"minimum": 0, "maximum": 2, "default": 1},  # 0 for non-prod
    recurrence=Recurrence(
        frequency="Week",
        schedule=RecurrentSchedule(
            time_zone="W. Europe Standard Time",
            days=["Saturday", "Sunday"],
            hours=[],
            minutes=[]
        )
    )
)
```

**Trade-offs:**
- Cold start-latency når skalering fra 0
- Krever nøyaktig analyse av trafikkprofil
- Mindre fleksibel ved uforutsigbare hendelser

---

### Mønster 3: Endpoint Consolidation med Model Registry

**Scenario:** Organisasjonen har mange modeller med lav individuell trafikk, hver deployet til separat endpoint.

**Løsning:**
- Samle flere modeller i én managed endpoint med multi-model serving
- Bruk model registry og dynamisk model-loading i scoring script
- Én sett med autoscaling-instanser deles av alle modeller

**Kostnadsfordel:**
- Reduserer antall idle instances (N endpoints med 1 instance hver → 1 endpoint med 2-3 instances totalt)
- Typisk besparelse: 60-80% for low-traffic modell-kataloger

**Implementering:**
```python
# Scoring script med multi-model support
import os
import json
from azureml.core.model import Model

def init():
    global models
    models = {}
    # Last alle modeller fra model registry
    model_dir = os.getenv("AZUREML_MODEL_DIR")
    for model_name in os.listdir(model_dir):
        model_path = os.path.join(model_dir, model_name)
        models[model_name] = load_model(model_path)

def run(raw_data):
    data = json.loads(raw_data)
    model_name = data.get("model", "default")
    input_data = data.get("data")

    if model_name not in models:
        return {"error": "Model not found"}

    return models[model_name].predict(input_data)
```

**Trade-offs:**
- Økt kompleksitet i scoring script
- Memory footprint øker med antall modeller (krever større instance)
- Potensielt redusert isolation mellom modeller

## Beslutningsveiledning

### Når velge Managed Compute vs. Serverless

| Faktor | Managed Compute | Serverless API |
|--------|-----------------|----------------|
| **Trafikkmønster** | Konsistent, forutsigbar | Sporadisk, uforutsigbar |
| **Request volume** | >10 000 requests/dag | <10 000 requests/dag |
| **Modellstørrelse** | Stor (>1GB), krever GPU | Liten-medium (<500MB) |
| **Latency-krav** | <100ms (P95) | <500ms akseptabelt |
| **Custom runtime** | Ja (BYOC support) | Begrenset (standard runtimes) |
| **Kostnadskontroll** | Forutsigbar (fixed hourly) | Variabel (token-basert) |
| **Governance** | Full kontroll over compute | Managed (mindre kontroll) |

### Vanlige feil og røde flagg

| Anti-pattern | Konsekvens | Løsning |
|--------------|------------|---------|
| **Minimum instances > 0 i non-prod** | Kontinuerlig kostnad selv uten bruk | Sett min=0 for dev/test environments |
| **Ingen autoscaling-regler** | Over-provisioning for peak load 24/7 | Implementer metric-basert autoscaling |
| **Feil instance-størrelse** | Betaler for ubrukt CPU/RAM eller dårlig ytelse | Start med profiling, juster basert på metrics |
| **Glemt å slette failed deployments** | Compute fortsetter å kjøre og koste | Automatiser cleanup via Azure Policy |
| **Ett endpoint per modell (low traffic)** | Mange idle instances | Konsolider til multi-model endpoint |
| **Ingen cooldown-periode** | Flapping (rapid scale up/down) | Sett cooldown til 5-10 minutter |
| **For aggressive scale-in** | Hyppig cold start, dårlig brukeropplevelse | Øk idle-time før scale-down til 5-10 min |
| **Serverless for høy-volum workload** | Token-kostnader eksploderer | Migrer til Provisioned Throughput (PTU) eller managed compute |

### Beslutningstrær

**Velg deployment-type:**
```
START
│
├─ Er trafikk konsistent (>50% av døgnet aktiv)?
│  ├─ JA → Managed Compute Endpoint
│  └─ NEI → Er total monthly requests >100k?
│     ├─ JA → Hybrid (Managed base + Serverless overflow)
│     └─ NEI → Serverless API Endpoint
│
└─ Trenger du GPU for inferencing?
   ├─ JA → Managed Compute Endpoint (GPU SKU)
   └─ NEI → (fortsett analyse over)
```

**Velg autoscaling-strategi:**
```
START
│
├─ Har du tydelig dag/natt eller uke/helg-mønster?
│  ├─ JA → Schedule-Based Scaling
│  └─ NEI → Metrics-Based Scaling (CPU/latency)
│
├─ Er workload mission-critical (SLA >99.9%)?
│  ├─ JA → Minimum instances ≥ 2 (HA), conservative scale-in
│  └─ NEI → Minimum instances = 0 (non-prod) eller 1 (prod)
│
└─ Er latency mer kritisk enn kostnad?
   ├─ JA → Proaktiv scaling (lavere threshold, høyere min instances)
   └─ NEI → Reaktiv scaling (høyere threshold, aggressiv scale-in)
```

## Integrasjon med Microsoft-stakken

### Azure AI Foundry

**Serverless endpoints:**
- Provisjoneres via AI Foundry Portal eller SDK (`ServerlessEndpoint`)
- Støtter Microsoft-modeller (Phi-3, m.fl.) og Azure Marketplace-modeller
- Kostnadsoppfølging via Azure Cost Management med marketplace-meters

**Managed compute (via Azure ML integration):**
- Krever Azure ML workspace attachment til AI Foundry hub
- Deployes som `ManagedOnlineEndpoint` via Azure ML SDK/CLI
- Full autoscaling-support via Azure Monitor

### Azure Machine Learning

**Managed Online Endpoints:**
```python
from azure.ai.ml.entities import ManagedOnlineEndpoint, ManagedOnlineDeployment

endpoint = ManagedOnlineEndpoint(
    name="cost-optimized-endpoint",
    auth_mode="key"
)

deployment = ManagedOnlineDeployment(
    name="blue",
    endpoint_name=endpoint.name,
    model=model,
    instance_type="Standard_DS3_v2",  # Right-sized for workload
    instance_count=2  # Minimum for HA, autoscaling vil justere
)
```

**Autoscaling via Azure Monitor:**
```python
from azure.mgmt.monitor import MonitorManagementClient

mon_client.autoscale_settings.create_or_update(
    resource_group,
    autoscale_settings_name,
    parameters={
        "target_resource_uri": deployment.id,
        "profiles": [base_profile, workday_profile, offhours_profile]
    }
)
```

### Azure API Management (APIM)

**Gateway for cost optimization:**
- Rate limiting for å kontrollere token-forbruk (serverless)
- Circuit breaker for å unngå kaskerende failures og kostnader
- Routing-policies for hybrid managed/serverless
- Caching av inference-resultater for identiske requests

**Policy-eksempel (rate limiting):**
```xml
<policies>
    <inbound>
        <rate-limit calls="1000" renewal-period="60" />
        <quota calls="100000" renewal-period="86400" />
    </inbound>
</policies>
```

### Azure Monitor & Cost Management

**Cost tracking:**
- Managed endpoints: Tag-basert kostnadssporing (`azuremlendpoint`, `azuremldeployment`)
- Serverless: Meters i Azure Cost Management (separate for Microsoft vs. Marketplace-modeller)
- Budsjett-alerts for proaktiv kostnadskontroll

**Metrics for optimalisering:**
- `CpuUtilizationPercentage` → Instance sizing
- `RequestLatency` → Performance vs. cost trade-off
- `RequestsPerMinute` → Autoscaling threshold-tuning

## Offentlig sektor (Norge)

### Datasuverenitet og compliance

**Deployment-valg:**
- **Managed compute:** Full kontroll over compute-region (velg Norway East/West for data residency)
- **Serverless:** Begrenset region-valg (verifiser at serverless-modeller støtter norske regioner)
- **Marketplace-modeller:** Data kan prosesseres utenfor Norge (GDPR-vurdering nødvendig)

**Compliance-krav:**
- Offentlige virksomheter: Foretrekk managed compute med norsk region for sensitive data
- PTU-modeller (Azure OpenAI): Garantert kapasitet i spesifikk region

### Budsjettprosesser

**Utfordringer:**
- Offentlig sektor opererer ofte med årlige, faste budsjetter
- Serverless (variable kostnader) kan være utfordrende å budsjettere
- Behov for kostnadskontroll og forecasting

**Løsninger:**
- **Commitment tiers:** Fast månedskostnad for forutsigbar budsjettplanlegging
- **Azure Reservations:** 1-3 års commitment for managed VMs (opptil 72% rabatt)
- **Cost Management budgets:** Automatiske alerts ved 50%, 80%, 100% av budsjett
- **Quarterly reviews:** Analyser faktisk forbruk vs. budsjett, juster autoscaling-regler

**Budget-modell for offentlig sektor:**
```
Årlig budsjett = (Antall arbeidsdager × arbeidstimer × prod instances × timepris)
                + (Antall helg/natt-timer × min instances × timepris)
                + 20% buffer for spikes og testing

Eksempel (Standard_DS3_v2, ~20 kr/time):
- Prod: 250 dager × 10 timer × 3 instances × 20 kr = 150 000 kr
- Off-hours: 6 000 timer × 1 instance × 20 kr = 120 000 kr
- Buffer (20%): 54 000 kr
TOTAL: ~324 000 kr/år
```

### Sikkerhetsoverveielser

- **Network isolation:** Managed endpoints støtter private endpoints (VNet integration)
- **Serverless:** Mindre kontroll over network-isolasjon (managed service)
- **Secrets management:** Bruk Azure Key Vault for API-nøkler og connection strings

## Kostnad og lisensiering

### Prismodeller (Azure ML Managed Endpoints)

**Compute-kostnader:**
- Betaler for VM-instanser per time (uavhengig av request-volum)
- Ingen ekstra "surcharge" for managed endpoint-tjenesten
- Network egress kan gi tilleggskostnader (data ut av Azure)

**Kostnadskomponenter:**
```
Total kostnad = (Instance hours × Instance price)
              + (Network egress × Data transfer price)
              + (Storage for models og logs)
```

**Managed virtual network (optional):**
- Tilleggskostnad for private link og FQDN outbound rules
- Kun relevant hvis VNet-isolasjon er påkrevd (typisk prod)

### Prismodeller (Serverless API Endpoints)

**Token-basert prising:**
- Pris per 1M tokens (input og output prises separat)
- Pris per 1000 API requests
- Quota: 200k tokens/min og 1k requests/min per deployment (standard)

**Microsoft-modeller (direkte fra Azure):**
- Phi-3: ~10 kr per 1M input tokens, ~30 kr per 1M output tokens (estimat)
- Priser vises i "Pricing and terms" tab ved deployment

**Marketplace-modeller (tredjepart):**
- Faktureres via Azure Marketplace (SaaS-meters)
- Separate meters for input/output tokens
- Prisene varierer sterkt per modell og leverandør

### Optimaliseringstips

| Strategi | Kostnadsbesparing | Kompleksitet | Risiko |
|----------|-------------------|--------------|--------|
| **Sett min instances = 0 (non-prod)** | 30-50% | Lav | Lav (kun dev/test) |
| **Implementer autoscaling** | 20-40% | Medium | Lav |
| **Schedule-based scaling** | 40-60% | Medium | Lav |
| **Right-size instances** | 15-30% | Lav | Medium (krever profiling) |
| **Low-priority VMs (batch)** | 50-80% | Lav | Høy (preemption) |
| **Azure Reservations (1-3 år)** | 30-72% | Lav | Medium (lock-in) |
| **Endpoint consolidation** | 60-80% | Høy | Medium (shared resources) |
| **Hybrid managed/serverless** | 30-50% | Høy | Lav |
| **APIM caching** | 10-30% | Medium | Lav |
| **Serverless → PTU migration** | 40-70% | Medium | Lav (for high-volume) |

**Prioritering for quick wins:**
1. **Non-prod min instances = 0** (umiddelbar 30%+ saving på non-prod)
2. **Implementer metric-based autoscaling** (20-40% saving på prod)
3. **Right-size instances** (15-30% saving, krever én gang profiling)
4. **Schedule-based scaling for forutsigbare workloads** (40-60% for offentlig sektor)

**Langsiktige strategier:**
1. Azure Reservations for stabile prod-workloads (1-års commitment)
2. Endpoint consolidation for low-traffic modell-kataloger
3. Hybrid arkitektur for variable workloads

### VM-størrelser og use cases

| Scenario | Anbefalt SKU | Pris ca. NOK/time | Reasoning |
|----------|--------------|-------------------|-----------|
| **Små scikit-learn modeller** | Standard_F2s_v2 | ~8 kr | Compute-optimized, lav memory |
| **Medium PyTorch/TensorFlow** | Standard_DS3_v2 | ~20 kr | Balansert CPU/RAM |
| **Stor transformer-modell (CPU)** | Standard_D8s_v3 | ~60 kr | Høy RAM for modell i minne |
| **GPU inference (BERT, ResNet)** | Standard_NC4as_T4_v3 | ~80 kr | T4 GPU, kostnadseffektiv |
| **High-performance GPU (GPT, Stable Diffusion)** | Standard_NC6s_v3 | ~300 kr | V100 GPU for tunge modeller |

**Valg-metodikk:**
1. Start med smallest instance som passer modellkrav (memory footprint)
2. Load-test med realistisk trafikk
3. Analyser CPU/GPU/Memory utilization metrics i Azure Monitor
4. Right-size: Hvis avg utilization <40%, downgrade; hvis >80%, upgrade
5. Iterer til optimal balance (70-80% avg utilization under normal load)

## For arkitekten (Cosmo)

### Spørsmål å stille kunden

**Trafikkprofil:**
1. Hva er forventet request-volum per dag/time? Er det forutsigbart mønster (dag/natt, uke/helg)?
2. Hva er peak vs. average traffic ratio? (f.eks. 10x spike under kampanjer?)
3. Hvor kritisk er lav latency? Hva er akseptabel P95-latency? (<100ms, <500ms, <1s?)
4. Er det seasonality i bruken? (f.eks. skoleår vs. sommerferie for utdanningssektor)

**Modell og ytelse:**
5. Hva er modellstørrelse og runtime-krav? (CPU, GPU, RAM, disk)
6. Hvor lang er cold start-tiden for modellen? (viktig for autoscaling fra 0)
7. Har dere flere modeller? Hvor mange, og hva er trafikk-fordeling?

**Kostnad og budsjettering:**
8. Hva er budsjettramme for inference-kostnader per måned/år?
9. Har dere eksisterende Azure commitments (EA, reservations)?
10. Er dere villige til å akseptere variable kostnader (serverless) eller foretrekk forutsigbarhet?

**Governance og compliance:**
11. Har dere data residency-krav? (må data forbli i Norge/EU?)
12. Krever dere network isolation (VNet, private endpoints)?
13. Er det interne prosesser for cost approval og budsjett-tracking?

### Fallgruver å unngå

**Tekniske:**
- **Over-provisioning for worst-case:** Mange dimensjonerer for peak load 24/7. Bruk autoscaling i stedet.
- **Ingen monitoring før optimalisering:** Implementer metrics-innsamling fra dag 1 for data-drevet tuning.
- **Glemt cleanup av failed deployments:** Compute blir værende og koster. Automatiser cleanup.
- **Feil instance-sizing:** Start konservativt (større instance), profiler, og downgrade. Billigere enn å re-deploye pga. OOM.

**Organisatoriske:**
- **Manglende cost governance:** Sett opp Azure Cost Management budgets og alerts før deployment.
- **Siloed beslutninger:** Inference-kostnader må ses i sammenheng med training, storage, networking (TCO).
- **Ingen re-evaluering:** Trafikkprofil endrer seg. Quarterly reviews av autoscaling-regler er essensielt.

**Offentlig sektor-spesifikke:**
- **Budsjettrigiditet:** Årsbudsjetter passer dårlig med variable cloud-kostnader. Bruk commitment tiers/reservations for forutsigbarhet.
- **Procurement-forsinkelser:** Azure Marketplace-modeller kan kreve procurement-godkjenning. Plan for dette.
- **Compliance-antagelser:** Ikke anta at serverless oppfyller data residency-krav. Verifiser.

### Anbefalinger per modenhetsnivå

**Nivå 1: Pilot/PoC (1-2 modeller, <1000 requests/dag)**
- Start med **serverless endpoints** for enkelhet og null idle-cost
- Implementer basic monitoring (Azure Monitor metrics)
- Sett opp cost alerts (50%, 80%, 100% av budsjett)
- **Ikke** bruk autoscaling ennå (unødvendig kompleksitet)

**Nivå 2: Production (3-10 modeller, 1k-50k requests/dag)**
- Migrer til **managed compute endpoints** med autoscaling
- Implementer schedule-based scaling hvis klart mønster
- Right-size instances basert på 2-4 ukers metrics
- Sett opp tag-basert kostnadssporing per deployment
- Vurder Azure Reservations for 1-års commitment

**Nivå 3: Skalert produksjon (10+ modeller, >50k requests/dag)**
- Implementer **hybrid arkitektur** (managed base + serverless overflow)
- Konsolider low-traffic modeller til multi-model endpoints
- Bruk APIM for rate limiting, caching og advanced routing
- Automatiser cost optimization via Azure Policy (f.eks. auto-delete idle deployments)
- Quarterly FinOps-reviews med re-tuning av autoscaling-strategi

**Nivå 4: Enterprise-skala (100+ modeller, millioner requests/dag)**
- Vurder **Provisioned Throughput (PTU)** for høy-volum modeller (Azure OpenAI)
- Implementer multi-region deployment for geo-distribusjon og cost arbitrage
- Bruk custom autoscaling-metrics (business KPIs, ikke bare CPU)
- Dedikert FinOps-team for kontinuerlig optimalisering
- Integrer cost-data i ML platform (kostnad per prediction synlig for data scientists)

### Kostnadsforventninger og benchmarks

**Typiske kostnader per 1000 predictions (estimat):**
- Enkel modell (scikit-learn, Standard_F2s_v2): 0,10-0,50 kr
- Medium kompleksitet (PyTorch/TF, Standard_DS3_v2): 0,50-2 kr
- GPU-modell (T4, Standard_NC4as_T4_v3): 2-8 kr
- Serverless (Azure OpenAI GPT-4o-mini): 0,50-5 kr (avhenger av token-lengde)

**ROI-indikator:**
Hvis inference-kostnad per prediction >10% av business value per prediction, er det rom for optimalisering.

*(Verified MCP 2026-04)*

## Kilder og verifisering

### Microsoft Learn-dokumentasjon (Verified via MCP)

**Managed Online Endpoints:**
- [Manage and optimize Azure Machine Learning costs](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-manage-optimize-cost?view=azureml-api-2) — **Verified**
- [Autoscale online endpoints in Azure Machine Learning](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-autoscale-endpoints?view=azureml-api-2) — **Verified**
- [View costs for an Azure Machine Learning managed online endpoint](https://learn.microsoft.com/en-us/azure/machine-learning/how-to-view-online-endpoints-costs?view=azureml-api-2) — **Verified**
- [Plan to manage costs for Azure Machine Learning](https://learn.microsoft.com/en-us/azure/machine-learning/concept-plan-manage-cost?view=azureml-api-2) — **Verified**

**Serverless API Endpoints:**
- [Deploy models as serverless API deployments (AI Foundry Portal)](https://learn.microsoft.com/en-us/azure/ai-foundry/how-to/deploy-models-serverless?view=foundry-classic) — **Verified**
- [Plan and manage costs for Microsoft Foundry](https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/manage-costs?view=foundry-classic) — **Verified**
- [Plan to manage costs for Azure OpenAI in Azure AI Foundry Models](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/manage-costs) — **Verified**

**Cost Governance:**
- [Govern Azure platform services (PaaS) for AI](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/platform/governance) — **Verified**
- [Manage AI costs](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/ai/manage#manage-ai-costs) — **Verified**

### Konfidensnivå per seksjon

| Seksjon | Konfidens | Kilde |
|---------|-----------|-------|
| Deployment-typer og kostnadsmodeller | **Verified** | Microsoft Learn MCP |
| Autoscaling-komponenter | **Verified** | Microsoft Learn MCP |
| Instance-størrelser og priser | **Baseline** | Azure Pricing Calculator (generiske estimater, ikke MCP) |
| Arkitekturmønstre | **Baseline** | Modellkunnskap + Microsoft Learn patterns |
| Beslutningsveiledning | **Baseline** | Best practices fra CAF + modellkunnskap |
| Integrasjon med Microsoft-stakken | **Verified** | Microsoft Learn MCP (SDK-eksempler) |
| Offentlig sektor (Norge) | **Baseline** | Generell offentlig sektor-kontekst (ikke MCP-verifisert) |
| Kostnad og lisensiering | **Verified** | Microsoft Learn pricing docs via MCP |
| For arkitekten | **Baseline** | Konsulenterfaring-simulering (modellkunnskap) |

**Totalt MCP-kall:** 3 (microsoft_docs_search) + 2 (microsoft_docs_fetch) + 1 (microsoft_code_sample_search) = 6
**Unike kilder:** 12 Microsoft Learn-artikler

---

**Sist oppdatert:** 2026-02
**Versjon:** 1.0
**Forfatter:** Cosmo Skyberg (AI-generert kunnskapsbase via MCP-research)
