Is een quadcore-CPU voldoende voor een privé-RAG-server?

Eva Wong is de Technisch Schrijver en en vaste knutselaar bij ZimaSpace. Een levenslange geek met een passie voor homelabs en open-source software, zij is gespecialiseerd in het vertalen van complexe technische concepten naar toegankelijke, praktische handleidingen. Eva gelooft dat zelf-hosting leuk moet zijn, niet intimiderend. Met haar tutorials stelt ze de community in staat om hardware-setup te ontrafelen, van het bouwen van hun eerste NAS tot het beheersen van Docker-containers.

Ja. Een moderne quadcoreprocessor kan voldoende zijn voor een private RAG-server wanneer de corpusomvang begrensd is, gegevens slechts af en toe worden geïmporteerd, één of twee gebruikers actief zijn en modelinferentie op afstand of op een afzonderlijke accelerator draait. Ga pas verder dan vier cores wanneer gemeten parsing, OCR, embeddings, herindexering, gelijktijdigheid of CPU-inferentie ervoor zorgen dat de latentie voor zoekopdrachten of gegevensimport de doelwaarde overschrijdt.

Bepaal wat de vier cores daadwerkelijk moeten uitvoeren

Een private RAG-server bestaat uit meerdere onderling verbonden workloads. De host kan bestanden importeren, tekst extraheren, documenten opsplitsen, embeddings genereren, een index bijwerken, een database uitvoeren, passages ophalen, resultaten opnieuw rangschikken, prompts samenstellen en een gebruikersinterface aanbieden. Het generatiemodel kan op dezelfde CPU draaien, op een lokale GPU, op een andere server of via een externe API. Die keuzes veranderen volledig wat vier CPU-cores betekenen.

De reeds gepubliceerde koopgids voor private RAG van ZimaSpace behandelt gegevensimport, vectoropslag, modelgeheugen en gelijktijdigheid als afzonderlijke resources. Dit artikel beperkt die bredere beslissing tot één vraag: kan de CPU-laag het retrievalsysteem responsief houden?

Noteer waar elke fase wordt uitgevoerd. Als de LLM en embeddings op afstand draaien, verwerkt de lokale CPU voornamelijk webservices, databases, retrieval, bestandsverwerking en orkestratie. Als embeddings, OCR, reranking en generatie allemaal lokaal blijven, krijgen vier cores een veel bredere taak en kunnen ze de eerste langdurige bottleneck worden.

De eerste uitkomst bij het kiezen van hardware is daarom een workloadoverzicht. Vier cores zijn aannemelijk wanneer de CPU een begrensde orkestratie- en retrievaltaak uitvoert. Ze zijn veel minder overtuigend wanneer “private RAG” in werkelijkheid betekent dat één apparaat elke AI- en documentverwerkingsfase tegelijk uitvoert.

Gebruik de huidige softwarevereisten als basis, niet als belofte voor doorvoer

De huidige applicatievereisten laten zien dat vier cores een legitieme instapcategorie kunnen zijn. RAGFlow vermeldt bijvoorbeeld momenteel een x86-CPU met minimaal vier cores, 16GB RAM en 50GB opslag in de vereisten voor de quickstart. Daarmee is een systeem met vier cores technisch geschikt voor de basisstack, maar een minimale installatievereiste is niet hetzelfde als een prestatiegarantie voor meerdere gebruikers.

Controleer vóór aankoop de actuele RAGFlow-vereisten, omdat ze een concrete ondergrens bieden voor een complete retrievalapplicatie. Het getal van vier cores moet samen met de vereisten van 16GB geheugen en opslag worden geïnterpreteerd, niet als bewijs dat elke processor met vier cores elke corpusomvang aankan.

AnythingLLM laat het andere uiteinde van het spectrum zien. De zelfgehoste Docker-applicatie kan veel lichter zijn wanneer modelinferentie extern plaatsvindt. De officiële Docker-vereisten vermelden een lage basisconfiguratie, omdat de LLM- of embeddingservice elders kan draaien.

