Rekomandime për menaxhimin e performancës dhe kujtesës për Ollama-n

  • Prioriteti është të sigurohet që modelet e përdorura të përshtaten në mënyrë interaktive 100% në VRAM për të shmangur rënie të ndjeshme të performancës.
  • Kuantizimi, gjatësia e kontekstit dhe zgjedhja e modelit ndikojnë si në cilësi ashtu edhe në konsumin e memories.
  • Ollama thjeshton menaxhimin e modeleve dhe burimeve krahasuar me llama.cpp, me koston e një kontrolli pak më të imët.
  • Një konfigurim i balancuar i harduerit për sa i përket VRAM, RAM, CPU dhe disku lejon një ofertë private SaaS të qëndrueshme dhe të qetë të LLM-ve.
Lorena Figueredo

Minuta 15

Rekomandime për menaxhimin e performancës dhe kujtesës për Ollama-n

Nëse po mendoni të vendosni një Shërbim privat LLM me OllamaQoftë ofruesi juaj i shërbimit të internetit në zonat rurale, një qendër e vogël të dhënash apo një kompjuter i fuqishëm në shtëpi, pyetja e madhe është gjithmonë e njëjtë: si ta shfrytëzoni sa më shumë performancën tuaj pa shpenzuar para për pajisje që nuk i përdorni?

Në botën e modeleve të mëdha gjuhësore, VRAM, RAM, CPU, GPU, kuantizimi dhe konteksti Këto nuk janë thjesht zhargon teknik: ato janë pjesët që do të përcaktojnë nëse klasteri juaj fluturon apo zvarritet. Për më tepër, Ollama dhe llama.cpp e menaxhojnë ndryshe memorien dhe ndarjen e CPU/GPU, dhe të kuptuarit e kësaj është çelësi për të vendosur nëse një nyje e madhe me GPU të shumta apo disa makina më modeste 1:1 për klient është më efektive nga ana e kostos.

Grupimi i GPU-ve në një klaster ose dedikimi i tyre 1:1: çfarë është më e mira për Ollama-n

Kur merrni në konsideratë një SaaS privat me Ollama, dilema e parë është nëse duhet të konfiguroni një grup i centralizuar i GPU-ve ose caktoni një makinë (ose GPU) për secilin klient. Këtu hyn në lojë mënyra se si Ollama dhe llama.cpp përdorin burimet:

  • Nyja "Monster" me GPU të shumëfishtaIdeale nëse dëshironi radhë të përbashkëta kërkesash, për të përfituar plotësisht nga GPU-ja me shumë përdorues të njëkohshëm dhe për të konsoliduar administrimin dhe mirëmbajtjen.
  • Makina 1:1 për klient: më shumë izolim, më pak shqetësime nga shumë qiramarrës, konsum i parashikueshëm i burimeve dhe shumë i përshtatshëm për klientët që paguajnë për makinën "e tyre".

Ollamama aktualisht po përqendrohet më shumë në shfrytëzoni një ose më shumë GPU lokale për instancë sesa orkestrimi i një klasteri të shpërndarë të tipit Kubernetes me balancim të imët të ngarkesës midis makinave. Për një ofrues të vogël shërbimesh interneti që dëshiron t'u shërbejë "përdoruesve të fuqishëm":

  • Nëse objektivi është thjeshtësi operacionaleDisa makina me madhësi të mirë (16-24 GB VRAM secila) me Ollama për nyje dhe shpërndarje klientësh për server janë zakonisht opsioni më i arsyeshëm.
  • Nëse doni të luani "mini-hiperscaler", mund të propozoni një server i madh me GPU të shumta dhe një ndërmjetës (ose disa raste të Ollama/llama.cpp) për secilin klient, por kompleksiteti i planifikimit dhe izolimit rritet ndjeshëm.

Faktori përcaktues nuk është vetëm topologjia, por Cilat modele do të shërbeni, në çfarë konteksti dhe sa seanca të njëkohshme?Kjo përcakton drejtpërdrejt se sa VRAM ju nevojitet për përdorues.

Si e menaxhon Ollama memorien, VRAM-in dhe ndarjen e CPU/GPU-së

Ollama mbështetet nga brenda në llama.cpp dhe backend-e të tjeraPor shton një shtresë orkestrimi që ta thjeshton shumë jetën. Sa i përket kujtesës dhe performancës, ka disa pika kyçe:

