Mikä on TensorCast – ja miksi se voi nopeuttaa suurten kielimallien käynnistystä?

TensorCast on Pekingin yliopiston, tekoäly-yhtiö StepFunin ja Beijing University of Posts and Telecommunicationsin ehdottama hajautettu järjestelmäkerros. Sen perusidea on käsitellä tensorien elinkaarta omana ohjelmoitavana kokonaisuutenaan – riippumatta siitä, mikä laskentamoottori tensorit tuottaa tai kuluttaa. 1

Käytännössä TensorCast pyrkii tarjoamaan yhteisen tavan hallita suurten tekoälymallien tilaa: mallipainoja, keskustelujen KV-välimuistia sekä muita välitiloja. Tällöin sovelluksen ei tarvitse erikseen tietää, millä palvelimella, millä grafiikkasuorittimella tai millä tallennusmedialla tietty tensoritila sijaitsee. Runtime-ympäristö huolehtii paikantamisesta, siirtämisestä ja käyttöön valmistelusta.

Miksi tällaista kerrosta tarvitaan?

Suurten kielimallien palveluissa hallittavana ei ole vain itse malli. Mallipainot ovat suhteellisen pysyvää dataa, mutta KV-välimuisti muuttuu jatkuvasti keskustelujen edetessä. Lisäksi järjestelmät käsittelevät erilaisia välitiloja, joita voidaan joutua siirtämään, jakamaan tai säilyttämään klusterin eri osissa. 1

Perinteisesti nämä tehtävät on hajautettu useisiin toisiinsa kytkeytyviin komponentteihin: päättelymoottoriin, pyyntöjen reititykseen, ajoittimeen, verkkokerrokseen ja tallennusjärjestelmään. Jokainen uusi optimointi voi siksi vaatia muutoksia useaan paikkaan. TensorCastin ehdotus on tehdä tensorien elinkaaren hallinnasta oma abstraktiokerroksensa.

Tämä erottaa sen tavallisesta objektitallennuksesta, joka yleensä käsittelee dataa läpinäkymättöminä bitteinä. TensorCast puolestaan ymmärtää tensorin identiteetin, sijainnin, omistajuuden ja elinkaaren. Se eroaa myös laskentakeskeisistä viitekehyksistä, joiden päätehtävä on laskentatehtävien ajoittaminen eikä tensoritilan hallinta. 1

TensorCastin keskeiset rakennuspalikat

• Ensiluokkaiset tensor-oliot: Tensorilla on oma identiteetti, omistaja, sijoittelu ja elinkaaren semantiikka. Järjestelmä voi viitata mallipainoon, KV-lohkoon tai välitilaan ilman, että kutsuvan moottorin tarvitsee sitoa sitä tiettyyn sijaintiin tai esitysmuotoon. 1
• Yhdisteltävät elinkaaritoiminnot: Kehittäjä voi koostaa käytäntöjä esimerkiksi siirroille, muunnoksille, ennakkolataukselle, replikoinnille ja tensorin materialisoinnille eli valmistelemiselle tietyn laitteen tai prosessin käyttöön. 1
• Käytännön ja toteutuksen erottaminen: Käytäntö kirjoitetaan TensorCast-ohjelmointirajapintojen avulla, kun taas runtime suorittaa hajautetun tiedonsiirron ja muun teknisen työn. Taustalla olevaa päättelymoottoria ei tarvitse muokata jokaisen uuden optimoinnin vuoksi. 1
• Ohjaus- ja datatason erottaminen: Global Store eli GS ylläpitää metatietoja, kuten työntekijöiden ja solmujen tilaa, tensorien sijainteja, omistajuutta ja ajoitustietoja. Worker-prosessit siirtävät varsinaiset tensorit. GS siis koordinoi liikennettä eikä kuljeta tensoridataa itse, mikä vähentää keskitetyn pullonkaulan riskiä. 1
• Kaksi metatietostrategiaa: Suhteellisen harvalukuiset ja pysyvät kohteet, kuten mallipainot, voidaan rekisteröidä keskitetysti GS:ään. Lukuisat ja nopeasti muuttuvat kohteet, kuten KV-välimuistin lohkot, voidaan jakaa osiin. Kunkin osan niin sanottu shard-home Worker ylläpitää omistajuutta ja eheyttä vuokrausten sekä fencing token -tunnisteiden avulla. 1
• Tehokas materialisointi: Paikalliset GPU-replikat voidaan jakaa CUDA IPC:n avulla ja CPU-muisti paikallisten memfd-kahvojen avulla. Etälähteistä dataa voidaan siirtää RDMA:n suorilla kirjoituksilla. Näin vältetään tarpeettomia kopioita ja hyödynnetään mahdollisuuksien mukaan suoria GPU–GPU- tai paikallisen muistin jakamispolkuja. 6

