Slik skal Jingang GC3 bruke RISC-V og dataflyt til å effektivisere video-AI

Jingang GC3, også omtalt som King Kong GC3, er rapportert som en spesialisert prosessor for video-AI og generativ AI fra SmarCo HT Tech. I stedet for å behandle videodekoding, AI-inferens og videogenerering som separate oppgaver for ulike enheter, skal brikken samle arbeidsflyten i én dataflytorientert arkitektur. De rapporterte spesifikasjonene omfatter 12 RISC-V-kjerner, 200 TOPS INT8-beregningskapasitet og 128 GB samlet LPDDR5 ECC-minne. 35

Det mest interessante er ikke nødvendigvis tallet 200 TOPS alene. GC3s hovedidé er at videoarbeidslaster ofte bruker mye tid og energi på å flytte videobilder, modelldata og mellomresultater mellom prosessorer og minne. Dataflytmotoren, det delte minnet og de integrerte video- og AI-funksjonene skal redusere denne flyttingen.

Hvorfor video-AI får problemer med datatransport

I en vanlig arbeidsflyt for videoanalyse dekodes videostrømmen til enkeltbilder. Bildene sendes deretter gjerne til en GPU for bildeanalyse, før resultatene går videre til flere behandlingstrinn. Når antallet samtidige videostrømmer øker, kan overføring og synkronisering bli en flaskehals ved siden av selve beregningene. 3

Videogenerering har en lignende utfordring. Diffusjonsmodeller og Transformer-baserte systemer arbeider med store modellparametere og omfattende mellomresultater. Omtalen av GC3 viser til at slike datasett kan komme opp i hundrevis av gigabyte, noe som gjør gjentatte lesinger, skrivinger og overføringer kostbare i form av båndbredde, strøm og tid. 3

Det er dette GC3 skal angripe: ikke bare mangel på regneenheter, men kostnaden ved å koordinere mange trinn i en stor og svært parallell arbeidslast.

Hva GC3-arkitekturen kombinerer

Dataflytberegning

I en tradisjonell kontrollflytbasert konstruksjon henter og utsteder en sentral prosessor eller planlegger instruksjoner, mens data beveger seg gjennom et minnehierarki. Dette er fleksibelt, men omtalen av GC3 beskriver modellen som mindre egnet for enkelte regelmessige og massivt parallelle videooperasjoner. 3

I en dataflytarkitektur kan beregninger i stedet settes i gang når dataene som trengs, er tilgjengelige. I prinsippet kan dette gi mer parallellitet og redusere venting som skyldes sentralisert planlegging og global koordinering. For videoarbeidslaster er målet å holde flere behandlingstrinn aktive uten at alt må gå gjennom én sentral kontrollbane. 3

Dette er et arkitekturmål, ikke et bevis på en bestemt hastighetsøkning. De tilgjengelige kildene inneholder ingen uavhengige ende-til-ende-sammenligninger med navngitte CPU-er, GPU-er eller video-AI-plattformer.

RISC-V som styringslag

De 12 RISC-V-kjernene skal ifølge den rapporterte utformingen fungere som et programmerbart styringslag. Spesialiserte behandlingsbaner håndterer video- og AI-operasjoner, mens RISC-V-kjernene står for generell kontroll og planlegging i stedet for at en tradisjonell CPU må styre hvert eneste trinn. 35

RISC-V presenteres dermed ikke som hele beregningsmotoren. Kjernegruppen arbeider sammen med dataflytmotoren og dedikerte video- og AI-funksjoner: RISC-V gir programmerbar styring, mens spesialmaskinvaren tar seg av operasjoner med høy gjennomstrømming.

128 GB samlet minne

GC3 skal bruke 128 GB samlet LPDDR5 ECC-minne som deles av CPU-, VPU-, GPU- og NPU-banene. 35 Den tiltenkte fordelen er at data i mindre grad må kopieres mellom separate minneområder for CPU og GPU.

Et felles minneområde kan gjøre at dekodede bilder, modellvekter og mellomresultater forblir tilgjengelige for flere behandlingsblokker uten like mange overføringer mellom enheter. ECC gir minnesystemet funksjoner for feildeteksjon og -korrigering. Forskning på RISC-V-prosessorer har også undersøkt ECC-beskyttet minne som et middel for bedre feiltoleranse. 1

