Ollama jõudluse ja mäluhalduse soovitused

Kui mõtled luua Privaatne LLM-teenus OllamagaOlgu selleks siis teie enda maapiirkonna internetiteenuse pakkuja, väike andmekeskus või võimas koduarvuti, on suur küsimus alati sama: kuidas oma jõudlusest maksimumi võtta, ilma et peaksite raiskama raha riistvarale, mida te ei kasuta?

Suurte keelemudelite maailmas Videomälu, muutmälu, protsessori, graafikakaardi, kvantiseerimise ja konteksti Need pole lihtsalt tehniline žargoon: need on osad, mis määravad, kas teie klaster lendab või roomab. Lisaks haldavad Ollama ja llama.cpp mälu ja protsessori/graafikaprotsessori jaotust erinevalt ning selle mõistmine on võtmetähtsusega otsustamaks, kas suur sõlm mitme graafikaprotsessoriga või mitu tagasihoidlikumat 1:1 masinat kliendi kohta on kulutõhusam.

GPU-de grupeerimine klastrisse või nende 1:1 eraldamine: mis on Ollama jaoks parim?

Kui kaalute privaatset SaaS-i Ollamaga, on esimene dilemma, kas seadistada tsentraliseeritud GPU-bassein või määrake igale kliendile masin (või graafikakaart). Siin tuleb mängu see, kuidas Ollama ja llama.cpp ressursse kasutavad:

• Mitme GPU-ga „koletis” sõlm: ideaalne, kui soovite jagatud päringute järjekordi, et paljude samaaegsete kasutajatega GPU-d täiel määral ära kasutada ning haldust ja hooldust konsolideerida.
• 1:1 masinad kliendi kohta: suurem isolatsioon, vähem mitme üürnikuga seotud vaeva, prognoositav ressursitarbimine ja väga mugav klientidele, kes maksavad "oma" masina eest.

Ollamama keskendub praegu rohkem kasutada ühte või mitut kohalikku GPU-d eksemplari kohta kui hajutatud Kubernetes-tüüpi klastri orkestreerimine masinate vahelise peeneteralise koormuse tasakaalustamisega. Väikese internetiteenuse pakkuja jaoks, kes soovib teenindada "võimsaid kasutajaid":

• Kui eesmärk on operatiivne lihtsusTavaliselt on kõige mõistlikum variant paar korraliku suurusega masinat (16–24 GB videomälu igaühel) koos Ollamaga sõlme kohta ja klientide jaotusega serveri kohta.
• Kui tahad mängida "minihüperskaleerijat", võid teha ettepaneku suur server mitme GPU-ga ja iga kliendi jaoks puhverserver (või mitu Ollama/llama.cpp eksemplari), kuid ajastamise ja isoleerimise keerukus suureneb märkimisväärselt.

Määravaks teguriks pole mitte ainult topoloogia, vaid ka Milliseid mudeleid te teenindate, millises kontekstis ja mitu samaaegset seanssi te korraldate?See määrab otseselt, kui palju videomälu iga kasutaja kohta vaja läheb.

Kuidas Ollama haldab mälu, videomälu ja protsessori/graafikaprotsessori jagamist

Ollama tugineb sisemiselt llama.cpp ja muud taustaprogrammidKuid see lisab orkestreerimiskihi, mis lihtsustab teie elu oluliselt. Mälu ja jõudluse osas on mitu olulist punkti:

Mudeli kaardistamine ja mälu laadimine

llama.cpp usa mmap mudeli GGUF-faili aadressiruumi kaardistamiseks. See võimaldab Operatsioonisüsteem otsustab, millised osad tegelikult RAM-is asuvad. igal hetkel, vähendades esialgset laadimisaega võrreldes kogu faili korraga mällu laadimisega.

Ollama vastutab omalt poolt järgmise eest:

• Laadige üles ja laadige alla mudeleid VRAM/RAM vastavalt aktiivsusele, arvestades aega OLLAMA_KEEP_ALIVE.
• Jaga mudeleid sama eksemplari seansside vahel vältige tarbetuid laadimisi.
• Näita ennast koos ollama ps mälukasutus, jagamine CPU / GPU ja kui protsessorile laaditakse kihte ümber.

Praktikas, kui näete mudelit, millel on näiteks 18%/82% protsessori/graafikaprotsessoriSee tähendab, et osa kihtidest ei mahtunud videomälusse ja neid käitatakse protsessori kaudu süsteemimälus, millel on mitmete näidete kohaselt kiirusele mõju. latentsusanalüüs kohalikes võrkudes.

