feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command
Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Kjell Tore Guttormsen
commit
baa2d0220b
488 changed files with 213221 additions and 0 deletions
|
|
@ -0,0 +1,599 @@
|
|||
# Token Optimization and Cost Efficiency
|
||||
|
||||
**Last updated:** 2026-02
|
||||
**Status:** GA
|
||||
**Category:** Prompt Engineering & LLM Optimization
|
||||
|
||||
---
|
||||
|
||||
## Introduksjon
|
||||
|
||||
Token-optimalisering er kritisk for både kostnadseffektivitet og ytelse i Azure OpenAI-løsninger. Hver API-forespørsel koster basert på antall tokens prosessert (input + output), og ineffektiv token-bruk kan raskt eskalere både kostnader og responstider. Denne guiden dekker praktiske teknikker for å redusere token-forbruk, utnytte caching-mekanismer, og balansere kostnad mot ytelse.
|
||||
|
||||
**Nøkkelkonsept:** Azure OpenAI-modeller prosesserer tekst ved å dele den opp i tokens. Ett token er ca. 4 tegn for vanlig engelsk tekst. Både input (prompt) og output (completion) blir målt i tokens, og prisene varierer betydelig mellom modeller og deployment-typer.
|
||||
|
||||
---
|
||||
|
||||
## Kjernekomponenter
|
||||
|
||||
### Token-basert prismodell
|
||||
|
||||
| Komponent | Beskrivelse | Kostnadsfaktor |
|
||||
|-----------|-------------|----------------|
|
||||
| **Input tokens** | Tokens i prompt (system message + user input + conversation history) | Lavest kostnad per token |
|
||||
| **Output tokens** | Tokens generert av modellen som respons | 2-4× høyere enn input |
|
||||
| **Cached tokens** | Input tokens som matcher cached content | 50-100% rabatt (avhenger av deployment-type) |
|
||||
| **Reasoning tokens** | Ekstra tokens brukt av o-series modeller for resonnering | Egen prisstruktur (kun synlig i API-respons) |
|
||||
|
||||
**Eksempel GPT-4o-mini (standard deployment):**
|
||||
- Input: ~$0.15 per 1M tokens
|
||||
- Output: ~$0.60 per 1M tokens
|
||||
- Cached input: ~$0.075 per 1M tokens (50% rabatt)
|
||||
|
||||
### Deployment-typer og token-optimalisering
|
||||
|
||||
| Deployment Type | Token-strategi | Best For |
|
||||
|----------------|----------------|----------|
|
||||
| **Standard (pay-as-you-go)** | Fokus på å redusere totale tokens; prompt caching gir moderat rabatt | Variabel last, utvikling, testing |
|
||||
| **Provisioned Throughput (PTU)** | Optimalisere for throughput (tokens/min); cached tokens kan gi opptil 100% rabatt | Forutsigbar, høy last; latenskritiske workloads |
|
||||
| **Global Standard** | Balansere token-effektivitet med geografisk fleksibilitet | Multi-region workloads uten data residency-krav |
|
||||
| **Batch** | Maksimere token-volum; 50% kostnadsbesparing | Bulk-prosessering, ikke-sanntid (24t turnaround) |
|
||||
|
||||
---
|
||||
|
||||
## Token-optimaliserings-teknikker
|
||||
|
||||
### 1. Prompt Engineering for Token-effektivitet
|
||||
|
||||
#### Kortere prompts uten kvalitetstap
|
||||
|
||||
```yaml
|
||||
❌ Ineffektivt (150 tokens):
|
||||
"You are an extremely helpful and knowledgeable assistant with expertise
|
||||
in multiple domains. Please provide a comprehensive and detailed analysis
|
||||
of the following situation, ensuring that you consider all relevant factors
|
||||
and provide actionable recommendations..."
|
||||
|
||||
✅ Effektivt (25 tokens):
|
||||
"You are an expert analyst. Analyze the situation and provide actionable
|
||||
recommendations."
|
||||
```
|
||||
|
||||
**Teknikk:** Few-shot vs. Zero-shot
|
||||
- Few-shot bruker flere tokens (eksempler i prompt), men gir bedre output-kvalitet
|
||||
- Zero-shot sparer input-tokens, men kan kreve regenerering hvis kvalitet er dårlig
|
||||
- **Trade-off:** Evaluer om ekstra input-tokens er billigere enn å regenerere output
|
||||
|
||||
#### Strukturerte outputs reduserer output-tokens
|
||||
|
||||
```python
|
||||
# ❌ Ustrukturert output (400+ tokens)
|
||||
"Explain the benefits of Azure OpenAI with examples and details..."
|
||||
|
||||
# ✅ Strukturert output (150 tokens)
|
||||
response = client.chat.completions.create(
|
||||
model="gpt-4o",
|
||||
messages=[{"role": "user", "content": "List 3 Azure OpenAI benefits"}],
|
||||
response_format={
|
||||
"type": "json_schema",
|
||||
"json_schema": {
|
||||
"name": "benefits",
|
||||
"schema": {
|
||||
"type": "object",
|
||||
"properties": {
|
||||
"benefits": {
|
||||
"type": "array",
|
||||
"items": {"type": "string"},
|
||||
"maxItems": 3
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
)
|
||||
```
|
||||
|
||||
### 2. Prompt Caching (automatisk funksjonalitet)
|
||||
|
||||
**Status:** GA for GPT-4o, GPT-4.1-serien, o-series (o1, o3-mini, o4-mini)
|
||||
|
||||
Prompt caching reduserer kostnader ved å cache de første 1024+ tokens i en prompt. Når identisk innhold gjentas, betaler du redusert pris for cached tokens.
|
||||
|
||||
#### Hvordan det fungerer
|
||||
|
||||
| Faktor | Krav |
|
||||
|--------|------|
|
||||
| **Minimum prompt-lengde** | 1024 tokens |
|
||||
| **Cache-treff** | Første 1024 tokens må være identiske |
|
||||
| **Granularitet** | Cache-treff per 128 tokens etter første 1024 |
|
||||
| **Cache-levetid** | 5-10 min inaktivitet (max 1 time for Azure AI Foundry; 24t for Foundry Models) |
|
||||
| **Deling** | Ikke delt mellom Azure subscriptions |
|
||||
|
||||
#### Design for cache-hits
|
||||
|
||||
```python
|
||||
# ✅ Strukturer prompts for caching-effektivitet
|
||||
system_context = """You are a Norwegian public sector AI assistant.
|
||||
[... 2000 tokens med policy-dokumenter, guidelines, etc. ...]
|
||||
""" # Dette blir cached
|
||||
|
||||
messages = [
|
||||
{"role": "system", "content": system_context}, # Cached
|
||||
{"role": "user", "content": user_query} # Variabel (ikke cached)
|
||||
]
|
||||
|
||||
# Cache-nøkkel (optional) for å forbedre hit rate
|
||||
response = client.chat.completions.create(
|
||||
model="gpt-4o",
|
||||
messages=messages,
|
||||
prompt_cache_key="public-sector-v1" # Forbedrer routing
|
||||
)
|
||||
|
||||
# Sjekk cache-hits i respons
|
||||
cached = response.usage.prompt_tokens_details.cached_tokens
|
||||
print(f"Cached tokens: {cached}/{response.usage.prompt_tokens}")
|
||||
```
|
||||
|
||||
**Konfidensmarkør:** 🟢 **Høy** – Prompt caching er GA og godt dokumentert.
|
||||
|
||||
#### Best practices for caching
|
||||
|
||||
1. **Plasser statisk innhold først:** System messages, dokumenter, eksempler
|
||||
2. **Hold variabelt innhold sist:** User queries, timestamps, session-spesifikk data
|
||||
3. **Bruk `prompt_cache_key`** for workloads med mange parallelle requests (>15 req/min)
|
||||
4. **Overvåk cache hit rate:** Sjekk `cached_tokens` i API-respons
|
||||
|
||||
**Anti-pattern:**
|
||||
```python
|
||||
# ❌ Variabel innhold først = ingen cache hits
|
||||
messages = [
|
||||
{"role": "user", "content": f"Timestamp: {now()} - {user_query}"}, # Endres hver gang
|
||||
{"role": "system", "content": long_static_context} # For sent i token-sekvens
|
||||
]
|
||||
```
|
||||
|
||||
### 3. Max Tokens-kontroll
|
||||
|
||||
`max_tokens`-parameteren begrenser output-lengde. Dette påvirker **ikke** kvalitet, men hindrer unødvendig lange svar.
|
||||
|
||||
```python
|
||||
# ❌ Ukontrollert output (kan generere 4000+ tokens)
|
||||
response = client.chat.completions.create(
|
||||
model="gpt-4o",
|
||||
messages=[{"role": "user", "content": "Explain Azure AI Foundry"}]
|
||||
)
|
||||
|
||||
# ✅ Kontrollert output
|
||||
response = client.chat.completions.create(
|
||||
model="gpt-4o",
|
||||
messages=[{"role": "user", "content": "Explain Azure AI Foundry in 3 sentences"}],
|
||||
max_tokens=150,
|
||||
stop=["\n\n"] # Stopp ved double line break
|
||||
)
|
||||
```
|
||||
|
||||
**Konfidensmarkør:** 🟢 **Høy** – `max_tokens` er standard API-funksjonalitet.
|
||||
|
||||
### 4. Streaming for opplevd ytelse
|
||||
|
||||
Streaming reduserer **ikke** totale tokens eller totaltid, men forbedrer brukeropplevelse ved å vise output inkrementelt.
|
||||
|
||||
```python
|
||||
stream = client.chat.completions.create(
|
||||
model="gpt-4o",
|
||||
messages=messages,
|
||||
stream=True
|
||||
)
|
||||
|
||||
for chunk in stream:
|
||||
if chunk.choices[0].delta.content:
|
||||
print(chunk.choices[0].delta.content, end='')
|
||||
```
|
||||
|
||||
**Når å bruke streaming:**
|
||||
- Chatbots, conversational interfaces (brukeren ser respons umiddelbart)
|
||||
- Lange genereringer (unngå client-side timeouts)
|
||||
|
||||
**Når å **ikke** bruke streaming:**
|
||||
- Bulk-prosessering (sentiment analysis, oversettelse)
|
||||
- Når du trenger hele responsen før videre prosessering
|
||||
|
||||
### 5. Batch API for massiv kostnadsbesparelse
|
||||
|
||||
**Status:** GA
|
||||
|
||||
Azure OpenAI Batch API gir 50% kostnadsrabatt for asynkrone workloads med 24-timers turnaround.
|
||||
|
||||
| Fordel | Detalj |
|
||||
|--------|--------|
|
||||
| **Kostnadsreduksjon** | 50% rabatt vs. global standard |
|
||||
| **Separat quota** | Enqueued token quota påvirker ikke online workloads |
|
||||
| **Turnaround** | 24 timer (target), ikke garantert |
|
||||
| **Cancellation** | Cancel jobb når som helst; betal kun for completed work |
|
||||
|
||||
**Use cases:**
|
||||
- Large-scale data analysis
|
||||
- Content generation (bulk artikler, produktbeskrivelser)
|
||||
- Dokumentrevidering og oppsummering
|
||||
- NLP-tasks (sentiment analysis, translation på store datasett)
|
||||
|
||||
**Konfidensmarkør:** 🟢 **Høy** – Batch API er GA og anbefales av Microsoft for bulk-workloads.
|
||||
|
||||
### 6. Modellvalg for kostnad vs. ytelse
|
||||
|
||||
| Modell | Input Cost | Output Cost | Best For |
|
||||
|--------|-----------|-------------|----------|
|
||||
| **GPT-4.1-nano** | Lavest | Lavest | Enkel klassifisering, routing, strukturert output |
|
||||
| **GPT-4.1-mini** | Veldig lav | Lav | De fleste use cases; beste kostnad/ytelse-balanse |
|
||||
| **GPT-4.1 / GPT-4o** | Moderat | Moderat | Kompleks resonnering, kreativt innhold |
|
||||
| **o3-mini** | Høy | Høy (reasoning tokens) | Matematikk, kode, logisk resonnering |
|
||||
| **GPT-5** | Høyest | Høyest | Mest krevende oppgaver (sjelden nødvendig) |
|
||||
|
||||
**Strategi:** Start med GPT-4.1-mini, oppgrader kun hvis kvalitet er utilstrekkelig.
|
||||
|
||||
---
|
||||
|
||||
## Arkitekturmønstre
|
||||
|
||||
### Mønster 1: Multi-tier model cascade
|
||||
|
||||
Bruk billige modeller for routing/filtering, dyre modeller kun for komplekse oppgaver.
|
||||
|
||||
```
|
||||
User Query
|
||||
↓
|
||||
[GPT-4.1-nano: Intent classification] (5 tokens output)
|
||||
↓
|
||||
├─→ [Simple query] → Cache lookup → Response
|
||||
└─→ [Complex query] → [GPT-4o: Full reasoning] → Response
|
||||
```
|
||||
|
||||
**ROI:** 70-80% av queries kan håndteres av billigere modeller.
|
||||
|
||||
### Mønster 2: Context compression med embeddings
|
||||
|
||||
Erstatt lange dokumenter med semantic search + RAG.
|
||||
|
||||
```
|
||||
❌ Direkte document injection (10 000 tokens/request):
|
||||
system_message = f"Context: {full_documents}" # Dyrt hver gang
|
||||
|
||||
✅ RAG med embeddings (500 tokens/request):
|
||||
1. Index documents med Azure AI Search (engangs-kostnad)
|
||||
2. Query → embedding → semantic search → top 3 relevante chunks
|
||||
3. Inject kun relevante chunks (500 tokens) i prompt
|
||||
```
|
||||
|
||||
**Besparelse:** 95% reduksjon i input tokens (10k → 500).
|
||||
|
||||
### Mønster 3: Fine-tuning for prompt-reduksjon
|
||||
|
||||
Fine-tune modeller for domene-spesifikke oppgaver → kortere prompts.
|
||||
|
||||
```
|
||||
❌ Base model med lang prompt (2000 tokens instruction):
|
||||
"You are a Norwegian legal expert. Follow these guidelines: [1800 tokens]"
|
||||
|
||||
✅ Fine-tuned model (50 tokens):
|
||||
"Analyze contract" → Modellen har allerede lært domene-spesifikk kunnskap
|
||||
```
|
||||
|
||||
**Trade-off:**
|
||||
- Opfront kostnad: Training (token-basert) + hosting ($1.70/time for fine-tuned deployment)
|
||||
- Løpende besparelse: 95% reduksjon i input tokens per request
|
||||
- **Break-even:** Evaluer etter forventet request-volum (typisk >100k requests)
|
||||
|
||||
**Konfidensmarkør:** 🟡 **Moderat** – Fine-tuning kostnad/nytte varierer sterkt med use case.
|
||||
|
||||
---
|
||||
|
||||
## Beslutningsveiledning
|
||||
|
||||
### Når å prioritere token-optimalisering
|
||||
|
||||
| Scenario | Prioritet | Teknikk |
|
||||
|----------|-----------|---------|
|
||||
| Høyt request-volum (>1M requests/måned) | 🔴 Kritisk | Alle teknikker; vurder fine-tuning |
|
||||
| Repetitive prompts (chatbot, support) | 🔴 Kritisk | Prompt caching, RAG, model cascade |
|
||||
| Lange dokumenter i context | 🔴 Kritisk | RAG, context compression |
|
||||
| Batch-prosessering | 🟡 Viktig | Batch API (50% rabatt) |
|
||||
| Prototyping, lav last | 🟢 Lav | Fokus på funksjonalitet først |
|
||||
|
||||
### Decision tree: Kostnadsoptimalisering
|
||||
|
||||
```
|
||||
Start: Høye token-kostnader?
|
||||
│
|
||||
├─→ Høyt request-volum? (>100k/mnd)
|
||||
│ ├─→ Ja: Vurder Provisioned Throughput (PTU)
|
||||
│ └─→ Nei: Optimaliser per-request tokens
|
||||
│
|
||||
├─→ Repetitive prompts? (>50% overlapp)
|
||||
│ └─→ Ja: Design for prompt caching (system message først)
|
||||
│
|
||||
├─→ Lange dokumenter i context? (>5k tokens)
|
||||
│ └─→ Ja: Implementer RAG + Azure AI Search
|
||||
│
|
||||
├─→ Bulk-prosessering? (ikke-sanntid OK)
|
||||
│ └─→ Ja: Bruk Batch API (50% rabatt)
|
||||
│
|
||||
└─→ Kompleks domene-logikk? (lang instruction prompt)
|
||||
└─→ Ja: Vurder fine-tuning (break-even >100k requests)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integrasjon med Microsoft-stakken
|
||||
|
||||
### Azure AI Foundry: Token monitoring
|
||||
|
||||
```python
|
||||
# Overvåk token-bruk i Azure Monitor
|
||||
from azure.monitor.query import MetricsQueryClient
|
||||
|
||||
metrics_client = MetricsQueryClient(credential)
|
||||
|
||||
# Hent Processed Prompt Tokens (input TPM)
|
||||
response = metrics_client.query_resource(
|
||||
resource_uri=f"/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.CognitiveServices/accounts/{account}",
|
||||
metric_names=["ProcessedPromptTokens"],
|
||||
timespan=timedelta(days=7),
|
||||
granularity=timedelta(minutes=1),
|
||||
aggregations=["Average", "Maximum"]
|
||||
)
|
||||
|
||||
# Hent Generated Completion Tokens (output TPM)
|
||||
completion_response = metrics_client.query_resource(
|
||||
resource_uri=resource_uri,
|
||||
metric_names=["GeneratedCompletionTokens"],
|
||||
timespan=timedelta(days=7),
|
||||
granularity=timedelta(minutes=1),
|
||||
aggregations=["Average", "Maximum"]
|
||||
)
|
||||
```
|
||||
|
||||
**Nøkkel-metrics:**
|
||||
- `ProcessedPromptTokens`: Input TPM (inkludert cached tokens)
|
||||
- `GeneratedCompletionTokens`: Output TPM
|
||||
- `TokenTransaction`: Total tokens prosessert
|
||||
|
||||
### Azure API Management: Token rate limiting
|
||||
|
||||
Implementer token-baserte quotas per consumer/application.
|
||||
|
||||
```xml
|
||||
<llm-token-limit
|
||||
counter-key="@(context.Subscription.Id)"
|
||||
tokens-per-minute="10000"
|
||||
estimate-prompt-tokens="true"
|
||||
remaining-tokens-variable-name="remainingTokens">
|
||||
</llm-token-limit>
|
||||
```
|
||||
|
||||
**Fordeler:**
|
||||
- Forhindre at én app bruker all quota
|
||||
- Pre-calculate prompt tokens → avvis requests før de når backend
|
||||
- Rettferdig fordeling av TPM på tvers av apps
|
||||
|
||||
### Copilot Studio: Token-bevissthet
|
||||
|
||||
Copilot Studio abstraherer token-håndtering, men:
|
||||
- Lange conversation histories akkumulerer tokens (automatisk summarization etter 10-15 meldinger)
|
||||
- Adaptive Cards og rich content legger til tokens
|
||||
- Generative answers fra data sources kan bli dyre (hele documents injectes)
|
||||
|
||||
**Anbefaling:** Bruk **Generative Answers** med Azure AI Search (semantic ranking) istedenfor full document injection.
|
||||
|
||||
---
|
||||
|
||||
## Offentlig sektor (Norge)
|
||||
|
||||
### Budsjettstyring og kostnadskontroll
|
||||
|
||||
Offentlige virksomheter må ha forutsigbare IT-kostnader. Token-optimalisering er kritisk for:
|
||||
|
||||
1. **Årsbudsjett-compliance:** Unngå overforbruk midt i budsjettåret
|
||||
2. **Anbud og kontrakter:** Estimere token-kostnader for 3-5 års driftsperiode
|
||||
3. **Transparens:** Kunne forklare kostnader til politisk ledelse
|
||||
|
||||
**Praktisk tilnærming:**
|
||||
```
|
||||
1. Baseline-måling (1 måned):
|
||||
- Mål faktisk token-bruk i pilot (Azure Monitor)
|
||||
- Identifiser kostnadsdrivere (store prompts? høyt volum?)
|
||||
|
||||
2. Optimaliser (2-4 uker):
|
||||
- Implementer prompt caching (rask win)
|
||||
- Evaluer modellvalg (GPT-4.1-mini vs. GPT-4o)
|
||||
- Vurder RAG hvis lange dokumenter brukes
|
||||
|
||||
3. Produksjon med budsjett-alerts:
|
||||
- Sett Azure Cost Management budgets
|
||||
- Alerts ved 80% / 100% av månedlig budsjett
|
||||
- Action groups for automatisk skalering/throttling
|
||||
```
|
||||
|
||||
### Data residency og token-kostnader
|
||||
|
||||
| Krav | Deployment Type | Token-strategi |
|
||||
|------|----------------|----------------|
|
||||
| Data residency Norge | Standard (regional) eller Data Zone Standard | Må akseptere høyere kostnader; fokus på token-effektivitet |
|
||||
| Ingen residency-krav | Global Standard | 10-30% rabatt; kan bruke mer tokens innenfor samme budsjett |
|
||||
|
||||
**Anbefaling:** For **ikke-personopplysninger** (FAQ, interne dokumenter), bruk Global Standard → mer rom for tokens.
|
||||
|
||||
### Compliance og token-logging
|
||||
|
||||
**GDPR/logging-krav:** API requests logges i Azure Monitor, inkludert token-bruk. Sikre at:
|
||||
- PII ikke injectes i prompts (kan logges)
|
||||
- Stored Completions (hvis brukt) har data retention policies
|
||||
- Token-bruk kan audits for kostnadskontroll
|
||||
|
||||
---
|
||||
|
||||
## Kostnad og lisensiering
|
||||
|
||||
### Azure OpenAI prismodell (per 1M tokens, Feb 2026)
|
||||
|
||||
#### Standard deployment (pay-as-you-go)
|
||||
|
||||
| Modell | Input | Output | Cached Input |
|
||||
|--------|-------|--------|--------------|
|
||||
| GPT-4.1-nano | $0.10 | $0.40 | $0.05 |
|
||||
| GPT-4.1-mini | $0.20 | $0.80 | $0.10 |
|
||||
| GPT-4.1 | $2.50 | $10.00 | $1.25 |
|
||||
| GPT-4o | $2.50 | $10.00 | $1.25 |
|
||||
| GPT-4o-mini | $0.15 | $0.60 | $0.075 |
|
||||
| o3-mini | $1.10 | $4.40 | $0.55 |
|
||||
|
||||
**Merk:** Reasoning tokens (o-series) har separat pricing.
|
||||
|
||||
#### Batch API (50% rabatt)
|
||||
|
||||
| Modell | Input | Output |
|
||||
|--------|-------|--------|
|
||||
| GPT-4.1-mini | $0.10 | $0.40 |
|
||||
| GPT-4o | $1.25 | $5.00 |
|
||||
| o3-mini | $0.55 | $2.20 |
|
||||
|
||||
#### Provisioned Throughput (PTU-basert)
|
||||
|
||||
PTU-prising er basert på kapasitet (PTUs), ikke tokens. Token-optimalisering påvirker:
|
||||
- **Hvor mange PTUs du trenger:** Færre tokens → lavere PTU-krav
|
||||
- **Cached tokens:** Opptil 100% rabatt (frigjør PTU-kapasitet)
|
||||
|
||||
**Eksempel:**
|
||||
- Workload: 500k input TPM + 150k output TPM = 30 PTUs
|
||||
- Med 50% cache hit rate: 250k input TPM (cached, gratis) + 250k input TPM + 150k output = 20 PTUs
|
||||
- **Besparelse:** 33% reduksjon i PTU-kostnad
|
||||
|
||||
**Konfidensmarkør:** 🟢 **Høy** – Priser hentet fra offisiell Azure-dokumentasjon (Feb 2026).
|
||||
|
||||
### Fine-tuning kostnader
|
||||
|
||||
| Kostnadstype | Beregning | Eksempel (GPT-4.1) |
|
||||
|--------------|-----------|-------------------|
|
||||
| **Training** | Tokens × epochs × training price | 1M tokens × 2 epochs × $2/M = $4 |
|
||||
| **Hosting** | $1.70/time (standard deployment) | $1,224/måned (kontinuerlig) |
|
||||
| **Inference** | Input + output tokens (samme som base + hosting) | 20M input × $1.10 + 40M output × $4.40 = $198 |
|
||||
|
||||
**Break-even analyse:**
|
||||
```
|
||||
Besparelse per request (prompt-reduksjon): 1800 tokens × $0.20/1M = $0.00036
|
||||
Månedlig hosting-kostnad: $1,224
|
||||
Break-even requests/måned: $1,224 / $0.00036 = 3.4M requests
|
||||
|
||||
→ Kun lønnsomt ved **svært** høyt volum (>3M requests/måned)
|
||||
```
|
||||
|
||||
### ROI-kalkulator for token-optimalisering
|
||||
|
||||
**Scenario:** Chatbot for offentlig sektor (1M requests/måned)
|
||||
|
||||
| Tiltak | Token-reduksjon | Månedlig besparelse (NOK) |
|
||||
|--------|-----------------|---------------------------|
|
||||
| Baseline (ingen optimalisering) | - | Kostnad: 15 000 kr |
|
||||
| Prompt caching (50% cache hit) | 50% input | Sparer: 3 750 kr (25%) |
|
||||
| Kortere prompts (-30% input) | 30% input | Sparer: 2 250 kr (15%) |
|
||||
| Strukturerte outputs (-20% output) | 20% output | Sparer: 2 400 kr (16%) |
|
||||
| Bytt til GPT-4.1-mini fra GPT-4o | - | Sparer: 10 500 kr (70%) |
|
||||
| **Total optimalisering** | **Kombinert** | **Sparer: 12 000 kr/måned (80%)** |
|
||||
|
||||
**Konfidensmarkør:** 🟡 **Moderat** – Besparelser varierer med workload; disse er representative estimater.
|
||||
|
||||
---
|
||||
|
||||
## For arkitekten (Cosmo)
|
||||
|
||||
### Praktiske spørsmål under arkitekturrådgivning
|
||||
|
||||
1. **"Hvor mange requests forventer dere per måned?"**
|
||||
- <100k: Standard deployment, fokus på funksjonalitet
|
||||
- 100k-1M: Optimaliser tokens (caching, compression)
|
||||
- >1M: Vurder PTU, Batch API, fine-tuning
|
||||
|
||||
2. **"Har dere repetitive prompts (chatbot, FAQ, support)?"**
|
||||
- Ja → Design for prompt caching (system message først)
|
||||
- Nei → Fokus på andre optimaliseringsteknikker
|
||||
|
||||
3. **"Bruker dere lange dokumenter som context?"**
|
||||
- Ja → Implementer RAG + Azure AI Search (95% token-reduksjon)
|
||||
- Nei → Standard prompt engineering
|
||||
|
||||
4. **"Har dere budsjettbegrensninger eller årsbudsjett?"**
|
||||
- Ja → Sett Azure Cost Management budgets + alerts
|
||||
- Implementer token rate limiting i API Management
|
||||
|
||||
5. **"Er sanntids-respons kritisk?"**
|
||||
- Ja → Standard/PTU + streaming
|
||||
- Nei → Vurder Batch API (50% rabatt)
|
||||
|
||||
### Red flags for kostnadsfeller
|
||||
|
||||
🚩 **"Vi sender hele PDF-filer (100+ sider) som context"**
|
||||
→ RAG er obligatorisk; ellers 50k+ tokens per request
|
||||
|
||||
🚩 **"Fine-tuned modell har vært deployed i 6 måneder uten bruk"**
|
||||
→ $1.70/time × 24 × 180 dager = $7,344 hosting-kostnad uten verdi
|
||||
|
||||
🚩 **"Vi bruker GPT-4o for alt"**
|
||||
→ 80% av use cases kan bruke GPT-4.1-mini (5× billigere)
|
||||
|
||||
🚩 **"Vi har ikke monitoring på token-bruk"**
|
||||
→ Kostnader kan eskalere ukontrollert; sett opp Azure Monitor metrics
|
||||
|
||||
### Anbefalte arkitekturmønstre per scenario
|
||||
|
||||
| Scenario | Anbefalt mønster | Estimert besparelse |
|
||||
|----------|-----------------|---------------------|
|
||||
| **Kundeservice chatbot (repetitive spørsmål)** | Prompt caching + model cascade (nano for routing) | 60-70% |
|
||||
| **Dokumentanalyse (lange PDF-er)** | RAG + Azure AI Search + GPT-4.1-mini | 80-90% |
|
||||
| **Bulk content generation (ikke-sanntid)** | Batch API + strukturerte outputs | 50-60% |
|
||||
| **Kompleks resonnering (kode, matematikk)** | o3-mini (kun når nødvendig) + caching | 30-40% |
|
||||
| **Intern FAQ (lavt volum)** | Standard deployment + GPT-4.1-mini | 70% (vs. GPT-4o) |
|
||||
|
||||
### Validering av løsning: Token-effektivitets-checklist
|
||||
|
||||
✅ **Prompt design:**
|
||||
- [ ] Statisk innhold (system message, dokumenter) plassert først?
|
||||
- [ ] `max_tokens` satt til minimum nødvendig?
|
||||
- [ ] Stop sequences definert for å hindre overgenerering?
|
||||
|
||||
✅ **Caching:**
|
||||
- [ ] Prompts >1024 tokens har statisk prefix?
|
||||
- [ ] `prompt_cache_key` brukt for high-frequency workloads?
|
||||
- [ ] Cache hit rate monitores i Azure Monitor?
|
||||
|
||||
✅ **Modellvalg:**
|
||||
- [ ] Bruker GPT-4.1-mini som default (oppgrader kun hvis nødvendig)?
|
||||
- [ ] Model cascade implementert (billig modell for routing)?
|
||||
|
||||
✅ **Kostnadsovervåking:**
|
||||
- [ ] Azure Cost Management budgets satt opp?
|
||||
- [ ] Alerts ved 80%/100% av budsjett?
|
||||
- [ ] Token-metrics logges og analyseres månedlig?
|
||||
|
||||
✅ **Arkitektur:**
|
||||
- [ ] RAG implementert for lange dokumenter?
|
||||
- [ ] Batch API vurdert for bulk-workloads?
|
||||
- [ ] Content filtering justert (hvis lavrisiko use case)?
|
||||
|
||||
---
|
||||
|
||||
## Kilder og verifisering
|
||||
|
||||
**Offisiell Microsoft-dokumentasjon:**
|
||||
1. [Prompt caching for Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/prompt-caching)
|
||||
2. [Plan and manage costs for Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/manage-costs)
|
||||
3. [Performance and latency optimization](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/latency)
|
||||
4. [Batch API for Azure OpenAI](https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/batch)
|
||||
5. [Azure OpenAI pricing](https://azure.microsoft.com/pricing/details/cognitive-services/openai-service/)
|
||||
|
||||
**Verifisert:** Februar 2026 via microsoft-learn MCP-server
|
||||
|
||||
**Confidence level:** 🟢 **Høy** for GA-funksjoner (prompt caching, batch API, standard pricing), 🟡 **Moderat** for ROI-estimater (workload-avhengige).
|
||||
|
||||
---
|
||||
|
||||
**Sist oppdatert av Cosmo Skyberg, Microsoft AI Solution Architect**
|
||||
*For spørsmål om token-optimalisering i din løsning, start en arkitektursesjon med `/architect`.*
|
||||
Loading…
Add table
Add a link
Reference in a new issue