Qwen 27B draaien op een VPS met Ollama: zo werkt het

Kunt u Qwen 3.8 27B draaien op een VPS zonder GPU?

Om Qwen 3.8 27B op een VPS te draaien, heeft u eerst een bestaande model-tag nodig. Op 4 augustus 2026 bevat de Ollama-bibliotheek geen qwen3.8-vermelding. De dichtstbijzijnde uitgebrachte 27B-tag is qwen3.6:27b: 27,8 miljard parameters, Q4_K_M-kwantisatie, Apache 2.0-licentie. Elk commando en elk getal hieronder gebruikt die tag op Ollama v0.32.5, gepubliceerd op 27 juli 2026.

Het korte antwoord is ja op een VPS met 32 GB RAM of meer, maar het gaat traag. Een 27B dense model op Q4 vereist ongeveer 17 GB aan RAM alleen al voor de gewichten, nog voordat er één token aan context is opgeslagen. Dat sluit plannen met 8 GB en 16 GB volledig uit. Op een gangbare VPS met dual-channel DDR4 ligt het plafond op ongeveer 3 tokens per seconde, wat trager is dan de gemiddelde leessnelheid.

Waar komt die 3.8 vandaan? Waarschijnlijk van het aantal parameters. De Ollama-pagina voor qwen3.6:27b vermeldt 27,8B parameters, en 27,8 is later makkelijk te onthouden als 3.8. Er is ook een qwen3.5:27b, dezelfde Q4_K_M-build van de vorige release. Controleer de actuele lijst voordat u een commando kopieert, op de Ollama qwen3.6 tag-pagina. Mocht er later een echte qwen3.8 verschijnen, dan blijft de berekening hier van kracht, omdat deze afhankelijk is van het aantal parameters en bits per gewicht in plaats van het versienummer.

Welke Ollama-tag u moet pullen en hoe u dit controleert

Het pullen van een tag die niet bestaat, resulteert in een duidelijke foutmelding, waardoor u dit snel op de server zelf kunt vaststellen.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show toont de architectuur, het aantal parameters, de contextlengte en de kwantisatie voor de tag die u momenteel heeft. Als de parameterregel 27.8B aangeeft en de kwantisatieregel Q4_K_M, dan beschikt u over de build waarvoor deze handleiding is geschreven. De bibliotheek bevat ook qwen3.6:27b-q8_0 en qwen3.6:27b-bf16 voor dezelfde gewichten met een hogere precisie, plus een set 35b-a3b-tags. Dit zijn MoE-modellen (mixture of experts) die zich op de CPU heel anders gedragen. Hieronder volgt meer informatie hierover.

Aantal parameters maal bytes per gewicht

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

De formule bestaat uit één regel. Bytes aan gewichten = parameters * bits per gewicht / 8. Bij een zuivere 4 bits zouden 27,8 miljard parameters 13,9 GB in beslag nemen. De uitgebrachte Q4_K_M-tag is 17 GB, wat in de praktijk neerkomt op 4.89 bits per gewicht.

Dat verschil is geen fout. K-quant-formaten slaan niet elke tensor op met de nominale breedte. De tensors die de meeste kwaliteit verliezen door compressie worden op 5 of 6 bits gehouden, en de token embedding- en output-lagen worden doorgaans op Q6_K of Q8_0 gelaten. De naam van het formaat is een gemiddelde, en dat gemiddelde ligt rond de 4,9. Hetzelfde effect is zichtbaar aan de andere kant van het spectrum: 56 GB voor BF16 is 16.1 bits per gewicht in plaats van exact 16, omdat het bestand ook metadata en een embedding-tabel met volledige precisie bevat.

Q5_K_M heeft geen gepubliceerde tag voor dit model, dus de rij van 19.8 GB is berekend op de gebruikelijke 5,7 bits per gewicht voor dat formaat in plaats van gemeten. Q8_0 verdubbelt Q4 bijna tot 30 GB. Op een systeem dat alleen op de CPU draait, kost die verdubbeling twee keer zoveel geheugenverkeer per token, waardoor uw tokens per seconde ruwweg halveren. Alleen al om die reden is Q4_K_M hier de juiste standaardinstelling.

Wat de KV-cache kost naarmate de context groeit

De gewichten vormen een vaste kostenpost. De KV-cache (key and value cache, de attention-status die het model bijhoudt voor elke token die het al heeft gezien) groeit lineair met de contextlengte. Dit is het punt waar de meeste mensen daadwerkelijk zonder RAM komen te zitten.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

