När modell, verktyg och hårdvara väljs samtidigt blir resultatet ofta ett tekniktest utan beslut. Separera i stället problemet, datagränsen, kvalitetsprovet och körmiljön.
1. Beskriv arbetslasten
Skriv en mening som innehåller indata, önskat resultat och användare. ”Sammanfatta godkända interna mötesanteckningar till beslut och åtgärder för projektledaren” går att prova. ”Vi ska ha en lokal chatbot” gör det inte.
- Vilken indata får systemet läsa?
- Vilket resultat ska en människa kunna kontrollera?
- Hur snabbt behöver svaret komma?
- Hur många ska använda tjänsten samtidigt?
- Vilken kostnadsgräns gäller för piloten och för en fortsatt drift?
- Vad får systemet aldrig göra eller hitta på?
2. Bestäm varför körningen ska vara lokal
Skälet styr arkitekturen. Det kan handla om att arbeta utan internet, hålla material inom ett avgränsat nät, få förutsägbar styckkostnad eller kunna välja och frysa modellversion. ”Integritet” är för vagt tills du har beskrivit vilka data som skyddas och mot vilken överföring eller åtkomst.
Modellen kan köras på din maskin samtidigt som gränssnittet skickar telemetri, dokument synkas till molnet eller API:t exponeras utan autentisering. Kontrollera hela flödet i integritetsguiden.
3. Skapa provpaketet före installationen
Samla 15–30 representativa exempel. Använd syntetiskt eller uttryckligen godkänt material i den första piloten. Lägg till normalfall, ovanliga format, långa indata och fall där modellen ska svara att underlaget inte räcker. Samma paket återanvänds sedan för att jämföra modellkandidater och för att avgöra om en uppdatering blev bättre — bygg det en gång och frys det.
För varje exempel skriver du vad ett godkänt resultat kräver. Bedöm exempelvis faktastöd, svenska, format, fullständighet och om modellen avstår när information saknas. Det minskar risken att en övertygande demo förväxlas med ett fungerande system.
4. Välj den enklaste körvägen
Regeln är kort: välj den minsta driftformen som löser dagens arbetslast, och skriv ner vad som ska få dig att flytta upp en nivå. Skrivbordsapp för att prova, lokal tjänst när något annat ska anropa modellen, server när flera ska dela kapacitet. Jämförelsen och det ifyllbara beslutet hör hemma i nästa steg — verktygsguiden — så att du inte låser driftformen innan arbetslasten är beskriven.
5. Kör och dokumentera piloten
Spara maskin, operativsystem, runtimeversion, modellvariant, kvantisering, inställningar och testdatum. Kör provpaketet och mät kvalitet, tid till första svar, total svarstid och maximal minnesanvändning. Notera fel, omstarter och manuellt efterarbete. Jämför också utfallet med kostnadsgränsen: inköp och installationstid i piloten, och beräknad hårdvara, energi, backup och förvaltningstid vid fortsatt drift. Befintlig hårdvara är en angiven förutsättning, inte en kostnad som får försvinna ur kalkylen.
6. Fatta ett verkligt beslut
Avsluta piloten med ett av fyra utfall: fortsätt i samma skala, byt modell, byt hårdvara eller avbryt lokal väg för detta användningsfall. Skriv vad som skulle få beslutet att omprövas. En pilot som bara lämnar en installerad app är inte färdig.
Pilotspecifikationen
De sex stegen ryms på en sida. Den sidan är det som gör piloten granskningsbar — och det som de tre följande guiderna bygger vidare på.
Exemplet är påhittat och följer samma fall genom hela guidevägen. Kopiera formen, inte värdena.
| Fält | Exempel | Vad raden ska bevisa |
|---|---|---|
| Arbetslast | Sammanfatta godkända interna mötesanteckningar till beslut och åtgärder för projektledaren | Att uppgiften går att prova — ”vi ska ha en lokal chatbot” gör det inte |
| Indata | Mötesanteckningar som mötesägaren godkänt; syntetiskt material under piloten | Vad systemet får läsa, och inget mer |
| Godkänt resultat | Varje beslut och åtgärd har ansvarig och stöd i anteckningen; modellen skriver att underlaget saknas när det gör det | Vad en människa faktiskt ska kontrollera |
| Svarstidskrav | Under en minut för ett möte på tio sidor | Att kravet är mätbart i stället för ”snabbt nog” |
| Kostnadsgräns | Pilot på befintlig arbetsstation, högst åtta timmars installation och inget nyinköp; före fyra användare ska hårdvara, energi, backup och månatlig förvaltningstid vara prissatta | Att piloten har ett tak och att en senare uppskalning inte kallas gratis |
| Användare nu och planerat | En under piloten; fyra projektledare efter godkännande | Vilken driftform steg 2 ska landa i |
| Får aldrig | Hitta på beslut, behandla ogodkända anteckningar eller lämna arbetsstationen | Gränsen som gör ett fel till ett avbrott i stället för en incident |
| Skäl till lokal körning | Materialet ska inte lämna arbetsstationen | Att ”integritet” är preciserat till en namngiven överföring |
| Provpaket | 15–30 exempel: normalfall, ovanliga format, långa möten och fall utan tillräckligt underlag | Att bedömningen inte vilar på en lyckad demo |
| Miljö | Maskin, operativsystem, runtimeversion, modellvariant, kvantisering, inställningar, datum | Att resultatet går att återskapa |
| Mätvärden | Godkända exempel, tid till första svar, total svarstid, högsta minnesanvändning | Baslinjen som driftguiden senare jämför mot |
| Beslut | Fortsätt, byt modell, byt hårdvara eller avbryt — med datum och namn | Att piloten faktiskt avslutas |
| Omprövas | Vad som skulle ändra beslutet | Att beslutet är villkorat och inte permanent |
Kopiera tom mall
PILOTSPECIFIKATION — <arbetslastens namn> Upprättad: <datum> Ägare: <namn> Arbetslast ........... en mening: indata, resultat, användare Indata ............... Godkänt resultat ..... Svarstidskrav ........ Kostnadsgräns ........ inköp, arbetstid och högsta löpande kostnad Kostnadsantaganden ... befintlig hårdvara, energi, backup, förvaltning Användare nu ......... Användare planerat ... Får aldrig ........... Skäl till lokal körning Provpaket Antal .............. (15–30) Normalfall ......... Ovanliga format .... Långa indata ....... Underlag saknas .... Bedömningsregler ... skrivna före första körningen Miljö Maskin / OS ........ Runtime / version .. Modell / kvantisering Inställningar ...... Testdatum .......... Mätvärden Godkända exempel ... Tid till första svar Total svarstid ..... Högsta minnesanvändning Fel och efterarbete Utfall mot kostnadsgräns Beslut ............... fortsätt / byt modell / byt hårdvara / avbryt Fattat av ............ <namn>, <datum> Omprövas om ..........
Källor och tekniskt underlag
- Ollama — serverkonfiguration, lokalt läge, modellagring och samtidighet
- LM Studio — vad som fungerar offline och vad som kräver nätverk
- llama.cpp — lokala körsätt, modellformat och hårdvarubackends
Källorna kontrollerades 31 augusti 2026. Produktfunktioner ska kontrolleras mot installerad version och källorna på nytt senast 30 september 2026.