uutiset

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Uusi viisausraportti

Toimittaja: Qiao Yang

[Johdatus uuteen viisauteen] Skaalauslaki ei ole vielä päättynyt, ja "pienistä malleista" on vähitellen tullut trendi, jota teknologiajätit ovat kuromassa kiinni. Metan äskettäin julkaiseman MobileLLM-sarjan mittakaava on jopa pienentynyt alle 1B:n luokkaan. Molemmissa versioissa on vain 125M ja 350M parametrit, mutta ne ovat saavuttaneet paremman suorituskyvyn kuin suuremmat mallit.

Useiden teknologiajättiläisten lehdistötilaisuuksista touko- ja kesäkuussa voimme jo hämärästi tuntea tekoälyn tärkeän kehitystrendin: pilvipalvelinkeskuksista yksittäisiin käyttäjiin, suurista palvelimista kannettaviin ja mobiililaitteisiin.

Skaalauslain noudattaminen ei ole enää ainoa tapa, ja tarina malleista, jotka "ottavat pientä voittaakseen suuren", kehittyy edelleen.

Ensin Microsoft päivitti sen, sitten Google käytti sitä.

Laitteiston osalta olemme nähneet, että tekoälytoiminnot integroituvat vähitellen syvälle elektronisiin tuotteisiin.

Esimerkiksi Microsoftin surullisen kuuluisa Recall-toiminto on tärkeä osa niitä.

Nykyään LLM:n parametrit nousevat usein kymmeniin miljardeihin Apple 3B:n parametrit ovat jo hyvin pieniä, mutta mobiililaitteille, kuten matkapuhelimille, on silti korkea kynnys.

Se ei vain käytä 2- ja 4-bittistä sekoitettua tarkkuuspakkausmallia (keskimäärin 3,5 bittiä painoa kohti), vaan se vaatii myös vähintään 8 Gt muistia ja M1-sirun toimiakseen.

Metan äskettäin julkaisema artikkeli osoittaa, että parametrien määrää voidaan edelleen vähentää. Äskettäin ehdotetun MobileLLM-mallin parametrien määrä on alle 1B, mutta suorituskyky on silti vaikuttava.

Paperiosoite: https://arxiv.org/abs/2402.14905

LeCun myös henkilökohtaisesti twiittasi tukeakseen tätä tutkimusta ja ylisti sarjaa operaatioita, jotka vähensivät parametrien määrää.

Tämän paperin on hyväksynyt ICML 2024, ja mallin koulutuskoodi on avoimen lähdekoodin GitHubissa.

GitHub-osoite: https://github.com/facebookresearch/MobileLLM

Johdanto

Tehdään ensin hypoteesi, jos GPT-4 (noin 1 biljoonalla parametrilla) on käytössä päättelynopeudella 50 merkkiä/s, minkälaista laitteistoa tarvitset?

Vastaus on 100 miljoonaa H100 GPU:ta. Puhumattakaan mobiililaitteista, niitä ei voi sijoittaa kotiin.

Entä jos laskemme standardia ja käytämme mallia, kuten LLaMA-v2 7B, yhdistettynä 8-bittiseen kvantisointiin?

Yksinkertainen laskelma osoittaa, että pelkkä malliparametrien tallentaminen vaatii noin 7 Gt, mutta se ei ole tallennustilaa, vaan arvokasta käyttömuistitilaa (DRAM).

Lisäksi AI-malli ei voi täysin varata DRAM-muistia Käyttöjärjestelmän ja muiden sovellusten toiminta huomioon ottaen LLM-muistisuhde ei voi ylittää 10%.

Kuvan 2 tilastojen mukaan eri merkkien äskettäin julkaisemat mobiililaitteet on yleensä varustettu 6-12 Gt DRAMilla. Tämä tarkoittaa, että jos haluat ottaa sen käyttöön matkapuhelimessa onnistuneesti, mallin parametrikokoa tulee pienentää <1B.

Ei vain tallennus, vaan myös virrankulutus on suuri ongelma. 7B-mallin energiankulutus on noin 0,7 J/token, ja täyteen ladatussa iPhonessa on hukkaan noin 50 kJ. Laskennallisesti, jos sukupolven nopeus on 10 tokenia/s, matkapuhelimesi täyteen latauksella voit puhua mallin kanssa vain 2 tuntia.

