Hvorfor robotter har brug for dedikeret Edge Compute

En humanoid, der kan gå, er et løst problem. En humanoid, der forstår, hvad den ser på, planlægger på tværs af en opgave i flere trin og husker, hvad der skete for fem minutter siden, er ikke. Den databehandling, der lukker dette hul, passer ikke på robotten, og skyen er det forkerte sted at placere den. Denne artikel er den tekniske argumentation for, hvorfor en dedikeret on-prem inferensserver er det banebrydende svar i 2026 for enhver robotimplementering, der er seriøs nok til at udføre nyttigt arbejde.

I01 dækker hvordan Robotten og serveren er forbundet med hinanden. Denne artikel er hvorfor du ville overhovedet købe serveren. Hvis du stadig er i tvivl om, hvorvidt on-prem giver mening, så læs dette først.

Beslutningslatenstidsbudgettet

Enhver handling, en robot udfører, er placeret i et af fire latenstidsniveauer. Hvert niveau har et budget, som opgavens fysik pålægger – hvis man misser det, afbrydes adfærden på en specifik, genkendelig måde.

Disse er ikke vilkårlige. De kommer fra båndbredden af ​​det lukkede kredsløb, de befinder sig indeni.

Reaktiv kontrol kører ved 500 Hz til 1 kHz på ledniveau, fordi dynamikken i et 30 kg tungt humanoidben kræver det - ved 100 Hz resonanserer lemmet, og gangen divergerer. Refleksiv perception arver kameraets billedhastigheder (30-60 FPS = 16-33 ms pr. billede) og tidsskalaen for fysisk kontakt (et fingertryk på et objekt lukker en kontakthændelse på 20-40 ms). Deliberativ planlægning er begrænset af menneskelige samtaleforventninger (et sekund føles responsivt, to føles langsomme) og af modellatensen for en nyttig VLM. Strategisk ræsonnement er det eneste niveau med reel spillerum, hvilket er grunden til, at alle ønsker at presse planlægning ind i det og bliver bidt, når deres VLM ikke kan følge med.

Dette er ikke en Kentino-opfattelse. Budgettet med fire niveauer er den skillevæg, som enhver troværdig robotstyringsstak — ROS 2, Isaac, Drake, OCS2 — rummer. Det, der er forskelligt, er hvilken hardware du sætter bag hvert niveau.

Hvad den indbyggede computer kan og ikke kan

En humanoid fra 2026 bærer en NVIDIA Jetson AGX Orin øverst på specifikationsarket - 64 GB samlet hukommelse, op til 275 sparse INT8 TOPS (138 dense), 15-60 W konfigurerbar effekt. Det er virkelig imponerende for et indlejret modul. Det er heller ikke i nærheden af, hvad en moderne VLM-drevet robot ønsker.

Kør regnestykket på tre modelklasser, som du måske rent faktisk vil have en humanoid til at bruge:

Orin AGX 64 GB vil være vært for en 32B-klasse VLM ved INT4, hvis man accepterer langsom inferens, ingen reel batching og ingen samtidige arbejdsbelastninger. Den vil ikke være vært for 70B-klasse VLM'erne, der er state-of-the-art til sceneforståelse i 2026 - Qwen2.5-VL 72B, de større Cosmos-varianter, de proprietære modeller, som leverandører ikke offentliggør vægte for. De kombinerede vægte, KV-cache til lang visuel kontekst og eventuel plads til en anden model passer ikke.

Der er et andet tal, der bliver overset: strøm. Orins 275 TOPS-tal forudsætter MAX_N (60 W) tilstand. Det er en batteridrevet platform, der bruger 60 W beregningskraft oven i en aktuatorbelastning på 200-800 W. Vedvarende MAX_N halverer robottens køretid. I praksis bruger Orin det meste af sin tid i 30 W-tilstand, hvilket halverer TOPS'en omtrent og skubber allerede marginal inferens til "ubrugeligt" område.

Oversættelse: Den indbyggede Jetson er dimensioneret til reaktive og refleksive niveauer. Den er ikke dimensioneret til at være en VLM-vært. Enhver, der fortæller dig, at deres humanoid "kører Qwen2.5-VL indbygget", kører enten 3B- eller 7B-modellen og kalder den god, eller kører den større model ved 0.5 FPS og kalder den en demo. Begge er gyldige til specifikke brugsscenarier. Det er heller ikke generel robotopfattelse.

Hvorfor cloud-løsningen er det forkerte svar på lukket robotteknologi