Deze cijfers gaan uit van de configuratie die Qwen heeft gebruikt voor recente dense modellen in deze grootteklasse: 64 lagen, 8 key/value-heads onder GQA (grouped-query attention) en een head-dimensie van 128. Dit komt neer op 256 KiB per token bij f16, oftewel 8 GB bij 32k tokens en 32 GB bij 128k. Vertrouw niet blindelings op mijn berekening, maar controleer uw eigen systeem. Laad het model en lees de SIZE-kolom van ollama ps, die de gewichten, cache en overhead als één totaalcijfer rapporteert.

Dit is de reden waarom de 256K-context op de modelkaart een blikvanger is en geen concreet plan. Het vullen hiervan op f16 zou 64 GB aan cache kosten bovenop de gewichten, op een machine die al 17 GB aan gewichten verbruikt. Ollama stelt standaard niet het volledige venster beschikbaar. Het laadt een veel kleiner venster, dat u bewust kunt vergroten met OLLAMA_CONTEXT_LENGTH. Verhoog dit in stappen en controleer ollama ps na elke wijziging.

Twee instellingen halveren de cache of verminderen deze nog verder. OLLAMA_KV_CACHE_TYPE=q8_0 slaat de cache op in 8 bits in plaats van 16, waardoor 32k tokens dalen van 8 GB naar 4 GB. Dit vereist flash attention, dus stel ook OLLAMA_FLASH_ATTENTION=1 in en bevestig de afname in ollama ps in plaats van aan te nemen dat het is toegepast. OLLAMA_NUM_PARALLEL=1 is net zo belangrijk. Ollama kan meerdere verzoeken tegelijk afhandelen en elke slot krijgt zijn eigen deel van de context. Het ongewijzigd laten van de standaardwaarde voor parallellisme vermenigvuldigt stilletjes de cache die u had begroot. Als meer dan één persoon deze machine gaat gebruiken, ontstaat daar het probleem. Het aantal gelijktijdige gebruikers dat een zelfgehost model kan bedienen wordt bepaald door cache-slots en wachtrijdiepte, lang voordat het aantal CPU-cores een rol speelt.

Wat past in 8, 16, 32 en 64 GB RAM

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

Lees de twee getallen als duizendtallen tokens aan context die naast de gewichten passen, bij f16-cache, op een headless Linux VPS met ongeveer 1,5 GB over voor het besturingssysteem en een kleine extra marge. Een nul betekent dat de gewichten zelf niet passen, dus dat er niets past.

8 GB en 16 GB zijn geen twijfelgevallen. 17 GB aan gewichten past niet in 16 GB RAM, en geen enkele context-instelling verandert dat. Swap toevoegen biedt evenmin uitkomst. Ollama gebruikt memory-mapping voor het GGUF-bestand; zodra de resident pages het RAM overschrijden, begint de kernel deze te verplaatsen naar disk en opnieuw in te lezen. Elk token haalt dan gigabytes aan data van de schijf. De server krijgt een hoge iowait en genereert minder dan één token per seconde.

32 GB is het instappunt. De gewichten nemen 17 GB in beslag en u heeft ongeveer 13 GB over, wat ruimte biedt voor circa 32k tokens aan f16-context met een marge. Q8_0-gewichten van 30 GB passen op dit niveau helemaal niet.

64 GB is comfortabel. Q4 laat ruimte voor ongeveer 128k tokens aan context, en Q8_0-gewichten passen met ongeveer 64k tokens aan context erachter. Voordat u betaalt voor 64 GB om Q8 te kunnen draaien, moet u duidelijk hebben wat u koopt: iets betere output op de helft van de snelheid, op een machine die al traag was. Q4 met een langere context is voor bijna iedereen de betere keuze.

Hoe snel is CPU-inferentie op een VPS?

Het genereren van één token uit een dense model betekent dat elk gewicht één keer uit het geheugen moet worden gelezen. Niet slechts een deel, maar alles. De snelheidslimiet wordt daarom niet bepaald door het aantal cores, maar door de geheugenbandbreedte gedeeld door de grootte van de gewichten. Bij Q4-kwantisatie resulteert dit in 17 GB aan geheugenverkeer per token.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

