Google brengt LiteRT Tensor API uit voor modelbouw in C++

LiteRT Tensor API laat ontwikkelaars AI-grafen zelf in C++ opbouwen en via LiteRT naar CPU, GPU of ondersteunde NPU’s sturen, maakt Google op 19 oktober bekend.

Een productteam kan modeluitvoering, beeldbewerking vóór het model en nabewerking op één apparaat houden. Denk aan een camera-app die objecten volgt zonder ieder beeld naar een clouddienst te sturen. Dat kan de vertraging en hoeveelheid gedeelde data beperken, maar verplaatst werk naar ontwikkelaars: zij beschrijven de modelstructuur zelf en testen die op de doelapparaten.

De API bouwt de modelgraaf op

LiteRT Tensor API is een C++-laag waarin ontwikkelaars een model stap voor stap beschrijven als een graaf van tensorbewerkingen. Google’s API ondersteunt meer dan 90 bewerkingen, van matrixvermenigvuldiging en convolutie tot normalisatie en kwantisering. Daaronder vallen ook bouwstenen voor taalmodellen, zoals scaled dot-product attention, RMSNorm en updates van de KV-cache. Gewichten zijn direct uit Hugging Face .safetensors-bestanden in te lezen, zonder aparte conversiescripts; een graaf is te exporteren als .tflite-bestand.

Dezelfde C++-graaf heeft drie uitvoerroutes: direct op de CPU met XNNPACK, via LiteRT op CPU, GPU of ondersteunde NPU’s, of met ML Drift op GPU’s via OpenCL of WebGPU. Welke bewerkingen op een versneller draaien, verschilt per backend. Voorverwerking, model en nabewerking kunnen buffers delen, zodat gegevens tussen die stappen niet telkens naar de CPU terug hoeven.

De API richt zich op eigen modelarchitecturen en pijplijnen die op de versneller blijven. Een codeagent kan met dezelfde bouwstenen een graaf maken en varianten per apparaat vergelijken.

SAM 2 laat de verschillen per apparaat zien

Google demonstreert de API met Segment Anything Model 2.1 Hiera-Tiny, dat objecten in videobeelden selecteert en volgt. De voorbeeldapp draait in een browser met WebGPU. De pijplijn schaalt een camerabeeld naar 512 bij 512 pixels, berekent beeldkenmerken, voorspelt een masker na een klik of tekstprompt en schaalt dat terug naar het oorspronkelijke formaat. Google meldt dat alle 791 encoder- en decoderbewerkingen op de GPU draaien. Voor- en nabewerking voegen volgens het bedrijf ongeveer 0,34 milliseconde toe.

Op een MacBook Pro met Metal kostte de beeldencoder 11,72 milliseconde, tegenover 17,77 voor Apple MLX; de interactieve decoder kostte 0,90 tegenover 1,69 milliseconde. Op een iPhone met Metal mat Google 31,71 milliseconde voor de encoder en 1,60 voor de decoder, tegenover 35,1 en 3,30 milliseconde voor MLX. Op Android met OpenCL waren de cijfers 32,03 en 1,82 milliseconde. Voor die telefoon publiceerde Google geen MLX-vergelijking. Dit zijn losse modelstappen, niet de totale reactietijd van een afgewerkte app.

Google zegt dat een codeagent de videoversie van onder de 10 naar boven de 30 beelden per seconde bracht bij 512 bij 512 pixels. Google deelt benchmarkcommando’s, maar deze aankondiging bevat geen onafhankelijke cijfers voor andere modellen of toestellen. Geheugen, drivers en ontbrekende bewerkingen kunnen de uitkomst op een ander apparaat veranderen.

Google voegt modelbouw aan lokale modellen toe

Dit bouwt voort op Googles recente aanbod voor lokale AI, maar op een andere laag. Op 6 oktober bracht Google EmbeddingGemma 2 uit: een model dat tekst, code, beeld, video en audio in één 768-dimensionale vectorruimte zet voor lokaal zoeken. Dat model maakt bestanden vindbaar; Tensor API laat ontwikkelaars zelf de rekenstappen en datastroom van een model samenstellen.

Ook ontwikkeltools schuiven verwerking naar de computer van de gebruiker. GitHub Copilot plant vanaf eind oktober per taak tussen lokale en cloudmodellen te kiezen. Die keuze bepaalt waar een verzoek wordt verwerkt. LiteRT Tensor API richt zich op de eerdere laag: hoe het model en de verwerking eromheen zijn opgebouwd.

Apple’s MLX is ontwikkeld voor Apple silicon en ondersteunt daar CPU- en GPU-berekeningen. Het C++-project llama.cpp ondersteunt uiteenlopende backends, waaronder Apple Metal, Qualcomm OpenCL, CUDA, Vulkan en WebGPU. Google sluit daarbij aan met een handgeschreven C++-graaf die op meerdere LiteRT-routes kan worden uitgevoerd.

De meetlat blijft van Google

Google beveelt modelconversie aan als standaardroute voor de meeste projecten. Tensor API is bedoeld wanneer ontwikkelaars een architectuur willen bouwen die een converter niet oplevert, of de hele pijplijn op de versneller willen houden. Lokaal AI ontwikkelen vraagt dus niet altijd om een zelfgeschreven modelgraaf.

De benchmark is smaller dan de hardwarelijst doet vermoeden. Google vergelijkt SAM 2.1 met MLX op Mac en iPhone, niet op Android. Op iOS is de encoder 3,39 milliseconde sneller; de decoder ongeveer twee keer zo snel. De uitkomst hangt af van welk deel van de taak wordt gemeten. Google noemt NPU-vriendelijke bewerkingen en automatische kwantisering bovendien als werk in uitvoering. Niet elke bewerking draait dus al op elke NPU.

Voor een Nederlandse productorganisatie maakt dit het haalbaarder om AI op een apparaat te laten draaien, mits de toepassing past bij de ondersteunde bewerkingen en beschikbare rekenkracht. Klantbeelden of andere invoer kunnen lokaal blijven wanneer de hele gegevensroute daarop is ingericht. Teams krijgen invloed op zowel de modelbouw als de route van invoer tot resultaat. Googles volgende stap is meer bewerkingen en ondersteuning voor wisselende invoerformaten; tot die tijd blijft testen op de doelapparaten nodig om te weten of de toepassing bruikbaar is.