Tekoälyn päivälehti — mallit, työkalut ja hardware
llama.cpp b10355 · vetopyyntö 25532 · Työkalut
Vetopyyntö numero 25532 hautui pitkään ja meni sisään eilen illalla. Se sallii usean ulostulon näytteenoton laskentataustassa yhtä aikaa tokenispekulaation kanssa — ja sen todellinen työ oli saada suorittimen ja näytönohjaimen antamat jakaumat vastaamaan toisiaan.
Tekstin tuottamisessa on kaksi vaihetta, jotka mielletään helposti yhdeksi. Ensin malli laskee jokaiselle sanaston tokenille pistemäärän, ja sitten jostain on valittava, mikä token otetaan. Ensimmäinen vaihe on raskasta matriisilaskentaa ja tapahtuu siellä missä malli on, useimmiten näytönohjaimella. Toinen vaihe on kevyt, mutta llama.cpp on perinteisesti tehnyt sen suorittimella — mikä tarkoittaa, että jokaista tokenia kohti sanaston kokoinen pistemäärätaulukko on kopioitava näytönohjaimelta keskusmuistiin.
Eilen illalla kello 23.15 julkaistu build b10355 muuttaa tämän kunnolla. Vetopyyntö numero 25532 lisää tuen usean ulostulon näytteenotolle laskentataustassa, ja sen ensimmäinen kohta commit-viestissä on suoraan asiaan: näytteenotto taustaosassa yhdessä tokenispekulaation kanssa. Aiemmin taustanäytteenotto toimi vain silloin, kun sekvenssistä syntyi täsmälleen yksi ulostulo kerrallaan. Spekulatiivisessa dekoodauksessa niitä syntyy monta yhdellä kertaa, koska luonnostelija on ehdottanut lohkon tokeneita ja päämalli tarkistaa ne rinnakkain — ja juuri se yhdistelmä ei ennen toiminut.
Suurin osa vetopyynnön työstä ei ollut uuden ominaisuuden kirjoittamista vaan sen saamista käyttäytymään täsmälleen samoin kuin vanha polku. Commit-viesti luettelee vaiheet melkein saarnamaisesti: leikkaa maskin summa ennen kuin se muunnetaan otetuksi indeksiksi, lisää numeerinen konteksttiparametri, joka kertoo sekvenssin suurimman sallitun ulostulomäärän, älä kierrätä muistia ulostulonäkymille, sovita jakauma suorittimen ja taustaosan välillä, korjaa suorittimen ja taustaosan näytteenoton erot, korjaa testit Vulkanilla. Kaksi noista riveistä sanoo saman asian eri sanoin, ja se kertoo, kuinka hankala ongelma oli.
Miksi tämä on tärkeää juuri nyt? Koska spekulatiivinen dekoodaus on kahdessa vuorokaudessa muuttunut erikoisuudesta oletukseksi. Eilen Meta toimitti Muse Glimmerin mukana oman DFlash-luonnostelijansa, tänään Nvidia toimitti Nemotron 3.5 Lightningin mukana kaksi luonnostelijaa ja sisäänleivotun monitokeniennusteen. Kun luonnostelija on osa mallipakettia eikä enää harrastelijan viritys, ajomoottorin on osattava käsitellä monta ehdotettua tokenia kerralla ilman, että jokainen niistä pakottaa edestakaisen matkan keskusmuistiin.
Käytännön hyöty riippuu koneesta. Isolla sanastolla — ja nykymallien sanastot ovat kahdensadantuhannen tokenin luokkaa — pistemäärätaulukon siirto on satojen kilotavujen kopio jokaista tokenia kohti. Nopealla PCIe-väylällä varustetulla työpöytäkoneella tämä on pieni kustannus. Yhteismuistikoneella, jossa suoritin ja näytönohjain jakavat saman muistin, hyöty on pienempi. Mutta sulautetuilla laitteilla ja kapean väylän minikoneilla ero näkyy, ja juuri niillä spekulatiivista dekoodausta eniten tarvitaan.
Tämä lehti ei ole mitannut lukuja itse, eikä vetopyyntö esitä omia mittauslukuja. Ominaisuus on rakennuspalikka, ei nopeuslupaus: se poistaa esteen, joka aiemmin sulki taustanäytteenoton ja spekulaation toisensa pois. Jos ajat luonnostelijaa käyttävää mallia llama.cpp:llä, päivitä b10355:een tai uudempaan ja katso, kannattaako taustanäytteenotto kytkeä päälle. Jos et aja luonnostelijaa, tämä build ei muuta sinulle mitään.