A Hugging Face bejelentette, hogy a transformers keretrendszer immár képes hatékonyan betölteni és futtatni GGUF-formátumú, kvantizált modelleket Apple Silicon gépeken. A cél, hogy a helyi futtatás egyszerűbbé váljon: a Hubról kiválasztott GGUF checkpointot a megszokott from_pretrained API-val lehet betölteni, és azonnal generálásra használni a saját gépen.
Mi az a GGUF és miért fontos?
A GGUF-formátumot a llama.cpp csapat hozta létre; egy fájlban tárolja a modellsúlyokat, a tokenizáló metaadatait és opcionálisan chat-sablonokat. Támogat különböző kvantizációs szinteket, így a felhasználó memóriakorlátaihoz igazítható a modell pontosága és mérete. Például az Unsloth által publikált Qwen3.5-4B modell különböző kvantizációs variánsainak fájlméretei:
- BF16 (nativ, nem kvantizált): 8.42 GB
- Q6_K: 3.53 GB
- Q5_K_M: 3.14 GB
- Q4_K_M: 2.74 GB
A cikk szerzői javaslata szerint érdemes Q4_K_M-mel kezdeni, majd ha több memóriánk van, kipróbálni Q5_K_M vagy Q6_K verziókat. A Hub GGUF dokumentációja részletezi a kvantizációs opciókat.
Hogyan lehet betölteni GGUF modellt transformers-szel?
A működés elindításához szükséges környezet:
- Apple Silicon (Mac).
- PyTorch verzió, amely kompatibilis a publikált ggml-quantization kernel buildjeivel (általában a két legfrissebb PyTorch kiadás).
- A transformers legújabb forrás-verziója (jelenleg main), és egy hozzáillő kernels build.
A Hubon tárolt modell azonosítóját és a GGUF fájl nevét gguf_file argumentummal kell megadni a from_pretrained hívásban. Ha a súlyok Metal-en maradnak „packed” formában, a transformers automatikusan betölti a kompatibilis ggml/Metal layer kerneljeit és a ggml-org/ggml-attn implementációt használja az attentionhoz. Ha a szükséges kernel nem érhető el, visszaesés történik az "sdpa" megoldásra egy figyelmeztetéssel; ezt explicit módon is kérhetjük attn_implementation="sdpa" átadásával.
A betöltés után a generálás a szokásos transformers API-kat használja: a tokenizálás, a generate hívás és a dekódolás ugyanúgy működik, mint bármely más AutoModelForCausalLM-alapú munkamenetben. Fontos megjegyezni, hogy kernel hiányában a loader dequantizálhatja a modellt, ami több memóriát igényel.
Szervírozás és kliensek
Ugyanezt a GGUF checkpointot a transformers serve parancs segítségével is ki lehet szolgálni, amely OpenAI-kompatibilis HTTP API-t nyújt. A model argumentum formátuma <model_id>:<filename>.gguf, így egy repositoryban több kvantizációs fájl közül lehet konkrétan választani. A szerver indításához a transformers[serving] és a kernels telepítése szükséges.
OpenAI-kompatibilis kliensekkel, például Jan vagy Pi, a helyi endpoint összeköthető: a kliens adja a beszélgetési felületet, míg a transformers a modellt futtatja a Macen.
Teljesítmény és összehasonlítás a llama.cpp-vel
A referencia a helyi inferencia teljesítményére a llama.cpp. A cikkben szereplő összehasonlítás három GGUF checkpointot vizsgált: egy kis sűrű modellt, egy nagyobb sűrű modellt és egy mixture-of-experts (MoE) modellt. A llama.cpp oszlop adatai a llama-bench eszközből származnak (build 5f55650a7, release b10200, Metal backend ggml 0.18.0), futtatva a llama-bench -m <file> -p 0 -n 128 -r 3 paranccsal, és a tg128 értéket (128 tokenre számított generálási sebesség, 3 ismétlés átlaga, prompt nélkül) mutatja.
A transformers mérése a generate-ből származik, amely ugyanazon 128 tokent generálta egy 12 tokenes promptból, három bemelegített futás legjobb eredményét mutatva, és ez tartalmazza a prefill lépést is. A mérés MacBook Pro M2 Max rendszeren készült, 32 GB unified memóriával, macOS 26.6, PyTorch 2.12.1, kernels 0.17.0 beállításokkal, hálózati áramforrás csatlakoztatva.
Az eredmények szerint a transformers közelíti a llama.cpp teljesítményét mindhárom ellenőrzőpont esetén; a mérések összevetésekor figyelembe kell venni, hogy a transformers mérés tartalmazza a prefillt, míg a llama-bench csak a dekódolást méri.
Műszaki megoldás: ggml Metal kernlek és generate optimalizációk
A teljesítményjavítás két fő irányból érkezett:
- ggml Metal kernel-ek újrafelhasználása
A kernels könyvtár segítségével kompatibilis buildjeit terjesztik ggml Metal kernel-eknek a Hubon, amelyeket a transformers hívhat. Ezek a specializált kernlek képesek közvetlenül olvasni a tömörített, kvantizált súlyokat, illetve egyes műveleteket fuzionálni, csökkentve a GPU-műveletek mennyiségét. A cikkben felsorolt kernel csomagok:
- ggml-quantization: csomagolt kvantizált súlyok olvasása, beleértve az MoE modell kiválasztott szakértőit.
- ggml-norm: normalizációs műveletek fuzionálása (pl. zero-centered RMSNorm Qwen modellekhez).
- ggml-attn: ggml Metal flash attention prompt feldolgozáshoz és token dekódoláshoz.
- ggml-gated-delta-net: a Qwen3.5/3.8 hibrid architektúrák lineáris-attention rétegéhez gyorsítás.
- topk: saját Metal implementáció az MoE top-k routing problémájának gyors kiválasztására.
Ezek együttesen csökkentik a generáláshoz szükséges GPU-munkát.
- A generate hívás csökkentett szinkronizációja
A szerzők két lényeges optimalizációt vezettek be a generate környékén, amelyek nem csak a GGUF esetén hasznosak:
- Felesleges attention-maszk eltávolítása korán: ha egy támogatott decoder-only inputnál nincs padding, az all-ones padding maskát eltávolítják a generálás elején, így a downstream attention kód nem vizsgálja ismételten a maszkot.
- A megállási feltétel ellenőrzésének deferálása: a generate aszinkron módon másolja a megállási döntést és a következő lépésben dolgozza fel, így a CPU közben tovább tudja időzíteni a GPU munkáit és csökkenthető a visszarántás miatti várakozás. Ez a módszer streaming tokeneknél is alkalmazható.
E kombinációk: a kernlek csökkentik az egy művelet költségét, míg a generate módosításai növelik a CPU és GPU átfedését — együtt jobb végrehajtási hatékonyságot eredményeznek.
Current limitations és további fejlesztések
A bevezetés jelenlegi korlátai:
- A packed (csomagolt) inferencia út MPS-only (Metal Performance Shaders) a jelenlegi célplatformon.
- A GGUF import dequantizációval továbbra is külön opció marad; a formátum támogatása nem jelenti automatikusan, hogy a packed kernlek minden eszközön elérhetők.
- Padding és batching terén további munkára van szükség: az unpadded inputok profitálnak az optimalizációból, a padolt batch-ek jelenleg nem vehetik igénybe ugyanazt a gyorsítást. A tervek között szerepel a generate_batch támogatás MPS-en.
- Az architektúra-támogatás kezdetben a Qwen3.5 sűrű és MoE architektúrákat, valamint kompatibilis Qwen3.8 checkpointokat fedi le; további architektúrák támogatása fokozatosan bővül.
Ha valaki olyan GGUF modellt használna, amelyet szeretne a transformers-ben futtatni, a szerzők azt javasolják, hogy nyisson egy issue-t a checkpoint és a használati eset megadásával, így priorizálni tudják a támogatást.
Mire jó ez a fejlesztés a fejlesztőknek?
A GGUF betöltése transformers-be több gyakorlati előnnyel jár:
- Kísérletezés Python/PyTorch környezetben: ellenőrizhetők köztes aktivációk, módosítható a forward pass, és prototípusként használhatók egyedi rétegek a megszokott PyTorch eszközökkel.
- Értékelés: meglévő transformers értékelési munkafolyamatokkal mérhetők a kvantizált checkpointok minőségi különbségei.
- Konverzió validálása: az eredeti checkpoint és a GGUF konverzió betöltése segít ellenőrizni, hogy a kvantizáció hibája elfogadható-e.
- Új dekódolási ötletek tesztelése: egyéni logits processorok, megállási kritériumok vagy akár saját generálási ciklus írása Pythonban.
- Finomhangolás GGUF-ból: a súlyok dequantizálásával folytatható a hagyományos transformers oktatási munkafolyamat; a példában GgufConfig(dequantize=True) használatát mutatják.
Köszönetnyilvánítás
A munkát Arthur Zucker kezdeményezte és több PR-t is véleményezett; Cyril Vallez jelentős generate PR-okat készített. További köszönet illeti Sayak Paul-t, a llama.cpp csapatot és Bertrand Chevalier-t a kernel integrációban nyújtott segítségért, valamint Aritra Roy Gosthipaty-t és Pedro Cuenca-t a poszt véleményezéséért. Lysandre Debut felügyelete alatt zajlott a projekt.
Összefoglalva: a transformers GGUF-támogatása közelebb hozza a llama.cpp hatékonyságát és a transformers flexibilitását, különösen Apple Siliconon, és megnyitja az utat a gyorsabb helyi inferencia és további architektúrák támogatása felé.
