Se malli vaan valitettavasti lopulta määrittää mikä on latenssi. Sitä ei myöskään voi aina 'rakentaa mahtumaan budjettiin', vaan voidaan jäädä tavoitteesta kuten FSD:n kanssa on jääty. Jos tämä menisi kuten esität, niin jo ensimmäinen HW versio jota myytiin autossa yhdessä FSD lisenssin kanssa voisi FSD:tä hyödyntää. Todellisuus kuitenkin oli että tesla ei vieläkään tiedä mitä laskentaresursseja FSD lopulta tulee tarvitsemaan.
Yksittäisen mallin latenssi kyllä määräytyy mallista ja raudastaeli tästä ollaan samaa mieltä mutta tuotantojärjestelmässä malli ei ole vapaa muuttuja vaan sitä rajoittaa käyttökohde. Eli jos malli ei mahdu latency-budjettiin niin sitä ei ajeta sellaisenaan vaan sitä pienennetään, kvantisoidaan ja jaetaan useaan vaiheeseen. Tämä on ihan normaalia käytäntöä kaikessa edge/embedded AI:ssa. Se että HW-versioita tulee lisää ei kumoa tätä vaan se kertoo että headroomia tarvitan lisää mallien kasvaessa.
Joka kerta yllätytään että kuinka monimutkaisia malleja tarvitaan, sitten suunnitellaan uusi hardis, ja sitten taas todetaan että ei riittänyt. Se siitä laskentaprofiilille optimoimisesta, mitä se sitten käytännössä tarkoittaakaan.
Tämä ei ole ristiriita vaan juuri odotettu kehityskaari eli arkkitehtuuri tehdään tietylle workload-luokalle, mallit kasvavat ajan myötä ja lopulta kapasiteetti ei riitä on uusi rauta. Sama ilmiö on GPU:issa, puhelimissa ja käytännössä kaikessa laskennassa. Optimointi ei tarkoita että yksi rauta riittää ikuisesti vaan että se on tehokas sille kuormaluokale mihin se on suunniteltu.
Sekoitat että mistä mallin latenssi tulee, ja sen että mikä on käytännön vaatimus tuossa käytössä.
En sekoita vaan erotan ne nimenomaan mallin latenssi on malli ja rauta, järjestelmän latensivaatimus on käyttökohde. Suunnittelu lähtee jälkimmäisestä. Malli ei saa rikkoa sitä koska muuten se ei kelpaa käyttöön.
Hyvä kuitenkin että ollaan nyt samaa mieltä siitä että malli määrittää laskennan latenssia. Tästä voisi sitten jatkaa loogisesti että kun malli ei ole valmis, niin miten voidaan rauta suunnitella siten että malli jota ei vielä ole olemassa voidaan ajaa sillä riittävän nopeasti jotta pysytään reaaliaikatavoitteissa.
Hoksaatko?
Koska ei suunnitella yhdelle mallille vaan kuormaluokalle. Tiedetään etukäteen multi-camera video input, jatkuva inferenssi (ei batch), tensorioperaatioihin perustuva laskenta ja target latency-luokka. Näistä saadaan riittävä arvio eli memory bandwidth, compute throughput ja rinnakkaisuus. Tätä täydennetään headroomilla ja prototyypeillä. Täydellistä tietoa ei ole koskaan ja tämä on normaalia ASIC-suunnittelussa.
Taas sekoitat latenssin ja latenssivaatimukset.
Datavirta on noissa autoissa ihan todella pientä, ei tarvitse kauheasti transistoreja käännellä eri asentoihin sen vuoksi.
Datavirta ei määritä latenssia. Malli määrittää latenssin.
Aiemmin taas kerroit kuinka tässä on rauta optimoitu softaan. Nyt taas toisin päin.
Datavirta ei yksin määritä latenssia mutta se määrittää kuinka paljon dataa pitää käsitellä per aika ja kuinka paljon rinnakkaisuutta tarvitaan. Lisäksi kuorma ei ole pelkkä “pikselivirta” vaan useita kameroita, useita verkkoja per frame ja temporal processing. Laskenta syntyy datavirran k
äsittelystä eikä pelkästä siirosta.
Inferenssi on nimenomaan datavirran prosessointia. Ilman datavirtaa ei ole inferenssiä ja datavirran luonne määrittää kuinka paljon laskentaa per sekunti tarvitaan ja kuinka paljon dataa liikkuu muistissa. Nämä ovat keskeisiä asioita piiritasolla.
Tämä ei ole joko–tai vaan co-design eli rauta optimoidaan workloadille (video + tensorilaskenta + low latency) ja mallit optimoidaan mahtumaan siihen. Tämä tehdään rinnakkain eikä peräkkäin.
Luulin että tässä keskusteltiin autoista eikä inferenssistä. Datavirratkaan ei liity inferenssiin ja on olleet kovasti esillä.
Auton “älykkyys” on käytännössä inferenssiä. Se mitä auto tekee (havainto, päätös, ohjaus) on juuri se pipeline, jonka raskain osa on inferenssi. Siksi nämä eivät ole erilisiä asioita.
Et vastannut kysymykseen.
Jos kameran fps tuplataan, niin miten piiri pitäisi optimoida eri tavalla. Esitit että tämä piiri on nimenomaan optimoitu RAUTATASOLLA jotenkin näihin datavirtoihin. Tämä on täyttä hölynpölyä. Tuolla piirillä ei ole mitään kameran resoluutiospesifiä optimointia missään.
Piiriä ei muuteta jälkikäteen vaan se suunnitellaan kuormaluokalle jossa on headroom. Jos FPS kasvaa niin kuorma kasvaa lineaarisesti ja käytetään enemmän rinnakkaisuutta. Sama rauta mutta suurempi käyttöaste. Tätä varten kapasiteettia ei mitoiteta täyteen 100%:iin.
Ei ole kovakoodattua “tälle resoluutiolle” logiikkaa mutta arkkitehturi on silti optimoitu tietylle datavirran suuruusluokalle eli tietylle rinnakkaisuuden tasolle ja tietylle memory bandwidth -luokalle. Tämä on juuri sitä piiritason optimointia.
Yliprovisointi taas on hyvä tapa kertoa että piiriä ei oltukkaan optimoitu jollekkin tietylle kuormalle, vaan jollekkin tuntemattomalle isommalle kuormalle.
Yliprovisointi (headroom) ei tarkoita ettei olisi optimointia vaan että järjestelmä kestää mallien kasvua ja sama rauta toimii useammalla malliversiolla. Tämä on käytännössä välttämätöntä kaikessa pitkäikäisessä embedded-raudassa.
Jep. Nyt sekoitat asiaa missä on tiedossa algoritmit ja vaatimukset, siihen että vaatimukset ovat epäselvät ja kukaan ei ole algoritmiakaan keksinyt, ja sitten heität ilmoille että tuntemattoman algoritmin tuntemattomat vaatimukset huomioiden osattaisiin tehdä optimoitu piiri. Tämä on tosiasiassa mahdollista vasta kun on toimiva algoritmi.
Ei optimoida tuntemattomalle algoritmille vaan tunnetulle laskentaluokalle jossa video, tensorilaskenta, low-latency inference, multi-stream processing. Algoritmit vaihtuvat (CNN, transformer, E2E),mutta nämä perusominaisudet eivät.
Siksi optimointi on mahdollista ennen lopullista mallia.