Cloud-inferens er billig, skalerbar uden besvær og kræver ingen kapitaludgifter. For en robot har den fire problemer, i omtrentlig rækkefølge efter alvorlighed.

1. WAN-latensgrænse. Et velafstemt cloudopkald inden for EU tager 15-40 ms tur/retur på selve WAN'et, plus 5-15 ms TLS/HTTP/load-balancer overhead, plus modelinferenstid plus turen tilbage. Transatlantic tilføjer 80-120 ms tur/retur oveni. For en refleksiv opfattelsesforespørgsel — "er der en forhindring foran mig?" — at tilføje 30-50 ms, før modellen overhovedet starter, er et budgetbrud. deliberative Hvis du planlægger at bruge 200-500 ms, kan du måske tolerere det, men hver tabt pakke, hver retransmission, hver failover til mobilmast fører dig op til det næste niveau.

2. Rystelser. WAN RTT er ikke en konstant. Det er en fordeling. Median 25 ms, P99 250 ms, P99.9 flere sekunder. En robot, der agerer i den virkelige verden, kan ikke acceptere en pause på flere sekunder, fordi en BGP-rute flapper. On-prem LAN P99.9 er 1-2 ms.

3. Omkostninger ved vedvarende belastning. En enkelt 70B VLM-inferens koster en cloududbyder næsten ingenting – de opkræver et par cent. En robot, der "altid opfatter", foretager ét VLM-opkald hver 100-500 ms, mens den er aktiv. Det er 7,000-36,000 opkald i timen pr. robot. En flåde på tre robotter, der kører otte timer om dagen i den øvre ende, er 850,000 opkald. Med blot $0.005 pr. opkald på et hosted 72B-slutpunkt er det $4,250 pr. dag, $125 pr. måned. En on-prem 8× GPU-server tjener sig hjem på under tre måneder ved den belastning.

4. Datasuverænitet. Robotten ser en fabriksgulv, et patientværelse, et forskningslaboratorium, et lager med proprietært lagerlayout, et militært træningsområde. Den video er privilegeret eller reguleret under GDPR, HIPAA, ITAR eller simpel konkurrencefølsomhed. At sende den til en tredjeparts-cloud – selv en, der underskriver en DPA – er enten forbudt eller en ikke-triviel compliance-byrde. On-prem inferens får spørgsmålet om datasuverænitet til at forsvinde: bytes forlader aldrig bygningen.

Der er et femte, blødere problem: leverandørlåsningCloud-API'er betjener de modeller, som udbyderen ønsker at betjene, med de kvantiseringer og kontekstvinduer, som udbyderen har valgt. Du kan ikke køre en finjusteret VLM på OpenAI's endpoint. Du kan ikke fastlåse en specifik commit fra en open-weight-model. Du kan ikke blande modeller fra konkurrerende leverandører i én pipeline. Til prototyping er disse begrænsninger fine. Til en produktionsrobotimplementering, der skal være forudsigelig i årevis, er de ikke det.

Casen med dedikerede servere

En dedikeret on-prem inferensserver sidder i LAN'et, et eller to hop fra robotten. For Kentino K-AI-linjen er det en 4U rackserver, EPYC- eller Xeon-vært, 4× eller 8× GPU, på en 10 GbE-switch. Tallene, den bringer til bordet:

De to kolonner, som on-prem-indstillingen dominerer, er vedvarende gennemstrømning og modelvalgDet er også de to kolonner, der er vigtigst for de arbejdsbyrder, vi er ved at opregne.

En repræsentativ K-AI 256 Turin Dual med 8× RTX 5090 har 256 GB samlet VRAM og 1.0-1.5 kW GPU-kraft under belastning. Det er nok til at hoste, samtidigt:

