GGUF: ce e înăuntru, în afară de greutăți, și ce lipsește?
Despărțim GGUF în bucăți: de la headere la tokenizer — și găsim câteva găuri care strică viața.

Dacă ai descărcat vreodată un model LLM și ai oftat „încă un format, grozav”, atunci GGUF îți este familiar. Dar ce se ascunde de fapt în acest fișier, în afară de greutăți? Se pare că e o grădină zoologică de metadate, de la tipuri de date la informații despre tokenizer. Dar, ca în orice grădină zoologică, unele cuști sunt goale.
GGUF este evoluția lui GGML, creat pentru încărcarea comodă a modelelor fără dansuri în jurul focului. În interior: header, metadate (cheie-valoare) și tensori. Metadatele pot include de la numele modelului până la detalii despre tokenizare. Dar uite că standardul încă nu descrie o mulțime de lucruri importante — de exemplu, cum să stochezi informații despre adaptoarele LoRA sau cum să specifici corect arhitectura pentru modele custom. Dezvoltatorii se descurcă cum pot: unii bagă date în JSON în metadate, alții — în fișiere separate. Ironia: formatul care ar trebui să simplifice viața uneori o transformă într-un quest „ghicește arhitectura”.
Ce lipsește cu adevărat? În primul rând, o specificație clară pentru descrierea arhitecturilor — acum e un teren de creație la limita haosului. În al doilea rând, suport pentru checkpoint-uri de antrenare (da, GGUF e făcut pentru inferență, dar cine interzice să visezi?). Și în al treilea rând, un mod unitar de a stoca preprocesoare — fără asta, fiecare framework face magia lui, iar utilizatorul suferă.
Comentariul studioului METABYTE: GGUF e o idee excelentă, dar, ca orice standard tânăr, necesită ajustări. În proiectele noastre, preferăm să împachetăm modelele în containere universale, ca să nu ghicim ce tokenizer a fost folosit. Voi încă păstrați greutățile în Safetensors?
URMATORUL PAS
Ti-a placut abordarea?
Aplicam aceleasi principii in proiectele clientilor: AI, automatizari, produse care nu se sting dupa lansare.