Een snel antwoord op één korte vraag laat zien dat een lokaal taalmodel in principe werkt. Voor een infrastructuurkeuze zegt een test met de toekomstige taken en hun werkelijke belasting veel meer. Daarbij horen antwoordkwaliteit, wachttijden, langere invoer, gelijktijdig gebruik en de werking na een storing.
Een pilot is vooral nuttig als vooraf duidelijk is welke beslissing het resultaat moet ondersteunen. Bijvoorbeeld: volstaat de bestaande omgeving, is andere hardware nodig of past een externe of hybride dienst beter? Die vraag bepaalt het testplan.
Beginnen met een kleine, representatieve verzameling taken
Geschikte testtaken komen uit het beoogde werkproces: een korte vakinhoudelijke vraag, de samenvatting van een langer goedgekeurd document of een te controleren scriptontwerp. Voor elke taak wordt bepaald waaraan een bruikbaar resultaat herkenbaar is.
Bij kennisvragen horen verwachte bronnen en situaties zonder voldoende onderbouwing. Code vereist inhoudelijke controle en passende tests. Vertrouwelijke oorspronkelijke gegevens worden alleen in de daarvoor goedgekeurde omgeving gebruikt; voor de voorbereiding kunnen geschikte opgeschoonde of speciaal gemaakte testgegevens volstaan.
Kwaliteit en snelheid afzonderlijk beoordelen
Een model dat snel onjuiste resultaten levert, bereikt het doel niet. Daarom worden eerst inhoudelijke bruikbaarheid, benodigde correcties en de omgang met ontbrekende informatie beoordeeld. Daarna kan worden vergeleken met welke responstijd en inspanning die kwaliteit wordt bereikt.
Modelversie, kwantisatie, inferentiesoftware, instellingen en testgegevens worden vastgelegd. Anders kan een sneller antwoord voortkomen uit een gewijzigde taak of een ander kwaliteitsniveau. Ook een wisselend documentenbestand kan de vergelijking van een RAG-toepassing veranderen.
De wachttijd in onderdelen opsplitsen
- Tijd tot het eerste token
- Die beschrijft wanneer de uitvoer begint. Wachtrijen en de verwerking van de invoer kunnen deze tijd beïnvloeden. Meet daarnaast de ervaren tijd vanaf het versturen in de toepassing tot het verschijnen van het antwoord.
- Lopende uitvoer
- De snelheid tijdens het genereren beïnvloedt hoe lang een langer antwoord duurt. Een hoge totale serverdoorvoer zegt op zichzelf nog niet hoe snel een individuele gebruiker zijn antwoord krijgt.
- Totale duur
- Die omvat de volledige bewerking in de toepassing. Zoeken, documentverwerking, toolaanroepen en netwerktrajecten kunnen daar tijd aan toevoegen.
- Spreiding en fouten
- Typische waarden en tragere uitzonderingsgevallen worden samen bekeken. Het aantal metingen, time-outs en afgebroken taken horen bij het resultaat.
De officiële vLLM-documentatie over metrieken (externe link) onderscheidt onder meer metingen van wachttijd, invoer en uitvoer. Controleer welke metrieken de concrete runtime in de gebruikte versie biedt. Meetwaarden van verschillende componenten moeten dezelfde periode en dezelfde taak beschrijven.
Korte chats, lange contexten en gelijktijdigheid testen
Een lange context vereist extra verwerking en geheugen. Bij gelijktijdige aanvragen delen meerdere processen de beschikbare middelen. De Ollama-documentatie over context (externe link) en de vLLM-documentatie over optimalisatie (externe link) lichten die verbanden toe; concrete instellingen zijn afhankelijk van de versie en hardware.
Een zinvolle test combineert daarom korte en langere invoer met een gelijktijdigheid die past bij het geplande gebruik. Naast regelmatig binnenkomende aanvragen worden ook verwachte pieken bekeken. Als batching meer doorvoer oplevert, moet nog steeds worden gecontroleerd of de afzonderlijke responstijden voor gebruikers voldoen.
Een mogelijk testplan
Voer eerst dezelfde inhoudelijke taken afzonderlijk uit. Test daarna korte aanvragen samen met taken op goedgekeurde documenten. Boots vervolgens een verwachte piekperiode na en observeer het gedrag bij overbelasting. De streefwaarden worden vooraf met gebruikers afgesproken.
Dit plan is een aanpasbaar voorbeeld. Het bevat geen gemeten DAXS-prestatiecijfers en vervangt geen onderzoek van de concrete omgeving.
Opstarten, normaal bedrijf en herstel onderscheiden
Na een herstart moet een model mogelijk eerst worden geladen. Deze koude start wordt afzonderlijk gemeten van het bedrijf met een al geladen model. Snelle NVMe-schijven kunnen laad- en gegevensbewerkingen ondersteunen; daaruit volgt geen algemene versnelling van tokengeneratie bij een model dat volledig in het GPU-geheugen staat.
Bij de pilot horen ook een verbroken verbinding, een afgebroken opdracht en het herstarten van een dienst. De toepassing hoort haar status begrijpelijk te tonen en een zinvolle route voor opnieuw proberen of overdragen te bieden. Overbelasting mag niet stilzwijgend tot onvolledige resultaten leiden.
Resultaten omzetten in een architectuurkeuze
Vergelijk bruikbare resultaten, correctiewerk, latentie, capaciteit en dagelijks beheer. Bij de totale kosten tellen ook administratie, onderhoud, energie, back-up en benodigde beschikbaarheid mee. Bij externe diensten komen de concrete gebruikskosten en de afgesproken gegevensroutes erbij.
De uitkomst kan een kleiner passend model, extra middelen, een begrensde wachtrij of een ander beheermodel zijn. Lokale, externe en hybride oplossingen worden op dezelfde taak beoordeeld. Een pilot moet een onderbouwde volgende beslissing mogelijk maken, zonder achteraf de aanschaf van vooraf veronderstelde hardware te rechtvaardigen.
DAXS plant de test, richt een geschikte omgeving in en beoordeelt de resultaten samen met uw IT. Onze vakpagina over lokale LLM’s en infrastructuurlegt de technische basis uit. Bij gekoppelde kennisverzamelingen hoort de kwaliteit van zoeken, bronnen en toegangsrechten in hetzelfde toetsingskader.