Hartimi i modelit dhe ngarkimi i memories

llama.cpp SHBA mmap për të hartëzuar skedarin GGUF të modelit në hapësirën e adresave. Kjo lejon Sistemi operativ vendos se cilat pjesë janë në të vërtetë në RAM në çdo moment, duke zvogëluar kohën fillestare të ngarkimit krahasuar me hedhjen e të gjithë skedarit në memorie menjëherë.

Ollama, nga ana e saj, është përgjegjëse për:

  • Ngarkoni dhe shkarkoni modele të VRAM/RAM sipas aktivitetit, duke respektuar kohën e OLLAMA_KEEP_ALIVE.
  • Ndani modelet midis seancave të të njëjtit instancë për shmangni rimbushjet e panevojshme.
  • Trego veten me ollama ps përdorimi i kujtesës, pjesëtimi CPU / GPU dhe nëse ka shkarkim të shtresave në procesor.

Në praktikë, kur shihni një model me, për shembull, 18%/82% CPU/GPUKjo do të thotë që një pjesë e shtresave nuk u përshtatën në VRAM dhe po ekzekutohen në RAM-in e sistemit nëpërmjet CPU-së, me ndikimin pasues në shpejtësi, siç tregojnë disa shembuj. analiza e latencës në rrjetet lokale.

Çfarë ndodh nëse modeli nuk përshtatet në VRAM?

Ja një nga pyetjet më të rëndësishme: nëse një model futet plotësisht në VRAM, ju merrni kthimi i pritur në 100%Por kur modeli tejkalon VRAM-in e disponueshëm, Ollama shpërndan shtresa midis GPU-së dhe CPU-së. A përkeqësohet performanca në mënyrë proporcionale me numrin e shtresave të lëshuara në RAM, apo ju bllokon plotësisht në shpejtësinë e RAM-it dhe të autobusit?

Të dhëna praktike me një RTX 4080 16 GB Ato janë shkatërruese:

  • Modele 100% GPU: në rendin e 60 deri në 140 token/s (p.sh. gpt-oss:20b me 14 GB të përdorura arrin ~140 tok/s).
  • Modelet 70-80% GPU (pushim në CPU): bie në ~19-50 tok/s.
  • Modele me ~20% GPU (kryesisht në CPU): ato qëndrojnë në ~12 tok/s (rasti i gpt-oss: 120b, 66 GB RAM+VRAM i përdorur).

Me fjalë të tjera, nuk është thjesht çështje e "Unë humbas 30% të performancës sepse 30% është në CPU", por përkundrazi Vonesa e lëvizjes së të dhënave midis RAM dhe VRAM dhe ekzekutimit të shtresave në CPU shumëfishon bllokimin.Një konfigurim me 20B të gjitha GPU-të mund të jetë 10-11 herë më i shpejtë se një konfigurim me 120B kryesisht i bazuar në CPU.

Pra, për klasterin tuaj: Qëllimi numër një është që modelet kritike të përdorimit interaktiv të përshtaten tërësisht në VRAM.Çdo gjë që nuk përshtatet është më mirë të rezervohet për detyra në grup, çdo natë ose me përparësi të ulët.

Modelet e MoE (Përzierje Ekspertësh) dhe Shkarkimi i CPU-së

Modelet e tipit Përzierje e ekspertëve (si GLM 4.7 Flash ose disa instanca Qwen dhe DeepSeek) kanë shumë parametra totalë, por aktivizojnë vetëm një pjesë të vogël të ekspertëve për token. Kjo, në teori, mund të ndihmojë në skenarë me kufizime në VRAM sepse Jo të gjitha pjesët e modelit përdoren në të njëjtën kohë..

Në praktikë, me Ollama:

  • Një MoE prej 30B-A3B (gjithsej 30B, 3B aktive) si glm-4.7-flash Lëviz rreth 30-35 tok/s me shkarkim të pjesshëm të CPU-së, mjaft i respektueshëm për madhësinë e tij.
  • Avantazhi i MoE nuk kompenson nëse modeli vazhdon të tejkalojë VRAM-in dhe detyron shumë shtresa të zhvendosen nëpër autobus.
  • Ollama nuk e "kupton" MoE si diçka të veçantë në nivelin e planifikuesit; ai thjesht sheh shtresa dhe memorie. Magjia e MoE qëndron në arkitekturën e modelit, jo në Ollama.