Dit zijn theoretische maxima, geen gemeten waarden. De werkelijke output ligt op ongeveer 50 tot 70 procent van deze waarde, omdat geheugenlatentie en imperfecte prefetching ervoor zorgen dat de theoretische piek nooit wordt bereikt. Een VPS met dual-channel DDR4-3200 heeft een plafond van 3 tokens per seconde; reken dus op ongeveer 2. Een systeem met dual-channel DDR5-4800 heeft een plafond van 4.5; reken hier op ongeveer 3.

Bij grote serverconfiguraties is voorzichtigheid geboden. Een EPYC-platform met twaalf kanalen heeft 460.8 GB/s en een plafond van 27.1 tokens per seconde, maar u huurt geen volledige EPYC. Geheugenbandbreedte is een gedeelde bron voor alle tenants op de host; een slice met 8 vCPU's krijgt dus niet de exclusieve bandbreedte van twaalf kanalen. GPU-gerichte handleidingen negeren dit vaak, terwijl dit de reden is waarom twee VPS-abonnementen met een identiek aantal vCPU's tot een factor drie in snelheid kunnen verschillen bij hetzelfde model.

Meer vCPU's helpen al snel niet meer om dezelfde reden. Zodra de cores sneller om data vragen dan de geheugencontroller kan leveren, zorgen extra threads alleen voor extra scheduling-overhead. Stel OLLAMA_NUM_THREAD in op het aantal fysieke cores, meet de prestaties en probeer daarna de helft van dat aantal. Bij veel gedeelde abonnementen is de lagere instelling sneller.

Promptverwerking gedraagt zich anders. De prefill-fase, de verwerking van uw input voordat het eerste token verschijnt, is compute-bound in plaats van bandwidth-bound en schaalt daarom wel met het aantal cores. Het praktische gevolg is een lange pauze voordat de output begint bij een grote prompt, gevolgd door de hierboven genoemde trage, constante snelheid. Meet beide helften afzonderlijk met --verbose, die voor elk verzoek een prompt eval rate en een eval rate weergeeft.

Als het dense 27B-model simpelweg te traag is, kijk dan naar de qwen3.6:35b-a3b-tags voordat u CPU-inferentie opgeeft. Deze activeren ongeveer 3 miljard parameters per token in plaats van alle 27,8 miljard. Hierdoor neemt het geheugenverkeer per token met bijna een factor tien af, ook al is het bestand op de schijf groter. U ruilt RAM-gebruik in voor snelheid. De keuze van de runtime is hierbij ook van belang, en Ollama en llama.cpp bieden verschillende CPU-tuningopties voor dezelfde onderliggende inferentiecode.

Wanneer u in plaats daarvan een GPU per uur huurt

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

Dezelfde formule toegepast op de gepubliceerde geheugenbandbreedte van een GPU levert een andere categorie antwoorden op. Een consumentenkaart met 24 GB heeft een plafond van 59 tokens per seconde op deze gewichten. Een huidige datacenterkaart bereikt 197. Dat is geen kloof die u dicht door het aantal threads aan te passen. De kaart draait zijn geheugen op 1008 GB/s, terwijl uw VPS op tientallen GB/s draait.

Trek daarom de grens op basis van de werklast in plaats van op basis van voorkeur. CPU-inferentie is het juiste antwoord wanneer het werk asynchroon is en niemand erop wacht: het 's nachts samenvatten van een stapel documenten, of een dagelijkse classificatietaak die draait terwijl u slaapt. Huur een GPU op het moment dat een persoon op output wacht, of zodra verzoeken sneller binnenkomen dan één per 30 seconden, omdat een box met alleen een CPU geen ruimte heeft voor batching en de wachtrij simpelweg groeit.

De kostenvergelijking is minder voor de hand liggend dan het lijkt. Een VPS met 64 GB wordt elk uur van de maand gefactureerd, ongeacht of het model geladen is of niet, terwijl een GPU-instantie alleen de uren factureert dat u deze actief houdt. Als uw werkelijke gebruik twee uur per dag is, kan de gehuurde GPU zowel sneller als goedkoper zijn. Bepaal eerst uw bedrijfscyclus en bereken daarna de prijs. Een VPS met een GPU kiezen behandelt waar u op de instantie zelf op moet letten, en vLLM presteert beter dan Ollama zodra u gelijktijdige verzoeken op een GPU bedient omdat het deze correct in batches verwerkt.

Er is een derde optie die mensen vergeten. Houd het 27B-model op de CPU voor batchwerk en plaats een gehost API-model voor het interactieve pad. Niets verplicht u om één model beide taken te laten uitvoeren.

Ollama installeren en uw eigen systeem meten

