Helyi LLM-ek.
Megfelelően méretezve.
A megfelelő modelltől a támogatott MI-szolgáltatásig: a DAXS helyi LLM-infrastruktúrát tervez, valós terhelésen ellenőrzi a hardvert, és a megoldást a meglévő informatikájába integrálja.
Az MI-szerver a terhelési profillal kezdődik.
A helyi nyelvi modell belső szövegeket dolgozhat fel, kódvázlatokat támogathat, vagy tudáskeresés részeként működhet. A használható megoldáshoz a modellminőségnek, engedélyezett adatútvonalaknak és várható használatnak összhangban kell lennie. A DAXS felméri ezeket a követelményeket, megtervezi az infrastruktúrát, és ellátja a telepítést, integrációt és megállapodott üzemeltetést, az Ön IT-részlegével közösen vagy körülhatárolt szolgáltatási elemként.
Feladat és minőség
Milyen kérdéseket, nyelveket, dokumentumokat vagy kódfeladatokat kell kezelnie a megoldásnak? A rövid csevegés és hosszú dokumentumok elemzése eltérő modelleket és kontextusokat igényel.
Használat és várakozási idő
Hány kérés érkezik egyszerre? Milyen gyorsan kell elkezdődnie az első reakciónak, és mennyi ideig tarthat a teljes válasz? Az alkalmi egyedi kérések és a folyamatosan használt csoportszolgáltatás eltérő tartalékokat igényelnek.
Adatok és üzemeltetés
Mely források és funkciók engedélyezettek? Hol lehet a modell, keresőindex, napló és mentés? Ki kezeli a frissítéseket és hibákat, és milyen visszaállási út szükséges?
Alkalmazás, következtetés és üzemeltetés rendezett összekapcsolása.
A felhasználói felület csak egy rész. Előtte identitás- és hozzáférés-ellenőrzések működnek; mögötte a következtetési szolgáltatás, modelltár és adott esetben tudáskeresés vagy vállalati interfészek dolgoznak. A megfigyelés, frissítés és helyreállítás ugyanannak a tervnek a része.
Az ábra egy lehetséges architektúrát mutat be. A reverse proxy védheti a TLS-kapcsolatot és a belépési pontot. Az alkalmazásnak emellett érvényesítenie kell a felhasználói jogokat. A modell-API-kat a szükséges hálózatokra és funkciókra korlátozzuk; egy elérhető következtetési port önmagában még nem kész vállalati szolgáltatás.
Több a modellfájl méreténél.
A kiválasztáshoz a súlyokat, futtatási igényt, kontextust, párhuzamosságot és teljes adatútvonalat vizsgáljuk. A GPU memóriája elegendő lehet, miközben a kívánt válaszidőre mégsem alkalmas. Fordítva: egy kisebb, jól kiválasztott modell gazdaságosabban oldhatja meg a feladatot.
| Összetevő | Mit ellenőrzünk | Miért számít |
|---|---|---|
| GPU és VRAM | Architektúra, illesztőprogramok, következtetési backend, támogatott számformátumok, memóriaméret és sávszélesség. | A súlyoknak és KV-cache-nek hely kell. A számítási kapacitás és memóriaátvitel eltérő munkafázisokat befolyásol; egy hirdetett TOPS-érték önmagában nem írja le az alkalmazást. |
| Egy vagy több GPU | A modell felosztása, GPU-k közötti kapcsolat, PCIe-csatlakozás, energia és hűtés. | A VRAM nem válik automatikusan szabadon használható közös memóriává. A felosztást és szinkronizációt a választott szoftverkörnyezetnek támogatnia kell; további GPU-k új szűk keresztmetszeteket is létrehozhatnak. |
| CPU és rendszermemória | Futtatókörnyezet, tokenizálás, adatelőkészítés, párhuzamos folyamatok, adott esetben CPU-s következtetés vagy offloading. | A tehermentesítő kihelyezés futtathatóvá tehet egy modellt, de megváltoztatja a teljesítményprofilt. A RAM és GPU közötti átvitel lassíthatja a választ. A GPU-szervernek is megfelelő CPU- és RAM-tartalékra van szüksége. |
| NVMe és tárolás | Modellverziók, betöltési idők, keresőindex, importadatok, naplók, szabad kapacitás és mentések. | A gyors NVMe-SSD-k segítik a modellbetöltést és bizonyos adatműveleteket. A teljesen GPU-memóriában lévő modell tokenelőállítását főként számítási, memória- és futtatási tényezők határozzák meg. |
| Hálózat és ellátás | Kapcsolat, engedélyezett adatútvonalak, hely, áramigény, hőleadás és karbantartási hozzáférés. | A legjobb önálló számítási komponens is keveset segít, ha valós terhelés alatt hőmérsékleti, szervezeti vagy adathozzáférési korlátok akadályozzák a szolgáltatást. |
Számítási segédlet, nem vásárlási ajánlás.
A súlyok puszta alsó memóriaigénye durván a paraméterszám × bit súlyonként ÷ 8 képlettel becsülhető. Egy elméleti, nyolcmilliárd paraméteres modell súlyonként négy bittel számítva négy gigabájtot, azaz körülbelül 3,73 GiB-ot ad.
Ehhez kvantálási metaadatok, esetleg nagyobb felbontású modellrészek, KV-cache, munkaterületek és futtatókörnyezet járulnak. Ez az érték ezért kifejezetten nem mondja meg, mekkora VRAM elegendő az alkalmazásához. Szakértői architektúrájú modelleknél az aktív számítási részt és az összes készen tartandó súlyt is meg kell különböztetni.
A rövid válasz más teszt, mint a csoportszolgáltatás.
A kontextusablak azokat az információkat fogja át, amelyeket a modell egy kéréshez figyelembe vehet. Az alkalmazástól függően utasítások, beszélgetési előzmények, visszakeresett dokumentumrészek és a tervezett kimenet tartoznak ide. A névlegesen nagy kontextusablak sem megfelelő hardvert, sem megbízható információhasználatot nem garantál.
KV-cache
A Key-Value-cache a figyelmi mechanizmus köztes állapotait tárolja. Igénye többek között a modellarchitektúrától, adattípustól, ténylegesen foglalt kontextustól és egyidejűleg aktív szekvenciáktól függ. A több kontextus és nagyobb párhuzamosság gyakran jelentősen növeli a memóriaigényt.
Prefill és decode
A prefill során a modell feldolgozza a bemeneti kontextust; decode közben további tokenek keletkeznek. A két fázis eltérően terheli a hardvert. A hosszú dokumentumok növelhetik az első tokenig eltelt időt, akkor is, ha a későbbi kimenet folyamatosnak tűnik.
Kötegelt feldolgozás és várakozási sor
A közös feldolgozás növelheti az összesített áteresztőképességet. Eközben egyes felhasználók hosszabban várhatnak. A lefoglalt kapacitás, várakozási sorok, korlátok és párhuzamosság megfelelő tervezése ezért a megoldás része.
A tényleges felhasználási esetet mérjük.
A pilot jellemző rövid és hosszú kéréseket, valamint egyidejű hozzáféréseket tartalmaz. Ennek során vizsgáljuk az első tokenig eltelt időt, a teljes válaszidőt, kimeneti sebességet, várakozási sort, hibaarányt és memóriafoglalást. A másodpercenkénti tokenszám csak a modellverzió, kvantálás, kontextus, terhelés és mérési feltételek ismeretében hasonlítható össze értelmesen.
A szoftverkörnyezet a modellhez és használathoz igazodik.
Az Ollama, llama.cpp és vLLM lehetséges összetevők. A kiválasztás és konfiguráció a modelltámogatáshoz, hardverhez, kívánt párhuzamossághoz, üzemeltetéshez és integrációhoz igazodik. A konkrét verziót ellenőrizzük, ahelyett hogy egy általános telepítési parancsot éles architektúrának tekintenénk.
Ollama
Lehetséges belépési pont modellkezeléshez és helyi szolgáltatáshoz. A modelltárnak, engedélyezett modelleknek, kontextusnak, párhuzamosságnak és szolgáltatásvédelemnek illeszkednie kell a környezethez.
llama.cpp
Rugalmas összetevő megfelelő modellekhez különféle CPU-/GPU-backendeken, kvantált formátumokkal és szerverüzemmel. A hardvertámogatást, felosztást és ténylegesen szükséges API-funkciókat gyakorlatban ellenőrizzük.
vLLM
Lehetőség megfelelő szerveroldali következtetési és terhelési profilokhoz. Az ütemezést, KV-cache-t, kötegelt feldolgozást és adott esetben több GPU-t együtt hangoljuk össze. A nagyobb összesített áteresztőképesség nem jelenti minden egyes kérés rövidebb várakozását.
Konténer, virtuális gép vagy saját host?
A konténerek reprodukálhatóan foghatják össze a szoftververziókat. A virtuális gép szervezetileg és műszakilag is tovább határolhatja a környezetet. A megfelelő út az eszközátadástól, illesztőprogramoktól, karbantartástól és meglévő üzemeltetési eljárásoktól függ. A kompatibilis API megkönnyíti a csatlakozást, de nem helyettesíti az alkalmazásával végzett működési tesztet.
Mikor megfelelő a Proxmox GPU-passthrough-val?
A GPU-passthrough egy megfelelő fizikai GPU-t rendel egy virtuális géphez. Ehhez többek között a platformnak és firmware-nek, IOMMU-csoportoknak, host- és vendégillesztőprogramoknak, valamint az eszköz visszaállítási viselkedésének kell megfelelnie. A konkrét kombinációt a vállalás előtt ellenőrizzük.
A hozzárendelt GPU nem osztható automatikusan rugalmasan több VM között. A vGPU és a közvetlen eszközátadás eltérő megközelítés, saját feltételekkel és esetleges licencelőírásokkal. A karbantartáshoz, mentéshez és lehetséges hostváltáshoz is megfelelő folyamat kell; általános élőmigrációs ígéret nem lenne helyénvaló.
Infrastruktúra és virtualizáció · Proxmox-migráció értékelése
A megfelelő modellnek teljesítenie kell a feladatot.
A modelleket a későbbi használat jóváhagyott példáival hasonlítjuk össze: például német nyelvű szakmai kérdésekkel, dokumentumrészletekkel, többnyelvű kérésekkel vagy konkrét szkriptfeladattal. A kódolási modell és az embedding-modell eltérő feladatokat lát el. Tudáskereséshez a keresésnek, embeddingeknek és válaszmodellnek illeszkednie kell egymáshoz.
A kvantálás gyakran csökkenti a memóriaigényt. A válaszminőségre, eszközhívásokra és sebességre gyakorolt hatását a választott formátummal ellenőrizzük. A nagyobb modell nem automatikusan jobb vagy gazdaságosabb. A hosszú maximális kontextus sem bizonyítja, hogy a modell minden benne lévő információt megbízhatóan használ.
- Licenc: a kiválasztott modellsúlyok, kereskedelmi használat, továbbadás és szükséges megjegyzések konkrét ellenőrzése; az egyszerű letöltés nem helyettesíti ezt.
- Verzió: a modell, kvantálás, tokenizer és futtatókörnyezet követhető rögzítése.
- Átvétel: a szakmai alkalmasság, nem megengedett válaszok, nyelvi minőség és hibaesetek vizsgálata megismételhető kérdéskészlettel.
- Változtatások: az új modellverziók előzetes tesztelése, használható visszaállási út megőrzése, valamint a keresőindexek megfelelő újragenerálása megváltozott embeddingek esetén.
Helyben, külső szolgáltatással vagy megfelelő kombinációban.
A saját hardver megfelelő kihasználtság, világos adatkövetelmények és meglévő üzemeltetési keretek mellett lehet célszerű. A külső szolgáltatás ingadozó használatnál, különleges modellképességeknél vagy korlátozott saját üzemeltetési kapacitásnál illeszkedhet jobban. A hibrid megoldás célzottan körülhatárolt feladatokat és adatútvonalakat kapcsol össze.
Az összehasonlítás a beszerzést vagy használatot, áramot és hűtést, licenceket, integrációt, frissítéseket, támogatást, tartalékokat és kiesési következményeket fogja át. A helyi feldolgozás nem automatikus biztonsági vagy GDPR-garancia: a modelleknek, embeddingeknek, telemetriának, frissítéseknek, külső eszközöknek és naplóknak is illeszkedniük kell az egyeztetett adatkoncepcióhoz.
Először jól körülhatárolt pilotot tervezünk mérhető követelményekkel. Ennek eredményéből születik döntés bővítésről, módosításról vagy egyszerűbb alternatíváról. További alapok itt: Felhő és SaaS.
A támogatott szolgáltatáshoz átlátható felelősségek kellenek.
A DAXS hardvert és szoftvert tervezhet, telepíthet, meglévő identitásokhoz és alkalmazásokhoz kapcsolhat, valamint elláthatja a megállapodott folyamatos üzemeltetést. Ide tartozik az elérhetőség és erőforrások megfigyelése, verziókarbantartás, hibakezelés és dokumentáció. A szükséges rendelkezésre állásról és reagálási útvonalakról konkrétan állapodunk meg.
Meghatározzuk, mely konfigurációkat, alkalmazáskomponenseket, indexadatokat és adott esetben módosított modelleket mentjük. Az újra beszerezhető modellsúlyok és védendő üzemi adatok mentési követelményei eltérők. A helyreállítási teszt a megfelelő üzemeltetési koncepció része.
Követelményfelmérés, architektúrajavaslat, modell- és terhelési teszt, dokumentált adatútvonalak és követhető ajánlás a hardverre, üzemeltetési formára és következő integrációs lépésekre.
Ezeket a beszélgetésben tisztázzuk.
Mennyi VRAM kell egy helyi LLM-hez?
Ez a modelltől és kvantálástól, futtatókörnyezettől, kontextustól és egyidejű kérésektől függ. A modellfájl önmagában nem elegendő alap. A kívánt feladatot hosszú kérésekkel és terhelési csúcsokkal is teszteljük, mielőtt konkrét felszereltséget ajánlunk.
A második GPU automatikusan gyorsabb?
Nem. A választott szoftverkörnyezetnek támogatnia kell a felosztást. A GPU-k közötti kapcsolatok, szinkronizáció és modellarchitektúra befolyásolják az eredményt. A több memória lehetővé teheti a futtatást anélkül, hogy minden választ felgyorsítana.
Használható egy meglévő Proxmox-szerver?
Megfelelő lehet, ha a hardver, IOMMU-csoportok, illesztőprogramok és GPU-átadás alkalmasak. Emellett a más szolgáltatásokhoz szükséges tartalékoknak és a karbantartási, mentési és helyreállítási folyamatoknak is megfelelőnek kell lenniük. A meglévő platformot konkrétan ellenőrizzük.
A belső dokumentumokat betanítják a modellbe?
Tudáskereséshez ez gyakran nem szükséges. A RAG megfelelő, engedélyezett dokumentumrészeket keres, és kontextusként átadja a modellnek. A modellsúlyok módosítása más beavatkozás, amelyet külön indokolunk.
Mikor gazdaságosabb a külső szolgáltatás?
Alacsony vagy erősen ingadozó használat, különleges modellkövetelmények vagy hiányzó üzemeltetési kapacitás esetén a külső szolgáltatás illeszkedhet jobban. A költségeket, adatútvonalakat, minőséget és üzemeltetést a tervezett használati időszakra hasonlítjuk össze.
Modellek, terhelés és költségek együttes megfigyelése.
A GPU-kihasználtság és válaszidő mellett a használható feladatra jutó költséget is vizsgáljuk. A modellfrissítést használat előtt összehasonlítjuk a jóváhagyott tesztkészlettel. A hibaarányokhoz, várakozási sorokhoz, memóriakorlátokhoz és kiesésekhez megnevezett felelősök és visszaállási út szükséges. Külső helyettesítő szolgáltatás csak akkor jöhet szóba, ha az adatosztály és jóváhagyás ezt megengedi.
Beszéljük meg a felhasználási esetét.
Mi legyen egyszerűbb, milyen adatok érintettek, és milyen rendszerek vannak már? Ebből alakítunk ki ésszerű indulást és jól körülhatárolt következő lépést.