Mis juhtub, kui mudel ei mahu videomälusse?

Siin on üks olulisemaid küsimusi: kui mudel läheb täielikult VRAM-i, siis saate oodatav tootlus 100% juuresAga kui mudel ületab saadaoleva videomälu mahu, jaotab Ollama kihid graafikakaardi ja protsessori vahel. Kas jõudlus väheneb proportsionaalselt muutmälule langevate kihtide arvuga või seob see teid täielikult muutmälu ja siini kiirusega?

Praktilised andmed koos a-ga RTX 4080 16GB Need on laastavad:

• 100% GPU mudelidsuurusjärgus 60–140 tokenit/s (nt gpt-oss:20b 14 GB kasutusega saavutab ~140 tokenit/s).
• Mudelid 70–80% graafikakaardi võimsusest (puhkeaeg protsessoris): langeb ~19-50 toni/s-ni.
• Mudelid, millel on ~20% graafikakaarti (peamiselt protsessori peal): need püsivad ~12 tok/s juures (gpt-oss juhtum: 120b, kasutatud on 66 GB muutmälu + videomälu).

Teisisõnu, asi pole lihtsalt selles, et "ma kaotan 30% jõudlusest, sest 30% on protsessoris", vaid pigem selles, et Andmete RAM-i ja VRAM-i vahelise liikumise latentsus ning protsessori kihtide käivitamine mitmekordistab kitsaskohta.20B ainult GPU-l põhinev seadistus võib olla 10–11 korda kiirem kui 120B peamiselt protsessoril põhinev seadistus.

Seega teie klastri jaoks: Peamine eesmärk on kriitiliste interaktiivsete kasutusmudelite täielik mahutamine videomälusse.Kõik, mis sinna ei mahu, on kõige parem reserveerida partii-, öiste või madala prioriteediga ülesannete jaoks.

MoE (Mixture of Experts) mudelid ja protsessori koormuse vähendamine

Tüüpmudelid Ekspertide segu (nagu GLM 4.7 Flash või mõned Qwen ja DeepSeek eksemplarid) omavad palju parameetreid, kuid aktiveerivad iga märgi kohta vaid murdosa ekspertidest. See võib teoreetiliselt aidata VRAM-i piiratud stsenaariumides, sest Kõiki mudeli osi ei kasutata korraga..

Praktikas Ollamaga:

• MoE 30B-A3B (kokku 30B, 3B aktiivsed) kui glm-4.7-flash See liigub osalise protsessori koormuse vähendamisega umbes 30-35 tok/s, mis on oma suuruse kohta üsna auväärne.
• MoE eelis ei kompenseeri seda, kui mudel ületab jätkuvalt VRAM-i ja sunnib paljusid kihte siinil liigutama.
• Ollama ei "mõista" MoE-d kui midagi erilist planeerija tasandil; see näeb lihtsalt kihte ja mälu. MoE võlu peitub mudeli arhitektuuris, mitte Ollamas endas.

Praktiline järeldus: HTM aitab, aga imesid see ei tee.Kui ületate oluliselt videomälu limiiti, maksate jätkuvalt RAM-i ja protsessori kasutuse eest. Parem on kasutada MoE-d piiride veidi edasiliikumiseks, mitte selleks, et õigustada pidevat töötamist väljaspool videomälu.

Llama.cpp ja Ollama võrdlus riistvara maksimaalseks ärakasutamiseks

Paljud arutelud algavad tüüpilise küsimusega: „Miks kasutada Ollamat, mitte otse llama.cpp-i?“ Jõudluse ja mäluhalduse osas tasub selgelt eristada igaühe rolle.

llama.cpp: tensoroperatsioonisaal

llama.cpp on suure jõudlusega C++ mootorSelle eesmärk on pigistada protsessorist ja graafikakaardist välja viimanegi jõudluskild, pöörates erilist tähelepanu x86 protsessoritele AVX, Apple Silicon ja NVIDIA/AMD graafikakaartidega. See on loodud neile, kes soovivad:

• Reguleerige kvantiseerimine üksikasjalikult (Q4_K_M, Q5_0, Q8_0, Q2_K…).
• kontroll GPU kihtide arv koos --n-gpu-layers.
• Käepide kontekst, partii, lõimede arv, GBNF grammatikad ja muud peenparameetrid.