Përfundim praktik: Ministria e Arsimit ndihmon, por nuk bën mrekulli.Nëse e tejkaloni ndjeshëm limitin e VRAM-it, do të vazhdoni të paguani çmimin për përdorimin e RAM-it dhe CPU-së. Është më mirë të përdorni MoE për të shtyrë pak më tej kufijtë, jo për të justifikuar punën gjithmonë jashtë VRAM-it.

Krahasimi i Llama.cpp me Ollama për të përfituar sa më shumë nga hardueri juaj

Shumë diskutime fillojnë me pyetjen tipike: "Pse të përdoret Ollama dhe jo llama.cpp direkt?" Për sa i përket performancës dhe menaxhimit të memories, ia vlen të dallohen qartë rolet e secilit.

llama.cpp: salla e operacionit tensor

llama.cpp është motor C++ me performancë të lartëQëllimi i tij është të nxjerrë çdo grimcë të fundit të performancës nga CPU-ja dhe GPU-ja, me vëmendje të veçantë te CPU-të x86 me GPU AVX, Apple Silicon dhe NVIDIA/AMD. Është projektuar për ata që duan të:

  • përshtat kuantizim në detaje (Q4_K_M, Q5_0, Q8_0, Q2_K…).
  • kontroll numri i shtresave në GPU me --n-gpu-layers.
  • trajtuar kontekst, grupi, numri i fijeve, gramatikat GBNF dhe parametra të tjerë të hollësishëm.

Nivel i ulët, po, por shumë i fuqishëm. Për sa i përket kujtesës:

  • Përdorim mmap për të ngarkuar modelin dhe për të lënë bërthamën të vendosë se çfarë mbahet në RAM.
  • Ju lejon të zgjidhni me saktësi se cilat shtresa i kalohen GPU-së me -ngl, duke rregulluar konsumin e VRAM në milimetër.
  • Integra K-Quants për të zvogëluar madhësinë me ndikimin më të vogël të mundshëm në cilësi.

Shkurt: llama.cpp është perfekt nëse dëshironi Ndërtoni shërbimin tuaj super të optimizuar ku kontrolloni çdo parametër dhe nuk ju shqetëson të ngatërroni duart me opsionet e rreshtit të komandës dhe konfigurimin e përparuar.

Ollama: orkestruesi i prapavijës

Ollama është shkruar në Go dhe mbështetet në llama.cpp (dhe motorë të tjerë si vLLM në disa skenarë) si backend-i i saj. Qëllimi i tij është t'ju japë një Përvojë e tipit "Docker për modele":

  • CLI e thjeshtë: ollama pull, ollama run, ollama list, ollama ps.
  • REST API en 127.0.0.1:11434 Si parazgjedhje, është gati për të lidhur GUI-të si Open WebUI ose aplikacionet tuaja.
  • Menaxhimi i modelit: shkarko nga regjistri juaj, përditëso, ruajtja lokale, kopjo dhe shtyj modelet tuaja.
  • Zbulimi automatik i pajisjeveAnalizon GPU-në, RAM-in dhe kontekstin për të rregulluar shtresat e GPU-së/CPU-së pa pasur nevojë të prekni asgjë. --n-gpu-layers.

Dallimi i vërtetë është niveli i abstraksionitllama.cpp është motori i papërpunuar, Ollama është makina e plotë dhe gati për t'u drejtuar. Në këmbim të një kontrolli pak më pak ekstrem, ju merrni:

  • Nisni modelet me një komandë të vetme.
  • Radhë kërkesash dhe shkarkim automatik pas mosaktivitetit (OLLAMA_KEEP_ALIVE).
  • Integrim i drejtpërdrejtë me GUI dhe framework-e.

Për një përdorues fundor ose për të ofruar shërbim të përgjithshëm për klientët e ISP-së, Ollama është zakonisht zgjedhja e qartëPër modelet XXL shumë të ngushta ose për të përfituar sa më shumë nga një GPU specifike, llama.cpp mund të ketë një avantazh të vogël nëse dini si ta akordoni mirë.

Rekomandime për harduerin: VRAM, RAM, CPU dhe disk për Ollama

Rekomandime për menaxhimin e performancës dhe kujtesës për Ollama-n

