A beállítások többet számítanak, mint a helyi LLM-szerverek neve
A Mozilla.ai négy népszerű helyi LLM-szervert hasonlított össze Mac Studio M4-en, NVIDIA L40S-en és Steam Decken. A mérések szerint a teljesítményt sok esetben inkább a fordító, a grafikus beállítások és a spekulatív dekódolás paraméterei határozzák meg, mint az, hogy melyik kiszolgálót választja a felhasználó.
- A Mozilla.ai a llama.cpp, a llamafile, az LM Studio és az Ollama teljesítményét mérte.
- A konfiguráció több esetben nagyobb különbséget okozott, mint a szerverválasztás.
- A CUDA-grafikonok engedélyezése az L40S-en 16,8 százalékkal javította a llamafile dekódolását a 0.8B modellen.
- Az újabb Vulkan shadereszközök a Steam Decken akár 63,3 százalékos promptfeldolgozási javulást hoztak.
- A spekulatív dekódolás optimális vázlatmérete platformonként eltért.
Négy szerver, három eltérő környezet
A Mozilla.ai a llama.cpp, a llamafile, az LM Studio és az Ollama működését mérte saját exp-llama-benchy eszközével, amely a llama-benchy segítségével hasonlít össze különböző szervereket és platformokat. A teszt nem végleges rangsort állít fel, hanem azt vizsgálja, hogyan viselkednek ezek az eszközök azonos modellfájlokkal, eltérő hardveren.
A mérések egy 64 GB egyesített memóriával rendelkező Mac Studio M4 Maxon, Metal GPU-gyorsítással, egy 48 GB VRAM-mal felszerelt NVIDIA L40S rendszeren, CUDA használatával, valamint egy 16 GB megosztott memóriájú Steam Deck OLED modellen, Vulkan mellett zajlottak. A vizsgált modellek a Qwen3.5 0.8B és 9B, illetve a Qwen3.8 27B voltak. A 27B modellt a Steam Decken memóriahiány miatt nem tesztelték.
A promptfeldolgozást 1 024, 2 048, 4 096 és 8 192 tokenes bemenetekkel mérték. A szöveggenerálásnál 32 és 64 tokenes kimenetet vizsgáltak. Minden mérési pont 15 llama-benchy-futtatásból állt, az első bemelegítő futást eldobták, majd a két leggyorsabb és két leglassabb eredményt is kihagyták az átlagolásból.
A konfiguráció több esetben nagyobb különbséget okozott
A Mozilla.ai szerint mind a négy szerver ugyanarra az alapra épül: GGUF-fájlokat szolgálnak ki a llama.cpp alatt. Ez magyarázza, hogy azonos súlyok és környezet mellett a promptfeldolgozási eredmények gyakran csak néhány százalékkal tértek el. A különbségek jelentős része a beállításokból származott.
Az NVIDIA L40S rendszeren a llamafile CUDA-grafikonjainak engedélyezése a 0.8B modell dekódolási teljesítményét 16,8 százalékkal javította. A javulás a 9B modellnél 6,5, a 27B modellnél pedig 4,3 százalékos volt. A Mozilla.ai szerint a korábban használt llamafile CUDA-háttérben ezek a grafikonok nem voltak bekapcsolva.
A Steam Decken elsősorban a Vulkan árnyékfordítója számított. Ugyanabból a llamafile és llama.cpp commitból építve, de két különböző Vulkan shaderkönyvtárral a promptfeldolgozás 25,9 százalékkal javult a 0.8B, és 63,3 százalékkal a 9B modellnél. A dekódolás a 9B esetében 18,2 százalékkal lett gyorsabb, a 0.8B modellnél pedig 0,6 százalékkal romlott.
A tesztelők a spekulatív dekódolásnál sem találtak minden platformon működő legjobb beállítást. A Macen a 27B modellnél a két tokenes vázlatméret körülbelül 24, 25 token/másodperces sebességet eredményezett, míg a négyes beállítás nagyjából 15 token/másodpercre lassított a spekuláció nélküli 23,4 token/másodperchez képest. Az L40S-en ezzel szemben a négyes vázlatméret akár 16 százalékkal is gyorsabb volt a kettesnél.
A hardver határozza meg, hol látszik a különbség
A Mac Studio M4 Maxon a promptfeldolgozás a llama.cpp, a llamafile és az Ollama esetében minden vizsgált promptméretnél egymáshoz közeli volt, a különbség legfeljebb plusz-mínusz 3 százalékot tett ki. Az LM Studio eltérése a kisebb modelleknél jelent meg markánsabban.
Az L40S-en szintén közel álltak egymáshoz a promptfeldolgozási eredmények, a szerverek közötti eltérés inkább a tokenek generálásakor vált láthatóvá. A Mozilla.ai ezt részben állandó, gépen végzett többletköltséggel magyarázza. Ez tokenenként körülbelül 1,8 ezredmásodperc volt az L40S-en, 0,4 ezredmásodperc a Macen és 5,4 ezredmásodperc a Steam Decken. Ugyanaz az abszolút eltérés ezért a gyorsabb modelleknél nagyobb százalékos különbségként jelenik meg.
A Steam Deck produkálta a legnagyobb szórást. A llama.cpp és a llamafile a promptfeldolgozásban és a generálásban is megelőzte az Ollamát, az LM Studio pedig különösen a 9B modell generálásánál maradt el. A Mozilla.ai szerint ez az LM Studio által szállított futtatókörnyezet tulajdonsága, amelyet a felhasználó nem tud saját kezűleg javítani, mert az előre lefordítva érkezik.
Mit jelent ez a helyi modellek használóinak?
A mérés alapján a helyi LLM-eknél a szerver kiválasztása önmagában nem mondja meg, milyen teljesítményre számíthat a felhasználó. A GPU-gyorsítás módja, a fordító eszközei, a futtatókörnyezet verziója és a spekulatív dekódolás vázlatmérete ugyanazon modellen is jelentős eltérést okozhat.
A promptfeldolgozás főként hosszú dokumentumok, nagy kódbázisok, ügynöki feladatok és hosszú beszélgetési előzmények esetén fontos. A tokenenkénti generálási sebesség inkább interaktív csevegésnél számít, amikor a felhasználó a válasz megjelenésére vár. A Mozilla.ai eredményei ezért gyakorlati összehasonlításként szolgálnak, és azt mutatják, hogy a helyi futtatás optimalizálásakor a környezethez illő beállítások keresése legalább olyan fontos, mint maga a választott szerver.