Madal tase, jah, aga väga võimas. Mälu osas:

• USA mmap mudeli laadimiseks ja kerneli otsustamiseks, mida muutmälus hoida.
• See võimaldab teil täpselt valida, millised kihid GPU-le edastatakse. -ngl, kohandades VRAM-i tarbimist millimeetri täpsusega.
• Integra K-kvantid et vähendada suurust, mõjutades kvaliteeti võimalikult vähe.

Lühidalt: llama.cpp on ideaalne, kui soovite Looge oma superoptimeeritud teenus kus sa kontrollid iga parameetrit ja ei pahanda käte määrimist käsurea valikute ja täpsema konfigureerimisega.

Ollama: taustasüsteemi orkestreerija

Ollama on kirjutatud Go keeles ja selle taustsüsteem kasutab llama.cpp-i (ja mõnel juhul ka teisi mootoreid, näiteks vLLM-i). Selle eesmärk on anda teile „Docker for models” tüüpi kogemus:

• lihtne CLI: ollama pull, ollama run, ollama list, ollama ps.
• REST API en 127.0.0.1:11434 Vaikimisi on see valmis ühendama GUI-sid, näiteks Open WebUI-d või teie enda rakendusi.
• Mudelihaldusoma mudelite allalaadimine registrist, värskendamine, kohalik salvestusruum, kopeerimine ja edastamine.
• Automaatne riistvaratuvastusAnalüüsib GPU-d, RAM-i ja konteksti, et GPU/CPU kihte ilma, et peaksite neid puudutama. --n-gpu-layers.

Tegelik erinevus on abstraktsiooni tasellama.cpp on algne mootor, Ollama aga täielik ja sõiduvalmis auto. Veidi vähem äärmusliku juhitavuse eest saate:

• Käivitage mudelid ühe käsuga.
• Taotlusjärjekorrad ja automaatne allalaadimine pärast tegevusetust (OLLAMA_KEEP_ALIVE).
• Otsene integratsioon graafiliste liideste ja raamistikega.

Lõppkasutajale või üldise teenuse osutamiseks internetiteenuse pakkuja klientidele, Ollama on tavaliselt selge valik.Väga pingeliste XXL-mudelite puhul või konkreetsest graafikaprotsessorist maksimumi saamiseks võib llama.cpp-l olla väike eelis, kui osata seda hästi häälestada.

Riistvara soovitused: Ollama jaoks videomälu, muutmälu, protsessori ja ketta jaoks

Klastri suuruse määramiseks ei piisa ainult GPU vaatamisest. Tasakaal ... ja ... vahel Videomälu, muutmälu, protsessor, ketas ja kontekst Tal on rohkem võimu, kui paistab.

Videomälu: kriitiline ressurss

Videomälu on peamine kitsaskoht. Ainult juhiseks:

• 8 GB VRAM-i: piisav väikeste/keskmiste kvantiseeritud mudelite jaoks (7B, umbes 13B Q4_K_M-is tagasihoidliku kontekstiga).
• 16 GB VRAM-iPraegune optimaalne aeg tõsiseks kasutamiseks: 14B, 20B, 24B Q4_K_M-is täielikult GPU-l ~16-32K kontekstidega.
• 24 GB või rohkem: vajalik, kui soovite 30B-35B laia GPU kontekstiga või keskmise suurusega mudelite mitme samaaegse seansi haldamiseks ilma kihte maha laadima hakkamata.

Mõned praktilised väärtused RTX 4080 16 GB puhul ~19K konteksti ja Q4_K_M kvantiseerimisega:

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

Iga mudel, mis neid piiranguid ületab, segab protsessori ja graafikakaardi. Kui soovite oma projektis pakkuda mitmele kasutajale suurt konteksti, näiteks 80–100K, Iga kontekstihüpe suurendab ka VRAM-i efektiivset tarbimist.sest KV vahemälu kasvab.

Süsteemi RAM ja protsessorid: olulisemad, kui paistavad

Kui Ollama laadib kihid protsessorile, siis teie protsessorist saab osa järeldusmootoristTestides i7-14700 (8P+12E) ja 64 GB DDR5-6000 mäluga:

• 20-30% protsessorikihtidega mudelid on endiselt kasutatavad (~30-50 tok/s).
• Kui protsessori kasutusprotsent tõuseb üle 50%, hakkab vestluskogemus tunduma aeglane, eriti kui kontekst on suur.

