feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs]
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.
This commit is contained in:
parent
ed92d65385
commit
ddce43d8b2
330 changed files with 4643 additions and 83 deletions
|
|
@ -3,6 +3,19 @@
|
|||
**Kategori:** AI Security Engineering
|
||||
**Dato:** 2026-06-19
|
||||
**Status:** Aktiv
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/concepts/ai-red-teaming-agent
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Oversikt](#oversikt)
|
||||
- [Adversarial Test Case Generation](#adversarial-test-case-generation)
|
||||
- [Fuzzing Frameworks for AI](#fuzzing-frameworks-for-ai)
|
||||
- [Input Perturbation Techniques](#input-perturbation-techniques)
|
||||
- [Robustness Metrics](#robustness-metrics)
|
||||
- [Continuous Security Testing](#continuous-security-testing)
|
||||
- [For Cosmo: Practical Implementation](#for-cosmo-practical-implementation)
|
||||
- [References](#references)
|
||||
|
||||
## Oversikt
|
||||
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-05 | Verified: MCP 2026-05
|
||||
**Status:** Established Practice
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/backup/backup-overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Effektiv håndtering av sikkerhetsbrudd i AI-systemer krever spesialiserte prosedyrer som adresserer både tradisjonelle cybersecurity-trusler og AI-spesifikke sårbarheter som data poisoning, model inversion og prompt injection. Moderne AI-systemer opererer i komplekse økosystemer hvor angrep kan manifestere seg på tvers av datalag, treningsinfrastruktur, inferens-endepunkter og integrasjoner med forretningsapplikasjoner.
|
||||
|
|
|
|||
|
|
@ -4,6 +4,22 @@
|
|||
**Sist oppdatert:** 2026-06-19
|
||||
**Målgruppe:** Arkitekter som skal beskytte AI-systemer mot prompt injection og jailbreak-angrep
|
||||
**Status:** To separate produkter — Content Safety Prompt Shields (GA), AI Gateway Prompt Shield (Preview)
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/ai-services/content-safety/overview
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Del 1: Azure AI Content Safety Prompt Shields (GA)](#del-1-azure-ai-content-safety-prompt-shields-ga)
|
||||
- [Del 2: AI Gateway Prompt Shield via Global Secure Access (Preview)](#del-2-ai-gateway-prompt-shield-via-global-secure-access-preview)
|
||||
- [Del 3: Azure API Management — Gateway-nivå Prompt Shield](#del-3-azure-api-management--gateway-nivå-prompt-shield)
|
||||
- [Del 4: Groundedness Detection — Relatert funksjonalitet](#del-4-groundedness-detection--relatert-funksjonalitet)
|
||||
- [Relevans for norsk offentlig sektor](#relevans-for-norsk-offentlig-sektor)
|
||||
- [Forsvarsdybde-arkitektur (Defence in Depth)](#forsvarsdybde-arkitektur-defence-in-depth)
|
||||
- [Kostnadsestimater](#kostnadsestimater)
|
||||
- [Kjente begrensninger](#kjente-begrensninger)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
- [Referanser](#referanser)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
|
|
|
|||
|
|
@ -4,9 +4,26 @@
|
|||
**Sist oppdatert:** 2026-02-05
|
||||
**Relatert:** ai-prompt-injection-defense.md, ai-jailbreak-prevention.md
|
||||
**Source:** https://learn.microsoft.com/security/ai-red-team/training
|
||||
**Type:** reference
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Oversikt](#oversikt)
|
||||
- [Red Team Metodikk for AI](#red-team-metodikk-for-ai)
|
||||
- [Verktøy for AI Red Teaming](#verktøy-for-ai-red-teaming)
|
||||
- [Attack Simulation Planning](#attack-simulation-planning)
|
||||
- [Safe Testing Boundaries](#safe-testing-boundaries)
|
||||
- [Tolking av Resultater](#tolking-av-resultater)
|
||||
- [Dokumentasjon og Logging](#dokumentasjon-og-logging)
|
||||
- [Integrasjon i CI/CD Pipelines](#integrasjon-i-cicd-pipelines)
|
||||
- [Continuous Red Teaming](#continuous-red-teaming)
|
||||
- [For Cosmo: Anvendelse i Microsoft AI-arkitektur](#for-cosmo-anvendelse-i-microsoft-ai-arkitektur)
|
||||
- [Ressurser og Training](#ressurser-og-training)
|
||||
- [Sjekkliste: Red Teaming Readiness](#sjekkliste-red-teaming-readiness)
|
||||
- [Key Takeaways for Arkitekter](#key-takeaways-for-arkitekter)
|
||||
|
||||
## Oversikt
|
||||
|
||||
Praktisk veiledning for å gjennomføre red teaming-operasjoner mot AI-systemer. Dekker metodikk, verktøy, testmiljøer og dokumentasjon av funn.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** Established Practice
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/security/benchmark/azure/mcsb-v2-artificial-intelligence-security
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Å score og rangere AI-sikkerhetsrisiko krever et strukturert rammeverk som kombinerer kvantitativ måling med kvalitativ vurdering. Microsoft sin tilnærming, basert på AI Risk Assessment Framework v4.1.4, gir en systematisk metode for å evaluere AI-systemer gjennom hele livssyklusen — fra datainnsamling til produksjonsdrift.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-05 | Verified: MCP 2026-05
|
||||
**Status:** Established Practice
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/ai/playbook/technology-guidance/generative-ai/mlops-in-openai/security/security-plan-llm-application
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Trusselmodellering for AI-systemer krever en tilpasning av etablerte sikkerhetsprinsipper til nye angrepsflater som er spesifikke for maskinlæring og generativ AI. Microsoft har utvidet det klassiske STRIDE-rammeverket (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) til å dekke AI-spesifikke trusler som datapoisoning, adversarial attacks, model inversion og prompt injection.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry-classic/foundry-models/concepts/content-filter
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Content Safety-filtre i Microsoft AI-stakken krever nøye kalibrering for å balansere sikkerhet med brukervennlighet. Feil konfigurering fører enten til for mange false positives (legitim brukergenerert innhold blokkeres) eller false negatives (skadelig innhold slipper gjennom). For norsk offentlig sektor er dette spesielt kritisk: filterkalibrering må håndtere norsk språkkontekst, kulturelle nyanser og juridiske krav til transparens og etterprøvbarhet.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,23 @@
|
|||
**Kategori:** AI Security Engineering
|
||||
**Sist oppdatert:** 2026-06-19 | Verified: MCP 2026-06-19
|
||||
**Målgruppe:** Enterprise AI architects og security teams
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/security/benchmark/azure/mcsb-v2-artificial-intelligence-security
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Oversikt](#oversikt)
|
||||
- [1. Prompt Context Isolation](#1-prompt-context-isolation)
|
||||
- [2. Model Extraction Defense](#2-model-extraction-defense)
|
||||
- [3. Membership Inference Protection](#3-membership-inference-protection)
|
||||
- [4. DLP Policy Enforcement Across AI Workloads](#4-dlp-policy-enforcement-across-ai-workloads)
|
||||
- [5. Cache Security Management](#5-cache-security-management)
|
||||
- [6. Praktiske Arkitekturmønstre](#6-praktiske-arkitekturmønstre)
|
||||
- [7. Compliance & Audit](#7-compliance--audit)
|
||||
- [8. Tooling & Automation](#8-tooling--automation)
|
||||
- [9. Monitoring & Detection](#9-monitoring--detection)
|
||||
- [10. Anbefalinger for Cosmo Skyberg](#10-anbefalinger-for-cosmo-skyberg)
|
||||
- [For Cosmo Skyberg](#for-cosmo-skyberg)
|
||||
|
||||
## Oversikt
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@
|
|||
**Last updated:** 2026-06-24 | Verified: MCP 2026-06-24
|
||||
**Status:** GA (AI applications) · Preview (AI agents, fra 2026-02-02)
|
||||
**Category:** AI Security Engineering — Threat Detection & Monitoring
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/defender-for-cloud/ai-threat-protection
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,8 @@
|
|||
**Sist oppdatert:** 2026-06-19 | Verified: MCP 2026-06
|
||||
**Status:** Public Preview, utvidet etter Ignite 2025 (50+ nye/oppdaterte artikler i Entra Agent ID-portføljen; opt-out er midlertidig — vil bli obligatorisk for nye agenter) *(Verified MCP 2026-06)*
|
||||
**Målgruppe:** Arkitekter som skal sikre AI-agenter med dedikerte identiteter og Zero Trust-prinsipper
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/entra/id-governance/agent-id-governance-overview
|
||||
|
||||
### Ignite 2025-utvidelser (Verified MCP 2026-05)
|
||||
|
||||
|
|
@ -17,6 +19,22 @@ Microsoft har bredt utvidet Entra Agent ID-porteføljen i forbindelse med Ignite
|
|||
|
||||
**Copilot Studio-integrasjon (preview):** Når funksjonen aktiveres på miljønivå i Power Platform Admin Center, oppretter Copilot Studio automatisk en Entra Agent ID for hver ny agent og knytter den til *Microsoft Copilot Studio agent identity blueprint* (Blueprint ID `25664c89-cea5-4ab6-b924-a54fd8a19ae0`). Eksisterende agenter beholder sine app registrations til de migreres senere — governance fungerer for begge under overgangen.
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Hva er Microsoft Entra Agent ID?](#hva-er-microsoft-entra-agent-id)
|
||||
- [Kjernekomponenter og begreper](#kjernekomponenter-og-begreper)
|
||||
- [Zero Trust-prinsipper for agenter](#zero-trust-prinsipper-for-agenter)
|
||||
- [Agent Registry — Livsløpsadministrasjon](#agent-registry--livsløpsadministrasjon)
|
||||
- [Workload Identities vs. Agentidentiteter](#workload-identities-vs-agentidentiteter)
|
||||
- [Integrasjon med Microsoft Foundry](#integrasjon-med-microsoft-foundry)
|
||||
- [Integrasjon med Copilot Studio](#integrasjon-med-copilot-studio)
|
||||
- [Norsk offentlig sektor — Alignment](#norsk-offentlig-sektor--alignment)
|
||||
- [Sikkerhetshensyn og beste praksis](#sikkerhetshensyn-og-beste-praksis)
|
||||
- [Status og tilgjengelighet](#status-og-tilgjengelighet)
|
||||
- [Kilder](#kilder)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Etter hvert som AI-agenter blir en integrert del av virksomhetens arbeidsprosesser, oppstår et fundamentalt sikkerhetsproblem: tradisjonelle identitetsmodeller er ikke designet for autonome programvaresystemer som handler på egenhånd, opprettes og slettes dynamisk, og kan proliferere ukontrollert — kjent som «agent sprawl».
|
||||
|
|
|
|||
|
|
@ -3,9 +3,21 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/ai-services/content-safety/concepts/jailbreak-detection
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Jailbreak-kategorier](#jailbreak-kategorier)
|
||||
- [Forsvarsmønstre](#forsvarsmønstre)
|
||||
- [Azure-implementering](#azure-implementering)
|
||||
- [Produksjonsovervåking](#produksjonsovervåking)
|
||||
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
|
||||
- [Kilder og verifisering](#kilder-og-verifisering)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Jailbreak-angrep er bruker-prompts designet for å provosere LLM til å opptre på måter den er trent til å unngå, eller bryte reglene satt i system-meldingen. Disse angrepene kan variere fra intrikate rollespill til subtile undergravinger av sikkerhetsmekanismene. I produksjonssammenheng er robuste forsvarsmønstre kritiske for å beskytte LLM-applikasjoner mot både direkte (user prompt) og indirekte (document-baserte) angrep.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Kategori:** AI Security Engineering
|
||||
**Dato:** 2026-06-19
|
||||
**Status:** Active
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/machine-learning/concept-model-management-and-deployment
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Hva dette handler om](#hva-dette-handler-om)
|
||||
- [Content Watermarking i Microsoft-stakken](#content-watermarking-i-microsoft-stakken)
|
||||
- [Model Fingerprinting og Provenance](#model-fingerprinting-og-provenance)
|
||||
- [Legal og Compliance Implications](#legal-og-compliance-implications)
|
||||
- [Implementering i Microsoft-stakken](#implementering-i-microsoft-stakken)
|
||||
- [Anbefalinger for norsk offentlig sektor](#anbefalinger-for-norsk-offentlig-sektor)
|
||||
- [For Cosmo Skyberg](#for-cosmo-skyberg)
|
||||
- [Kilder](#kilder)
|
||||
|
||||
## Hva dette handler om
|
||||
|
||||
Model fingerprinting og watermarking er teknikker for å etablere eierskap, spore opprinnelse og beskytte AI-modeller og AI-generert innhold mot uautorisert bruk, kopiering eller manipulasjon. Dette er kritiske sikkerhetskontroller i en tid hvor AI-modeller representerer betydelig forretningsverdi, og hvor AI-generert innhold må kunne verifiseres og spores.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,25 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA (text moderation, Prompt Shields) / Preview (Groundedness, Custom Categories)
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/ai-services/content-safety/overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Språkstøtte for norsk](#språkstøtte-for-norsk)
|
||||
- [Oppsummeringstabell — norsk støtte per feature](#oppsummeringstabell--norsk-støtte-per-feature)
|
||||
- [Workarounds for manglende norsk støtte](#workarounds-for-manglende-norsk-støtte)
|
||||
- [Implementeringsmønstre](#implementeringsmønstre)
|
||||
- [Testing av Content Safety for norsk](#testing-av-content-safety-for-norsk)
|
||||
- [Kostnader og ytelse](#kostnader-og-ytelse)
|
||||
- [Rate limits](#rate-limits)
|
||||
- [Anbefalinger for norsk offentlig sektor](#anbefalinger-for-norsk-offentlig-sektor)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
- [Kilder og verifisering](#kilder-og-verifisering)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Azure AI Content Safety er Microsofts tjeneste for automatisert innholdsmoderering i AI-applikasjoner. Tjenesten detekterer og klassifiserer potensielt skadelig innhold i tekst og bilder, med fire skadekategorier (hate, sexual, violence, self-harm) og fire alvorlighetsgrader (safe, low, medium, high). For norsk offentlig sektor er norsk språkstøtte kritisk — dette dokumentet kartlegger nøyaktig hvilke Content Safety-features som støtter norsk nativt, hvilke som kun fungerer på engelsk, og hvilke workarounds som finnes.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-24 | Verified: MCP 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/ai-services/content-safety/overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Output validation, grounding verification og fact-checking er fundamentale sikkerhetsteknikker for å sikre at LLM-genererte svar er faktisk korrekte, basert på kildemateriale, og ikke inneholder hallusinasjoner eller fabricerte fakta. Disse teknikkene er spesielt kritiske i RAG-systemer (Retrieval Augmented Generation) der modellen skal basere sine svar på hentet dokumentasjon.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,8 @@
|
|||
**Last updated:** 2026-06-24 | Verified: MCP 2026-06-24
|
||||
**Status:** Referanse (OWASP 2025 + Azure-tiltak)
|
||||
**Category:** AI Security Engineering — Threat Modeling & Controls
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/ai-services/content-safety/overview
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/ai-services/language-service/personally-identifiable-information/overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Beskyttelse av personopplysninger er ikke bare en teknisk nødvendighet, men en juridisk plikt i Norge. Azure AI Language tilbyr PII-deteksjon som kan identifisere og maskere sensitive opplysninger som fødselsnummer, D-nummer, adresser og telefonnummer i norsk tekst.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** AI Security Engineering
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/ai-services/content-safety/overview
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Angrepstyper](#angrepstyper)
|
||||
- [Forsvarsmønstre](#forsvarsmønstre)
|
||||
- [Azure-implementering](#azure-implementering)
|
||||
- [Arkitekturmønstre](#arkitekturmønstre)
|
||||
- [Beslutningsveiledning](#beslutningsveiledning)
|
||||
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
|
||||
- [Kilder og verifisering](#kilder-og-verifisering)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Prompt injection er en av de mest kritiske sikkerhetstruslene mot generative AI-systemer. Angrep skjer når brukere eller tredjeparter manipulerer input-prompter for å omgå sikkerhetskontroller, endre modellens oppførsel, eller ekstrahere sensitiv informasjon. Microsoft har utviklet et helhetlig forsvarsmønster som kombinerer tekniske kontroller, arkitekturmønstre og kontinuerlig overvåking.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,19 @@
|
|||
**Kategori:** AI Security Engineering
|
||||
**Dato:** 2026-02-05
|
||||
**Målgruppe:** Arkitekter som skal sikre AI-modeller i produksjonsmiljøer
|
||||
**Type:** reference
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Container Image Scanning](#container-image-scanning)
|
||||
- [Runtime Memory Protection](#runtime-memory-protection)
|
||||
- [Resource Exhaustion Defense](#resource-exhaustion-defense)
|
||||
- [Model Integrity Verification](#model-integrity-verification)
|
||||
- [Secrets Management i Deployment](#secrets-management-i-deployment)
|
||||
- [Sikkerhetsjekkliste for Deployment](#sikkerhetsjekkliste-for-deployment)
|
||||
- [Best Practices: Deployment Hardening Workflow](#best-practices-deployment-hardening-workflow)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
|
|
|
|||
|
|
@ -3,6 +3,25 @@
|
|||
**Kategori:** AI Security Engineering
|
||||
**Sist oppdatert:** 2026-06-19 | Verified: MCP 2026-06
|
||||
**Målgruppe:** Sikkerhetsarkitekter og SOC-ledere som vurderer AI-assistert sikkerhetsoperasjon
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/copilot/security/agents-overview
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Standalone vs Embedded](#standalone-vs-embedded)
|
||||
- [Innebygde Security Copilot-agenter](#innebygde-security-copilot-agenter)
|
||||
- [Lisensiering](#lisensiering)
|
||||
- [Integrasjon med Microsoft Defender XDR](#integrasjon-med-microsoft-defender-xdr)
|
||||
- [Integrasjon med Microsoft Sentinel](#integrasjon-med-microsoft-sentinel)
|
||||
- [Tilpassede Security Copilot-plugins](#tilpassede-security-copilot-plugins)
|
||||
- [Norsk offentlig sektor — Relevans og tilnærming](#norsk-offentlig-sektor--relevans-og-tilnærming)
|
||||
- [Kostnadsmodell](#kostnadsmodell)
|
||||
- [Sammenligning: Standalone vs M365 E5 Embedded](#sammenligning-standalone-vs-m365-e5-embedded)
|
||||
- [Referansearkitektur: Security Copilot i norsk SOC](#referansearkitektur-security-copilot-i-norsk-soc)
|
||||
- [Beslutningsveiledning](#beslutningsveiledning)
|
||||
- [Spørsmål Cosmo bør stille kunden](#spørsmål-cosmo-bør-stille-kunden)
|
||||
- [Kilder](#kilder)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
|
|
|
|||
|
|
@ -4,9 +4,27 @@
|
|||
**Kategori:** AI Security Engineering
|
||||
**Status:** Established Practice
|
||||
**Formål:** Deterministiske rubrikker for security-assessment-agent — erstatter vage 1-5 beskrivelser med eksakte, verifiserbare sjekkpunkter
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/security/benchmark/azure/mcsb-v2-artificial-intelligence-security
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Oversikt](#oversikt)
|
||||
- [Vektingsmodell](#vektingsmodell)
|
||||
- [Dimensjon 1: Identity & Access Control (20 %)](#dimensjon-1-identity--access-control-20)
|
||||
- [Dimensjon 2: Network Security (10 %)](#dimensjon-2-network-security-10)
|
||||
- [Dimensjon 3: Data Protection (20 %)](#dimensjon-3-data-protection-20)
|
||||
- [Dimensjon 4: Content Safety & AI Security (15 %)](#dimensjon-4-content-safety--ai-security-15)
|
||||
- [Dimensjon 5: Compliance & Governance (25 %)](#dimensjon-5-compliance--governance-25)
|
||||
- [Dimensjon 6: Monitoring & Incident Response (10 %)](#dimensjon-6-monitoring--incident-response-10)
|
||||
- [Totalscoreberegning](#totalscoreberegning)
|
||||
- [Referansecaser](#referansecaser)
|
||||
- [Sammenligning av casene](#sammenligning-av-casene)
|
||||
- [Kilder og forankring](#kilder-og-forankring)
|
||||
- [For Cosmo Skyberg](#for-cosmo-skyberg)
|
||||
|
||||
## Oversikt
|
||||
|
||||
Denne filen definerer **30 rubrikk-celler** (6 dimensjoner × 5 nivåer) med ja/nei-sjekkpunkter for å sikre konsistent, reproduserbar sikkerhetsvurdering av Microsoft AI-arkitekturer. Rammeverket er forankret i Microsoft Cloud Security Benchmark (MCSB) v2, Azure AI security baselines og norske offentlig sektor-krav.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Kategori:** AI Security Engineering
|
||||
**Dato:** 2026-06-19
|
||||
**Relatert plattform:** Microsoft Foundry, Azure Machine Learning, Azure DevOps, Microsoft Defender for Cloud
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/machine-learning/concept-vulnerability-management
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Oversikt](#oversikt)
|
||||
- [1. Model Provenance Tracking](#1-model-provenance-tracking)
|
||||
- [2. Dependency Vulnerability Scanning](#2-dependency-vulnerability-scanning)
|
||||
- [3. Vendor Security Assessment](#3-vendor-security-assessment)
|
||||
- [4. Model Poisoning Prevention](#4-model-poisoning-prevention)
|
||||
- [5. Software Bill of Materials (SBOM) for AI](#5-software-bill-of-materials-sbom-for-ai)
|
||||
- [6. Secure ML Supply Chain: Oppsummert Implementasjon](#6-secure-ml-supply-chain-oppsummert-implementasjon)
|
||||
- [For Cosmo: Veiledning i Arkitekturdialog](#for-cosmo-veiledning-i-arkitekturdialog)
|
||||
- [Referanser og Videre Lesning](#referanser-og-videre-lesning)
|
||||
|
||||
## Oversikt
|
||||
|
||||
Supply chain security for AI-modeller handler om å sikre integriteten og autentisiteten til AI-komponenter gjennom hele livssyklusen — fra treningsdata og pre-trained models til dependencies og deployment artifacts. I motsetning til tradisjonell software supply chain security, må AI-systemer også beskytte modellvekter, datasett, og ML-spesifikke komponenter mot kompromittering.
|
||||
|
|
|
|||
|
|
@ -3,6 +3,20 @@
|
|||
**Kategori:** AI Security Engineering
|
||||
**Sist oppdatert:** 2026-06-19
|
||||
**Målgruppe:** Arkitekter som skal sikre AI-tjenester med Zero Trust-prinsipper
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/security/zero-trust/apply-zero-trust-azure-services-overview
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Arkitekturmønstre](#arkitekturmønstre)
|
||||
- [Beslutningsveiledning](#beslutningsveiledning)
|
||||
- [Integrasjon med Microsoft AI-plattformer](#integrasjon-med-microsoft-ai-plattformer)
|
||||
- [Offentlig sektor-hensyn](#offentlig-sektor-hensyn)
|
||||
- [Kostnad og ressursbruk](#kostnad-og-ressursbruk)
|
||||
- [For arkitekten](#for-arkitekten)
|
||||
- [Kilder](#kilder)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/ai-builder/credit-management
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
AI Builder er Microsofts low-code AI-plattform som inngår i Power Platform. Historisk har AI Builder brukt en egen kredittmodell (AI Builder credits) for å regulere forbruk av AI-funksjoner i Power Apps og Power Automate. I oktober 2025 annonserte Microsoft en progressiv avvikling av AI Builder credits til fordel for en felles kredittmodell basert på Copilot Credits.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Cost governance i Microsoft Foundry representerer det strukturelle rammeverket som forhindrer ukontrollert AI-forbruk og sikrer at AI-investeringer forblir innenfor budsjetterte rammer. I motsetning til tradisjonell cloud-kostnadsstyring, krever AI-arbeidsbelastninger spesialiserte kontroller som håndterer både infrastrukturkostnader (compute, storage) og forbruksbaserte kostnader (tokens, API-kall, modelldeployments).
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/cost-management-billing/costs/tutorial-acm-create-budgets
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Azure Cost Management er Microsofts innebygde plattform for kostnadsovervåking, budsjettering og optimalisering på tvers av alle Azure-ressurser. For AI-workloads er økonomisk styring spesielt kritisk fordi token-baserte modeller, GPU-compute og storage-intensive RAG-løsninger kan generere uforutsigbare kostnader hvis de ikke overvåkes systematisk.
|
||||
|
|
|
|||
|
|
@ -4,9 +4,22 @@
|
|||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/how-to/batch
|
||||
**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
|
||||
|
||||
Azure OpenAI Batch API er designet for å håndtere storskala- og høyvolumsbehandling av AI-oppgaver effektivt. Ved å prosessere asynkrone grupper av requests i batch-format, fremfor én og én request, oppnår organisasjoner **50% kostnadsreduksjon** sammenlignet med standard global deployment. Batch API benytter separat enqueued token-kvote, som sikrer at batch-jobber ikke forstyrrer sanntidsapplikasjoner.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Budget forecasting og finansiell planlegging er kritiske disipliner for AI-prosjekter i Microsoft-stakken. Mens tradisjonell IT-budsjettforing opererer med forutsigbare kapasitetsmodeller, introduserer AI-arbeidsbelastninger nye utfordringer: token-basert forbruk, uforutsigbare skaleringsmønstre, og kostnadsvarians knyttet til modellvalg og treningsfrekvens.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/platform/governance
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Cost allocation og chargeback er fundamentale FinOps-kapabiliteter for å håndtere delte kostnader og skape kostnadsansvar i organisasjoner som bruker Microsoft AI-plattformer. Disse mekanismene lar deg omfordele kostnader fra sentrale, delte tjenester til de faktiske forbrukerne — som team, avdelinger eller prosjekter — og dermed sikre både transparens og ansvarliggjøring.
|
||||
|
|
|
|||
|
|
@ -4,9 +4,24 @@
|
|||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Rolle:** Kanonisk prissannhet — eneste autoritative enhetspris-register for pluginen
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/copilot/microsoft-365/microsoft-365-copilot-licensing
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Seksjon 1: Enhetspris-register](#seksjon-1-enhetspris-register)
|
||||
- [Seksjon 2: Eksplisitte beregningsformler](#seksjon-2-eksplisitte-beregningsformler)
|
||||
- [Seksjon 3: P10/P50/P90 konfidensintervaller](#seksjon-3-p10p50p90-konfidensintervaller)
|
||||
- [Seksjon 4: Mellomregnings-format](#seksjon-4-mellomregnings-format)
|
||||
- [Seksjon 5: Valutakonvertering USD → NOK](#seksjon-5-valutakonvertering-usd--nok)
|
||||
- [Seksjon 6: Typiske referansearkitekturer — kostnadsprofiler](#seksjon-6-typiske-referansearkitekturer--kostnadsprofiler)
|
||||
- [Seksjon 7: Oppdatering og vedlikehold](#seksjon-7-oppdatering-og-vedlikehold)
|
||||
- [Kilder og verifisering](#kilder-og-verifisering)
|
||||
- [For Cosmo Skyberg](#for-cosmo-skyberg)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Kostnadsestimater i AI-arkitekturvurderinger lider ofte av tvetydighet: runde tall uten kilde, manglende mellomregning, og uklare konfidensintervaller. Denne referansen definerer en **deterministisk beregningsmodell** som fjerner all tvetydighet fra kostnadsestimater.
|
||||
|
|
|
|||
|
|
@ -3,10 +3,23 @@
|
|||
**Last updated:** 2026-06 | Priser verifisert: WebSearch + OpenAI/Azure pricing juni 2026
|
||||
**Status:** GA (GPT-4.1-serien), GA (GPT-5-serien — `gpt-5` og `gpt-5-codex` har registreringskrav). GPT-5.2 reasoning og GPT-5.3 chat lagt til i Copilot Studio-prompt-builder
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs
|
||||
**Prissannhet:** Rå token-priser eies av `deterministic-cost-calculation-model.md` §1.1 (kanonisk register). Denne fila gir kontekst, scenarioer og rådgivning — ved tallkonflikt vinner registeret.
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Beslutningsveiledning](#beslutningsveiledning)
|
||||
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
|
||||
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
|
||||
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
|
||||
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
|
||||
- [Kilder og verifisering](#kilder-og-verifisering)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
GPT-5- og GPT-4.1-seriene er de to nyeste flaggskipmodellene fra OpenAI tilgjengelig i Microsoft Foundry. De representerer to distinkte designfilosofier: GPT-5 optimalisert for dyp resonnering og komplekse oppgaver, GPT-4.1 optimalisert for hastighet, gjennomstrømming og kostnadseffektivitet.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Managed inference endpoints i Azure Machine Learning og Microsoft 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 (Microsoft Foundry), med fokus på praktiske optimaliseringsstrategier som kan redusere Total Cost of Ownership (TCO) uten å kompromittere på ytelse eller tilgjengelighet.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/cloud-adoption-framework/scenarios/ai/plan
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
Lisenskostnader er ofte den største enkeltposten i organisasjoners Microsoft-budsjett, og med introduksjonen av AI-kapabiliteter gjennom Microsoft 365 Copilot, Azure AI Services, og Power Platform AI har kompleksiteten økt dramatisk. En moderne Microsoft AI-organisasjon må forholde seg til et flerlags lisensieringslandskap som inkluderer base-lisenser (M365 E3/E5, Business Premium), add-on-lisenser (Microsoft 365 Copilot, AI Builder), consumption-baserte modeller (Azure OpenAI, AI Search), og seeded credits som endrer seg over tid.
|
||||
|
|
|
|||
|
|
@ -4,9 +4,22 @@
|
|||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
|
||||
**Type:** reference
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Valg av AI-modell har direkte innvirkning på både ytelse og kostnad. Microsoft Azure AI tilbyr et bredt spekter av modeller med ulike pris-/ytelsekarakteristikker — fra små, kostnadseffektive modeller som GPT-4o mini og GPT-4.1-nano, til store resonneringsmodeller som GPT-5. Riktig modellvalg kan redusere kostnader med 60-80% uten å ofre kvalitet for det aktuelle bruksområdet.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19 | Verified: MCP 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Moderne AI-løsninger krever ofte forskjellige modellkapabiliteter for ulike oppgaver. En multi-model strategy innebærer intelligent routing av requests til den mest kostnadseffektive modellen som tilfredsstiller kvalitetskravene. Med Azure OpenAI-modeller som varierer fra GPT-4.1-nano (59 400 tokens/PTU) til GPT-5 (4 750 tokens/PTU) kan besparelsene være betydelige — opptil 90% kostnadsdifferanse mellom modeller for enkle oppgaver.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19 | Verified: MCP 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/azure-monitor/app/opentelemetry-configuration
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Observability og monitoring er kritiske for produksjonsklare AI-løsninger, men kan raskt bli en betydelig kostnadsfaktor hvis de ikke konfigureres riktig. Azure Monitor, Application Insights og Log Analytics workspace representerer ofte 15-30% av den totale driftskostnaden for AI-workloads. Denne referansen fokuserer på strategier for å optimalisere kostnader knyttet til telemetri-innsamling, lagring og spørringer, samtidig som du opprettholder nødvendig innsikt i systemets helse og ytelse.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Prompt engineering er en av de mest kostnadseffektive optimaliseringsstrategiene for Azure OpenAI-løsninger. Siden prismodellen er basert på antall tokens (både input og output), kan godt utformede prompts redusere kostnader med 30-70% uten å kompromittere kvaliteten på responsen. Dette handler om å maksimere verdien av hver token som sendes til modellen.
|
||||
|
|
|
|||
|
|
@ -4,9 +4,22 @@
|
|||
**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.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry-classic/openai/concepts/use-your-data
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Retrieval Augmented Generation (RAG) representerer en av de mest kostnadsintensive delene av AI-applikasjoner i produksjon. Mens utvikling og testing av RAG-løsninger kan virke rimelig, eskalerer kostnadene raskt når systemet møter produksjonsvolumer med hundrevis eller tusenvis av queries daglig. Hver query utløser en pipeline med minimum to LLM-kall (intent generation og response generation), embedding-operasjoner, search-queries mot Azure AI Search, og potensielt semantic ranking. For organisasjoner som bygger chat-løsninger eller copilots på Microsoft-stakken, er query-kostnader ofte den største driftskostnaden.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/machine-learning/concept-endpoints-batch
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Request batching og response aggregation er kritiske kostnadsoptimaliseringsteknikker for AI-løsninger som gjør det mulig å konsolidere flere API-forespørsler i én enkelt nettverksoperasjon. I stedet for å sende hundrevis eller tusenvis av individuelle API-kall, kan applikasjoner samle disse i batches, redusere nettverkslatens, minimere API throttling-risiko og drastisk kutte kostnader.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput-billing
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
Reserved capacity og commitment tier pricing er Azures to primære mekanismer for kostnadsoptimalisering av AI-tjenester gjennom term-baserte rabatter. Disse mekanismene lar organisasjoner oppnå betydelige kostnadsbesparelser (opptil 40-60% for reservasjoner) i bytte mot å binde seg til en bestemt kapasitet over tid.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Semantic caching er en teknikk som reduserer kostnader og latens for LLM-baserte applikasjoner ved å cache og gjenbruke svar basert på semantisk likhet mellom prompts — ikke kun eksakte tekstmatch. Dette er spesielt verdifullt i AI-workloads der samme eller lignende spørsmål stilles flere ganger.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
|
||||
|
||||
---
|
||||
|
||||
## 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
|
||||
|
||||
Small Language Models (SLMs) representerer en fundamental endring i hvordan organisasjoner kan tilnærme seg AI-økonomisering. I motsetning til Large Language Models (LLMs) som GPT-4, som typisk har over 10 milliarder parametere, opererer SLMs med under 10 milliarder parametere — noe som gir dramatiske kostnadsbesparelser uten å ofre ytelse for veldefinerte oppgaver.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Token counting og optimization er fundamentale teknikker for å kontrollere kostnader i Azure OpenAI og andre LLM-baserte løsninger. Siden fakturering baserer seg på antall tokens (både input og output), er presis måling og aktiv reduksjon av token-forbruk kritisk for økonomisk bærekraft — spesielt i høyvolum-scenarier.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Cost Optimization & FinOps for AI
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/concepts/manage-costs
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [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
|
||||
|
||||
Vector storage og embeddings utgjør ofte den største kostnadsposten i moderne RAG-løsninger (Retrieval Augmented Generation). En typisk embedding-modell genererer vektorer på 1536 dimensjoner (text-embedding-ada-002) eller opptil 3072 dimensjoner (text-embedding-3-large), der hver dimensjon lagres som et 32-bit flyttall (float32). Dette gir en råstørrelse på 6-12 KB per dokument, før man tar høyde for algoritme-overhead og indekseringsstrukturer.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,25 @@
|
|||
**Last updated:** 2026-06-24 | Verified: MCP 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/architecture/guide/architecture-styles/event-driven
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Queue-based Architectures](#queue-based-architectures)
|
||||
- [Event-Driven Design](#event-driven-design)
|
||||
- [Request-Response Decoupling](#request-response-decoupling)
|
||||
- [Status Polling and Webhooks](#status-polling-and-webhooks)
|
||||
- [Event-Driven Architecture Styles (oppdatert 2026-04)](#event-driven-architecture-styles-oppdatert-2026-04)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Asynkron prosessering er en arkitekturstrategi der AI-forespørsler behandles uavhengig av den opprinnelige klientforbindelsen. I stedet for at klienten venter synkront på et svar fra Azure OpenAI (som kan ta fra 500ms til flere minutter for reasoning-modeller), plasseres forespørselen i en kø, behandles i bakgrunnen, og resultatet leveres via polling, webhook eller push-notifikasjon.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,24 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Grunnleggende skaleringstyper](#grunnleggende-skaleringstyper)
|
||||
- [Azure Container Apps for AI-arbeidslaster](#azure-container-apps-for-ai-arbeidslaster)
|
||||
- [Skaleringsmetrikker og triggere](#skaleringsmetrikker-og-triggere)
|
||||
- [Cooldown-perioder og stabilisering](#cooldown-perioder-og-stabilisering)
|
||||
- [Kapasitetsplanlegging](#kapasitetsplanlegging)
|
||||
- [Kostnadsoptimalisering gjennom skalering](#kostnadsoptimalisering-gjennom-skalering)
|
||||
- [Azure OpenAI-spesifikk skalering](#azure-openai-spesifikk-skalering)
|
||||
- [Overvaking av skalering](#overvaking-av-skalering)
|
||||
- [Sjekkliste for auto-scaling](#sjekkliste-for-auto-scaling)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Auto-scaling er en fundamental kapabilitet for AI-infrastruktur i Azure, der arbeidslaster kan variere dramatisk basert pa brukertrafikk, batch-prosessering og hendelsesdrevne triggere. For norsk offentlig sektor er auto-scaling spesielt viktig fordi trafikkmonstre er svart forutsigbare (arbeidstid, sesongvariasjon) men ogsaa kan ha uforutsigbare topper (hoeringsfrister, mediadekning).
|
||||
|
|
|
|||
|
|
@ -4,9 +4,23 @@
|
|||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/how-to/batch-blob-storage
|
||||
**Type:** reference
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Oversikt over Batch API](#oversikt-over-batch-api)
|
||||
- [Batch Job-sammensetning](#batch-job-sammensetning)
|
||||
- [Filopplasting og -handtering](#filopplasting-og--handtering)
|
||||
- [Batch Job-oppretting og -overvaking](#batch-job-oppretting-og--overvaking)
|
||||
- [Kostnadsberegning og besparelser](#kostnadsberegning-og-besparelser)
|
||||
- [Retry og feilhhandtering](#retry-og-feilhhandtering)
|
||||
- [Bruksomrader for norsk offentlig sektor](#bruksomrader-for-norsk-offentlig-sektor)
|
||||
- [Sjekkliste for batch-optimalisering](#sjekkliste-for-batch-optimalisering)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Azure OpenAI Batch API er designet for storskala, asynkron prosessering av AI-arbeidslaster. Med 50% lavere kostnad enn Global Standard-prising og separat kvote som ikke pavirker online-trafikken, er Batch API ideelt for norsk offentlig sektor som trenger a prosessere store volumer av dokumenter, klassifiseringer eller analyser.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,22 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Azure Front Door for AI-endepunkter](#azure-front-door-for-ai-endepunkter)
|
||||
- [CDN Caching-regler for AI-responser](#cdn-caching-regler-for-ai-responser)
|
||||
- [Semantic Caching for AI](#semantic-caching-for-ai)
|
||||
- [Edge Compute for pre-prosessering](#edge-compute-for-pre-prosessering)
|
||||
- [Geografisk routing og optimalisering](#geografisk-routing-og-optimalisering)
|
||||
- [DDoS-beskyttelse for AI-endepunkter](#ddos-beskyttelse-for-ai-endepunkter)
|
||||
- [Ytelsesgevinster: Oppsummering](#ytelsesgevinster-oppsummering)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Content Delivery Networks (CDN) og edge computing er etablerte teknologier for a akselerere webinnhold, men bruken i AI-kontekst krever en nyansert tilnaerming. AI-responser er dynamiske og ofte personaliserte, noe som gjor tradisjonell caching mer kompleks. Likevel finnes det betydelige muligheter for a redusere latens og kostnader ved a cache AI-relatert innhold pa riktig mate.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,24 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/how-to/latency
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Concurrency Level Tuning](#concurrency-level-tuning)
|
||||
- [Request Queueing Strategies](#request-queueing-strategies)
|
||||
- [Deadlock Prevention](#deadlock-prevention)
|
||||
- [Resource Contention Resolution](#resource-contention-resolution)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Concurrent request optimization handler om å maksimere antall samtidige forespørsler mot Azure OpenAI uten å overbelaste tjenesten eller miste forespørsler. Den optimale graden av samtidighet avhenger av deployment-type (Standard vs. PTU), tildelt kvote (TPM/RPM), modellens responstid og klientens evne til å håndtere parallelle forbindelser.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,25 @@
|
|||
**Last updated:** 2026-06-19 | Verified: MCP 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/architecture/ai-ml/guide/azure-openai-gateway-multi-backend
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Pool Sizing-strategier](#pool-sizing-strategier)
|
||||
- [Keep-alive-konfigurasjon](#keep-alive-konfigurasjon)
|
||||
- [Connection Recycling](#connection-recycling)
|
||||
- [Load Distribution](#load-distribution)
|
||||
- [Azure API Management som Connection Pooling-lag (oppdatert 2026-06-19)](#azure-api-management-som-connection-pooling-lag-oppdatert-2026-06-19)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Connection pooling er en kritisk ytelsesoptimalisering for applikasjoner som kommuniserer med Azure AI Services. Hver HTTP-forbindelse til Azure OpenAI eller andre AI-endepunkter krever TCP-håndtrykk og eventuelt TLS-forhandling, noe som legger til betydelig latens per forespørsel. Uten connection pooling opprettes og lukkes forbindelser for hver eneste forespørsel, noe som fører til port-utmattelse, økt responstid og unødvendig CPU-bruk.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,25 @@
|
|||
**Last updated:** 2026-06-24 | Verified: MCP 2026-06
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput-billing
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [GPU Type Comparison](#gpu-type-comparison)
|
||||
- [Memory Requirements](#memory-requirements)
|
||||
- [Batch Size Influence](#batch-size-influence)
|
||||
- [Cost-Performance Analysis](#cost-performance-analysis)
|
||||
- [Azure ML Online Endpoints — oppdatert (2026-04)](#azure-ml-online-endpoints--oppdatert-2026-04)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
GPU- og compute-dimensjonering for AI-workloads på Azure handler om å velge riktig balanse mellom ytelse, kostnad og tilgjengelighet. For de fleste organisasjoner som bruker Azure OpenAI Service er GPU-valg abstrahert bak Provisioned Throughput Units (PTU) — du spesifiserer ønsket throughput, og Azure allokerer nødvendig GPU-kapasitet. Men for custom model hosting via Azure Machine Learning, Azure Kubernetes Service eller Azure Container Instances er eksplisitt GPU-valg nødvendig.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Forstaelse av latenskomponenter](#forstaelse-av-latenskomponenter)
|
||||
- [Request Pipeline-optimalisering](#request-pipeline-optimalisering)
|
||||
- [Connection Pooling og gjenbruk](#connection-pooling-og-gjenbruk)
|
||||
- [Regional endepunktsvalg](#regional-endepunktsvalg)
|
||||
- [Time-to-First-Token-reduksjon](#time-to-first-token-reduksjon)
|
||||
- [Provisioned Throughput Units (PTU) for forutsigbar latens](#provisioned-throughput-units-ptu-for-forutsigbar-latens)
|
||||
- [Overvaking og malinger](#overvaking-og-malinger)
|
||||
- [Sjekkliste for latensoptimalisering](#sjekkliste-for-latensoptimalisering)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Latens er en av de mest kritiske ytelsesparameterne for AI-applikasjoner i produksjon. For norsk offentlig sektor, der innbyggertjenester krever rask respons og interne saksbehandlingssystemer må operere effektivt, er optimalisering av Azure OpenAI-latens avgjorende. Høy latens kan direkte påvirke brukeropplevelsen og redusere adopsjonen av AI-drevne tjenester.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,24 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/load-testing/overview-what-is-azure-load-testing
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Load Test Design](#load-test-design)
|
||||
- [Realistic Traffic Patterns](#realistic-traffic-patterns)
|
||||
- [Bottleneck Analysis](#bottleneck-analysis)
|
||||
- [Capacity Forecasting](#capacity-forecasting)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Load testing av Azure AI Services er fundamentalt annerledes enn tradisjonell web-applikasjons lasttesting. AI-tjenester har variabel responstid basert på input-størrelse og output-kompleksitet, token-baserte rate limits (TPM/RPM) som ikke korrelerer lineært med antall forespørsler, og kostnader som skalerer med bruk. En enkelt Azure OpenAI-forespørsel kan ta fra 200ms til 120 sekunder avhengig av modell, prompt-størrelse og generert output.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,25 @@
|
|||
**Last updated:** 2026-04 | Verified: MCP 2026-04
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/concepts/fine-tuning-considerations
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Distillation Training Process](#distillation-training-process)
|
||||
- [Model Size vs. Quality Tradeoffs](#model-size-vs-quality-tradeoffs)
|
||||
- [Token Reduction Benefits](#token-reduction-benefits)
|
||||
- [Use Case Suitability](#use-case-suitability)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Modellvalg og routing-strategi (oppdatert 2026-04)](#modellvalg-og-routing-strategi-oppdatert-2026-04)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Model distillation er prosessen der en stor, kraftig modell (teacher) brukes til å trene en mindre, raskere modell (student) som oppnår akseptabel kvalitet for en spesifikk oppgave. I Azure OpenAI-konteksten betyr dette typisk å samle produksjonsdata fra en premium-modell som GPT-4o eller o3, og bruke disse som treningsdata for å fine-tune en mindre modell som GPT-4o-mini eller GPT-4.1-nano.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,24 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/load-testing/overview-what-is-azure-load-testing
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Metric Definition Standards](#metric-definition-standards)
|
||||
- [Baseline Establishment](#baseline-establishment)
|
||||
- [Regression Detection](#regression-detection)
|
||||
- [Comparative Analysis Methods](#comparative-analysis-methods)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Et performance benchmarking framework for Azure AI Services gir en strukturert tilnærming til å måle, sammenligne og spore ytelse over tid. Uten et rammeverk blir ytelsesmålinger ad hoc, ikke-reproduserbare og vanskelige å sammenligne mellom modellversjoner, deployment-konfigurasjoner eller arkitekturendringer.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,24 @@
|
|||
**Last updated:** 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Cache Eligibility Requirements](#cache-eligibility-requirements)
|
||||
- [Prefix Strategy Design](#prefix-strategy-design)
|
||||
- [Cost Reduction Calculation](#cost-reduction-calculation)
|
||||
- [Cache Invalidation](#cache-invalidation)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Azure OpenAI prompt caching er en innebygd mekanisme som reduserer latens og kostnad for forespørsler med identiske prefixer. Når de første 1024+ tokens i en prompt er identiske med en tidligere forespørsel, gjenbruker tjenesten de allerede beregnede token-representasjonene i stedet for å prosessere dem på nytt. Dette gir raskere time-to-first-token (TTFT) og lavere kostnad — cached tokens faktureres med rabatt for Standard deployments og opptil 100% rabatt for Provisioned (PTU) deployments.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,25 @@
|
|||
**Last updated:** 2026-06-19 | Verified: MCP 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/quotas-limits
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Exponential Backoff Implementation](#exponential-backoff-implementation)
|
||||
- [Quota Request Process](#quota-request-process)
|
||||
- [Multi-Region Failover](#multi-region-failover)
|
||||
- [Usage Monitoring](#usage-monitoring)
|
||||
- [Gateway Multi-Backend som Rate Limit-strategi (oppdatert 2026-06-19)](#gateway-multi-backend-som-rate-limit-strategi-oppdatert-2026-06-19)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Azure OpenAI bruker to rate limit-mekanismer: Tokens-per-Minute (TPM) og Requests-per-Minute (RPM). Når en av disse grensene overskrides, returnerer tjenesten HTTP 429 (Too Many Requests) med en `Retry-After` header som angir hvor mange sekunder klienten bør vente. For Standard deployments er rate limits direkte koblet til den tildelte kvoten, mens Provisioned Throughput (PTU) deployments returnerer 429 når utilization overstiger 100%.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,26 @@
|
|||
**Last updated:** 2026-06-19 | Verified: MCP 2026-06-19
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/foundry-models/concepts/deployment-types
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Region Selection Criteria](#region-selection-criteria)
|
||||
- [Traffic Routing Strategies](#traffic-routing-strategies)
|
||||
- [Cross-Region Redundancy](#cross-region-redundancy)
|
||||
- [Data Residency Requirements](#data-residency-requirements)
|
||||
- [Azure Front Door — oppdatert (2026-06-19)](#azure-front-door--oppdatert-2026-06-19)
|
||||
- [Gateway Multi-Backend — 4 topologier (oppdatert 2026-06-19)](#gateway-multi-backend--4-topologier-oppdatert-2026-06-19)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Multi-region deployment av Azure OpenAI-tjenester er en strategi for å minimere latens, øke tilgjengelighet og oppfylle krav til dataresidency. Azure OpenAI tilbyr flere deployment-typer som adresserer ulike regionale behov: Global Standard (automatisk routing til region med tilgjengelig kapasitet), Data Zone (data holdes innenfor en geografisk sone som EU), Regional Standard (fast region) og tilsvarende Provisioned-varianter.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,24 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/application-gateway/use-server-sent-events
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Streaming med Server-Sent Events](#streaming-med-server-sent-events)
|
||||
- [Semantic Chunking Approaches](#semantic-chunking-approaches)
|
||||
- [Client-Side Reassembly](#client-side-reassembly)
|
||||
- [Error Handling in Chunks](#error-handling-in-chunks)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Response chunking handler om hvordan store AI-modellresponser fra Azure OpenAI brytes opp og leveres til klienter. Det finnes to hovedtilnærminger: streaming via Server-Sent Events (SSE) der modellens output leveres token-for-token i sanntid, og chunking av store responser der output deles opp i semantisk meningsfulle blokker for videre prosessering.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,23 @@
|
|||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Server-Sent Events (SSE) Grunnleggende](#server-sent-events-sse-grunnleggende)
|
||||
- [Grunnleggende Streaming-implementasjon](#grunnleggende-streaming-implementasjon)
|
||||
- [Chunked Transfer Encoding](#chunked-transfer-encoding)
|
||||
- [Client-Side Stream Handling](#client-side-stream-handling)
|
||||
- [Error Recovery in Streams](#error-recovery-in-streams)
|
||||
- [Nar bruke streaming vs. non-streaming](#nar-bruke-streaming-vs-non-streaming)
|
||||
- [Avanserte monstre](#avanserte-monstre)
|
||||
- [Ytelsesmal for streaming](#ytelsesmal-for-streaming)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Streaming av AI-responser er en kritisk teknikk for a forbedre brukeropplevelsen i interaktive AI-applikasjoner. Istedenfor a vente pa at hele responsen genereres for den vises, lar streaming brukeren se svaret bygges opp token for token. For norsk offentlig sektor, der innbyggerportaler og saksbehandlingssystemer i okende grad integrerer AI, er streaming avgjorende for akseptabel responstid.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,25 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput-billing
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Parallel Request Execution](#parallel-request-execution)
|
||||
- [Request Buffering Strategies](#request-buffering-strategies)
|
||||
- [Queue Depth Tuning](#queue-depth-tuning)
|
||||
- [System Bottleneck Identification](#system-bottleneck-identification)
|
||||
- [Implementeringsmønstre](#implementeringsmønstre)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Throughput-optimalisering for Azure OpenAI og Azure AI Services handler om å maksimere antall fullførte forespørsler per sekund innenfor de tildelte kvotene. Azure OpenAI måler throughput i tokens per minutt (TPM) og forespørsler per minutt (RPM), og den reelle throughputen avhenger av en kompleks kombinasjon av input-størrelse, output-størrelse, modelltype og samtidige forespørsler.
|
||||
|
|
|
|||
|
|
@ -3,9 +3,24 @@
|
|||
**Last updated:** 2026-06-24
|
||||
**Status:** GA
|
||||
**Category:** Performance & Scalability
|
||||
**Type:** reference
|
||||
**Source:** https://learn.microsoft.com/azure/foundry/openai/concepts/provisioned-throughput-billing
|
||||
|
||||
---
|
||||
|
||||
## Innhold
|
||||
|
||||
- [Introduksjon](#introduksjon)
|
||||
- [Kjernekomponenter](#kjernekomponenter)
|
||||
- [Batch Sizing Impact](#batch-sizing-impact)
|
||||
- [Prompt Length Optimization](#prompt-length-optimization)
|
||||
- [GPU Utilization og throughput-monitorering](#gpu-utilization-og-throughput-monitorering)
|
||||
- [Throughput per PTU per modell](#throughput-per-ptu-per-modell)
|
||||
- [Norsk offentlig sektor](#norsk-offentlig-sektor)
|
||||
- [Beslutningsrammeverk](#beslutningsrammeverk)
|
||||
- [Referanser](#referanser)
|
||||
- [For Cosmo](#for-cosmo)
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Token-per-second (TPS) er en kritisk ytelsesmetrikk for Azure OpenAI-deployments som måler hvor raskt modellen genererer output-tokens. Denne metrikken påvirker direkte brukeropplevelsen ved streaming og den totale gjennomstrømmingen for batch-workloads. Azure OpenAI tilbyr latens-mål per PTU som varierer fra 25 TPS (o1) til 100 TPS (gpt-4.1-nano), og optimalisering av TPS er nøkkelen til å utnytte tildelt kapasitet effektivt.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue