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,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