Miksi KV-välimuistin siirtäminen helpottuu?

Monikierroksisessa keskustelussa käyttäjän aiempaan historiaan liittyvä KV-välimuisti voi olla tärkeä siirtää uuden päättelyinstanssin yhteyteen esimerkiksi kuormituksen tasaamiseksi. Perinteisessä palvelupinossa tämä voi edellyttää samanaikaisia muutoksia pyyntöjen reitittimeen, päättelymoottorin KV-toteutukseen sekä välimuisti- ja verkkotaustajärjestelmään.

TensorCastissa käytäntö voi sen sijaan tunnistaa istunnon KV-tensorit, pyytää niiden sijoittelua ja materialisointia kohde-Workerille sekä ohjata tulevat pyynnöt sinne. TensorCastin elinkaariajonaikainen ympäristö hoitaa haun, siirron ja muistiosoitusten sitomisen. 1

Tämä ei tee siirrosta ilmaista tai poista verkkoliikenteen kustannuksia. Hyöty on siinä, että siirtokäytäntö voidaan kuvata yhdellä hallintakerroksella sen sijaan, että sama logiikka rakennettaisiin erikseen useisiin tiukasti kytkeytyviin komponentteihin. Samalla on helpompi kokeilla esimerkiksi välimuistin sijaintiin perustuvaa reititystä, mallipainojen uudelleenkäyttöä tai toisiinsa liittyvien tilojen sijoittamista samalle solmulle. 1

Mitä kokeissa havaittiin?

Tutkijat yhdistivät TensorCastin vLLM- ja SGLang-päättelykehikoihin. Kokeissa tarkasteltiin muun muassa mallipainojen materialisointia ja synkronointia, KV-välimuistin hallintaa sekä ohjelmoitavaa pyyntöjen reititystä. 1

Raportin mukaan KV-välimuistin suorituskyky oli kilpailukykyinen Mooncaken kanssa. Mooncake on tähän käyttötarkoitukseen erikoistunut KV-välimuistijärjestelmä, kun taas TensorCast pyrkii säilyttämään mahdollisuuden rakentaa käytäntöjä useiden järjestelmäkomponenttien yli. 1

Qwen3-235B-A22B:n käynnistyksessä TensorCastin kerrotaan olleen parhaimmillaan 228,6 kertaa nopeampi kuin tavanomaiset hajautetut tiedostojärjestelmät. Mallissa on yhteensä 235 miljardia parametria, joista 22 miljardia aktivoituu. 12

Korkean samanaikaisuuden monikierroksisissa agenttikuormissa ohjelmoitava TensorCast-käytäntö pienensi raportin mukaan mediaaniaikaa ensimmäiseen tokeniin eli TTFT-aikaa (time to first token) parhaimmillaan 93,2 prosenttia. 1

Mitä tulokset merkitsevät?

TensorCastin merkitys on ennen kaikkea arkkitehtuurissa. Jos mallipainojen, KV-välimuistin ja muiden tensoritilojen hallinta voidaan toteuttaa yhteisen kerroksen kautta, tekoälypalveluista voi olla helpompi rakentaa elastisia, tilallisia ja kuormitukseen mukautuvia.

Raportoidut tulokset viittaavat siihen, että mallien nopea käyttöönotto, välimuistin sijaintiin perustuva reititys, tilan siirtäminen ja tensorien uudelleenkäyttö voidaan kuvata ohjelmoitavina järjestelmäkäytäntöinä erillisten, kehyskohtaisten optimointien sijaan.

On kuitenkin hyvä huomata, että luvut ovat tutkijoiden raportoimia kokeellisia tuloksia tutkimuksen esiversiosta. Riippumaton toistaminen ja laajamittainen tuotantokäytön validointi ovat vielä tarpeen, ennen kuin suorituskyky- ja ylläpitohyödyt voidaan arvioida lopullisesti. 1