Samlet minne fjerner likevel ikke alle båndbreddebegrensninger. Det endrer hvordan de ulike beregningsblokkene får tilgang til data, mens den praktiske gevinsten vil avhenge av minnebåndbredde, programvarestøtte, planlegging og den aktuelle arbeidslasten.

Integrerte video- og AI-baner

Den rapporterte utformingen kombinerer videoenkoding og -dekoding med AI-beregninger på samme plattform. Det skal gi en mer direkte vei fra videoinnhenting til analyse, og fra generert innhold til ferdig enkoding. 35

Den foreslåtte arbeidsflyten blir dermed å:

• dekode video på plattformen;
• holde videobildene tilgjengelige for den relevante AI-banen;
• kjøre analyse eller generering uten å krysse separate enhetsgrenser gjentatte ganger; og
• kode resultatet på det samme integrerte systemet.

Det betyr ikke at alle operasjoner utføres som ett udelelig trinn. Poenget er at arkitekturen skal redusere unødvendige overleveringer mellom prosessorer og minnesystemer som ellers ville vært separate.

Slik skal brikken redusere kostnader, strømbruk og forsinkelse

Den tiltenkte økonomiske effekten følger direkte av arkitekturen. Hvis en arbeidslast krever mindre kopiering, færre turer til og fra minnet og mindre synkronisering mellom enheter, kan mer av tiden og energien brukes på selve beregningen i stedet for på datatransport. Det kan være relevant for flerstrøms videoanalyse, lokal videobehandling og videogenerering med store mellomresultater. 3

De mulige gevinstene kan deles i tre:

• Forsinkelse: Færre overføringer mellom dekoding, AI-behandling og enkoding kan korte ned veien fra videobilde til resultat.
• Strømforbruk: Mindre datatransport kan redusere energien som brukes på minnetilgang og trafikk mellom behandlingsenheter.
• Kostnad: Én integrert plattform kan redusere infrastruktur- og driftskostnadene ved å samordne flere spesialiserte enheter.

Dette er målsettingene som beskrives i den tilgjengelige omtalen, ikke uavhengig verifiserte resultater. Kildene oppgir spesifikasjoner og en arkitektonisk begrunnelse, men dokumenterer ikke en målt reduksjon i kroner per video, watt per videostrøm eller millisekunder i total behandlingstid.

Hva spesifikasjonene faktisk forteller

Tallet 200 TOPS beskriver rapportert INT8-kapasitet for AI-beregninger, ikke garantert ytelse i en bestemt applikasjon. Den reelle gjennomstrømmingen i video-AI vil også avhenge av modellstøtte, tallpresisjon, minnebåndbredde, kompilator og kjøremiljø, videoformater, batchstørrelse, antall samtidige strømmer og hvor effektiv dataflytplanleggeren er.

På samme måte kan 128 GB samlet minne gjøre det enklere å håndtere store modeller og mellomresultater, men minnekapasiteten alene viser ikke at en bestemt videogenereringsmodell vil kjøre effektivt. Programvarestøtte og den faktiske datatrafikken i minnet er fortsatt avgjørende.

Konklusjonen

Jingang GC3 kan best forstås som et spesialisert forsøk på å bygge om video-AI-arbeidsflyten rundt bedre datanærhet. Den rapporterte kombinasjonen av dataflytkjøring, RISC-V-kjerner for styring, integrerte CPU-, VPU-, GPU- og NPU-baner samt 128 GB samlet minne skal møte overføringene og synkroniseringsbarrierene som kan begrense tradisjonelle CPU- og GPU-baserte systemer. 35

Hvis maskinvare og programvare fungerer som planlagt, kan arkitekturen gjøre flerstrøms videoanalyse og videogenerering mer effektivt. Den mest forsvarlige konklusjonen nå er likevel at GC3 representerer en plausibel arkitektonisk strategi og har en rekke leverandørrapporterte spesifikasjoner – ikke at det allerede finnes uavhengig dokumentasjon på lavere kostnader, strømforbruk eller forsinkelse.