Het nuttige resultaat bepalen voordat je naar doorvoer zoekt
Meet bij interactie de wachttijd voor het eerste token en die voor het volledige antwoord. Meet voor een offline corpus de tijd die nodig is om alle verwachte uitvoer te verkrijgen. Leg in beide gevallen de acceptatieregel vast: juistheid op bekende antwoorden, kwaliteit van een rangschikking of gecontroleerde veldextractie. Een syntactisch geldige JSON kan nog steeds een fout antwoord bevatten.
Scheid de wachttijd in de wachtrij, de verwerking en de volledige reis die je client waarneemt, wanneer je tools dat toelaten. Een meting binnen de engine heeft niet dezelfde grenzen als die van de toepassing. De documentatie van de vLLM-statistieken onderscheidt met name wachttijd, eerste token en totale duur: behoud dat onderscheid in je registraties, ongeacht de gekozen engine.
Technische bronnen: vLLM — statistieken voor verzoeken en latentie
Je verzoeken omzetten in keuzecriteria
Bereid korte, gebruikelijke en lange invoer voor met stabiele identificaties. Bewaar model, tokenizer, gesprekssjabloon en generatieparameters. Tel de werkelijk verzonden tokens, inclusief de geschiedenis en de documenten die de toepassing toevoegt. Noteer de gevraagde batch, de verzonden gelijktijdigheid en de verzoeken die daadwerkelijk gelijktijdig worden verwerkt afzonderlijk: dat zijn niet noodzakelijk dezelfde aantallen.
| Vast te leggen invoer | Meting en eenheid | Gevolg voor de keuze |
|---|---|---|
| Volledige prompt en uitvoerlimiet | Invoer- en uitvoertokens per verzoek | Lange gevallen en aan de limiet afgebroken antwoorden controleren |
| Gelijktijdige verzoeken en aankomsttempo | Actieve, wachtende en voltooide verzoeken | De haalbare belasting bepalen met de vereiste doorlooptijd |
| Precisie, kwantisatie en cache | Geheugenpiek per GPU, in bytes of Gio | Instellingen uitsluiten die het geheugen op de verwachte belasting overschrijden |
| Kwaliteitsregel en referenties | Geaccepteerde uitvoer / verwachte uitvoer; bedrijfsmetriek | Alleen varianten vergelijken die aan hetzelfde criterium voldoen |
| Bereik van de stopwatch | Eerste token, volledig antwoord of corpus: seconden | Duur vergelijken met dezelfde grenzen |
| Tijdlijn tot de opgehaalde bestanden | Totale periode, in uren of dagen | Kies daarna een pakket van 3, 7 of 30 dagen |
Geheugen meten met context en gelijktijdigheid
Voor een autoregressief model dat token voor token genereert, bewaart de KV-cache attention-states. De grootte hangt af van het model en de bewaarde tokens. Een dynamische cache kan tijdens de generatie groeien; een statische cache reserveert een maximale grootte. Sommige lagen met een sliding window beperken die groei. Test dus de verwachte lengtes en gelijktijdigheid met de strategie die je daadwerkelijk gebruikt.
Kwantificering van de gewichten en die van de cache zijn twee afzonderlijke keuzes. bitsandbytes vervangt bijvoorbeeld bepaalde lineaire lagen door gekwantiseerde versies; dat beschrijft niet alle toewijzingen van je uitvoering. Controleer na een wijziging van de precisie opnieuw geheugen en kwaliteit in plaats van aan te nemen dat de hele piek in dezelfde verhouding daalt.
Meet met PyTorch de piek van de toegewezen tensors en die van het door de allocator gereserveerde geheugen apart. Tel ze niet op. Vermeld welke GPU je hebt gemeten en de eenheid: 1 GiB komt overeen met 2³⁰ bytes. Deze tellers geven niet noodzakelijk het volledige gebruik van het apparaat weer. Het geheugendossier beschrijft hun beperkingen.
Technische bronnen: Hugging Face Transformers 5.17 — strategieën voor KV-cache · Hugging Face Transformers 5.17 — bitsandbytes-kwantificering · PyTorch 2.14 — CUDA-geheugenbeheer en tellers
Een meetbare proef op 300 documenten
Voorbeeld om uit te voeren met je toegestane corpus: haal datum, bedrag en categorie uit 300 documenten. Lees de verwachte waarden na, verduidelijk de behandeling van ontbrekende velden en leg de acceptatiedrempel vast vóór de proef. Het aantal documenten beschrijft het protocol; er wordt geen enkele tijd, score of doorvoer verondersteld.
- Zet de 300 identificatoren, de modelrevisie, de prompts, de tokenlimieten en de parsingregel vast. Houd lange documenten identificeerbaar in de balans.
- Voer een referentie uit met één verzoek tegelijk. Splits het laden, opwarmen en meten; bewaar de voorspellingen en fouten per document.
- Verhoog daarna één enkele parameter: batch voor gegroepeerde verwerking, of gelijktijdigheid voor een query-engine. Houd dezelfde invoer en kwaliteitscriteria aan.
- Noteer voor elke doorgang de duur, het geheugenpiek, het aantal teruggevonden identificatoren zonder duplicaten en de geaccepteerde uitvoer. Herhaal de metingen en bewaar de ruwe waarden met hun spreiding.
- Als een variant mislukt, noteer dan de reden: geheugen, afkapping, formaat of kwaliteit. Een kleinere batch of een hervatting levert een beslissing op om te documenteren, geen fout om weg te poetsen.
Technische bronnen: IteraGPU — gedetailleerd protocol voor vergelijking bij gelijkwaardige kwaliteit
IteraGPU Lab v1-resources binnen de juiste scope gebruiken
De notebook en het bijbehorende script bieden een gewichtsberekening en een meting op een klein synthetisch netwerk. De meetcode is uitgevoerd op een lokale RTX 5070 met PyTorch 2.11.0, op een kleine configuratie in float32. Deze test verifieert dat uitvoeringsscenario; hij meet geen LLM, geen KV-cache en ook niet de GPU's uit de catalogus op jouw requests.
Gebruik de notebook om de tellers te begrijpen en meet daarna je werkelijke belasting met je eigen omgeving. Het kwaliteitsprotocol en de ruwe tabel dienen om de vergelijking voor te bereiden. De uitvoer van de meegeleverde notebook en de resultaatregels van de CSV blijven leeg; de procedure installeert geen model of stuurprogramma. Lees de vereisten in de README vóór de uitvoering.
- IteraGPU Lab v1-geheugennetbook
Berekeningen en een klein synthetisch netwerk om de geheugenmeting te begrijpen.
- Aan te vullen kwaliteitsprotocol
Vaste invoer, uitvoeracceptatie en vergelijking van de tests.
- Leeg ruw tabelblad
Eén regel per daadwerkelijke run, met parameters, metingen en verdict.
- Vereisten en beperkingen van IteraGPU Lab v1
Instructies en precieze scope van de reeds uitgevoerde lokale test.
Van metingen naar een aanbod
Je keuzekaart moet een compatibele omgeving, geheugen per kaart, context, gelijktijdigheid, behaalde kwaliteit en gemeten doorlooptijden samenbrengen. Vergelijk de configuraties die aan deze criteria voldoen, en daarna de pakketten van 3, 7 en 30 dagen volgens de volledige planning: voorbereiding, verwerking, evaluatie, herstarts en export. De calculator van het benchmarkdossier gebruikt het volledige pakket en daadwerkelijk gevalideerde, nuttige corpora.
Bewaar deze kaart en de codeversies in je notitieboek. Jij kiest je software en je verwerkingen; IteraGPU inspecteert de inhoud van je bestanden, prompts of berekeningen niet. Een omgevingskeuze bij de bestelling drukt je voorbereidingsbehoefte uit: het vormt geen bewijs dat je model al is geïnstalleerd of getest.
Praktische vragen
Is 24 GB voldoende voor mijn inferentiemodel?
De capaciteit van 24 GB volstaat niet om die vraag te beantwoorden zonder het model en de belasting te kennen. Controleer samen gewichten, uitvoeringsallocaties, context en gelijktijdige verzoeken. De configuratie moet lange gevallen met de gevraagde kwaliteit afronden; een bestandsgrootte of een schatting van alleen de gewichten toont dat niet aan.
Welke doorvoer moet ik vergelijken voor een offline corpus?
Vergelijk eerst de tijd die nodig is om hetzelfde corpus af te ronden en te evalueren. Als je een doorvoer publiceert, geef dan het aantal geaccepteerde nuttige uitvoer, de gebruikte tijd en de fouten. Een doorvoer in tokens per seconde zonder antwoordlengte of kwaliteitscontrole volstaat niet om twee configuraties te onderscheiden.
Vereist een geheugenoverschrijding dat ik van GPU verander?
Bij een geheugenoverschrijding moet je eerst de instelling en de invoer identificeren die deze hebben veroorzaakt. Je kunt batch, gelijktijdigheid, lengte of precisie onderzoeken, met behoud van het projectdoel. Elke verlaging die de verwerkte documenten of de verwachte antwoorden verandert, vereist een nieuwe kwaliteitscontrole; meer geheugen kan nodig zijn als deze beperkingen behouden moeten blijven.
Valideert de meegeleverde notebook mijn inferentietoepassing?
De meegeleverde notebook valideert je toepassing niet: hij meet een klein synthetisch netwerk en legt de geheugentellers uit. De gedocumenteerde lokale test betreft alleen dit geval. Je toepassing moet worden geëvalueerd met zijn model, zijn invoer, zijn omgeving en zijn eigen acceptatiecriteria voordat je conclusies trekt over capaciteit of prestaties.