Az Aleph Alpha bemutatta, hogyan tervezték a Kolibri architektúráját
Az Aleph Alpha részletes elemzésben mutatja be, hogyan befolyásolják a nyelvi modellek architekturális döntései a tanítás és a használat költségeit. A kutatás a Kolibri modell kialakításán keresztül vizsgálja a paraméterek, a számítási műveletek és a sorozatállapot elosztását.
- Az Aleph Alpha a Kolibri architektúrájának költségbeli kompromisszumait elemzi.
- A vizsgálat a paraméterekre, a FLOP-számra és a sorozatkeverő állapotára koncentrál.
- A Kolibri 78,1 milliárd teljes és 3,5 milliárd tokenenként aktív paramétert tartalmaz.
- A Kolibri Apache 2.0 licenc alatt jelent meg a forrás szerint.
- Az interaktív eszköz nyílt súlyú modellek és saját konfigurációk összehasonlítását teszi lehetővé.
A költségek három fontos dimenziója
Az Aleph Alpha 2026. október 7-én közzétett bejegyzése szerint egy nyelvi modell architektúrája meghatározza, hogyan oszlik meg a modell kapacitása és számítási igénye. A vállalat az elemzésben három fő szempontot vezet le: a paraméterek elosztását, az egy tokenre jutó lebegőpontos műveletek számát, valamint a sorozatkeverő állapotának méretét.
A teljes paraméterszám elsősorban a súlyok memóriaigényét határozza meg, ez pedig a modell telepítéséhez szükséges minimális hardverre is hatással van. Az egy tokenre jutó FLOP-számot a tanításhoz használt tokenmennyiséggel megszorozva megbecsülhető a tanítás számítási igénye. Ez az érték a bemeneti feldolgozás, vagyis a prefill költségének is hasznos közelítése.
A sorozatkeverő állapota, figyelemalapú modelleknél például a kulcs-érték gyorsítótár, azt befolyásolja, hogy egy dekódolási kötegben hány sorozat és mekkora kontextus fér el. A rövid kontextusú, kis kötegű dekódolást elsősorban a súlyok beolvasása korlátozza, a hosszú kontextusú dekódolásnál viszont a sorozatállapot olvasása válhat szűk keresztmetszetté.
A Kolibri és a vizsgált nyílt súlyú modellek
Az Aleph Alpha egy interaktív eszközt is készített, amelyben a felhasználók módosíthatják az architektúra beállításait, vagy saját konfigurációt adhatnak hozzá. A vállalat ezt egy belső, modelltervezéshez használt eszköz egyszerűsített változataként írja le. Az összehasonlításban több friss, nyílt súlyú architektúra szerepel.
A kiinduló konfigurációk között megtalálható a Kolibri Origin és a Kolibri. A bejegyzés szerint a Kolibri modellt nemrég Apache 2.0 licenc alatt adták ki. A táblázat alapján a Kolibri teljes paraméterszáma 78,1 milliárd, az egy tokennél aktív paraméterek száma 3,5 milliárd, vagyis az aktív paraméterek aránya 4,4 százalék.
A Kolibri Origin 30,6 milliárd teljes és 3,3 milliárd tokenenként aktív paramétert tartalmaz. Az Aleph Alpha konfigurációjában 50 dekóderréteg, 2560-as rejtett dimenzió, 384 útválasztott szakértő és tokenenként 6 aktív szakértő szerepel. A modellnél 40 réteg használ csúszóablakos figyelmet, az ablak mérete 512.
Miért fontos az elosztás a Mixture of Experts modelleknél?
Az elemzés központi témája a Mixture of Experts, röviden MoE architektúra. Ezeknél a teljes és az aktív paraméterszám jelentősen eltérhet egymástól. A teljes paraméterszám a tárolási és memóriaigényt, az aktív paraméterek pedig jellemzően a tanítás és a prefill számítási igényének nagy részét határozzák meg.
Az egy tokenhez kiválasztott szakértők száma, a szakértők belső szélessége és a megosztott szakértők mérete mind hatással van arra, hogy mennyi modellkapacitás vesz részt az adott token feldolgozásában. Az Aleph Alpha szerint a szakértői rétegekben a kapuzó, fel- és leképező lineáris műveletek adják a paraméterek jelentős részét. A router a rejtett állapotból képez választási értékeket az összes szakértőhöz, de a teljes paraméterszámon belül kis részt képvisel.
A vállalat szerint az interaktív felfedező célja, hogy a fejlesztők már egy konfiguráció véglegesítése előtt számszerűsíthessék az egyes döntések következményeit. A felhasználók így ugyanazon a felületen hasonlíthatják össze a paraméterigényt, a tokenenkénti számítási költséget és a sorozatállapot méretét.
