Et hurtigt svar på ét kort spørgsmål viser, at en lokal sprogmodel grundlæggende fungerer. Til en infrastrukturbeslutning er en test med de kommende opgaver og deres faktiske belastning langt mere oplysende. Det omfatter svarkvalitet, ventetider, længere input, samtidig brug og drift efter en fejl.
Et pilotprojekt er især nyttigt, når det på forhånd står klart, hvilken beslutning resultatet skal muliggøre. Eksempelvis: Er det eksisterende miljø tilstrækkeligt, kræves anden hardware, eller passer en ekstern eller hybrid tjeneste bedre? Testplanen følger dette spørgsmål.
Begynd med et lille, repræsentativt opgavesæt
Egnede testopgaver kommer fra den planlagte arbejdsgang: et kort fagligt spørgsmål, et resumé af et længere godkendt dokument eller et scriptudkast, som skal kontrolleres. For hver opgave fastlægges, hvad der kendetegner et brugbart resultat.
Ved vidensspørgsmål indgår forventede kilder og tilfælde uden tilstrækkeligt grundlag. Kode kræver faglig gennemgang og passende tests. Fortrolige originaldata bruges kun i det miljø, der er godkendt til formålet; til forberedelsen kan egnede rensede eller særligt fremstillede testdata være nok.
Vurder kvalitet og hastighed hver for sig
En model, der hurtigt leverer forkerte resultater, opfylder ikke målet. Derfor vurderes først faglig anvendelighed, nødvendige rettelser og håndtering af manglende oplysninger. Derefter kan man sammenligne den svartid og indsats, der skal til for at opnå denne kvalitet.
Modelversion, kvantisering, inferenssoftware, indstillinger og testdata registreres. Ellers kan et hurtigere svar skyldes en ændret opgave eller et andet kvalitetsniveau. En skiftende dokumentsamling kan også påvirke sammenligningen af en RAG-applikation.
Opdel ventetiden i dens bestanddele
- Tid til første token
- Den beskriver, hvornår output begynder. Kø og behandling af input kan påvirke tiden. Desuden bør den oplevede tid fra afsendelse i applikationen til det synlige svar måles.
- Løbende output
- Hastigheden under genereringen påvirker, hvor længe et længere svar tager. Høj samlet serverkapacitet siger endnu ikke, hvor hurtigt den enkelte bruger får sit svar.
- Samlet varighed
- Den omfatter hele applikationsforløbet. Søgning, dokumentbehandling, værktøjskald og netværksveje kan komme oveni.
- Spredning og fejl
- Typiske værdier og langsommere ydertilfælde vurderes sammen. Antal målinger, timeouts og afbrudte opgaver hører med til resultatet.
Den officielle vLLM-dokumentation om metrikker (eksternt link) skelner blandt andet mellem målinger af ventetid, input og output. Hvilke metrikker et konkret runtime tilbyder, kontrolleres for den anvendte version. Målinger fra forskellige komponenter skal beskrive samme tidsrum og opgave.
Test korte chats, lange kontekster og samtidighed
En lang kontekst kræver ekstra behandling og hukommelse. Ved samtidige forespørgsler deler flere forløb de tilgængelige ressourcer. Dokumentationen om kontekst i Ollama (eksternt link) og dokumentationen om optimering af vLLM (eksternt link) forklarer disse sammenhænge; konkrete indstillinger afhænger af version og hardware.
En meningsfuld test kombinerer derfor korte og længere input med en samtidighed, der passer til den planlagte brug. Ud over jævnt indkommende forespørgsler undersøges forventede spidsbelastninger. Hvis batching øger kapaciteten, skal det stadig kontrolleres, om de enkelte svartider passer til brugerne.
En mulig testplan
Udfør først de samme faglige opgaver enkeltvis. Test derefter korte forespørgsler sammen med opgaver på godkendte dokumenter. Efterlign så en forventet spidsperiode, og observer adfærden ved overbelastning. Målværdier aftales med brugerne på forhånd.
Planen er et eksempel, der kan tilpasses. Den indeholder ingen målte DAXS-ydelsestal og erstatter ikke en vurdering af det konkrete miljø.
Skeln mellem opstart, løbende drift og genopretning
Efter en genstart skal modellen muligvis først indlæses. Denne kolde start måles separat fra drift med en allerede indlæst model. Hurtige NVMe-drev kan understøtte indlæsning og dataoperationer; det betyder ikke en generel acceleration af tokengenereringen for en model, der ligger helt i GPU-hukommelsen.
Pilotprojektet omfatter også tab af forbindelse, en afbrudt opgave og genstart af en tjeneste. Applikationen bør vise sin tilstand forståeligt og tilbyde en fornuftig vej til genforsøg eller overdragelse. Overbelastning må ikke ubemærket føre til ufuldstændige resultater.
Gør resultater til en arkitekturbeslutning
Sammenlign brugbare resultater, rettelsesarbejde, latenstid, kapacitet og løbende drift. De samlede omkostninger omfatter også administration, vedligeholdelse, energi, backup og nødvendig tilgængelighed. Ved eksterne tjenester kommer deres faktiske brugsomkostninger og de aftalte dataveje oveni.
Resultatet kan være en mindre model, der passer til opgaven, ekstra ressourcer, en afgrænset kø eller en anden driftsmodel. Lokale, eksterne og hybride tilgange vurderes på samme opgave. Et pilotprojekt skal muliggøre en velunderbygget næste beslutning uden bagefter at begrunde køb af hardware, man allerede havde forudsat.
DAXS planlægger testen, etablerer et egnet miljø og vurderer resultaterne med jeres IT. Vores fagside om lokale LLM’er og infrastrukturforklarer det tekniske grundlag. Ved tilknyttede videnssamlinger hører kvaliteten af søgning, kilder og adgangsrettigheder til i samme testramme.