Yllä olevien näkökohtien perusteella on ihanteellinen valinta ottaa käyttöön <1B-malli mobiilipäätteessä. Siksi MobileLLM:n parametrikoko on 125M/350M, mikä on suuruusluokkaa pienempi kuin Applen 3B-malli voidaan sanoa olevan "mini minijen joukossa".

Älä kuitenkaan rajoita skaalauslakia. Pienet parametrit eivät tarkoita heikkoja ominaisuuksia.

MobileLLM ei ainoastaan ​​saavuta SOTA-suorituskykyä samankokoisissa malleissa, vaan ehdottaa myös, että arkkitehtuurin syvyys on tärkeämpi kuin leveys. "Syvä ja kapea" "hoikka" pieni malli voi myös oppia abstrakteja käsitteitä.

Arkkitehtuuri ja menetelmät

Vain 125M/350M parametrien ansiosta arkkitehtuurin suunnittelun optimoinnista rajoitetulla alueella on tullut tärkeä kysymys.

LLM <1B:lle kirjoittaja on tutkinut 4 tehokasta arkkitehtuurin suunnittelutekniikkaa.

1) Käytä SwiGLU-syöttöverkkoa

2) Tee verkon kokonaismuodosta "pitkä ja kapea", eli syvä ja kapea

3) Käytä uudelleen upottamisen jakamismenetelmää

4) Käytä ryhmäkyselyn huomiomekanismia (ryhmitelty kyselyn huomio)

Tämän perusteella kirjoittaja ehdotti myös lohkokohtaista kerrosten jakomenetelmää, joka voi parantaa mallin tarkkuutta lisäämättä ylimääräistä muistia, mutta dekoodausprosessin päättelyviiveen lisäämisen kustannuksella.

Tämä malli, johon on lisätty tasojen jakamismekanismi, on nimeltään MobileLLM-LS.

Skaalauslain kumoaminen: Pienten mallien arkkitehtoninen suunnittelu on erittäin tärkeää

Skaalauslakia vuonna 2020 ehdottavassa paperissa uskotaan, että harjoitusdatan määrä, parametrien määrä ja harjoitusiteraatioiden määrä ovat avaintekijöitä, jotka määräävät suorituskyvyn, ja malliarkkitehtuurin vaikutus voidaan melkein jättää huomiotta.

Tämän artikkelin kirjoittaja ehdotti kuitenkin vertailukokeiden avulla, että tämä laki ei koske pieniä malleja.

Kun malliparametrit on asetettu arvoon 125M tai 350M, "kapea" malli 30-42 kerroksella on huomattavasti parempi suorituskyky kuin "lyhyt ja paksu" malli, jossa on noin 12 kerrosta (kuva 4), terveen järjen päättely, kysymys ja vastaus. , luetun ymmärtäminen jne. 8 Samanlaisia ​​suuntauksia on kaikissa vertailuissa.

Tämä on itse asiassa erittäin mielenkiintoinen löytö, koska aiemmin, kun suunniteltiin arkkitehtuuria pienille, luokkaa 125 miljoonalle malleille, ne eivät yleensä pinoneet yli 12 kerrosta.

Miksi palata "koodin jakamiseen"

"Upotusjako" -menetelmää ehdottivat ensin pienet mallit, kuten OPT, koska pienessä mallissa koodauskerroksen parametrit muodostavat huomattavan osan.

Esimerkiksi 125M-mallissa käytetään koodausta, jonka kontekstin pituus on 32k ja mitta 512. Tulo- ja lähtökoodauskerrokset sisältävät 16M parametria, mikä vastaa 20%.

Vertailun vuoksi suurten mallien koodauskerroksen parametrien määrä on mitätön. Esimerkiksi LLaMA-7B:ssä tämä osuus putosi 3,7 %:iin ja LLaMA-70B:ssä se oli jopa vain 0,7 %. Siksi jaettu koodaus on välttämätön LLM:lle.

Koodin jakamisen vanhentuminen suurten mallien aikakaudella ei tarkoita, että tämä tekniikka ei enää sovellu pieniin malleihin. Se voi tehdä malliarkkitehtuurista kompaktimman ja tehokkaamman.