Mõistlikud soovitused teenindussõlme kohta:

• Minimaalne RAM 16 GB: ainult tuledega 7B ja 13B mängimiseks.
• Soovitatav RAM 32–64 GB: tõsiseks mitme kasutaja jaoks 14–24B mudelite ja laia konteksti jaoks.
• Vähemalt 8 südamikuga protsessor (või tänapäevase P+E kombinatsiooniga), et summutada kihtide mahalaadimist ilma sõlmede kokkuvarisemiseta, ning kaaluda ka seda, kuidas jõudlusprofiilide konfigureerimine Windowsi süsteemides, kui see on kohaldatav.

Album: Vaikne elevant

Mudelifailid on uskumatult suured. Kvantimine aitab, aga sellegipoolest:

• Väikesed kvantiseeritud mudelid~2 GB.
• Kvantiseeritud mediaanmudelid: 5-20 GB.
• Suured mudelid: kergesti 40–200 GB või rohkem; on kontrollpunkte, mis ületavad 1 TB.

Kiire reeglina reserveerige alati varu vähemalt 2-3 korda iga mudeli suurusest baasfaili, variantide, vahemälude ja logide vahel ning hindab valikuid kohalik salvestusruum versus hübriidpilvJa kasutage NVMe SSDMMAP-i laadimisajad ja lehekülgede jaotamine paranevad sellest märkimisväärselt.

Kvantifitseerimine, kontekst ja mudeli valik: otsene mõju tulemuslikkusele

Kuigi seda mõnikord tähelepanuta jäetakse, kvantiseerimine mille sa valid ja konteksti pikkus Need muudavad mälu tarbimist ja kiirust tohutult.

Kvantimise „Rosetta kivi”

Lihtsustatult öeldes võite mõelda järgmistele variatsioonidele:

• FP16Peaaegu ilma tihendamiseta mudel, maksimaalne kvaliteet, tohutu suurus. Nõuab palju videomälu/mälu.
• Q8_0Õrn kokkusurumine, kvaliteet peaaegu identne FP16-ga, kuid siiski suur.
• Q4_K_M: kohalikuks kasutamiseks mõeldud „tasakaalustatud” standard. Vähenda suurust poole võrra vaid ~1-2% keskmise täpsuse kaoga. See on enamiku juurutuste puhul soovitatav valik.
• Q2_K: äärmuslik kokkusurumine, minimaalne suurus, kuid mudel muutub selgelt vähem usaldusväärseks ja hallutsinatsioone esineb rohkem.

Praktikas, kohaliku SaaS-i puhul, millel on mitu klienti, vali Q4_K_M mudelid See pakub parimat kvaliteedi/jõudluse/videomälu tarbimise suhet. Q8_0 on kasulik, kui teil on palju videomälu ja soovite väikesest/keskmise suurusega mudelist veidi rohkem kvaliteeti välja pigistada.

Konteksti pikkus (num_ctx) ja selle varjatud kulu

Parameeter num_ctx Ollama/llama.cpp määrab, mitu märki mudel korraga "näeb": süsteem, vestluste ajalugu, praegune viip ja vastus. Kontseptuaalsel tasandil:

• Väikesed aknad (2K–4K): vähem mälu, suurem kiirus, aga pikkades vestlustes või suurtes dokumentides kaob kontekst.
• Keskmise suurusega aknad (8K–32K): enamiku professionaalsete kasutusalade jaoks mõistlik keskpunkt.
• Hiiglaslikud aknad (64K–128K+): paberil suurepärased, aga tarbivad palju rohkem videomälu ja halvendavad jõudlust, kui riistvara on juba oma piiril.

Lisaks, kui sa sunnid a-d num_ctx on suurem kui kontekst, millega mudelit treenitiVõib esineda ebatavalist käitumist ja kvaliteedi langust. Ainult seadete väärtuse suurendamisest ei piisa; sellel on arhitektuuriline piirang.

Teie stsenaariumi puhul on mõistlik tegutseda järgmiselt:

• Paku "Tavalised" paketid 8K-16K kontekstigamis sobis hästi VRAM-i.
• Raamat 64K–100K kontekste ainult premium-masinate või GPU-de jaoks ja aktsepteerige tokenite/märkide langust.

Parimad tavad jõudluse ja mälu haldamiseks Ollama abil

