fix(ms-ai-architect): Sesjon 10 — K9-destale eng+infra (volatil status → ref)
Begge S10-kriterier møtt (operatør-gated kald LLM-judge): engineering K9 PASS, infrastructure K9 PASS. Deterministisk ikke regredert: validate 239 · kb-eval 15 · kb-update 122 · kb-integrity 192/192. K4 hevet 4→5 begge skills. Engineering: modellversjoner (GPT-4o/Whisper/Florence/text-embedding-3) → generisk kapabilitets-framing; MAF-«erstatter SK»-transisjon + Foundry Agent Service GA → pekere; «Start med GPT-4o» (ABSENT i ref) droppet. Infrastructure: SLA-tabell (ABSENT i ref) → relativ-veiledning + MCP-peker; RTO/RPO-tabell → sammendrag + peker (ref bærer hele tier-modellen); «peak+30%» (ref sier 20%) → generisk; Phi-3/Phi-4 + parametertall → «Phi-familien» (fjernet faktafeil «Phi-4 14B»). Metode: read-only verifiserings-agenter kartla ref-dekning FØR sletting. judge-results.json oppdatert med ferske kalde eng+infra-verdikter (_updated: S10). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01REiKFhP4w6xGXXqWKpPCJJ
This commit is contained in:
parent
a9ff401b6e
commit
6b3c44adc3
4 changed files with 48 additions and 39 deletions
|
|
@ -27,7 +27,7 @@ BCDR-planlegging for AI skiller seg fra tradisjonell DR ved at man også må hå
|
|||
|
||||
### 1.1 Multi-region deployment
|
||||
|
||||
Norway East som primærregion (datasuverenitet, lav latens), Sweden Central som sekundær (bredere modellutvalg, EU-compliant), France Central/UK South som tertiær. Data Zone-deployeringer forenkler ruting innenfor EU-sonen.
|
||||
Norway East som primærregion (datasuverenitet, lav latens), Sweden Central som sekundær (EU-compliant), France Central/UK South som tertiær. Data Zone-deployeringer forenkler ruting innenfor EU-sonen.
|
||||
|
||||
Lastbalansering via APIM som gateway foran Azure OpenAI-endepunkter:
|
||||
- Priority-based routing: primær region først, failover ved helsesjekk-feil
|
||||
|
|
@ -40,13 +40,7 @@ Separate kvoter per region -- planlegg for tilstrekkelig TPM i failover. PTU i p
|
|||
|
||||
### 1.2 RTO/RPO-planlegging
|
||||
|
||||
| Komponent | Typisk RTO | RPO | Strategi |
|
||||
|-----------|-----------|-----|----------|
|
||||
| Azure OpenAI | < 5 min | N/A (stateless) | Multi-region med APIM failover |
|
||||
| Azure AI Search | 15-60 min | Timer | Geo-replikerte indekser |
|
||||
| Embedding-vektorer | Timer | Sist fullført indeksering | Rebuild fra kilde |
|
||||
| Samtalehistorikk | Minutter | < 1 min | Cosmos DB multi-region writes |
|
||||
| Custom models | Timer-dager | Siste versjon | Modellregister med versjonering |
|
||||
RTO/RPO settes per komponent ut fra kritikalitet og tilstandsbehov: stateless endepunkter (Azure OpenAI) gjenopprettes raskt via multi-region failover, mens søkeindekser, embedding-vektorer og samtalehistorikk krever geo-replikering eller rebuild-pipelines med komponentspesifikke mål. Bruk ref-fila for tier-modell, innebygde RPO-tall per tjeneste og dokumentasjonsmal.
|
||||
|
||||
Definer kritikalitet per AI-arbeidsflyt, test failover regelmessig, dokumenter manuell prosedyre.
|
||||
|
||||
|
|
@ -84,18 +78,13 @@ AI-spesifikke incident-kategorier (hallusinering, datalekkasje, kapasitetsmangel
|
|||
|
||||
### 1.7 Kapasitetsplanlegging
|
||||
|
||||
TPM per region/modell -- planlegg for peak + 30% buffer. GPU-kapasitet varierer per region. PTU reserveres i forkant. Overvåk 429-rater og latens-percentiler for tidlig varsel.
|
||||
TPM per region/modell -- planlegg for peak med kapasitetsbuffer. GPU-kapasitet varierer per region. PTU reserveres i forkant. Overvåk 429-rater og latens-percentiler for tidlig varsel.
|
||||
|
||||
> **Ref:** `references/bcdr/capacity-planning-dr-configurations.md`
|
||||
|
||||
### 1.8 SLA-dokumentasjon
|
||||
|
||||
| Tjeneste | SLA | Merknad |
|
||||
|----------|-----|---------|
|
||||
| Azure OpenAI | 99.9% | Standard og PTU, per region |
|
||||
| Azure AI Search | 99.9% | Standard+ med replikaer |
|
||||
| Cosmos DB | 99.999% | Multi-region med multi-write |
|
||||
| Azure API Management | 99.95% | Standard v2, gateway-laget |
|
||||
Hver tjeneste har egen SLA som varierer med tier, replikering og region — datatjenester med multi-region-replikering ligger typisk høyere enn enkeltstående compute-tjenester. Hent gjeldende SLA-tall per tjeneste og region via `microsoft_docs_fetch` eller `research-agent` før DR-planlegging.
|
||||
|
||||
Beregn sammensatt SLA, kartlegg gap mot forretningskrav, etabler intern SLO.
|
||||
|
||||
|
|
@ -138,7 +127,7 @@ Sentralisert kontrollflate for hybride miljøer:
|
|||
|
||||
> **Ref:** `references/hybrid-edge/azure-arc-ai-management.md`
|
||||
|
||||
### 2.2 Azure Local (tidl. Azure Stack HCI)
|
||||
### 2.2 Azure Local
|
||||
|
||||
Fullstendig Azure-kompatibelt on-premises med AKS og Azure ML lokalt. Sertifisert maskinvare (Dell, Lenovo, HPE), Azure-abonnement (OpEx), VDI med GPU for AI-utvikling. Ideell for strenge dataresidens-krav.
|
||||
|
||||
|
|
@ -146,7 +135,7 @@ Fullstendig Azure-kompatibelt on-premises med AKS og Azure ML lokalt. Sertifiser
|
|||
|
||||
### 2.3 Edge-inferens med ONNX Runtime
|
||||
|
||||
Kryssplattform (Windows, Linux, Android, iOS, WebAssembly) med hardware-akselerasjon (CUDA/TensorRT, OpenVINO, QNN, CoreML). Kvantisering (INT8/INT4), modellkonvertering fra PyTorch/TF/HF. ONNX Runtime GenAI for generative modeller (Phi-3/Phi-4) på edge.
|
||||
Kryssplattform (Windows, Linux, Android, iOS, WebAssembly) med hardware-akselerasjon (CUDA/TensorRT, OpenVINO, QNN, CoreML). Kvantisering (INT8/INT4), modellkonvertering fra PyTorch/TF/HF. ONNX Runtime GenAI for generative modeller (Phi-familien) på edge.
|
||||
|
||||
> **Ref:** `references/hybrid-edge/onnx-runtime-edge-deployment.md`
|
||||
|
||||
|
|
@ -155,7 +144,7 @@ Kryssplattform (Windows, Linux, Android, iOS, WebAssembly) med hardware-akselera
|
|||
**Scenarier:** forsvar/beredskap, maritime operasjoner, feltarbeid uten dekning, air-gapped nettverk.
|
||||
|
||||
**Mønstre:**
|
||||
- Pre-lastet SLM (Phi-3/Phi-4) med lokal inferens
|
||||
- Pre-lastet SLM (Phi-familien) med lokal inferens
|
||||
- Lokal vektordatabase (ChromaDB, LanceDB) for offline RAG
|
||||
- Store-and-forward synkronisering med prioritering og konfliktløsning
|
||||
|
||||
|
|
@ -181,9 +170,9 @@ Lokal vektordatabase (edge tier) + Azure AI Search (cloud tier) med intelligent
|
|||
|
||||
> **Ref:** `references/hybrid-edge/hybrid-rag-architecture.md`
|
||||
|
||||
### 2.8 Phi-3/Phi-4 SLM på edge
|
||||
### 2.8 Phi-familien (SLM) på edge
|
||||
|
||||
Phi-4-mini (3.8B) og Phi-4 (14B), kvantisering til INT4. Deployment via ONNX Runtime GenAI, AKS Edge Essentials, Windows AI med NPU, eller Azure Local med GPU. Bruk: dokumentklassifisering, kodegenerering i sikre miljøer, sanntidsspråkprosessering, oversettelse offline.
|
||||
Phi-familiens kompakte modeller med aggressiv kvantisering (INT4). Deployment via ONNX Runtime GenAI, AKS Edge Essentials, Windows AI med NPU, eller Azure Local med GPU. Bruk: dokumentklassifisering, kodegenerering i sikre miljøer, sanntidsspråkprosessering, oversettelse offline.
|
||||
|
||||
> **Ref:** `references/hybrid-edge/on-premises-slm-phi-deployment.md`
|
||||
|
||||
|
|
@ -246,7 +235,7 @@ NSM stiller krav til: identifisering/kartlegging av AI-systemer, sikkerhetskontr
|
|||
|
||||
### 3.4 Disconnected scenarios for forsvar/beredskap
|
||||
|
||||
Air-gapped nettverk, feltdeployerbare AI-systemer, drift uten skyavhengighet. Phi-3/Phi-4 SLM med lokal inferens, Azure Local i lukkede miljøer med manuell oppdatering. Graderte miljøer krever NSM-godkjent infrastruktur.
|
||||
Air-gapped nettverk, feltdeployerbare AI-systemer, drift uten skyavhengighet. Phi-familiens SLM med lokal inferens, Azure Local i lukkede miljøer med manuell oppdatering. Graderte miljøer krever NSM-godkjent infrastruktur.
|
||||
|
||||
### 3.5 Suveren sky-initiativ i EU/EØS
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue