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.
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.
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.
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.
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.
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.
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 (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.
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.