Për të përcaktuar madhësinë e klasterit tuaj, nuk mjafton vetëm të shikoni GPU-në. Ekuilibri midis VRAM, RAM, CPU, disk dhe kontekst Ai ka më shumë pushtet nga sa duket.

VRAM: burimi kritik

VRAM është pengesa kryesore. Vetëm për udhëzime:

  • 8 GB RAM: i mjaftueshëm për modele të kuantizuara të vogla/mesme (7B, disa 13B në Q4_K_M me kontekst modest).
  • 16 GB RAMPika ideale për përdorim serioz: 14B, 20B, 24B në Q4_K_M plotësisht në GPU me kontekste ~16-32K.
  • 24 GB ose më shumë: e nevojshme nëse dëshironi 30B-35B me kontekst të gjerë GPU ose për të trajtuar seanca të shumëfishta të njëkohshme të modeleve të mesme pa filluar të shkarkoni shtresat.

Disa vlera praktike në një RTX 4080 16 GB me një kontekst ~19K dhe kuantizim Q4_K_M:

  • gpt-oss:20b (20B): ~14 GB, 100% GPU, ~ 140 tok/s.
  • qwen3:14b: ~ 12 GB, 100% GPU, ~ 62 tok/s.
  • mistral-3:14b: ~ 13 GB, 100% GPU, ~ 70 tok/s.

Çdo model që i tejkalon këto kufizime përfundon duke përzier CPU/GPU. Në projektin tuaj, nëse doni të ofroni një kontekst të madh, si 80-100K, për shumë përdorues, Çdo kërcim në kontekst rrit gjithashtu konsumin efektiv të VRAM-it.sepse memoria e përkohshme KV rritet.

RAM-i i sistemit dhe CPU-të: më të rëndësishme nga sa duken

Kur Ollama shkarkon shtresat në CPU, procesori bëhet pjesë e motorit të përfundimitNë testet me një i7-14700 (8P+12E) dhe 64 GB DDR5-6000:

  • Modelet me 20-30% shtresa CPU janë ende të përdorshme (~30-50 tok/s).
  • Kur përqindja e përdorimit të CPU-së rritet mbi 50%, përvoja e bisedës fillon të ndihet e ngadaltë, veçanërisht nëse konteksti është i gjerë.

Rekomandime të arsyeshme për një nyje shërbimi:

  • RAM minimale 16 GB: vetëm për të luajtur me dritën 7B dhe 13B.
  • RAM i rekomanduar 32-64 GBPër përdorim serioz nga shumë përdorues me modele 14-24B dhe kontekst të gjerë.
  • CPU me të paktën 8 bërthama (ose kombinim modern P+E) për të zbutur shkarkimin e shtresave pa shembjen e nyjeve, dhe gjithashtu të merrni në konsideratë se si konfiguroni profilet e performancës në sistemet Windows nëse është e aplikueshme.

Albumi: Elefanti i Heshtur

Skedarët e modelit janë tepër të mëdhenj. Kuantizimi ndihmon, por edhe kështu:

  • Modele të vogla të kuantizuara: ~2 GB.
  • Modelet e medianës së kuantizuar5-20 GB.
  • Modele të mëdha: lehtësisht 40-200 GB ose më shumë; ka pika kontrolli që tejkalojnë 1 TB.

Si rregull i shpejtë, gjithmonë rezervoni një diferencë prej të paktën 2-3 herë më të madhe se çdo model midis skedarit bazë, varianteve, memorjeve të përkohshme dhe regjistrave, dhe vlerëson opsionet e ruajtje lokale kundrejt cloud hibridDhe përdor NVMe SSDKohët e ngarkimit dhe faqosja e mmap përfitojnë shumë nga kjo.

Kuantifikimi, konteksti dhe përzgjedhja e modelit: ndikim i drejtpërdrejtë në performancë

Edhe pse ndonjëherë anashkalohet, kuantizimi që ju zgjidhni dhe gjatësia e kontekstit Ato bëjnë një ndryshim të madh në konsumin dhe shpejtësinë e kujtesës.

"Guri i Rosettës" i kuantizimit