Het installatiescript is de officiële versie en configureert een systemd-service die draait als een toegewezen ollama-gebruiker.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version hoort 0.32.5 of later weer te geven. Controleer free -g voordat u iets ophaalt. Als de kolom total op de Mem-regel onder 32 staat, stop dan hier en kies een kleiner model. Het ophalen van 17 GB die u niet kunt draaien, kost een uur tijd en veel schijfruimte.

Stel de runtime-opties in via een systemd-override in plaats van in uw shell. Het model draait binnen de service en ziet uw interactieve omgeving daarom niet.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

De uitvoer van --verbose is de meting waarvoor u kwam. eval rate is uw aantal tokens per seconde tijdens het genereren. prompt eval rate is uw prefill-snelheid. load duration is de tijd die nodig was om de gewichten van de schijf te lezen; dit is waarom OLLAMA_KEEP_ALIVE=60m is ingesteld: op de CPU kost het bij elk verzoek opnieuw laden van 17 GB vanaf de schijf meer tijd dan het verzoek zelf.

Controleer terwijl het model is geladen de voetafdruk vanuit een tweede terminal.

ollama ps

De kolom SIZE is de werkelijke geheugenvoetafdruk inclusief de KV-cache. Deze hoort dicht bij de gewichten te liggen, plus de rij voor uw contextlengte in de KV-tabel. Bij 8192 tokens met een 8-bit cache kunt u rekenen op ongeveer een gigabyte bovenop de gewichten, tegenover 2 GB als de cache op f16 zou blijven. De kolom PROCESSOR hoort 100% CPU aan te geven. Als er iets anders staat, heeft een ander proces een GPU geclaimd en beschrijven de snelheden in deze handleiding uw systeem niet.

Foutmodi en de exacte meldingen die u zult zien

Het model weigert te laden. Ollama toont een regel met beide getallen, in de vorm model requires more system memory (18.6 GiB) than is available (15.2 GiB). Dit is de gewenste foutmelding, omdat Ollama de controle uitvoerde vóórdat het geheugen werd toegewezen, in plaats van het aan de kernel over te laten. Verklein de contextlengte, stap over op een kleinere tag of kies een groter abonnement.

Het proces verdwijnt tijdens het genereren van een antwoord. De client toont niets nuttigs en journalctl -u ollama -n 50 laat zien dat de service opnieuw opstart. Voer dmesg -T | tail uit; een regel met de tekst Out of memory: Killed process ... (ollama) betekent dat de kernel OOM killer het proces heeft beëindigd. Dit gebeurt wanneer de controle vooraf slaagde, maar de cache tijdens een lang gesprek groter werd dan de schatting. Verklein de contextlengte.

Het ophalen (pull) mislukt direct. Error: pull model manifest: file does not exist betekent dat de tag niet in de bibliotheek staat. Het typen van qwen3.8:27b levert precies deze melding op, evenals elke typefout in het versienummer. Controleer de tag op de bibliotheekpagina voordat u uw netwerk de schuld geeft.

Alles werkt, maar het is ondragelijk traag. Minder dan één token per seconde op een systeem met voldoende RAM wijst op paging in plaats van op rekenkracht. Voer vmstat 1 uit tijdens het genereren. Een niet-nulwaarde in de kolom si of so betekent dat de kernel aan het swappen is; de oplossing is minder context of minder geladen modellen. Een constant hoge wa zonder swap-activiteit betekent dat de memory-mapped gewichten opnieuw van de schijf worden gelezen, wat inhoudt dat ze niet echt in het geheugen passen.

Het eerste token duurt 30 seconden en daarna versnelt de uitvoer. Dit is prefill en dit is normaal. Voor een lange systeemprompt moet bij elk verzoek dat de cache mist worden betaald, dus kort de systeemprompt in voordat u andere instellingen aanpast.

Waar een CPU-only 27B-model daadwerkelijk geschikt voor is

Stel verwachtingen op basis van de cijfers in plaats van op basis van hoop. Bij twee tot vier tokens per seconde duurt een antwoord van 500 tokens tussen de twee en vier minuten. Dat is onbruikbaar voor chat, maar uitstekend werkbaar voor een wachtrij. Document-samenvattingen, bulk-tagging, veldextractie uit een achterstand aan bestanden en onbeheerde code-reviews tolereren dit, omdat er niemand op het antwoord wacht. Programmeerondersteuning bevindt zich precies op die grens, dus een programmeer-agent koppelen aan een model dat u zelf host loont voor achtergrondtaken zoals commit-berichten en test-scaffolding, maar niet voor inline-suggesties waar u op moet wachten.