Kuten taulukosta 1 näkyy, koodin jakamisen jälkeen malli säilytti edelleen alkuperäisen suorituskyvyn, samalla kun parametrien kokonaismäärä pieneni 16 miljoonalla ja jopa parani joissakin vertailuissa.

kerrosten jakamismekanismi

Kuten aiemmin mainittiin, paperin kokeellisissa tuloksissa havaittiin, että pienten mallien tekeminen "hohoiksi" on hyödyllistä suorituskyvyn parantamiselle. Joten kirjoittaja ajatteli: Jos kerrosten jakamismekanismi otetaan käyttöön, eikö se vastaisi mallin syvyyden lisäämistä samalla, kun parametrien kokonaismäärä pysyy muuttumattomana.

Kokeet ovat osoittaneet, että tämä menetelmä todellakin voi parantaa suorituskykyä, ja paperissa verrattiin myös erilaisia ​​kerrosten jakamismenetelmiä (Kuva 6. Lopulta laitteen muistin, suorituskyvyn ja päättelyviiveen punnituksen jälkeen välitön lohkokohtainen jakaminen). , kuva 6b).

Arviointikoe

Kirjoittaja rakensi MobileLLM/MobileLLM-LS-malleja 125M ja 350M parametreilla ja koulutti niitä 1T-tietojoukolla.

Esikoulutettua mallia testataan useilla tietojoukoilla nollanäytteillä, mukaan lukien yleisesti käytetyt vertailuarvot, kuten ARC-easy, ARCchallenge, HellaSwag, WinoGrande, TQA ja RACE.

Taulukko 3 näyttää nollanäytteen terveen järjen päättelyn arviointitulokset MobileLLM-sarja on saavuttanut periaatteessa kattavan SOTA:n, joka ei vain ohita aiemmin julkaistut klassiset mallit, kuten OPT ja BLOOM, vaan myös parempi kuin äskettäin julkaistu GPT-neo, Galactica, RWKV ja muut parametrit.

Kysymyksiin vastaamisen ja luetun ymmärtämisen osalta MobileLLM toimii edelleen hyvin (taulukko 4). Verrattuna muihin malleihin, 125M ja 325M MobileLLM ovat parantuneet yli 6,4 pistettä ja vastaavasti noin 10 pistettä TQA:ssa.

Alavirran tehtävät

Vertailutestien pisteytyksen lisäksi työ ottaa huomioon mallille asetetut erilaiset vaatimukset sovellusskenaarioiden käyttöönotossa ja suorittaa vastaavat arvioinnit.

AlpacaEval ja MT-Bench testaavat mallin suorituskykyä yhden kierroksen ja usean kierroksen chat-tehtävissä Verrattuna kolmeen muuhun perusmalliin, MobileLLM:llä on edelleen paras suorituskyky, ja se voi jopa käyttää 350 miljoonaa parametria ylittääkseen muiden suorituskyvyn. parametri >1B mallit.

Dialogia lukuun ottamatta API-puheluskenaariossa MobileLLM:n EM-pisteet voivat vastata LLaMA-v2:n pistemäärää 7B-parametreilla.

Lisäksi MobileLLM on myös erittäin yhteensopiva kvantisoinnin (PTQ) kanssa. W8A8:n kvantifioinnin jälkeen mallin suorituskyky putosi alle 0,5 pistettä, ja se on edelleen yhteensopiva tasojen jakamismekanismin kanssa, joten se voi mukautua käyttöön tiukemmissa laitteisto-olosuhteissa.

kirjailijasta

Tämän artikkelin vastaava kirjoittaja Zechun Liu on Meta Reality Labsin tutkija. Hän valmistui Fudanin yliopistosta kandidaatin tutkinnon ja tohtorin tutkinnon Hongkongin tiede- ja teknologiayliopistosta. Ennen Metaan siirtymistään hän työskenteli vierailevana tutkijana CMU:ssa.

Zechunin tutkimusintressejä ovat syvän oppimisen soveltaminen tosielämän skenaarioissa, kuten riittämättömien resurssien rajoitukset, laskentaresurssien ja tarkkuuden välinen kompromissi jne. keskittyen verkon binarisointiin ja kvantisointiin, verkkokanavien karsimiseen, arkkitehtuuriin suunnittelu ja tiedon tislaus jne.

Viitteet:

https://x.com/ylecun/status/1810035281472491665

https://arxiv.org/abs/2402.14905