Embodied.cpp: A Portable Inference Runtime of Embodied AI Models on Heterogeneous Robots
1. Paper overview
In one sentence: Embodied.cpp unifies deployment around a C++ runtime, with reported latency and memory gains whose control-quality cost depends on model and precision. e02e03e07e09e10e13e14e15e16
| At a glance | What to know |
|---|---|
| Research problem | Author claim The authors argue that a trained embodied checkpoint still needs sensor wrappers, backend-specific inference and robot-side control integration. They identify three runtime requirements: modules that refresh at different rates, predictable low-latency batch-1 control, and extensible inputs and outputs beyond token serving. The proposed unit of deployment is therefore a stateful interaction system containing perception, prediction and action components. e02 |
| Core mechanism | Source description A runtime-oriented taxonomy separates four VLA and four WAM structures, drawing attention to intermediate subgoals, buffered context and predicted futures as explicit execution state. e03 |
| A key reported result | HY-VLA 4-bit deployment: Latency 0.37; success 0.99; VRAM 0.23. Normalized inference latency, success rate and VRAM. 4-bit C++; the same incompletely specified Table 3 evaluation. Python is 1.00 for every metric; unlabeled C++ gives 0.48, 1.02 and 0.68 respectively. Calculated from the ratios: approximately 2.70× speedup and 77% less VRAM versus Python, with 99% of baseline success retained. This is the strongest latency/memory reduction in Table 3. e10e13e16 |
| Reading caution | Reader analysis Missing task definitions, success criteria, splits, trial counts, seeds and uncertainty prevent a statistical or protocol-equivalence assessment. Missing hardware, software versions, absolute VLA latency and WAM latency prevent deriving an achievable control frequency or hardware-specific speedup. e16 |
Core contributions
- Source description
A runtime-oriented taxonomy separates four VLA and four WAM structures, drawing attention to intermediate subgoals, buffered context and predicted futures as explicit execution state. e03
Figure 1. Different prediction-to-action dependencies motivate explicit modules and runtime state. Original paper, p. 3 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Read each panel downward, using the color legend to distinguish inputs, intermediate representations, outputs and model blocks. The top row moves from an autoregressive action transformer to a separate action head, hierarchical planning and multiple encoder branches. In the WAM row, panel (e) sends a predicted future into policy/inverse dynamics; panel (f) branches one autoregressive backbone into future-image and action tokens. Panel (g) branches the video/world backbone into future video and a separate action decoder, while panel (h) places a latent future or subgoal before the action expert. The arrows agree with the architectural descriptions in Section 2.1 and Table 1. e03e07
What it supports. The runtime must accommodate different dependency structures. A predicted future is an intermediate input to the action path in panels (e) and (h), whereas panels (f) and (g) depict branching from a common backbone. This supports exposing model-specific modules and state instead of assuming every hosted model has the same inference graph.
Where the evidence stops. This is the authors' taxonomy of cited systems, not a new jointly trained architecture. Panel (d) does not draw refresh clocks or buffers; its asynchronous interpretation comes from Section 2.1 and Table 1, not the arrows alone.
2. Motivation
2.1 The problem and the proposed response
The authors argue that a trained embodied checkpoint still needs sensor wrappers, backend-specific inference and robot-side control integration. They identify three runtime requirements: modules that refresh at different rates, predictable low-latency batch-1 control, and extensible inputs and outputs beyond token serving. The proposed unit of deployment is therefore a stateful interaction system containing perception, prediction and action components. e02
2.2 What this reading follows
A robot policy needs more than a fast neural-network forward pass: observations must enter, model components must exchange state, and outputs must reach a control interface. Embodied.cpp organizes those responsibilities into a common runtime for vision-language-action and world-action models. Its strongest evidence is a set of backend and precision comparisons, including a substantial HY-VLA latency reduction and lower WAM memory use. Read the figures as architectural proposals and the tables as measured trade-offs under incompletely specified protocols. The useful question is which deployment costs the runtime can share across models, and which quality losses or timing guarantees still require direct testing. e02e03e07e09e10e13e14e15e16
3. Research context
We place the paper in the collection through its world–action interface. The catalog labels and the reading’s assessment are shown separately.
| Catalog dimension | Recorded classification |
|---|---|
| Major category | Foundational work |
| Architecture | Not applicable |
| Prediction paradigm | Not applicable |
| Quadrant | Not applicable |
This table preserves the labels recorded at reading time. The current major category is Related resources. View the current classification.
3.1 Evidence-based assessment
Conflicts with the recorded classification
Foundational work and Surveys & technical resources fit the runtime contribution. Architecture, prediction paradigm and quadrant are appropriately Not applicable: a common execution substrate is not a One Model WAM. The specific conflict is Training optimization & distillation, because the supplied contribution concerns inference infrastructure and quantized deployment without a new training or distillation method. The catalog snapshot is preserved exactly. e02e03e07e08e10e16
This is the collection’s architectural analysis, not a new related-work survey. Benchmark comparisons and their protocols appear in Section 6.
4. Problem formulation
4.1 Inputs and outputs
| Inputs | Outputs |
|---|---|
|
|
5. Method in detail
5.1 Separate the model's dependency graph from the runtime's shared path
Begin with the lower row of Figure 1. A predict-then-act model must produce a future representation before its policy or inverse-dynamics component can use it. A unified autoregressive model instead places future and action generation under one backbone, while the shared-backbone panel exposes separate future-video and action-decoder branches. These differences explain why Embodied.cpp names head plugins alongside sequence construction and backbone execution: a portable runtime needs to preserve each hosted model's dependencies. Figure 2 then adds input and deployment adapters around that computation. Reader interpretation: the reusable object is the execution infrastructure, not one universal learned policy. The source does not provide token layouts, tensor contracts or a model-specific graph, so the five-layer description cannot by itself be converted into an implementation recipe. e02e03e09
Figure 2. A stable deployment interface surrounds model-specific computation and execution services. Original paper, p. 9 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Start at the left, where sensor modalities and dataset examples sit beside the input adapter. The center groups the model gallery with the runtime library; arrows from its inputs lead to execution and then branch to future-world and action outputs. Below are three supporting services: modular multi-rate execution, batch-1 heterogeneous-hardware execution and the kernel warehouse. CPU, GPU and NPU backends sit underneath, while the output adapter borders the simulator/robot platforms on the right. Section 3.2 explains these as deployment interfaces and reusable execution services. The five named layers in the introduction are a finer organizational description than the boxes drawn here. e02e07e08e09e16
What it supports. The figure identifies what the runtime intends to reuse: input/output boundaries, scheduling support, device execution and operators. Future prediction and action generation remain properties of the hosted models. The common runtime is consequently infrastructure for several architectures, rather than evidence that all models share one learned world representation.
Where the evidence stops. The platform logos and hardware pictures do not identify evaluated devices. Section 4 omits hardware and adapter configurations. The figure also gives no executable scheduling rule, synchronization protocol or guarantee that its future-world output is consumed before every action.
5.2 Treat multi-rate execution as a state-management problem
Section 3.1 gives the motivating asymmetry: perception need not refresh at the action head's rate, and a predictive branch may run only when future estimation is required. Section 3.2 therefore calls for explicit execution units, shared state or feature pools and configurable refresh policies. Its latency-first principle additionally lists graph replay, buffer reuse, fusion and device dispatch. Reader interpretation: reducing computation and deciding which state is fresh enough are separate responsibilities. Faster kernels can shorten an invocation, while a refresh policy changes which invocation happens at all. The paper does not specify the synchronization or stale-state rules connecting those decisions. Its evaluation reports aggregate backend results without jitter distributions or a scheduling ablation, leaving predictable closed-loop timing an intended capability that still needs direct verification. e07e08e09e16
5.3 Read efficiency and control quality on their own scales
For Table 3, first keep the model fixed, then compare a single configuration across latency, success and memory. HY-VLA at 4-bit has ratios 0.37, 0.99 and 0.23: the reciprocal latency ratio gives approximately 2.70× speedup, while the memory ratio means 77% less VRAM. These calculations say nothing about the absolute control frequency because the baseline milliseconds are absent. Next examine pi0.5: 8-bit and 4-bit have identical reported latency ratios, but success retention falls from 0.90 to 0.70. Finally, change interpretation for Table 4, where success is reported as an absolute percentage. LingBot-VA's 100% to 98% change is two percentage points. Reader interpretation: a deployment choice must consider the joint trade-off and measurement protocol, not a single speedup headline. e10e11e13e15e16
5.4 Training and inference
During training
This is an inference-runtime contribution. No new learning objective, training schedule, frozen-module recipe, distillation algorithm or governing method equation is specified. Training approaches reviewed in related work are not Embodied.cpp training procedures. e05e07e08e09e16
The evaluated C++ variants include 8-bit, 6-bit and 4-bit configurations. Quantization algorithms, calibration data, precision allocation and any adaptation procedure are omitted; the unlabeled C++ and Python precisions are also unspecified. e10e16
During inference
Learned future prediction and action generation belong to the hosted model. A shared runtime does not imply jointly learned parameters across its model gallery. Figure 2 shows future-world and action outputs branching from model execution, followed by a deployment boundary; it does not specify a feedback controller or guarantee physical actuation. e03e09
5.5 Implementation flow
- Normalize the deployment boundary
Typed input adapters accept sensor streams and dataset samples. Figure 2 depicts examples of modalities and datasets; it does not establish that every listed input was used in the reported experiments. Sensor synchronization and preprocessing rules are unspecified. e09e16
- Construct and execute the shared path
Sequence builders precede backbone execution in the named five-layer architecture. The paper supplies this organizational description, but no concrete sequence layout, tensor specification or per-model execution graph. e02e09
- Keep prediction and action model-dependent
Head plugins accommodate action experts and predictive components. The taxonomy distinguishes future prediction followed by policy/inverse dynamics, joint autoregressive future/action generation, shared-backbone branching and latent-subgoal prediction. Embodied.cpp hosts these structures without defining one universal action-extraction algorithm. e03e09
- Expose state and refresh policies
The design calls for explicit execution units, shared state or feature pools and configurable refresh policies. Perception, prediction and action modules may run at different rates. A concrete scheduler, stale-state policy and temporal synchronization algorithm are not specified. e07
- Optimize and dispatch
Latency-first design principles list graph replay, buffer reuse, operator fusion, backend-specific dispatch and careful host-device movement. A kernel warehouse collects reusable operators and model-specific kernels; output adapters connect the result to robot and simulator stacks. e08e09
6. Experiments & results
Embodied.cpp proposes a common C++ execution and deployment framework for VLA and world-action models, with pluggable heads and stateful scheduling. Its strongest reported VLA configuration, 4-bit HY-VLA, has latency and VRAM ratios of 0.37 and 0.23 versus Python, while retaining 0.99 of baseline success. The results expose useful deployment trade-offs, but the paper omits the task protocols, hardware and mechanism ablations needed to establish reproducible control performance.
The source contains two architecture/overview figures, an architectural comparison table, a capability matrix and two quantitative deployment tables. Section 4 supplies no dedicated mechanism ablation, latency/jitter plot, heterogeneous co-execution benchmark or WAM latency/prediction-quality evaluation. Table 3 is included as a precision/configuration diagnostic, not evidence isolating scheduling, replay, buffering or fusion. The four selected crops cover the method overview, dependency taxonomy and both quantitative tables. e03e04e07e08e09e10e14e15e16
6.1 Read the original evidence
Table 4. Two WAM backend comparisons report lower memory with small absolute success decreases. Original paper, p. 10 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Read the two rows for each model as a backend pair. Unlike Table 3, these success values are absolute percentages and the memory values are GB. Cosmos3 moves from 49.00% success and 21.84 GB in Python to 48.00% and 19.49 GB in C++. LingBot-VA moves from 100.00% and 24.75 GB to 98.00% and 16.44 GB. The surrounding WAM evaluation paragraph identifies the metrics as closed-loop success and peak VRAM. Compare backends within each model; the table supplies no shared task protocol that would justify ranking Cosmos3 against LingBot-VA by their success rates. e14e15e16e17
What it supports. The reported backend changes reduce success by 1 percentage point for Cosmos3 and 2 percentage points for LingBot-VA while using less memory. The authors report a 33.6% memory reduction for LingBot-VA. These are numerical deployment comparisons, even though the conclusion characterizes the revision's WAM evidence as architectural positioning.
Where the evidence stops. No WAM latency, video-quality metric, hardware, trial count or physical-versus-simulated setting is specified. The conclusion on page 11 conflicts with Section 4's numerical WAM evidence; the edition preserves that discrepancy without inferring results for another revision.
6.2 Results and evaluation conditions
| Task & protocol | Reported result | Comparison & interpretation |
|---|---|---|
| HY-VLA C++ deployment C++ without a bit-width label; Section 4 calls the VLA evaluation closed-loop. Task, split, hardware and trial count unspecified. | Latency 0.48; success 1.02; VRAM 0.68. Normalized inference latency, success rate and VRAM | Each Python metric is independently normalized to 1.00. Reported latency is 52% lower and memory 32% lower. Success is 1.02 times baseline, not 102% absolute success; significance cannot be determined. e10e13e16 |
| HY-VLA 4-bit deployment 4-bit C++; the same incompletely specified Table 3 evaluation. | Latency 0.37; success 0.99; VRAM 0.23. Normalized inference latency, success rate and VRAM | Python is 1.00 for every metric; unlabeled C++ gives 0.48, 1.02 and 0.68 respectively. Calculated from the ratios: approximately 2.70× speedup and 77% less VRAM versus Python, with 99% of baseline success retained. This is the strongest latency/memory reduction in Table 3. e10e13e16 |
| GR00T N1.7 4-bit deployment 4-bit C++; task, split, hardware and trial count unspecified. | Latency 0.65; success 0.96; VRAM 0.38. Normalized inference latency, success rate and VRAM | Python is 1.00 for every metric. Latency and VRAM fall by 35% and 62%, respectively; absolute task success cannot be recovered from its 0.96 ratio. e10e12e16 |
| pi0.5 precision comparison 8-bit versus 4-bit C++; task, split, hardware and trial count unspecified. | 8-bit: 0.88 latency, 0.90 success, 0.41 VRAM. 4-bit: 0.88 latency, 0.70 success, 0.30 VRAM. Normalized inference latency, success rate and VRAM | Python is 1.00 for every metric. 4-bit saves additional memory without improving the reported latency over 8-bit. Its 30% relative success loss versus Python qualifies the accompanying prose's broad success-retention claim. e10e11e16 |
| Cosmos3 WAM deployment Author-described closed-loop evaluation; task, split, physical/simulated environment, hardware and trial count unspecified. | C++: 48.00% success; 19.49 GB VRAM. Success rate and peak VRAM | Python: 49.00% success; 21.84 GB VRAM. Reported success decreases by 1 percentage point with lower memory. No WAM latency or future-prediction quality metric is supplied. e14e16 |
| LingBot-VA WAM deployment Author-described closed-loop evaluation; task, split, physical/simulated environment, hardware and trial count unspecified. | C++: 98.00% success; 16.44 GB VRAM. Success rate and peak VRAM | Python: 100.00% success; 24.75 GB VRAM. Reported success decreases by 2 percentage points and VRAM by 33.6%. The unspecified evaluation does not establish verified physical deployment or visual prediction fidelity. e15e16 |
6.3 Ablations and diagnostic examples
Read component removals and qualitative examples within their stated evaluation conditions.
Table 3. A precision sweep reveals model-dependent quality costs beneath the efficiency gains. Original paper, p. 10 ↗
Excerpt from the authors’ paper; cropped without altering the figure or table.
How to read it. Choose one model row and read the same configuration across all three metric groups. Every Python entry is independently normalized to 1.00, so values are ratios within a model and metric, not absolute milliseconds or absolute success percentages. Lower latency and VRAM are favorable; higher success is favorable. For HY-VLA, the 4-bit column gives 0.37 latency, 0.99 success and 0.23 VRAM. Now compare pi0.5 at 8-bit and 4-bit: latency stays at 0.88, while success changes from 0.90 to 0.70 and VRAM from 0.41 to 0.30. The original caption defines latency per generated action step before normalization. e10e11e12e13e16
What it supports. HY-VLA's 4-bit ratios imply approximately 2.70× speedup and 77% less VRAM versus its Python baseline, while retaining 99% of baseline success. The pi0.5 comparison is a counterexample to a uniformly benign precision reduction: additional memory savings accompany lower success without a reported latency benefit over 8-bit.
Where the evidence stops. This is a configuration diagnostic, not an isolated scheduling or fusion ablation. Hardware, task protocols, quantization recipes and uncertainty are absent. In particular, a 0.70 success ratio is a 30% relative loss, not a 30-percentage-point loss.
7. Analysis & limitations
7.1 What the evidence leaves open
Missing task definitions, success criteria, splits, trial counts, seeds and uncertainty prevent a statistical or protocol-equivalence assessment. Missing hardware, software versions, absolute VLA latency and WAM latency prevent deriving an achievable control frequency or hardware-specific speedup. e16
No experiment separately tests refresh policies, fusion, graph replay, jitter or heterogeneous device cooperation. Table 2's capability checks are author assessments, and the platform images in Figure 2 are an overview rather than a measured portability matrix. e04e07e08e09e16
The conclusion says this revision validates three VLA models quantitatively and positions WAMs through architectural analysis. Section 4 nevertheless supplies two numerical WAM comparisons. Both statements are retained as an internal revision inconsistency. e14e15e17
7.2 Questions for discussion
- Which module's precision accounts for pi0.5's success loss, and can selective higher precision recover it?
- What state-age and synchronization rules make separately scheduled prediction and action safe for the intended control loop?
- How much of the latency reduction survives when precision, checkpoint, hardware and episode seeds are matched?
8. Reproducibility audit
8.1 Requirements and known gaps
A reproduction needs exact checkpoints, hardware and backend/compiler versions, adapters, quantization recipes, task definitions, rollout horizons and seeds. Section 4 supplies model labels but not these specifications; Cosmos3 in particular is not resolved to an exact evaluated checkpoint. e10e14e16
Reader-proposed checks should separate backend implementation effects from precision effects, and independently test multi-rate scheduling at fixed precision. Matched episodes, absolute latency distributions, state freshness, peak memory and success would make these comparisons discriminating. e07e08e11e16
The title page provides an Embodied.cpp project link; the paper itself does not supply an installation procedure or executable reproduction configuration. e18e16
8.2 Proposed reproduction checks
The following checks are proposals motivated by the paper. They have not been run as part of this reading.
Check 1: Isolate pi0.5's precision cost from the backend change
Reader-proposed experiment, not performed: first document one exact pi0.5 checkpoint, device, manipulation task, preprocessing pipeline and success criterion. Use 100 paired initial conditions with the same rollout horizon for Python, C++ at matching precision, and C++ at 8-bit and 4-bit. Keep scheduling and execution options fixed, and record absolute per-action-step latency, peak VRAM, success counts and uncertainty. The discriminating observation is whether 4-bit again loses success relative to 8-bit without lowering latency. If the loss disappears under a matched protocol, Table 3's pi0.5 trade-off does not generalize to that setting; if it persists, selectively restoring module precision can localize the sensitivity. The task and trial count here are proposed controls, not recovered paper settings. e10e11e16
Check 2: Test whether slower refresh improves latency without stale-state failures
Reader-proposed experiment, not performed: after specifying the missing module interfaces, hold one modular checkpoint, precision, hardware and action cadence fixed. Compare refreshing all components every action step against refreshing perception every second or fourth step through a shared feature pool; keep graph replay and fusion settings identical. Use paired episodes containing a documented scene change and log observation timestamps, feature age, sensor-to-action latency distributions, peak VRAM and success. The hypothesis is that reduced refresh lowers latency while preserving task success. Lower median latency accompanied by stale-feature failures or worse tail latency would falsify the stronger claim of improved stable control for that schedule. The refresh intervals are proposed experimental settings, since the paper supplies no concrete policy. e07e08e09e16
8.3 Reading coverage
Visual audit: Visually inspected the title/author/affiliation/version page, every body page through the conclusion, Figures 1–2 and Tables 1–4. All numerical, method, training-omission, evaluation and reproduction statements in the bundle are supported by these declared pages. Figure 1's relevant dependency arrows were checked against Section 2.1 and Table 1; Figure 2 was checked against its caption and Section 3.2, with no claim-relevant arrow conflict observed. Both numerical tables were checked directly, including all precision columns and WAM units. Each of the four final original crops was viewed after extraction; labels and the Figure 1 legend are retained and long captions excluded. The text reading covered all five chunks and references through page 18; reference-only pages 12–18 were not separately viewed. No appendix was present, and separate supplement availability remains unverified.
PDF pages inspected for this edition: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11. Appendix coverage: not present.
Original figures and tables remain the work of the source’s authors. Extractions preserve their scientific content; any HTML wrapper layout is disclosed with each figure. The surrounding reading notes are our own.
Text reading scope & known omissions
- Title, authors, affiliations, version stamp and abstract (p. 1)
- 1. Introduction (pp. 1–2)
- 2. Related Work and Motivation, including 2.1–2.3 (pp. 2–7)
- 3. Project Overview, including 3.1 Challenges and 3.2 Design Principles and Runtime Architecture (pp. 7–9)
- 4. Evaluation (pp. 9–10)
- 5. Conclusion (p. 11)
- References [1]–[89] (pp. 11–18)
Outside the original text pass
- Identity and edition scope: the observed title and all eleven authors match the catalog. The title page bears a 2026-07-01 header and an arXiv:2607.02501v3 stamp dated 9 August 2026; the catalog's submittedDate matches the latter. Only this supplied revision was read; no earlier edition was supplied for comparison. [e01]
- Text extraction does not reconstruct figure images; inspect the retained PDF for figures and equation/table layout.
- The preceding acquisition limitation was addressed by inspecting PDF body pages 1–11, both original figures, all four tables and every final crop. All five supplied text chunks were read individually through the end of the references.
- Separate supplemental material availability has not been fully verified.
- No appendix or separate supplement was supplied. References on pages 12–18 were read as text, without a separate visual pass.
- The linked project, code and external cited works were not inspected; no installation or experiments were performed.
The visual audit above records the subsequent illustrated pass.
8.4 Traceable evidence
e01PDF p. 1, title, author/affiliation block, header date and arXiv stamp
The exact observed title and all eleven author identities match the catalog. The header reads 2026-07-01; the margin identifies arXiv:2607.02501v3 [cs.RO], 9 Aug 2026. Four institutions are named.
Go to primary source ↓e02PDF pp. 1–2, abstract and Section 1, requirements, overview and contribution list
The authors motivate multi-rate execution, latency-first batch-1 control and extensible interfaces, and name input adapters, sequence builders, backbone execution, head plugins and deployment adapters as five runtime layers.
Go to primary source ↓e03PDF pp. 3–4, Figure 1 panels (a)–(h), caption, Table 1 and Section 2.1
Four VLA and four WAM structures differ in prediction/action coupling. Figure 1 uses purple inputs, green intermediate representations, orange outputs and gray model blocks. Panel (e) routes predicted future through policy/inverse dynamics; (f) branches a unified AR backbone to future-image and action tokens; (g) branches a video/world backbone to future video and an action decoder; (h) routes a latent future/subgoal to an action expert.
Go to primary source ↓e04PDF p. 5, Table 2, caption and Section 2.2 discussion
The capability matrix marks all seven Embodied.cpp columns as supported. Its heterogeneous-hardware definition requires jointly using heterogeneous devices, beyond merely switching backends. This table is a categorical comparison, not a measured deployment benchmark.
Go to primary source ↓e05PDF pp. 6–7, Section 2.3, embodied-workload-aware inference optimization
The related-work discussion covers action decoding, temporal caching, asynchronous execution and predictive-path optimization. These are descriptions of cited systems; the authors motivate a portable runtime combining useful optimization approaches.
Go to primary source ↓e07PDF p. 7, Section 3.1, challenge 1; p. 8, Section 3.2, principle 1
The proposed runtime should expose execution units, pluggable modules, shared state or feature pools and configurable refresh policies so perception, predictive branches and action heads can run at different rates. No concrete scheduler or synchronization algorithm is presented.
Go to primary source ↓e08PDF p. 8, Section 3.2, principles 2 and 3
Design principles list graph replay, buffer reuse, operator fusion, backend-specific dispatch, host-device movement, typed embodied interfaces, pluggable heads and deployment adapters.
Go to primary source ↓e09PDF p. 8, Section 3.1, challenge 3; p. 9, Figure 2, caption and Section 3.2 explanation
The source describes sensor/dataset input adapters, an embodied model gallery/runtime, future-world and action outputs, scheduling and batch-1 subsystems, a kernel warehouse, CPU/GPU/NPU backends and robot/simulator output adapters. It presents an architectural overview, without per-model tensor layouts or implementation algorithms.
Go to primary source ↓e10PDF p. 9, Section 4 opening; p. 10, Table 3 caption, headers and VLA evaluation paragraphs
VLA deployment is described as closed-loop. Each model's Python baseline is independently set to 1.00 for latency, success and VRAM. Latency is measured per generated action step in ms/step before normalization. C++ variants are unlabeled, 8-bit, 6-bit and 4-bit.
Go to primary source ↓e11PDF p. 10, Table 3, pi0.5 row, all C++ columns; VLA evaluation prose
Unlabeled/8-bit/6-bit/4-bit latency ratios are 0.90/0.88/0.95/0.88; success ratios 0.92/0.90/0.93/0.70; VRAM ratios 0.60/0.41/0.35/0.30. The prose broadly describes success retention as high across configurations.
Go to primary source ↓e12PDF p. 10, Table 3, GR00T N1.7 row
Unlabeled/8-bit/6-bit/4-bit latency ratios are 0.72/0.70/0.70/0.65; success ratios 0.96/0.97/0.97/0.96; VRAM ratios 0.93/0.57/0.48/0.38.
Go to primary source ↓e13PDF p. 10, Table 3, HY-VLA row
Unlabeled/8-bit/6-bit/4-bit latency ratios are 0.48/0.38/0.39/0.37; success ratios 1.02/1.00/1.01/0.99; VRAM ratios 0.68/0.27/0.25/0.23.
Go to primary source ↓e14PDF p. 10, Table 4, Cosmos3 rows and WAM evaluation paragraphs
Python: 49.00% success, 21.84 GB VRAM. C++: 48.00%, 19.49 GB. The accompanying text defines these as closed-loop success and peak VRAM.
Go to primary source ↓e15PDF p. 10, Table 4, LingBot-VA rows and final WAM evaluation paragraph
Python: 100.00% success, 24.75 GB VRAM. C++: 98.00%, 16.44 GB. The text reports a 33.6% memory reduction.
Go to primary source ↓e16PDF pp. 9–10, complete Section 4; pp. 7–9, complete Section 3
The design and evaluation omit a training procedure, task identities/splits, success definitions, trial counts, seeds, uncertainty, checkpoint identifiers, hardware/software configurations, absolute VLA latency, WAM latency and quantization recipes. No independent mechanism ablation, jitter distribution or heterogeneous co-execution experiment is supplied.
Go to primary source ↓e17PDF p. 11, Section 5, conclusion paragraph
The conclusion describes quantitative validation on three VLA models and WAM positioning through architectural analysis, despite Table 4's numerical WAM deployment comparisons.
Go to primary source ↓e18PDF p. 1, Project Link
The paper links https://github.com/SEU-PAISys/Embodied.cpp.
Go to primary source ↓8.5 Primary sources
Embodied.cpp: A Portable Inference Runtime of Embodied AI Models on Heterogeneous Robots ↗
PDF · 7,029 extracted words
Source fingerprint
6a105e5c018dd51c045a27ea4de9dd69d41c7d2691a11e5dc5d3beee93de66db