Lisaks riistvarale on mitmeid konfiguratsiooni- ja arhitektuurilisi otsuseid, mis võivad teie klastri sujuva töö tagamisel olulist rolli mängida.

Veenduge, et kriitilised mudelid on 100% GPU-s

Enne mudeli kliendile andmist on soovitatav seda testida ja kontrollida ollama ps et PROTSESSORI väli näitab 100% GPU-d kasutamise ajal. Kui näete 60/40 protsessori/graafikagraafika jaotust või veelgi halvemat, puudutage:

• Lülitu a-le agressiivsem kvantiseerimine (näiteks Q8_0-st Q4_K_M-ni).
• Kasutage a väiksem mudel (näiteks 20B 35B asemel).
• Vähendada num_ctx kui klient suudab elada mõnevõrra väiksemas kontekstis.

Interaktiivse vestluse jaoks on hästi häälestatud 20B kiirusel 140 tok/s eelistatavam kui 120B, mis roomab kiirusel 12 tok/s. Kasutajad hindavad viimast palju rohkem. kogemuse voolavus et hüpoteetilist kvaliteedi paranemist oleks raske tajuda.

Kohanda OLLAMA_KEEP_ALIVE ja laaditud mudeli strateegiat

Parameeter OLLAMA_KEEP_ALIVE määrab, kui kaua Ollama mudelit pärast viimast päringut mälus hoiab. Võimalikud väärtused:

• 0See laaditakse kohe pärast vastuse valmimist. See säästab mälu, kuid pikendab laadimisaega.
• X m (nt 5m, 15m): Tasakaalustab RAMi/VRAMi ja paindlikkust. Ideaalne teenustele, kus esineb aeg-ajalt esinevaid hüppeid.
• -1Mudel jääb laadituks, kuni teenus on aktiivne. Väga kasulik teie SaaS-i lipulaevamudelite jaoks.

Mitme kasutajaga stsenaariumis toimib see tavaliselt hästi, et säilitada üks või kaks baasmudelit on alati laaditud (näiteks generalist 14B ja koodipõhine) ning laadige ülejäänud alla pärast mõneminutilist tegevusetust.

Keskkonnamuutujate ja mudeliteede kontroll

Ollama võimaldab teil oma käitumist kohandada erinevate keskkonnamuutujatega, mis mõjutavad ressursside ja juurdepääsu haldamist:

• AHJUMUDELID: tee, kuhu mudelid salvestatakse. Kasulik nende saatmiseks spetsiaalsele suurema mahutavusega kõvakettale/SSD-le.
• OLLAMA_HOSTAPI liides ja port (vaikimisi 127.0.0.1:11434). Kui avate selle kohtvõrguga (LAN), piirake juurdepääsu tulemüüriga.
• OLLAMA_ORIGINSCORS väliste veebikasutajaliideste jaoks (Open WebUI, kohandatud paneelid jne).
• OLLAMA_DEBUG: silumisrežiim mudeli laadimise, GPU tuvastamise, CUDA/ROCm vigade jms üksikasjalike logide kuvamiseks.

Linuxis konfigureeritakse need parameetrid tavaliselt kasutades systemd (Koos systemctl edit ollama.service), samas kui Windowsis ja macOS-is on need määratud süsteemi- või kasutajakeskkonna muutujatena.

Jälgimine ja logid

Klastris peate selgelt aru saama, mis igas sõlmes toimub. Selleks tehke järgmist.

• Linuxis kasutage journalctl -u ollama teenuselogide jälgimiseks. Koos -f Sa näed seda reaalajas.
• Täiendage nvidia-smi või samaväärne AMD-s, et vaadata videomälu, graafikakaardi koormust ja energiatarbimist.
• Kui suhtud SaaS-i tõsiselt, integreeri oma jälgitavuspinu mõõdikud (tokenid/märgid, järjekorrad, vead).

Mudeli peamise protsessorikoormuse või järjekordade kinnijäämise varajane tuvastamine säästab klientidega palju vaeva; ja tööriistad selleks leidke oma kohaliku võrgu IP-aadress Nad saavad aidata sõlmede inventuuriga.

Mudelite valik ja tüüpilised kasutusjuhud Ollamas

Kõige eelnevaga on teine ​​​​sammas tulemuslikkuse seisukohalt vali iga ülesande jaoks õige mudelmitte ainult "täiskiirusel liikumiseks", vaid ka tarbimise ja latentsuse kontrollimiseks.

Üldise vestluse ja assistentide mallid

