Egy rövid kérdésre adott gyors válasz azt mutatja, hogy a helyi nyelvi modell alapvetően működik. Az infrastruktúráról szóló döntéshez sokkal többet mond a későbbi feladatokat és azok tényleges terhelését vizsgáló teszt. Ide tartozik a válaszok minősége, a várakozási idő, a hosszabb bemenet, az egyidejű használat és a hiba utáni működés.
A pilotprojekt különösen hasznos, ha előre tisztázott, milyen döntést kell lehetővé tennie az eredménynek. Például: elegendő a meglévő környezet, más hardver kell, vagy egy külső, illetve hibrid szolgáltatás alkalmasabb? A teszttervezés ezt a kérdést követi.
Kis, reprezentatív feladatkészlettel érdemes kezdeni
A megfelelő tesztfeladatok a tervezett munkafolyamatból származnak: rövid szakmai kérdés, hosszabb jóváhagyott dokumentum összefoglalása vagy ellenőrizendő szkripttervezet. Minden feladathoz meg kell határozni, miről ismerhető fel a használható eredmény.
Tudáskérdéseknél a várt forrásokat és a megfelelő alap nélküli eseteket is vizsgálni kell. A kód szakmai ellenőrzést és megfelelő teszteket igényel. Bizalmas eredeti adat csak az erre jóváhagyott környezetben használható; az előkészítéshez megfelelően tisztított vagy külön létrehozott tesztadat is elegendő lehet.
A minőséget és a sebességet külön kell értékelni
A gyorsan hibás eredményeket adó modell nem teljesíti a célt. Ezért először a szakmai használhatóságot, a szükséges javításokat és a hiányzó információk kezelését értékeljük. Ezután hasonlítható össze az e minőség eléréséhez szükséges válaszidő és ráfordítás.
Rögzíteni kell a modellverziót, kvantálást, inferenciaszoftvert, beállításokat és tesztadatokat. Különben a gyorsabb válasz megváltozott feladatból vagy más minőségi szintből eredhet. A változó dokumentumállomány a RAG-alkalmazás összehasonlítását is befolyásolhatja.
A várakozási idő felbontása
- Az első tokenig eltelt idő
- Azt mutatja, mikor kezdődik a kimenet. A sorban állás és a bemenet feldolgozása befolyásolhatja. Emellett az alkalmazásbeli elküldéstől a látható válaszig érzékelt időt is mérni kell.
- Folyamatos kimenet
- A generálás sebessége befolyásolja a hosszabb válasz elkészülését. A szerver nagy összesített átbocsátása önmagában nem mondja meg, milyen gyorsan kap választ az egyes felhasználó.
- Teljes időtartam
- Az egész alkalmazásműveletet lefedi. Hozzáadódhat a keresés, dokumentum-előkészítés, eszközhívás és hálózati útvonal ideje.
- Szóródás és hibák
- A jellemző értékeket a lassabb szélső esetekkel együtt kell vizsgálni. A mérések száma, időtúllépések és megszakított feladatok az eredmény részei.
A hivatalos vLLM-metrikadokumentáció (külső hivatkozás) többek között várakozási, bemeneti és kimeneti méréseket különböztet meg. Az adott futtatókörnyezet metrikáit a használt verzióhoz kell ellenőrizni. A különböző összetevők mérési adatainak ugyanazt az időszakot és feladatot kell leírniuk.
Rövid beszélgetések, hosszú kontextusok és párhuzamosság tesztelése
A hosszú kontextus további feldolgozást és memóriát igényel. Az egyidejű kérések megosztják a rendelkezésre álló erőforrásokat. Az Ollama kontextusdokumentációja (külső hivatkozás) és a vLLM optimalizálási dokumentációja (külső hivatkozás) ismerteti ezeket az összefüggéseket; a konkrét beállítások verzió- és hardverfüggők.
Az értelmes teszt ezért rövid és hosszabb bemeneteket kombinál a tervezett használatnak megfelelő párhuzamossággal. Az egyenletesen érkező kérések mellett a várható csúcsokat is vizsgálja. Ha a kötegelt feldolgozás növeli az átbocsátást, továbbra is ellenőrizni kell, megfelelnek-e az egyes válaszidők a felhasználóknak.
Egy lehetséges tesztterv
Először ugyanazokat a szakmai feladatokat egyenként kell végrehajtani. Utána rövid kéréseket és jóváhagyott dokumentumfeladatokat együtt tesztelni. Ezután a várható csúcsidőszakot kell modellezni, és megfigyelni a túlterhelési viselkedést. A célértékeket előre egyeztetni kell a felhasználókkal.
Ez a terv testre szabható példa. Nem tartalmaz mért DAXS-teljesítményadatokat, és nem helyettesíti a konkrét környezet vizsgálatát.
Indítás, folyamatos működés és helyreállás megkülönböztetése
Újraindítás után előfordulhat, hogy előbb be kell tölteni a modellt. Ezt a hidegindítást a már betöltött modellel végzett működéstől külön kell mérni. A gyors NVMe-meghajtók segíthetik a betöltést és az adatműveleteket; ebből nem következik a tokengenerálás általános gyorsulása egy teljes egészében GPU-memóriában tárolt modellnél.
A pilotprojekt része a kapcsolat elvesztése, egy feladat megszakítása és egy szolgáltatás újraindítása is. Az alkalmazásnak érthetően kell jeleznie az állapotát, és észszerű újrapróbálási vagy átadási utat kell kínálnia. Túlterhelés nem vezethet észrevétlenül hiányos eredményekhez.
Az eredményekből architekturális döntés születik
A használható eredményeket, javítási ráfordítást, késleltetést, kapacitást és folyamatos üzemeltetést hasonlítjuk össze. A teljes költséghez az adminisztráció, karbantartás, energia, mentés és szükséges rendelkezésre állás is hozzátartozik. Külső szolgáltatásnál hozzáadódik a tényleges használati díj és az egyeztetett adatútvonal.
Az eredmény lehet kisebb, megfelelő modell, további erőforrás, korlátozott várakozási sor vagy más üzemeltetési modell. A helyi, külső és hibrid megoldásokat ugyanazon feladaton értékeljük. A pilotprojekt célja a következő megalapozott döntés lehetővé tétele, nem egy előre feltételezett hardvervásárlás utólagos igazolása.
A DAXS megtervezi a tesztet, kialakítja a megfelelő környezetet, és az Önök IT-csapatával értékeli az eredményeket. A műszaki alapokat a helyi LLM-ekről és infrastruktúráról szóló szakoldalunkismerteti. Csatlakoztatott tudásállományoknál a keresés, források és jogosultságok minősége ugyanebbe a vizsgálati keretbe tartozik.