ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-security/references/cost-optimization/inference-endpoint-cost-optimization.md

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:

# 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:

# 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:

# 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:

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:

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

<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 — Verified
• Autoscale online endpoints in Azure Machine Learning — Verified
• View costs for an Azure Machine Learning managed online endpoint — Verified
• Plan to manage costs for Azure Machine Learning — Verified

Serverless API Endpoints:

• Deploy models as serverless API deployments (AI Foundry Portal) — Verified
• Plan and manage costs for Microsoft Foundry — Verified
• Plan to manage costs for Azure OpenAI in Azure AI Foundry Models — Verified

Cost Governance:

• Govern Azure platform services (PaaS) for AI — Verified
• 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)