Në terma të thjeshtuar, mund të mendoni për këto variacione:

  • FP16Model pothuajse pa kompresim, cilësi maksimale, madhësi masive. Kërkon shumë VRAM/RAM.
  • Q8_0: kompresim i butë, cilësi pothuajse identike me FP16, por prapëseprapë madhësi e madhe.
  • Q4_K_Mstandardi i "balancuar" për përdorim lokal. Zvogëloni madhësinë përgjysmë me vetëm ~1-2% humbje mesatare të saktësisë. Është opsioni i rekomanduar për shumicën e implementimeve.
  • Q2_K: kompresim ekstrem, madhësi minimale, por modeli bëhet qartësisht më pak i besueshëm, me më shumë halucinacione.

Në praktikë, për një SaaS lokal me klientë të shumtë, zgjidhni modelet Q4_K_M Ofron raportin më të mirë cilësi/performancë/konsum VRAM. Q8_0 është i dobishëm nëse keni shumë VRAM dhe doni të përfitoni pak më shumë cilësi nga një model i vogël/mesëm.

Gjatësia e kontekstit (num_ctx) dhe kostoja e saj e fshehur

Parametri num_ctx Ollama/llama.cpp përcakton se sa tokena mund të "shohë" modeli në të njëjtën kohë: sistemin, historikun e bisedave, kërkesën aktuale dhe përgjigjen. Në një nivel konceptual:

  • Dritare të vogla (2K-4K): më pak memorie, më shumë shpejtësi, por humbet konteksti në biseda të gjata ose dokumente të mëdha.
  • Dritaret mesatare (8K-32K): një pikë mesatare e arsyeshme për shumicën e përdorimeve profesionale.
  • Dritaret gjigante (64K-128K+): spektakolare në letër, por konsumojnë shumë më tepër VRAM dhe përkeqësojnë performancën nëse hardueri është tashmë në limitin e tij.

Për më tepër, nëse e detyroni një num_ctx më i lartë se konteksti me të cilin është trajnuar modeliMund të hasni sjellje të pazakontë dhe një rënie të cilësisë. Vetëm rritja e vlerës në cilësime nuk mjafton; ekziston një kufi arkitekturor.

Për skenarin tuaj, gjëja më e arsyeshme për të bërë është:

  • Oferta Planet "normale" me kontekst 8K-16Ktë cilat përshtaten mirë në VRAM.
  • Rezervë 64 mijë-100 mijë kontekste vetëm për makina premium ose GPU, dhe pranoni rënien e tokenëve/e.

Praktikat më të mira për menaxhimin e performancës dhe kujtesës me Ollama

Përtej harduerit, ekzistojnë disa vendime për konfigurimin dhe arkitekturën që mund të bëjnë gjithë ndryshimin në sigurimin që klasteri juaj të funksionojë pa probleme.

Sigurohuni që modelet kritike janë 100% në GPU

Përpara se t'i jepni një model klientit, këshillohet ta provoni dhe ta kontrolloni me ollama ps se Fusha PROCESORI tregon 100% GPU kur është në përdorim. Nëse shihni ndarje 60/40 CPU/GPU ose më keq, prekni:

  • Kaloni në një kuantizim më agresiv (për shembull, nga Q8_0 në Q4_K_M).
  • Përdorni një model më i vogël (për shembull, 20B në vend të 35B).
  • reduktuar num_ctx nëse klienti mund të jetojë me një kontekst disi më të vogël.

Një 20B i akorduar mirë me 140 tok/s është i preferueshëm sesa një 120B që lëviz me 12 tok/s për bisedë interaktive. Përdoruesit e vlerësojnë shumë më tepër këtë të fundit. rrjedhshmëria e përvojës se një përmirësim hipotetik i cilësisë do të ishte i vështirë për t’u perceptuar.

Rregulloni OLLAMA_KEEP_ALIVE dhe strategjinë e modelit të ngarkuar

Parametri OLLAMA_KEEP_ALIVE Përcakton se për sa kohë Ollama e mban një model në kujtesë pas kërkesës së fundit. Vlerat e mundshme:

  • 0Shkarkohet menjëherë pasi të përfundojë përgjigja. Kjo kursen memorie, por rezulton në kohë më të gjata ngarkimi.
  • X m (p.sh., 5m, 15m): Balancon RAM/VRAM dhe shkathtësinë. Ideale për shërbime me rritje të herëpashershme.
  • -1Modeli mbetet i ngarkuar ndërsa shërbimi është aktiv. Shumë i dobishëm për modelet tuaja kryesore SaaS.