Het privacy-argument is het meest valide. Het model draait op hardware die u huurt en beheert, er verlaat geen enkel verzoek de server en er is geen facturatie per token. Dat is voor gereguleerde data veel waard, zelfs bij drie tokens per seconde. Weeg dit eerlijk af tegen het alternatief: het zelf hosten van een frontier-scale model vereist een orde van grootte meer hardware, en een 27B-model op de CPU is het goedkoopste punt op die curve waar de output nog steeds de moeite waard is om te lezen.

Als dit uw eerste Ollama-installatie is, behandelt de volledige handleiding voor het draaien van Ollama op een VPS de service-setup, de HTTP API en de firewallregels waarvan deze gids uitgaat dat u ze al heeft. Stel poort 11434 niet bloot aan het internet. Ollama wordt geleverd zonder eigen authenticatie, dus iedereen die de poort bereikt, kan uw model gebruiken en uw prompts lezen.

FAQ

Is er een Qwen 3.8 27B-model op Ollama?

Nee. Per 4 augustus 2026 bevat de Ollama-bibliotheek geen qwen3.8-namespace. De bestaande 27B-tags zijn qwen3.5:27b en qwen3.6:27b; beide zijn Q4_K_M-builds van een dense model met 27,8 miljard parameters. De 3.8 in de zoekterm is vrijwel zeker het aantal van 27,8B parameters dat onthouden is als versienummer. Controleer https://ollama.com/library/qwen3.6/tags voor de huidige lijst en voer qwen3.6:27b uit als u de nieuwste uitgebrachte 27B-versie wilt ophalen. Een tag die niet bestaat, faalt met Error: pull model manifest: file does not exist.

Hoeveel RAM heb ik nodig om een Qwen 27B-model op een VPS te draaien?

32 GB is het praktische minimum voor Q4_K_M. De gewichten zijn 17 GB, het besturingssysteem heeft ongeveer 1,5 GB nodig en de KV-cache voegt ongeveer 1 GB toe per 4000 tokens aan context op f16. Een plan met 16 GB kan de gewichten in zijn geheel niet laden, en swap helpt niet omdat het bestand memory-mapped is en de kernel het bij elke token opnieuw van de schijf leest. 64 GB geeft u ruimte voor een lange context of voor Q8_0-gewichten van 30 GB.

Hoeveel tokens per seconde levert een 27B-model op een CPU?

Deel uw geheugenbandbreedte door de grootte van de gewichten en neem daar 50 tot 70 procent van. Een VPS met dual-channel DDR4-3200 heeft een plafond van bijna 3 tokens per seconde en levert er ongeveer 2. Een box met dual-channel DDR5-4800 heeft een plafond van bijna 4.5 en levert er ongeveer 3. Serverplatforms met meer kanalen zien er op papier veel beter uit, maar de geheugenbandbreedte wordt gedeeld met alle andere huurders op de host. Meet daarom uw eigen snelheid met ollama run qwen3.6:27b --verbose en lees de eval rate-regel.

Moet ik Q4 of Q8 gebruiken op een VPS zonder GPU?

In vrijwel elk geval Q4_K_M. Q8_0 is 30 GB tegenover 17 GB, dus dit vereist een plan met 64 GB en verplaatst per token bijna twee keer zoveel geheugen, wat uw tokens per seconde ongeveer halveert. Het kwaliteitsverschil tussen Q4_K_M en Q8_0 is bij een 27B-model voor de meeste taken klein. Besteed het RAM-geheugen liever aan een langere context, aangezien dat bepaalt wat het model kan doen in plaats van hoe het zinnen formuleert.

Wanneer is het huren van een GPU goedkoper dan een VPS met veel RAM?

Wanneer uw gebruikscyclus laag is of wanneer er een gebruiker op de output wacht. Een GPU met 24 GB geheugen haalt ongeveer 59 tokens per seconde met deze gewichten, tegenover 2 of 3 op een typische VPS, en u betaalt alleen voor de uren dat deze actief is. Een VPS met 64 GB wordt de hele maand gefactureerd, ongeacht of het model geladen is of niet. Bereken hoeveel uur per dag u daadwerkelijk tokens genereert. Bij minder dan twee of drie uur per dag is GPU-huur per uur meestal voordeliger qua snelheid en kosten. Continue batchverwerking met lage prioriteit is waar de altijd actieve VPS wint.