Lokale LLM's.
Passend gedimensioneerd.
Van passend model tot beheerde AI-dienst: DAXS plant lokale LLM-infrastructuur, toetst hardware onder werkelijke belasting en integreert de oplossing in uw bestaande IT.
Een AI-server begint met het belastingsprofiel.
Een lokaal taalmodel kan interne teksten uitwerken, codeconcepten ondersteunen of deel zijn van kenniszoekfuncties. Voor een bruikbare oplossing moeten modelkwaliteit, toegestane gegevenspaden en verwacht gebruik op elkaar aansluiten. DAXS inventariseert deze eisen, plant de infrastructuur en verzorgt installatie, integratie en het afgesproken beheer, samen met uw IT of als afgebakend dienstonderdeel.
Taak en kwaliteit
Welke vragen, talen, documenten of codetaken moet de oplossing beheersen? Een korte chat en een analyse van lange documenten vragen om verschillende modellen en contexten.
Gebruik en wachttijd
Hoeveel aanvragen komen gelijktijdig binnen? Hoe snel moet de eerste reactie beginnen en hoelang mag een volledig antwoord duren? Incidentele losse aanvragen en een continu gebruikte teamdienst hebben andere reserves nodig.
Gegevens en beheer
Welke bronnen en functies zijn vrijgegeven? Waar mogen model, zoekindex, logboeken en back-ups staan? Wie beheert updates en fouten, en welke terugvalroute is nodig?
Applicatie, inferentie en beheer goed verbinden.
De gebruikersinterface is slechts een onderdeel. Daarvóór zitten identiteits- en toegangscontroles; daarachter werken inferentiedienst, modelopslag en eventueel kenniszoekfuncties of bedrijfsinterfaces. Monitoring, updates en herstel horen in hetzelfde plan.
De tekening toont een mogelijke architectuur, geen werkelijk klantnetwerk. Een reverse proxy kan TLS en de ingang beveiligen. De applicatie moet gebruikersrechten desondanks afdwingen. Model-API's worden beperkt tot benodigde netwerken en functies; een bereikbare inferentiepoort is nog geen volwaardige bedrijfsdienst.
Meer dan de omvang van het modelbestand.
Voor de selectie bekijken we gewichten, runtimebehoefte, context, gelijktijdig gebruik en het volledige gegevenspad. Een GPU kan voldoende geheugen hebben en toch ongeschikt zijn voor de gewenste responstijd. Omgekeerd kan een kleiner, goed gekozen model de taak economischer oplossen.
| Bouwsteen | Wat we toetsen | Waarom het telt |
|---|---|---|
| GPU en VRAM | Architectuur, drivers, inferentiebackend, ondersteunde rekenformaten, geheugencapaciteit en bandbreedte. | Gewichten en KV-cache vragen ruimte. Rekenkracht en geheugentransfers beïnvloeden verschillende werkfasen; een geadverteerde TOPS-waarde beschrijft de toepassing niet op zichzelf. |
| Eén of meerdere GPU's | Modelverdeling, verbinding tussen GPU's, PCIe-aansluiting, energie en koeling. | VRAM wordt niet automatisch één vrij bruikbaar gedeeld geheugen. Verdeling en synchronisatie moeten door de gekozen stack worden ondersteund; extra GPU's kunnen nieuwe knelpunten veroorzaken. |
| CPU en systeem-RAM | Runtime, tokenisatie, gegevensvoorbereiding, parallelle processen en eventueel CPU-inferentie of offloading. | Offloading kan een model uitvoerbaar maken, maar verandert het prestatieprofiel. Transfers tussen RAM en GPU kunnen antwoorden vertragen. Ook een GPU-server heeft passende CPU- en RAM-reserves nodig. |
| NVMe en opslag | Modelversies, laadtijden, zoekindex, importgegevens, logboeken, vrije capaciteit en back-ups. | Snelle NVMe-SSD's helpen bij model laden en bepaalde gegevensbewerkingen. De tokengeneratie van een model dat volledig in het GPU-geheugen ligt, wordt vooral bepaald door reken-, geheugen- en runtimefactoren. |
| Netwerk en voorzieningen | Verbinding, toegestane gegevenspaden, ruimte, stroombehoefte, warmteafvoer en onderhoudstoegang. | De beste afzonderlijke rekencomponent helpt weinig als de dienst onder werkelijke belasting thermisch, organisatorisch of bij gegevenstoegang wordt begrensd. |
Een rekenhulp, geen aankoopadvies.
De ondergrens voor alleen de gewichten is grofweg met aantal parameters × bits per gewicht ÷ 8 te schatten. Een hypothetisch model met acht miljard parameters en vier bits per gewicht komt rekenkundig uit op vier gigabyte, ongeveer 3,73 GiB.
Daarbij komen quantisatiemetadata, eventueel modelonderdelen met hogere precisie, KV-cache, werkbuffers en de runtime. Deze waarde vertelt dus uitdrukkelijk niet welke VRAM-capaciteit voor uw toepassing volstaat. Bij modellen met een expertarchitectuur moeten bovendien actieve rekendelen en de totale te bewaren gewichten worden onderscheiden.
Een kort antwoord is een andere test dan een teamdienst.
Het contextvenster omvat de informatie die een model voor een aanvraag kan meenemen. Afhankelijk van de toepassing vallen daar instructies, gespreksgeschiedenis, opgehaalde documentfragmenten en geplande uitvoer onder. Een nominaal groot contextvenster garandeert geen passende hardware of betrouwbaar informatiegebruik.
KV-cache
De Key-Value-cache bewaart tussentoestanden van de aandacht. De behoefte hangt onder meer af van modelarchitectuur, gegevenstype, werkelijk gebruikte context en gelijktijdig actieve sequenties. Meer context en gelijktijdig gebruik verhogen de geheugenbehoefte vaak aanzienlijk.
Prefill en decode
Tijdens prefill verwerkt het model de invoercontext; bij decode ontstaan nieuwe tokens. Beide fasen belasten hardware verschillend. Lange documenten kunnen de tijd tot het eerste token verhogen, ook als de daaropvolgende uitvoer vloeiend lijkt.
Batching en wachtrij
Gezamenlijke verwerking kan de totale doorvoer verhogen. Tegelijk kunnen individuele gebruikers langer wachten. Gereserveerde capaciteit, wachtrijen, limieten en passende planning van gelijktijdig gebruik horen daarom bij het ontwerp.
We meten de werkelijke toepassing.
Een pilot omvat typische korte en lange aanvragen en gelijktijdige toegang. Daarbij bekijken we Time to First Token, volledige responstijd, uitvoersnelheid, wachtrij, foutpercentage en geheugengebruik. Tokens per seconde zijn alleen zinvol vergelijkbaar samen met modelversie, quantisatie, context, belasting en meetomstandigheden.
De stack volgt het model en het gebruik.
Ollama, llama.cpp en vLLM zijn mogelijke bouwstenen. Selectie en configuratie volgen uit modelondersteuning, hardware, gewenste gelijktijdigheid, beheer en integratie. We toetsen de concrete versie in plaats van een algemeen installatiecommando als productiearchitectuur te beschouwen.
Ollama
Een mogelijke start voor modelbeheer en lokale beschikbaarstelling. Modelopslag, vrijgegeven modellen, context, gelijktijdigheid en beveiliging van de dienst moeten bij de omgeving passen.
llama.cpp
Een flexibele bouwsteen voor passende modellen op verschillende CPU-/GPU-backends, met gequantiseerde formaten en servergebruik. Hardwareondersteuning, verdeling en werkelijk benodigde API-functies worden praktisch getoetst.
vLLM
Een optie voor geschikte servergerichte inferentie- en belastingsprofielen. Scheduling, KV-cache, batching en eventueel meerdere GPU's worden samen afgestemd. Een hogere totale doorvoer is niet hetzelfde als kortere wachttijd voor elke afzonderlijke aanvraag.
Container, virtuele machine of eigen host?
Containers kunnen softwareversies reproduceerbaar bundelen. Een virtuele machine kan de omgeving aanvullend organisatorisch en technisch afbakenen. De geschikte route hangt af van apparaatdoorvoer, drivers, onderhoud en bestaande beheerprocedures. Een compatibele API vereenvoudigt de koppeling, maar vervangt geen functietest met uw applicatie.
Wanneer past Proxmox met GPU-passthrough?
GPU-passthrough wijst een geschikte fysieke GPU aan een virtuele machine toe. Daarvoor moeten onder meer platform en firmware, IOMMU-groepen, host- en gastdrivers en het resetgedrag van het apparaat passen. We toetsen de concrete combinatie voordat we iets toezeggen.
Een toegewezen GPU kan niet automatisch flexibel tussen meerdere VM's worden gedeeld. vGPU en directe passthrough zijn verschillende concepten met eigen voorwaarden en eventuele licentievoorwaarden. Ook onderhoud, back-up en een mogelijke hostwissel vragen om een passende procedure; een algemene toezegging over livemigratie zou onjuist zijn.
Infrastructuur en virtualisatie · Proxmox-migratie beoordelen
Het passende model moet de taak aankunnen.
We vergelijken modellen met vrijgegeven voorbeelden uit het latere gebruik, zoals Duitstalige vakvragen, documentfragmenten, meertalige aanvragen of een concrete scripttaak. Een codingmodel en een embeddingmodel vervullen verschillende taken. Voor kenniszoeken moeten zoekfunctie, embeddings en antwoordmodel op elkaar aansluiten.
Quantisatie vermindert vaak de geheugenbehoefte. Effecten op antwoordkwaliteit, toolaanroepen en snelheid worden voor het gekozen formaat getoetst. Een groter model is niet automatisch beter of economischer. Een lange maximale context bewijst evenmin dat het model alle daarin opgenomen informatie betrouwbaar gebruikt.
- Licentie: de gekozen modelgewichten, zakelijk gebruik, verspreiding en verplichte vermeldingen concreet toetsen; een eenvoudige download vervangt deze toetsing niet.
- Versie: model, quantisatie, tokenizer en runtime inzichtelijk vastleggen.
- Acceptatie: inhoudelijke geschiktheid, ongewenste antwoorden, taalkwaliteit en foutscenario's met een herhaalbare vragenset toetsen.
- Wijzigingen: nieuwe modelversies eerst testen, een bruikbare terugvalroute behouden en zoekindices bij gewijzigde embeddings passend opnieuw opbouwen.
Lokaal, extern of in een passende combinatie.
Eigen hardware kan zinvol zijn bij geschikte benutting, heldere gegevenseisen en aanwezig beheerkader. Een externe dienst kan beter passen bij wisselend gebruik, bijzondere modelvaardigheden of beperkte eigen beheercapaciteit. Hybride verbindt gericht afgebakende taken en gegevenspaden.
De vergelijking omvat aanschaf of gebruik, stroom en koeling, licenties, integratie, updates, beheer, reserve en uitvalgevolgen. Lokale verwerking is geen automatische beveiligings- of AVG-garantie: ook modellen, embeddings, telemetrie, updates, externe hulpmiddelen en logboeken moeten bij het afgesproken gegevensconcept passen.
We plannen eerst een overzichtelijke pilot met meetbare eisen. Het resultaat leidt tot een besluit over uitbreiding, aanpassing of een eenvoudiger alternatief. Meer basisinformatie vindt u onder Cloud en SaaS.
Een beheerde dienst vraagt om inzichtelijke verantwoordelijkheden.
DAXS kan hardware en software plannen, installeren, koppelen aan bestaande identiteiten en applicaties en het afgesproken dagelijkse beheer verzorgen. Daaronder vallen bereikbaarheid en resourcebewaking, versieonderhoud, foutafhandeling en documentatie. Benodigde beschikbaarheid en reactieroutes worden concreet afgesproken.
We bepalen welke configuraties, applicatieonderdelen, indexgegevens en eventueel aangepaste modellen worden geback-upt. Opnieuw verkrijgbare modelgewichten en beschermenswaardige bedrijfsgegevens hebben verschillende back-upbehoeften. Een hersteltest hoort bij een passend beheerconcept.
Eiseninventarisatie, architectuurvoorstel, model- en belastingstest, gedocumenteerde gegevenspaden en een inzichtelijk advies over hardware, implementatievorm en volgende integratiestappen.
Dat verduidelijken we in het gesprek.
Hoeveel VRAM heeft een lokaal LLM nodig?
Dat hangt af van model en quantisatie, runtime, context en gelijktijdige aanvragen. Alleen het modelbestand is geen voldoende basis. We testen de gewenste taak, inclusief lange aanvragen en piekbelasting, voordat we concrete hardware adviseren.
Is een tweede GPU automatisch sneller?
Nee. De gekozen stack moet de verdeling ondersteunen. GPU-verbindingen, synchronisatie en modelarchitectuur beïnvloeden het resultaat. Meer geheugen kan de uitvoering mogelijk maken zonder elk afzonderlijk antwoord te versnellen.
Kan een bestaande Proxmox-server worden gebruikt?
Dat kan passen als hardware, IOMMU-groepen, drivers en GPU-passthrough geschikt zijn. Daarnaast moeten reserves voor andere diensten en de procedures voor onderhoud, back-up en herstel kloppen. We toetsen het bestaande platform concreet.
Worden interne documenten in het model getraind?
Voor kenniszoeken is dat vaak niet nodig. RAG zoekt passende, toegestane documentfragmenten en geeft die als context aan het model. Aanpassing van de modelgewichten is een andere maatregel en wordt apart gemotiveerd.
Wanneer is een externe dienst economischer?
Bij weinig of sterk wisselend gebruik, bijzondere modeleisen of ontbrekende beheercapaciteit kan een externe dienst beter passen. We vergelijken kosten, gegevenspaden, kwaliteit en beheer over de geplande gebruiksperiode.
Modellen, belasting en kosten samen bewaken.
Naast GPU-belasting en responstijd bekijken we de kosten per bruikbare taak. Een modelupdate wordt vóór inzet vergeleken met de vrijgegeven testset. Foutpercentages, wachtrijen, geheugengrenzen en uitval vragen om benoemde verantwoordelijken en een terugvalroute. Een externe vervangingsdienst komt alleen in aanmerking als gegevensklasse en goedkeuring dit toestaan.
Laten we uw toepassing bespreken.
Wat moet eenvoudiger worden, welke gegevens zijn betrokken en welke systemen zijn al aanwezig? Daaruit ontwikkelen we een zinvolle start en overzichtelijke vervolgstap.