Vestluste, toe, meilide kirjutamise, kokkuvõtete ja üldiste ülesannete jaoks sobivad mallid, näiteks:

• Qwen3 14BSuurepärane juhiste jälgimine ja hea kiirus 100% GPU kasutuse korral.
• Mistral 3 14B: keelekvaliteedi ja jõudluse poolest väga tasakaalustatud.
• Gemma ja laama 3.x 7-14B konfiguratsioonides: head üldised valikud vähem nõudlikele kasutajatele või lihtsamale riistvarale.

Nende Q4_K_M ja 8K-16K kontekstis olevate tooteperedega on teil enamiku professionaalsete kasutajate jaoks kindel alus ilma VRAM-i ülekoormamata.

Kodeerimise ja arenduse mudelid

Koodi genereerimise, ülevaatamise ja arendusülesannete jaoks on soovitatav valida konkreetsed mudelid:

• qwen3-kooder:30b: tugev programmeerimises ja tööriistades, kuigi osa mudelist lõpeb protsessoriga, millel on 16 GB videomälu.
• DeepSeek-kooder, CodeLlama ja muud koodivariandid väiksemate suuruste jaoks, kui soovite rohkem kergust.

Kui kavatsete pakkuda "arendajaplaane", kaaluge sõlme, millel on rohkem kui 16 GB videomälu et neid mudeleid mahutada ilma protsessori liigset koormust tekitamata.

Multimodaalsed mudelid ja visioon

Teksti ja pilti kombineerivate ülesannete (ekraanipiltide analüüs, skannitud dokumendid jne) puhul on märgistatud mudelid Vision (llava, moondream, bakllava, qwen-vl…) on need, mis peaksid kokku panema. Siin on:

• VRAM-i tarbimine suureneb ja märgi kiirus on tavaliselt madalam.
• Soovitav on piirduda konkreetsete ülesannetega ja mitte segada neid paljude kasutajatega intensiivse vestlusega.

Kui teil on segatud GPU-de paraad (näiteks 5070 + 5060 + 4060, kokku 48 GB videomälu), võib olla huvitav pühendada üks kaartidest visuaalsetele mudelitele ja teine ​​puhtale tekstile, vältides ühe seadme ülekoormamist kõigega.

Installi-, juurutamis- ja teostusvariandid (natiivne, Docker, konteinerid)

Operatiivsel tasandil saab Ollamat installida mitmel viisil: natiivselt Windowsi, macOS-i või Linuxi keskkondadesse või konteineritesse (Podman, Docker…).

Näiteks Linuxis saate llama.cpp faili juurutada GPU-le optimeeritud konteinerisse:

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

Seda tüüpi juurutamine võimaldab teil eraldi Ollama, llama.cpp ja muud tööriistad konteinerites kontrollige versioone ja isoleerige ressursse teenuse (ja soovi korral ka kliendi) kaupa.

Kallistavate Nägude Mudelite Haldamiseks GGUF-is või Safetensorsis saate kasutada selliseid tööriistu nagu rust-hf-allalaadija ja seejärel importige need Ollamasse, kasutades Modelfailidkus lisaks haldamisele defineerite FROM, TEMPLATE, vaikeparameetrid ja viibasüsteemi sünkroniseerimine ja kohalikud varukoopiad artefaktidest, kui töötate mitme sõlmega.

Kui tükid on kokku pandud, on ülejäänu juhtimisotsused: milliseid mudeleid millistele klientidele pakkuda, milliste kontekstipiirangutega ning milline on uuenduste ja kvantifitseerimise poliitika, et mitte rikkuda ühilduvust ega oodatavat jõudlust.

Kui olete kindel, et prioriteet on see, et mudelid mahuksid täielikult VRAM-i, et kvantiseerimine jääks mõistlikule tasakaalule (Q4_K_M) ja et kontekst ei ületaks teie riistvara taluvust, siis seadistage Ollama privaatne SaaS keskmise suurusega klastris See lakkab olemast ulme ja muutub mõistlikuks investeeringuks: maksad GPU-de eest seal, kus need tegelikult panustavad, hoolitsed RAM-i eest, et toetada aeg-ajalt allalaadimisi, ja kasutad orkestreerimistööriistu (Ollama, llama.cpp, konteinerid, Open WebUI), et pakkuda oma klientidele "privaatse ChatGPT" kogemust, kuid oma reeglitega ja ilma pilvest sõltumata.