Gebruik deze twee voorbeelden om een bandbreedte vast te stellen, niet om hun getallen te middelen. Een aankoop met vier cores moet worden getest tegen de exacte RAG-stack die je wilt gebruiken, de database en zoekmachine daarvan, en de vraag of de dure AI-fasen lokaal of op afstand worden uitgevoerd.

Scheid interactieve querylatentie van de tijd voor bulkimport

Vraag-en-antwoordverwerking verloopt meestal in korte pieken. Een gebruiker verstuurt een query, de server doorzoekt indexen, past filters of reranking toe en stuurt de opgehaalde context vervolgens naar het model. Bulkimport is anders: honderden of duizenden bestanden moeten mogelijk worden geparseerd, aan OCR worden onderworpen, opgesplitst, van embeddings worden voorzien en naar de database en index worden geschreven. Een CPU die tijdens chat snel aanvoelt, kan herindexering toch onaanvaardbaar traag maken.

De productiehandleiding van Flowise schaalt hoofdservers en workers afzonderlijk, in plaats van ervan uit te gaan dat één proces elke workload moet verwerken. De architectuur met wachtrijmodus is een belangrijk signaal voor hardwarekeuze: asynchrone taken en interactieve verzoeken veroorzaken verschillende vormen van druk op de gelijktijdigheid, ook wanneer ze deel uitmaken van dezelfde AI-applicatie.

Voor een privéserver thuis of voor een klein team hoef je geen enterprise-topologie over te nemen. Pas hetzelfde principe lokaal toe door grote imports buiten piekuren te plannen, het aantal workers te beperken en gelijktijdige OCR-, embedding- en chattests te vermijden wanneer je interactieve latentie probeert te meten.

Houd het bij vier cores wanneer gegevensimport binnen een acceptabel onderhoudsvenster wordt voltooid en queries responsief blijven tijdens normale updates. Vergroot de CPU-capaciteit wanneer noodzakelijke herindexering gebruikersqueries regelmatig blokkeert, wanneer er voortdurend nieuwe documenten binnenkomen of wanneer het systeem grote imports binnen een vaste operationele termijn moet afronden.

Gebruik het aantal CPU-cores niet als vervanging voor de juiste modelgrootte

Wanneer het generatiemodel op de CPU draait, kunnen modelgrootte en quantisatie de ervaring domineren. Een processor met vier cores kan nog steeds antwoorden genereren met een klein gequantiseerd model, maar “kan draaien” is niet hetzelfde als een interactieve responstijd. De koper moet bepalen of de CPU alleen een retrievalhost is of ook de inferentie-engine.

De ZimaSpace-gids voor het routeren van modelgeheugen legt uit dat gewichten slechts één onderdeel van de actieve werkomgeving vormen. Context, runtimebuffers en gelijktijdige verzoeken verhogen de geheugendruk, terwijl CPU-only generatie een langdurige rekenbelasting toevoegt waardoor een host met vier cores traag kan aanvoelen, zelfs als het model technisch gezien past.

Houd voor een compacte private RAG-opstelling modelinferentie op afstand of op een afzonderlijke GPU-node wanneer documentservices prioriteit hebben en voorspelbare responstijden belangrijk zijn. Als lokale generatie absoluut vereist is, benchmark dan het exacte model, de quantisatie, de contextlengte en de beoogde tokens per seconde voordat je het aantal cores voldoende acht.

De aanleiding om te upgraden is niet “RAG gebruikt AI”. Het gaat om bewijs dat CPU-inferentie of een andere CPU-intensieve fase de latentiedoelstelling niet haalt nadat retrieval en applicatiewerk afzonderlijk zijn gemeten.

Meet CPU-verzadiging tijdens de gecombineerde piekbelasting

Een nuttige aankooptest moet de zwaarste normale overlap nabootsen, niet een geïsoleerde benchmark. Start de RAG-interface, voer verschillende representatieve queries uit, importeer of werk een kleine batch documenten bij en laat de database, vectoropslag, authenticatielaag en normale achtergrondservices ingeschakeld. Als OCR deel uitmaakt van normaal gebruik, neem die dan ook mee.