Në një skenar me shumë përdorues, zakonisht funksionon mirë të mirëmbahet një ose dy modele bazë gjithmonë të ngarkuara (për shembull, një gjeneralist 14B dhe një kod një) dhe shkarkoni pjesën tjetër pas disa minutash mosaktiviteti.

Kontrolli i variablave të mjedisit dhe shtigjeve të modelit

Ollama ju lejon të rregulloni sjelljen e saj me disa variabla mjedisorë që ndikojnë në mënyrën se si menaxhohen burimet dhe qasja:

  • MODELET_E_FURRËS: shtegu ku ruhen modelet. I dobishëm për dërgimin e tyre në një hard disk/SSD të dedikuar me kapacitet më të lartë.
  • OLLAMA_HOSTNdërfaqja dhe porta e API-t (parazgjedhja 127.0.0.1:11434). Nëse e ekspozoni në LAN, kufizoni aksesin me firewall-in.
  • OLLAMA_ORIGINSCORS për GUI-të e jashtme të internetit (WebUI i hapur, panele të personalizuara, etj.).
  • OLLAMA_DEBUG: modaliteti i debugimit për të parë regjistrat e detajuar të ngarkimit të modelit, zbulimin e GPU-së, gabimet CUDA/ROCm, etj.

Në Linux, këto parametra zakonisht konfigurohen duke përdorur systemd (me systemctl edit ollama.service), ndërsa në Windows dhe macOS ato vendosen si variabla të sistemit ose të mjedisit të përdoruesit.

Monitorimi dhe regjistrat

Në një klaster, duhet të kuptoni qartë se çfarë po ndodh në secilën nyje. Për ta bërë këtë:

  • Në Linux, përdorni journalctl -u ollama për të monitoruar regjistrat e shërbimit. Me -f E shihni në kohë reale.
  • Plotësoni me nvidia-smi ose ekuivalent në AMD për të parë VRAM, ngarkesën e GPU-së dhe konsumin e energjisë.
  • Integroni metrikat (tokenët/s, radhët e pritjes, gabimet) në grumbullin tuaj të vëzhgueshmërisë nëse e merrni seriozisht SaaS.

Zbulimi i hershëm i faktit që një model po funksionon kryesisht në CPU, ose që radhët e gjata janë të bllokuara, ju kursen shumë telashe me klientët; dhe mjetet për zbuloni adresën IP në rrjetin tuaj lokal Ato mund të ndihmojnë me inventarin e nyjeve.

Përzgjedhja e modeleve dhe rastet tipike të përdorimit në Ollama

Me të gjitha sa më sipër, shtylla tjetër e performancës është zgjidhni modelin e duhur për secilën detyrëjo vetëm për të "shkuar me shpejtësi të plotë", por edhe për të kontrolluar konsumin dhe vonesën.

Shabllone për biseda të përgjithshme dhe asistentë

Për biseda, mbështetje, shkrim email-esh, përmbledhje dhe detyra të përgjithshme, shabllone të tilla si:

  • Qwen3 14BGjurmim i shkëlqyer i udhëzimeve dhe shpejtësi e mirë me 100% përdorim të GPU-së.
  • Mistral 3 14B: shumë e ekuilibruar në cilësinë dhe performancën gjuhësore.
  • Gemma dhe Llama 3.x Në konfigurimet 7-14B: opsione të mira gjeneraliste për përdoruesit më pak kërkues ose pajisje më bazë.

Me këto familje në kontekstin Q4_K_M dhe 8K-16K, ju keni një themel të fortë për shumicën dërrmuese të përdoruesve profesionistë pa e mbingarkuar VRAM-in.

Modele për kodim dhe zhvillim

Për detyrat e gjenerimit, rishikimit dhe zhvillimit të kodit, këshillohet të zgjidhni modele specifike:

  • qwen3-coder:30bi fortë në programim dhe mjete, megjithëse një pjesë e modelit përfundon me CPU me 16 GB VRAM.
  • Koduesi DeepSeek, CodeLlama dhe variante të tjera kodi për madhësi më të vogla, nëse dëshironi më shumë lehtësi.

Nëse do të ofroni "plane zhvilluesish", merrni në konsideratë një nyje me më shumë se 16 GB VRAM për të akomoduar këto modele pa shkaktuar shumë ngarkesë të CPU-së.

