Ett driftkort på en sida ska göra installationen begriplig för någon annan än den som satte upp den. Det är den minsta grunden för säker uppdatering och felsökning.
Frys det fungerande läget
Spara modellens exakta identifierare och kvantisering, runtimeversion, drivrutin, startkommando, konfiguration och hårdvaruprofil. Lägg till testpaketets resultat och datum. ”Senaste modellen” eller ”standardinställningar” går inte att återskapa efter en förändring.
Mät fyra sorters signaler
| Signal | Exempel | Varför |
|---|---|---|
| Tillgänglighet | Hälsokontroll, startfel, kötid | Visar om tjänsten går att använda |
| Kapacitet | Minne, GPU-belastning, samtidiga anrop | Visar när arbetslasten når gränsen |
| Prestanda | Tid till första token, total svarstid | Visar om användarupplevelsen försämras |
| Kvalitet | Godkända testfall, formatfel, manuellt efterarbete | Visar om en modelländring faktiskt blev bättre |
Ett långsamt svar är sällan en enda sak. Dela upp mätningen i modelladdning, promptbehandling och generering innan du drar slutsatsen att modellen är för stor — så här läser du av fälten var för sig.
Logga inte hela prompts eller svar slentrianmässigt. Mät tekniska metadata och använd ett separat, kontrollerat provpaket för kvalitet. Om innehåll måste sparas för felsökning ska åtkomst och gallring beslutas uttryckligen.
Uppdatera som en kontrollerad ändring
- Läs ändringen och bestäm vilken risk den kan påverka.
- Ta en återställningsbar kopia av konfigurationen.
- Kör provpaketet i en separat miljö eller på en begränsad instans.
- Jämför kvalitet, prestanda och resursanvändning mot baslinjen.
- Rulla ut med tydlig stoppregel och behåll föregående fungerande version.
Skilj backup från återställning
Modellfiler kan ofta hämtas igen, men konfiguration, åtkomstregler och lokala index kan vara unika. Bestäm vad som faktiskt behöver säkerhetskopieras. Prova sedan en återställning på en ren plats. En backup som aldrig har återlästs är bara ett antagande.
Planera modellbortfall och hårdvarufel
Reservrutinen kan vara en mindre lokal modell, en manuell process eller ett godkänt externt alternativ. Den behöver inte ge samma kapacitet, men användarna ska veta vad som fungerar och vilka data som får användas. Skriv också hur tjänsten stängs av snabbt vid felaktig exponering eller överbelastning.
Driftkortet
Sexton fält räcker för att någon annan ska kunna ta över installationen. Tabellen förklarar de tretton som behöver en motivering; mallen lägger dessutom till ersättare, baslinje och avstängningsväg. Kortet är färdigt när en kollega kan svara på vad som körs, hur det mår och hur man backar — utan att fråga den som byggde det.
Exemplet nedan är påhittat och visar detaljnivån. Kopiera formen, inte värdena: versioner, digest och portar ska vara det din egen installation faktiskt rapporterar.
| Fält | Exempel | Vad raden ska bevisa |
|---|---|---|
| Ägare | Namngiven förvaltare och en utsedd ersättare | Att någon är ansvarig även under frånvaro |
| Användare | Fyra projektledare på avdelningen, klienter på kontorsnätet | Hur många som märker ett avbrott |
| Syfte | Sammanfatta godkända interna mötesanteckningar till beslut och åtgärder | Att arbetslasten är avgränsad och kontrollerbar |
| Maskin | Arbetsstation, Ubuntu 24.04 LTS, 64 GB RAM, GPU med 24 GB VRAM, drivrutinsversion noterad | Vad mätvärdena i baslinjen gäller för |
| Modell | Exakt tagg och kvantisering samt de första tecknen i modellens digest | Att läget går att återskapa; ”senaste modellen” gör det inte |
| Runtime | Runtimens version enligt vad den själv rapporterar, plus startkommando och konfigurationsfil | Vad som faktiskt kör modellen |
| Nätverksyta | Bindadress och port, vilka klienter som når tjänsten och hur de autentiseras | Att exponeringen är avsedd och inte en bieffekt |
| Datalagring | Sökväg till modellfiler, historik, cache och loggar, med gallringsregel per post | Var data hamnar och när den försvinner |
| Hälsokontroll | Anrop mot runtimens versions- eller hälsoslutpunkt på loopbackadressen var 60:e sekund; friskt svar är HTTP 200 inom två sekunder | Hur avbrott upptäcks utan att en användare rapporterar det |
| Uppdateringssteg | Hänvisning till den kontrollerade ändringen ovan, med namn på den som får godkänna | Att uppdatering är en rutin, inte en impuls |
| Rollback | Föregående modellfil och konfiguration ligger kvar; kommandot som återgår är utskrivet | Att vägen tillbaka är provad och inte teoretisk |
| Backup | Konfiguration, åtkomstregler och lokala index; datum då återläsning senast provades | Att kopian går att läsa tillbaka |
| Reservrutin | Mindre lokal modell eller manuell process, plus vem som meddelar användarna | Vad som gäller när tjänsten är nere |
Kopiera tom mall
DRIFTKORT — <tjänstens namn> Upprättat: <datum> Senast ändrat: <datum> Ägare .............. Ersättare .......... Användare .......... Syfte .............. Maskin ............. Modell ............. tagg / kvantisering / digest Runtime ............ version / startkommando / konfigurationsfil Nätverksyta ........ bindadress:port / vilka klienter / autentisering Datalagring ........ modellfiler / historik / cache / loggar / gallring Hälsokontroll ...... vad anropas / hur ofta / vad räknas som friskt Baslinje ........... provpaketets resultat, svarstid, minne, datum Uppdateringssteg ... vem godkänner / var provkörning sker Rollback ........... vad sparas / kommandot tillbaka Backup ............. vad kopieras / var / senast återläst Reservrutin ........ alternativ / vem meddelar / tillåtna data Avstängning ........ hur tjänsten stoppas snabbt och av vem
Källor
- Ollama — loggar, modellernas livstid i minnet, kö och samtidighet
- Ollama — kontextlängd, minne och kontroll av processorplacering
- LM Studio — lokal server och API-alternativ
Källorna kontrollerades 1 september 2026 och ska kontrolleras på nytt senast 30 september 2026. Driftkortet ska uppdateras efter varje modell-, runtime- eller nätverksändring.