• Qwen2.5-VL 72B ved INT4 (~45-50 GB vægte + 10-20 GB KV pr. GPU-par, tensor-parallelt på tværs af 4 GPU'er)
• Qwen2.5 32B tekst-only (planlægning, dialog) på 2 GPU'er
• En lille VLA (OpenVLA 7B eller Cosmos-Reason 7B) på 1 GPU til bevægelsesintention
• Scenehukommelse / RAG-lager (pgvector eller ChromaDB) på værts-CPU'en
• Kapacitet til finjustering af onlinepolitikker på den resterende GPU, når robotten er docket

VLM TTFT for Qwen2.5-VL 72B på denne hardware lander i området 200-400 ms ved belastning med én anmodning og stiger til 1-4 sekunder under tung samtidig belastning. Token-streaming er 25-50 tok/s. Det er nok til at placere en 72B VLM i det deliberative planlægningsniveau (100 ms - 1 s) ved belastning med én robot og i det strategiske ræsonnementniveau (1 s - multi-s) for en lille flåde. Ingen af ​​niveauerne er et problem; de reaktive og refleksive niveauer forbliver om bord, hvor de hører hjemme.

Kompetencegab: hvad kun det dedikerede kantniveau tjener

On-prem-serveren er ikke bare "den samme robot, men hurtigere". Den muliggør en klasse af arbejdsbelastninger, som de to andre niveauer strukturelt set ikke kan hoste. Den ærlige liste:

1. Feedback til forståelse af scenen i realtid. En 72B VLM kigger på robottens kamera hvert 200-500 ms og returnerer en struktureret beskrivelse af den scene, som planlæggeren forbruger. Cloud kan ikke gøre dette i stor skala på grund af WAN-jitter og omkostninger. On-board kan ikke gøre dette, fordi modellen ikke passer. On-prem lukker løkken på i alt 250-500 ms.

2. VLM-fusion med flere kameraer. En humanoid har 3-5 kameraer (hoved, to håndled, to krop/bryst). At køre en VLM på tværs af dem alle samtidigt – til rumlig jordforbindelse, okklusionshåndtering eller hånd-øje-koordination – er 5 gange inferensbelastningen. Skyhastighedsgrænser eller opladninger pr. stream. On-board passer til én stream i lille skala. On-prem batches alle fem gennem det samme VLM-slutpunkt.

3. Langsigtet opgaveplanlægning med vedvarende scenehukommelse. "I går glemte jeg skruenøglen på den anden hylde. Find den." Dette kræver et VLM + LLM + vektorlager, der kører sammen med en vedvarende tilstand på tværs af robotsessioner. Tilstanden skal være et stabilt, forespørgselsvenligt og hurtigt sted. Det er en database på serveren, ikke et cloud-kontekstvindue pr. kald, og ikke 4 GB RAM på Jetson.

4. Finjustering af onlinepolitikker. Robotten indsamler opgavedemonstrationer i løbet af dagen. Om natten, mens den er docket, kører du LoRA-finjusteringer på dagens data mod en basis-VLA, pusher den opdaterede adapter, og robotten er bedre i morgen. Dette er et hukommelsesfodaftryk på 2× til 5× i forhold til inferens. Cloud opkræver træning og lagerplads separat. On-prem absorberer det i den samme boks.

5. Koordinering af flåde med flere robotter. To eller tre robotter deler en scenehukommelse, koordinerer opgaver og overvåger hinandens tilstand. Koordinationslaget på tværs af robotter ønsker en latenstid på under 10 ms mellem robotter. On-prem med en delt server på LAN'et leverer det. Cloud kan ikke – hver robots opdatering sendes ud til en region, kommer tilbage og rammer den næste robot.

6. Sim-til-real iteration. Isaac Sim kører på de samme GPU'er, der tjener inferens, genererer syntetiske træningsdata og validerer politikopdateringer, før de rammer den rigtige robot. Dette er en halv dag pr. iteration i skyen (kun dataflytning), et 30-minutters loop on-prem.

Ingen af ​​disse er sci-fi. De er alle arbejdsbelastninger, som robotintegratorer i 2026 kører i dag. Ingen af ​​dem fungerer problemfrit på nogen af ​​de to andre niveauer.

Hvorfor dette er det banebrydende svar i 2026

Den nyeste teknologi inden for robotopfattelse i 2026 er VLM-in-the-loopModellen ser på verden, ræsonnerer om den i sproget, udformer strukturerede planer, og politikken udfører dem. Dette var en forskningsidé i 2023, en produktdemonstration i 2024 og er et produktionsmønster i 2025-2026.

Tendensen til at tvinge on-prem-niveauet frem er ligetil: De VLM'er, der virker, bliver større, ikke mindre. Qwen2.5-VL 7B er god. Qwen2.5-VL 72B er betydeligt bedre. De proprietære modeller, som Frontier Labs ikke udgiver, er endnu større. Stien "lille VLM, der kører på enheden" eksisterer og vil fortsætte med at eksistere, men den halter 12-18 måneder efter Frontier-modellen og har et betydeligt kapacitetsgab. Hvis du vil have Frontier-opførslen, skal du hoste Frontier-modellen. Frontier-modellen passer ikke på en Jetson.

Cloud-teknologien kunne følge med i teorien. I praksis gør den det ikke, af de fire ovenstående grunde (latens, jitter, omkostninger, suverænitet), og fordi frontier-laboratorierne håndterer de største modeller bag partnerskabsniveauer, som en robot-startup ikke har adgang til. VLM'er i 70B-klassen med åben vægt do eksisterer, kan være hosted og køre godt på standard 8-GPU-servere. Denne sammenløb - åbne frontier-klasse modeller plus standard multi-GPU hardware - er grunden til, at on-prem er det rigtige svar lige nu og ikke var det i 2023.

Dette er heller ikke en Kentino-opfattelse. On-prem inferensniveauet er det, NVIDIAs Isaac-stak er bygget op omkring, det de store robotplatforme leverer referencearkitekturer til, og det alle seriøse integratorer, vi har talt med i de sidste seks måneder, klargør. Markedet indhentede hardwaren, der indhentede modellerne, og 2026 er året, hvor det klarede sig.

Når den lokale løsning er det forkerte svar

For at være ærlig: det dedikerede kantniveau er overkill i flere virkelige tilfælde.

• Telestyrede robotter. Operatøren er planlæggeren. Robotten er en marionetdukke med et kontrollink. Der er ingen VLM i loopet; den lille inferens, der sker (poseestimering, videokodning med lav latenstid), kan køre på Jetson. Tilføj cloud til det tunge arbejde, hvis det er nødvendigt. Ingen GPU-server nødvendig.
• Simpel inspektion af firbenede dyr. En robot i Spot-klassen eller Go2-klassen, der går en fast patruljerute med YOLO-detektion og et termisk kamera, behøver ikke en 72B VLM. Den indbyggede Jetson klarer jobbet. Dataene sendes til skyen til analyse efter patruljen, ikke under.
• Demoer og engangspiloter. Du skal bruge systemet kørende til en messe, en kundepitch eller en tre-ugers proof-of-concept-præsentation. Cloud-løsninger klarer det på en eftermiddag. On-prem-investeringer er forkerte til en arbejdsbyrde, der skal nedlægges på en måned.
• Hobby- og uddannelsesmæssig brug. Et universitetslaboratorium med én G1 EDU, et begrænset budget og fokus på RL-træning frem for inferens. Jetson og en enkelt 4090-arbejdsstation kan rumme nok til at udføre meningsfuld forskning. Det fulde K-AI 8×-niveau er den forkerte form for regning.
• Arbejdsbyrder på rene sprog. En robot, der taler, men ikke ser — en assistent med kun stemmestyring på ben. En cloud-LLM API er fin. Latensbudgettet er konversationelt, ikke lukket kredsløb.

Mønsteret: Hvis din robot ikke kører en rigtig VLM i det lukkede perceptionsloop, behøver du ikke det dedikerede kantniveau. Hvis den gør, behøver du det.

Når on-prem-stien taler for det

Det dedikerede kantniveau bliver det rigtige svar, når mindst ét ​​af følgende er sandt, og ideelt set to eller flere:

1. En rigtig VLM er i det lukkede kredsløb. Ikke "til lejlighedsvise spørgsmål" — in perception-to-action-løkken, der kører hvert 100.-500. ms. Dette er den strukturelle årsag til, at on-prem eksisterer.
2. Vedvarende belastning. Otte timer om dagen, fem dage om ugen, på ubestemt tid. Anlægsudgifter amortiseres. Cloud-omkostninger pr. opkald akkumuleres på ubestemt tid.
3. Data må ikke forlade bygningen. GDPR, HIPAA, ITAR, konkurrencepræget eller simpel paranoia. Bytes forbliver på LAN'et. Ikke til forhandling.
4. Flere robotter. To eller flere enheder deler en scenehukommelse eller koordinerer opgaver. Den delte servers amortisering er pr. robot, og latensbudgettet på tværs af robotter kollapser.
5. Tilpasning er vigtig. Finjusterede VLM'er, fastgjorte modelversioner, proprietære hoveder på åbne backbones, niche-kvantiseringer. Friheden er produktet.
6. Iterationshastighed er vigtig. Teamet sender politikopdateringer ugentligt eller hurtigere. Simulation og træning på den samme hardware, mens inferens lukker kredsløbet fra dage til timer.

Hvis du markerer tre eller flere af disse, er spørgsmålet ikke længere if på stedet, men hvilken størrelseFire-GPU K-AI 96 (RTX 4090 eller 5090) niveau er nok til én robot, der udfører rigtigt arbejde. Otte-GPU K-AI 256 (5090 eller Pro 6000 Blackwell) er den rette form til en lille flåde, de største VLM'er eller enhver implementering med et træningskrav ud over inferens.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.