Houd aanhoudend CPU-gebruik, load average of run queue, gebruik per proces, querylatentie, importsnelheid, geheugendruk, opslaglatentie en modelserverlatentie in de gaten. Het doel is niet om het CPU-gebruik laag te houden. Een processor kan tijdens een korte batch vrijwel volledig worden belast en toch perfect geschikt zijn als interactief werk responsief blijft en de taak op tijd wordt voltooid.

Een CPU met vier cores is te licht wanneer de wachtrij sneller groeit dan het systeem die kan verwerken, gebruikersverzoeken onvoorspelbaar worden, importvensters de toegestane tijd overschrijden of normale achtergrondtaken retrieval laten vastlopen terwijl geheugen, opslag en netwerk gezond blijven. Die symptomen wijzen erop dat rekenkracht de beperkende factor bij de aankoop is.

Blijft het systeem responsief en worden taken binnen het verwachte venster voltooid, houd dan vast aan de categorie met vier cores. Besteed het resterende budget aan RAM, SSD-capaciteit, back-ups of een afzonderlijke inferentieaccelerator als die resources een grotere verbetering opleveren.

Stem het platform af op de bewezen RAG-grens

Voor een private RAG-server met begrensde omvang en modelinferentie op afstand of op een afzonderlijk systeem is de ZimaBoard 2 1664 de geschiktere ZimaBoard 2-variant, omdat de vier cores van de Intel N150 en het geheugen van 16GB aansluiten bij de huidige CPU- en RAM-ondergrens van RAGFlow. Voeg SSD-opslag toe voor de applicatie, indexen, geüploade documenten en database, in plaats van het ingebouwde eMMC-geheugen als volledige opslagstrategie te beschouwen.

Kies de 1664 niet uitsluitend omdat die meer geheugen heeft dan de 832. De CPU is hetzelfde. De uitvoering met 16GB helpt een RAG-stack met meerdere services aan de geheugenvereisten te voldoen, maar verandert vier CPU-cores niet in een processor met acht of tien cores. Als het gemeten probleem langdurige parsing, OCR, embeddings of CPU-inferentie is, verwijdert extra RAM de rekenwachtrij niet.

Stap over op ZimaCube 2 wanneer de privédocumentbibliotheek ook meer opslagsleuven, meer CPU-reserves, zwaardere gelijktijdige applicaties of een sneller groeipad nodig heeft. Als een lokale LLM daadwerkelijk de bottleneck vormt, dimensioneer dan de GPU en VRAM afzonderlijk in plaats van ervan uit te gaan dat een grotere NAS-behuizing inferentie oplost.

De juiste beslissing over vier cores is voorwaardelijk: voldoende voor een gecontroleerde retrievalhost, maar geen universele bovengrens voor een alles-in-één AI-apparaat. Houd het bij vier cores wanneer inferentie op afstand, begrensde gegevensimport en lage gelijktijdigheid aan de doelstellingen voldoen. Koop pas meer CPU wanneer gemeten lokale documentverwerking of gelijktijdig querywerk de processor tot een aanhoudende beperking maakt.

Veelgestelde vragen

Maakt een GPU een CPU met vier cores automatisch voldoende voor RAG?

Nee. Een GPU kan lokaal model- en embeddingwerk overnemen of verminderen, maar de CPU kan nog steeds verantwoordelijk zijn voor parsing, OCR, databaseservices, orkestratie van vectorzoekopdrachten, decompressie, authenticatie en overhead van containers. Test het CPU-traject nadat acceleratie is ingeschakeld.

Zijn alle CPU's met vier cores gelijkwaardig voor een private RAG-server?

Nee. Architectuur, klokgedrag, geheugenbandbreedte, cache, vermogenslimieten, opslagpad en softwarematige acceleratie spelen allemaal een rol. Beschouw “vier cores” als een workloadcategorie en controleer de exacte processor met jouw corpus en pijplijn.

Koopgids

Meer om te lezen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.