Modelet dhe vizioni multimodal

Për detyrat që kombinojnë tekstin dhe imazhin (analiza e pamjeve të ekranit, dokumentet e skanuara, etj.), modelet e etiketuara vizion (llava, moondream, bakllava, qwen-vl…) janë ato që duhet t'i mblidhni. Ja:

  • Konsumi i VRAM rritet dhe shpejtësia e tokenëve zakonisht është më e ulët.
  • Këshillohet që ato të kufizohen në detyra specifike dhe të mos përzihen me biseda intensive që përfshijnë shumë përdorues.

Nëse keni një grup të përzier GPU-sh (për shembull 5070 + 5060 + 4060, 48 GB VRAM gjithsej), mund të jetë interesante t'i kushtoni njërës prej kartave modeleve të vizionit dhe një tjetrës tekstit të pastër, duke shmangur mbingarkesën e një pajisjeje të vetme me gjithçka.

Variantet e instalimit, vendosjes dhe ekzekutimit (native, Docker, kontejnerë)

Në një nivel operativ, Ollama mund të instalohet në disa mënyra: në mënyrë native në Windows, macOS ose Linux, ose në kontejnerë (Podman, Docker…).

Në Linux, për shembull, mund të vendosni llama.cpp në një kontejner të optimizuar për GPU-në:


Description=llama
After=network-online.target


Image=ghcr.io/ggml-org/llama.cpp:server-cuda
ContainerName=llama
PublishPort=8000:8000
AddDevice=nvidia.com/gpu=all
Environment=NVIDIA_DRIVER_CAPABILITIES=all
Environment=NVIDIA_VISIBLE_DEVICES=all

Exec=--host 0.0.0.0 \
     --port ${PORT} \
     -m ${MODEL_PATH} \
     -ngl ${NGL} \
     -c ${CONTEXT_SIZE} \
     --flash-attn on \
     --batch-size ${BATCH}

Volume=/data/models:/models:Z
Network=llama.network


Restart=always
Environment=PORT=8000
Environment=MODEL_PATH=/models/gemma-4-E4B-it-Q8_0.gguf
Environment=NGL=99
Environment=CONTEXT_SIZE=128000
Environment=BATCH=512


WantedBy=default.target

Ky lloj vendosjeje ju lejon mjete të ndara Ollama, llama.cpp dhe mjete të tjera në kontejnerë, kontrolloni versionet dhe izoloni burimet sipas shërbimit (dhe, nëse dëshironi, sipas klientit).

Për të menaxhuar modelet Hugging Face në GGUF ose Safetensors, mund të përdorni mjete si rust-hf-shkarkues dhe pastaj importojini ato në Ollama duke përdorur Modelfilesku përcaktoni FROM, SHABLLON, parametrat parazgjedhur dhe sistemin e promptit, përveç mirëmbajtjes së sinkronizimi dhe kopjet rezervë lokale të artefakteve nëse punoni me nyje të shumta.

Pasi të keni mbledhur pjesët, pjesa tjetër janë vendime qeverisjeje: çfarë modelesh u ofroni cilave klientëve, me çfarë kufizimesh kontekstuale dhe cila është politika për përditësimet dhe përcaktimet sasiore në mënyrë që të mos prishet përputhshmëria ose performanca e pritur.

Nëse e keni të qartë se përparësia është që modelet të përshtaten plotësisht në VRAM, që kuantizimi të mbetet në një ekuilibër të arsyeshëm (Q4_K_M) dhe që konteksti të mos tejkalojë atë që mund të përballojë hardueri juaj, atëherë konfigurimi i një SaaS privat i Ollama-s në një klaster të mesëm Nuk është më fanta-shkencë dhe bëhet një investim i arsyeshëm: ju paguani për GPU-të aty ku ato kontribuojnë vërtet, ju kujdeseni për RAM-in për të mbështetur shkarkimet e rastit dhe përdorni mjete orkestrimi (Ollama, llama.cpp, kontejnerë, Open WebUI) për t'u dhënë klientëve tuaj përvojën e një "ChatGPT privat", por me rregullat tuaja dhe pa u varur nga "cloud".

Auditimi vjetor i një kompjuteri në shtëpi
Artikulli i lidhur:
Paneli i telemetrisë lokale të PC-së pa cloud: një udhëzues i plotë

Shto si burim të preferuar