RhinoVLA Technical Report
Huixi Intelligence
arXiv:2606.07383v1 [cs.RO] 5 Jun 2026
Abstract Vision-Language-Action (VLA) models have shown strong potential for robotic manipulation, but real-time deployment on edge hardware remains challenging. In this work, we identify VLM visual and context tokens as a major source of deployment latency: for GEMM-dominated projection operators, computation grows linearly with the number of input tokens when model dimensions are fixed. Motivated by this observation, we propose RhinoVLA, a deployment-oriented VLA model co-designed with the Huixi R1 edge SoC. RhinoVLA adopts a token-efficient Qwen3-VL backbone and a continuous Action Expert, reducing the VLM-side token and computation burden while preserving pretrained multimodal capability. To support cross-robot learning, RhinoVLA further introduces a unified interface that combines View Registry, 72D physical state-action slot space, and robotinstance LoRA, allowing heterogeneous robot observations and action schemas to be aligned under a shared policy. On the deployment side, RhinoVLA is optimized through hardware-aware compilation, mixed-precision execution, and parallel visual encoding. Experiments show that RhinoVLA achieves downstream performance comparable to π0.5 at a similar parameter scale, while reaching 11.69 Hz end-to-end inference on Huixi R1, meeting the 10 Hz real-time closedloop control target. The project will be open-sourced at https://github.com/ HuixiAI/RhinoVLA.
1
Introduction
Vision-Language-Action (VLA) models have recently shown strong potential for robotic manipulation and embodied decision-making [5, 46, 17, 4, 3]. By combining visual perception, language understanding, and continuous action generation, these models provide a promising path toward general-purpose robot policies. However, deploying VLA models on real robots remains difficult. Modern VLA systems often use pretrained vision-language backbones with long multimodal contexts, and iterative action-generation modules. These components improve policy capability, but they also introduce substantial computation and memory traffic, making real-time closed-loop inference challenging on onboard edge hardware. The key deployment bottleneck is not model size alone, but how the VLA token structure maps to edge hardware. In a typical VLA pipeline, the VLM backbone processes visual observations and language context before the Action Expert generates continuous actions. Our analysis of π0.5 [31] shows that the VLM Backbone and Action Expert dominate end-to-end latency on NVIDIA Jetson AGX Orin [23], together accounting for more than 90% of the total runtime. A closer operator-level breakdown further shows that most VLM latency comes from MLP projection operators. Since these projections are GEMM-dominated, their FLOPs scale linearly with the number of VLM visual and context tokens when the hidden dimensions are fixed. Therefore, two VLA models with a similar parameter scale can have very different inference speeds if they use different visual-token organizations. This token-scaling property directly motivates our algorithm-system co-design. On the algorithm side, we need a VLM backbone that is not only pretrained for strong multimodal reasoning, but also
efficient in its visual token representation. We therefore build RhinoVLA on Qwen3-VL [1]. Under a common 256 × 256 image setting, Qwen3-VL can represent one image with about 64 merged visual tokens, while PaliGemma-224 [2] uses 256 image tokens. This lower visual-token cost is especially important for VLA inference, where multiple camera views and language context are processed by the VLM before action generation. On the hardware side, because the VLM occupies a large fraction of VLA runtime and its dominant operators are mostly compute-bound, VLA inference benefits from an edge SoC with high onboard compute headroom. We therefore deploy RhinoVLA on Huixi selfdeveloped chip R1, a 7 nm edge SoC with 500 TOPS INT8 compute, providing stronger AI compute headroom than Orin-class edge platforms. To translate this peak capability into actual inference speed, we further optimize RhinoVLA on R1 with hardware-aware compilation, mixed-precision execution, and parallel visual encoding. Beyond inference efficiency, RhinoVLA is designed to address another central challenge in VLA training: heterogeneous robot datasets do not share a unified input-output interface. Different robots may use different camera layouts, view orders, sensing modalities, action definitions, end effectors, and low-level control conventions. Directly pooling such data can make the learning problem illdefined, because the same image index may correspond to different camera roles, and the same action dimension may denote different physical quantities across robots. RhinoVLA resolves this mismatch with a unified interface and a unified pre-training strategy. A View Registry explicitly tags each image with its camera role and modality. A unified 72D physical slot space, together with binary state and action masks, assigns fixed physical semantics to state-action dimensions and excludes invalid slots from supervision. Robot-instance LoRA [14] modules model residual embodiment-specific behavior without introducing robot-specific output heads. During pre-training, RhinoVLA jointly optimizes the VLM LoRA, shared Action Expert, and robot-instance LoRA on mixed robot data. The masked flow-matching loss supervises only valid action slots, while residual regularization keeps the LoRA adapters focused on embodiment-specific corrections. This lets RhinoVLA learn shared visuomotor structure while retaining low-cost robot adaptation.
VLA RhinoVLA
Chip & System R1
Robot
System Board
Real-time control Freq (Hz)
Algorithm-system co-design for VLA stack
Real-time
11.69
10
1.17 π0.5 @Orin X
RhinoVLA @R1
Embodiment-agnostic deployment Task: Sort the red bag, black fan, and white foam into separate compartments.
AGIBOT G2
GALBOT G1
Figure 1: RhinoVLA achieves real-time edge control at 11.69 Hz through algorithm–system co-design and enables embodiment-agnostic deployment across diverse robots. Shown in Figure 1, these algorithm–deployment co-design choices translate into a VLA system with both competitive policy performance and real-time onboard inference. RhinoVLA keeps a parameter scale comparable to π0.5 , but achieves substantially higher end-to-end speed by reducing the VLM token burden and improving hardware utilization on R1. It reaches downstream task accuracy comparable to π0.5 and runs at 11.69 Hz on Huixi R1, meeting the 10 Hz closed-loop inference target [21, 16]. Our contributions are summarized as follows: 2
• We identify VLM visual and context tokens as a key source of VLA deployment cost. Based on this observation, we design RhinoVLA around a token-efficient Qwen3-VL backbone, enabling faster inference than PI-style models at a comparable parameter scale. • We introduce a unified cross-robot training framework. This framework enables RhinoVLA to learn shared visuomotor structure across heterogeneous robot embodiments while preserving embodiment-specific flexibility. • Through algorithm-system co-optimization, RhinoVLA achieves downstream task accuracy comparable to π0.5 while reaching 11.69 Hz end-to-end inference on the Huixi R1 edge SoC.
2
Background
2.1
Vision-Language-Action Models
Early VLA models mainly followed an end-to-end robot policy design. RT-1 [5] uses a transformerbased policy that takes visual observations and language instructions as inputs and predicts tokenized robot actions, trained mainly on large-scale robot trajectories from the Everyday Robots platform. RT-2 [46] further extends this paradigm by representing robot actions as text tokens and co-fine-tuning a pretrained VLM on both robot trajectories and web-scale vision-language data, making robot control compatible with next-token prediction. However, in these systems, visual-language understanding and action prediction are still tightly coupled within a single policy, and the action interface is largely discretized or tokenized for scalable training. Recent VLA models have gradually shifted toward a more modular architecture. Systems such as π0 [4], π0.5 [31], and GR00T N1 [3] typically build on pretrained VLM backbones for visuallanguage understanding, while introducing dedicated action modules for continuous robot control. π0 uses a flow-matching action expert on top of a pretrained VLM; π0.5 combines discrete actiontoken pretraining with continuous flow-matching post-training; and GR00T N1 adopts a dual-system design where a VLM module interprets visual-language inputs and a DiT-based [29] action module generates motor actions. Meanwhile, training data has expanded from relatively narrow robotplatform datasets toward cross-embodiment and heterogeneous mixtures, including multi-robot trajectories, web vision-language data, simulation, synthetic data, and human videos. This evolution improves the task-level capability and cross-embodiment generalization of VLA models, but also makes edge deployment increasingly challenging due to the high computation cost of pretrained VLM backbones, long multimodal context, and the real-time latency requirements of closed-loop robot control. Therefore, designing more efficient VLA architectures is necessary for practical deployment on resource-constrained robotic platforms. 2.2
VLM Backbones for VLA Models
The development of VLA backbones follows the broader progress of vision-language models. Early VLMs mainly focused on large-scale image-text alignment: CLIP [34] learned transferable visual representations from natural-language supervision, while later models such as Flamingo and LLaVA [19] extended VLMs toward interleaved image-text understanding, few-shot visual prompting, and visual instruction following. As a result, pretrained VLMs have become a natural choice for providing semantic visual-language representations in robot policies. When used in VLA models, the VLM backbone must balance semantic capability and deployment cost. Large backbones can improve instruction understanding and generalization, but their parameter size and visual token cost directly affect robotic deployment, especially on edge hardware. Existing VLA systems therefore span different scales. RT-2 [46] uses large PaLI-family VLMs [2], with RT-2-X [27] reaching the 55B scale, and represents robot actions as text tokens. OpenVLA [17] uses a 7B Prismatic-style VLM built from DINOv2 [28], SigLIP [42], and Llama 2 [38], and is trained on 970k robot demonstrations. In contrast, π0 adopts a more compact PaliGemma backbone of about 3B parameters and adds a 300M-parameter action expert, resulting in a 3.3B-parameter VLA. This comparison shows a practical trend: modern VLA systems increasingly use a pretrained VLM as the semantic backbone, but smaller and more efficient backbones are preferred when real-time edge deployment is considered. 3
The Qwen-VL series [39, 33, 1] is a promising backbone direction under this trend. Earlier QwenVL variants have already been used in VLA systems, such as DexVLA [40] with Qwen2-VL-2B and LingBot-VLA [41] with Qwen2.5-VL. Qwen3-VL further improves several capabilities that are directly useful for VLA: spatial-temporal modeling, fine-grained visual feature usage, long interleaved multimodal context, and timestamp-based video grounding. These upgrades better match multi-view robot observations, short visual histories, object grounding, and temporally changing scenes. Recent Qwen3-VL-based VLA examples, including VLA Foundry and InternVLA-A1, suggest that Qwen3-VL is becoming an important candidate backbone for future efficient VLA systems. 2.3
Edge Hardware for VLA Deployment
Existing VLA deployment hardware mainly includes desktop GPUs and NVIDIA Jetson edge platforms. Desktop GPUs such as RTX 4090/5090 [22, 24] offer strong compute capability and a mature CUDA ecosystem, but their high power, large form factor, and cooling requirements make them unsuitable for on-board robotic deployment. Jetson platforms such as Orin [23] and Thor [25] are more compact and widely used in robotics; however, Orin has limited compute headroom for 10 Hz VLA inference, while Thor offers higher performance at a much higher system cost. Recently, high-performance Chinese edge SoCs from vendors such as Huixi have also been adopted by robotics companies. In this work, we use Huixi R1, a 7 nm SoC designed for embodied intelligence. R1 provides 500 TOPS INT8 compute, an 8-core SIMT architecture, and 200 GB/s-class memory bandwidth, offering strong compute and memory support for multimodal visual encoding and VLA inference. It has also been adopted by leading embodied intelligence companies such as AgiBot as an on-board compute chip.
3
Method
3.1
Performance analysis
3.1.1
VLA Roofline Analysis
To quantify the deployment bottleneck of current VLA models on edge hardware, we conduct an end-to-end roofline analysis using NVIDIA Jetson AGX Orin as a representative platform. Orin provides a theoretical FP16 throughput of approximately 43 TFLOPS and a memory bandwidth of around 203 GB/s. Considering practical factors such as operator efficiency, scheduling overhead, irregular memory access, and model complexity, we assume an ideal compute utilization of 40%, corresponding to an effective FP16 throughput of approximately 17.2 TFLOPS. We select several representative VLA models, including π0.5 , GR00T N1, and RDT [31, 3, 20], and estimate their end-to-end computational requirements under different control frequencies. The estimation covers the main inference stages, including vision encoding, VLM prefill, and action expert inference. As shown in Figure 2, π0.5 and RDT already approach or exceed Orin’s effective roofline limit at a target frequency of 5 Hz, and significantly exceed the hardware capability at 10 Hz and above. This indicates that, even under the relatively optimistic assumption of 40% compute utilization, current edge hardware can hardly support these VLA models to meet the minimum real-time closed-loop control requirement of 10 Hz. 3.1.2
VLA Latency breakdown
To identify the major sources of latency in end-to-end VLA inference, we conduct a breakdown analysis of the π0.5 PyTorch-SDPA inference pipeline on NVIDIA Jetson AGX Orin. The results show that, within the total end-to-end latency of approximately 858.3 ms, the vision encoder, VLM Backbone, and action expert take 69.3 ms, 528.0 ms, and 257.0 ms, respectively. Among them, the VLM Backbone and action expert together account for more than 90% of the end-to-end inference time, making them the dominant performance bottlenecks in the π0.5 inference pipeline. Therefore, to meet the real-time closed-loop control requirement at the 10 Hz level, the latency introduced by the VLM Backbone and action expert should be the primary optimization targets. To further clarify the optimization direction for the VLM Backbone, we take π0.5 as an example and perform an operator-level latency breakdown of its VLM component on the Orin platform. 4
Required FP16 Throughput (TFLOPS)
102
101
Orin roofline Ridge: 86 FLOPs/Byte
30Hz
30Hz 30Hz
10Hz
10Hz 5Hz
10Hz
5Hz
5Hz Workload Pi0.5
1Hz
1Hz
GR00T
1Hz
RDT 100
102
Arithmetic Intensity (FLOPs / Byte)
103
Figure 2: End-to-end roofline analysis of representative VLA models on NVIDIA Jetson AGX Orin under FP16 precision. The results show that the latency of the VLM is not evenly distributed across all operators, but is highly concentrated in the MLP module inside the Transformer blocks. Specifically, the three linear projection operators, gate_proj, up_proj, and down_proj, together account for approximately 74.7% of the VLM latency. In contrast, the attention projection operators, including Q_proj, K_proj, V_proj, and O_proj, account for only about 7.2% in total, while the remaining operators account for approximately 18.1%. This indicates that, during π0.5 VLM inference, the MLP module is a more dominant source of latency than the attention projections. From the roofline perspective, gate_proj, up_proj, and down_proj are essentially GEMM operators with relatively high arithmetic intensity. For a typical linear layer, given an input matrix X ∈ RB×S×din
(1)
W ∈ Rdin ×dout
(2)
and a weight matrix
the output can be written as Y = XW,
Y ∈ RB×S×dout
(3)
The computational cost can be approximated as FLOPs = 2BSdin dout .
(4)
where B denotes the batch size, S denotes the number of input tokens, and din and dout denote the input and output channel dimensions, respectively. For gate_proj, up_proj, and down_proj in the MLP module, such computation is repeatedly performed in every Transformer block. Therefore, the total computational cost grows linearly with the number of input tokens, hidden size, intermediate size, and the number of layers. As shown by the formula, when the weight dimensions are largely fixed, the computational cost of MLP projection operators is proportional to the number of input tokens S. Therefore, the key to reducing VLM Backbone latency is to reduce the input size to the VLM, especially the number of 5
visual tokens and context tokens. Based on this observation, one design principle of RhinoVLA is to compress visual tokens, remove redundant context, and optimize the organization of multimodal tokens, thereby reducing the MLP GEMM computation at the source, alleviating the compute pressure on edge devices, and lowering the overall VLM latency. 3.2
RhinoVLA Architecture
Overview. RhinoVLA follows the two-module VLA decomposition used by π0.5 : a visual-language backbone encodes robot observations and language instructions, and an Action Expert generates continuous action chunks with flow matching. This design preserves a strong pretrained VLM for perception and instruction understanding, while keeping action generation in a separate robot-control module. For the visual-language backbone, the latency analysis motivates reducing the token burden at the VLA model level. Since the dominant MLP projection operators scale linearly with the number of visual and context tokens, RhinoVLA adopts a 2.13B-parameter Qwen3-VL [1] as its visual-language backbone. Under the common 224 × 224 image setting, Qwen3-VL represents one image with 64 merged visual tokens after spatial merging, whereas the PaliGemma-224 [2] backbone used by π0.5 uses 256 image tokens. This reduces the visual token burden by 4× before the multimodal sequence enters the language backbone. For multi-view VLA inputs, where several camera streams are processed together with language instructions, this reduction directly lowers the MLP GEMM computation analyzed above. At the same time, Qwen3-VL provides strong pretrained multimodal capability, making it a suitable backbone for token-efficient VLA inference without weakening visual-language reasoning. The Action Expert keeps a comparable scale to π0.5 , with 0.40B parameters versus about 0.43B, but is redesigned around the Qwen3-VL interface rather than directly reusing the original Gemma expert. It follows Qwen-compatible transformer components, including attention/cache handling and text-MLP blocks. At each denoising step, the Action Expert conditions on the last 18 layers of the Qwen3-VL KV cache, the current 72D robot state, state/action masks, the noisy action chunk, the flow-matching time, and the robot-instance index. It predicts a flow velocity over the unified 72D action slot space, with invalid dimensions masked out. In this way, action generation uses reusable visual-language context from the VLM, while the state/action masks and robot-instance index expose the robot-specific control interface to the Action Expert. While the compact VLM improves efficiency, cross-robot training introduces heterogeneity in observations, action interfaces, and robot embodiments. To enable a shared policy across diverse platforms, RhinoVLA incorporates three key mechanisms (Figure 3): a view registry for observation alignment, a unified 72D physical state–action slot space for action alignment, and robot-instance LoRA adapters for embodiment-specific adaptation. We detail these components next. Challenge A: Camera-view heterogeneity. Robot datasets often use different camera layouts and naming conventions. Although many datasets contain comparable view types, such as front, head-mounted, overhead, or wrist cameras, they may differ in camera count, mounting pose, field name, view order, and modality. Without explicit view labels, the model must infer camera identity from image order or dataset-specific field names. This is unreliable in cross-robot training: the first image in one dataset may be a head view, whereas the first image in another dataset may be a wrist view. Mechanism A: View Registry. RhinoVLA introduces a View Registry that maps each datasetspecific camera field to a fixed role-modality vocabulary during preprocessing. The corresponding tag is inserted before the image content, such as [head|rgb], [left_wrist|rgb], or [head|depth]. As a result, Qwen3-VL receives both the image content and its explicit camera identity before tokenization, while different samples may still contain different numbers of views. The View Registry decouples camera identity from dataset-specific image order. It makes camera observations comparable across datasets while preserving view-dependent cues: head or front cameras usually provide stable global context, whereas wrist cameras provide close-up manipulation views that move with the arm. Explicit view tags prevent these distinctions from being hidden inside dataset-specific conventions. Table 1 summarizes the View Registry vocabulary and prompt template. 6
Challenges in cross-robot heterogeneity A. Camera-view heterogeneity
B. Action-schema heterogeneity across robots Franka Panda
AgiBot G1 (8 cams: fisheye + top + wrist +...)
C. Robot-instance variation
AgiBot G2
AgiBot G1
Link-Joint Frames
Frame Axes
Head joint range
~40.6°
... + 5 more ● Camera roles
● Modalities
● View counts
● Arm joint DoF
● Body/mobile-base control
● Joint-chain topology
● End-effectors
● Joint base link
● Join limit * Referenced by Galbot G1 from RViz
Our contributions A. View-Registry prompt template
C. Robot-instance LoRA
B. Unified 72D slot space + binary masks
Shared Action-Expert base (trained on all platforms) Arm 0 D0–D6 Hand 1 DoF D32–D47 Waist D55–D57
···
[head | rgb]
[left_wrist | rgb]
[right_wrist | rgb]
[head | depth]
extensible
[role | modality] → view-registry tag
Arm 1 D7–D13 Head RPY D48–D50 Base velocity D58–D60
Gripper D14–D15 Torso D51–D52 Reserved D61–D71
Hand 0 DoF D16–D31 Folded leg D53–D54
Rhino VLA s
Task: "pick up the red bag" [head | rgb] <img> [left_wrist | rgb]<img> [right_wrist | rgb]<img>...
ms
LoRA · G2
A
A
×
expose last 18 layers KV cache →
Layer last - 17
xt
+
LoRA r = 64
...
Layer last
×
B
LoRA · ... A
×
B
ridx = i
hard-routed by ridx
Layer 1
+
B
action chunks over the 72D action space
Action Expert
Qwen3-VL Prefix ...
ma
LoRA · G1
LoRA idx 0
+
Layer 18 xt+Δt ← xt + Δt · vθ(xt, t, s, ms, ma, cvlm, ridx)
LoRA idx ...
LoRA idx N
Instance LoRA LoRA | idx i
xt
Figure 3: Overview of RhinoVLA. The architecture aligns heterogeneous robot datasets through three interface mechanisms. The Action Expert conditions on Qwen3-VL visual-language memory and predicts masked flow velocities over active action slots. Prompt field Example / value Task text pick up the cup View role front, left_wrist, head Modality rgb, depth, rgbd Image content structured Qwen-VL image item Training prompt template: Task: {task} Views: [{role_1} | {modality_1}] + image_1 [{role_2} | {modality_2}] + image_2 ... [{role_n} | {modality_n}] + image_n
Table 1: View Registry prompt fields and training template. Each image is explicitly tagged with its camera role and modality, allowing heterogeneous camera layouts to be represented through a shared prompt interface.
Challenge B: Action-schema heterogeneity. Robot action vectors cannot be shared by length or index position alone. The same vector index may refer to different physical quantities in different datasets, and some robots may not expose the corresponding degree of freedom at all. Directly pooling such action vectors would assign physically different meanings to the same output dimension, making cross-robot action learning ill-defined. Mechanism B: Unified 72D slot space with binary masks. RhinoVLA uses a unified 72D slot space as the shared state-action contract across robots. Each slot has a fixed physical meaning across datasets. State and action use the same slot definition: the state records the current physical value, while the action label represents the future target for the same slot whenever such a target is defined. For mobile-base slots, the action is defined as a velocity target rather than a position target. A dataset may activate only a subset of slots, but it cannot redefine their semantics. Binary masks are attached to the same 72D space. The state mask indicates which state dimensions exist in the current sample, and the action mask indicates which output dimensions are valid for supervision. As model inputs, the masks tell the Action Expert which slots are present in the current robot. During training, invalid or physically absent action slots are excluded from the flow-matching 7
Slots D0–D6
Physical group Arm 0 canonical joints
Unit rad
D7–D13 D14–D15 D16–D31 D32–D47 D48–D50 D51–D52 D53–D54
Arm 1 canonical joints Parallel grippers Hand 0 active DoF Hand 1 active DoF Head / neck RPY Torso pitch / lift Folded-leg mechanism joints
rad closed ratio rad rad rad rad, m rad
D55–D57 D58–D60 D61–D71
Waist RPY Base velocity command Reserved auxiliary slots
rad m/s, m/s, rad/s reserved
Examples upper arm, forearm, and wrist joints for a single arm or left arm right arm in a bimanual robot 0 is open, 1 is closed active hand-control slots for the first hand active hand-control slots for the second hand roll, pitch, and yaw when available torso pitch and vertical lift two actuated joints for foldable leg mechanisms waist roll, pitch, and yaw base vx , vy , and yaw rate inactive in the current schema
Table 2: Unified 72D slot space for RhinoVLA. The table defines the shared physical coordinate system used to align heterogeneous robot state and action schemas. Binary masks specify which slots are valid for each robot and sample.
supervision. This prevents missing dimensions from being treated as zero-valued targets and avoids introducing spurious supervision for robot-specific degrees of freedom. The 72D contract follows the motivation of physically interpretable action spaces inspired by RDT [20]. Active output dimensions are tied to physical quantities: arm, wrist, head, and waist angles use radians; parallel grippers use a closed ratio in [0, 1]; and base commands use metric velocity units. These slot groups define the physical coordinate system exposed to the Action Expert, as listed in Table 2. Detailed mapping rules, including dexterous-hand allocation and converter constraints, are provided in Appendix B. Together, the slot definitions and binary masks form a single robot interface: slots fix the physical meaning of each dimension, while masks select the subset that is valid for a particular robot and sample. This allows RhinoVLA to train on heterogeneous robots without forcing all datasets to share the same action-vector length or index convention. Challenge C: Robot-instance residual variation. The View Registry and unified 72D slot space align camera observations and state-action semantics, but they do not remove all embodiment-specific differences. Two robots may share the same nominal action slots while still responding differently due to calibration errors, joint limits, gripper mechanics, camera placement, payload, low-level controllers, or action scaling. A single shared policy must therefore capture both cross-robot common structure and instance-specific residual behavior. Mechanism C: Robot-instance LoRA. RhinoVLA places robot-instance LoRA modules inside the Action Expert. The shared Action Expert receives gradients from all datasets and learns common visuomotor structure across robot platforms. For each sample, the corresponding LoRA module is selected by instance_id and learns a small robot-specific correction on top of the shared base model. We use robot-instance LoRA instead of robot-specific output heads for two reasons. First, separate output heads would weaken the unified 72D action contract by allowing each robot to learn its own final action mapping. Second, they would introduce robot-specific deployment graphs, making it harder to reuse the same inference kernels and hardware-specific operator optimizations across robots. In contrast, robot-instance LoRA adapts the internal action-generation features while keeping the attention modules, final action projection, and 72D output interface shared. The LoRA modules are inserted into the feed-forward network of every Action Expert layer, while the attention modules and final action projection remain shared. This placement keeps the main action-generation computation common across robots, while providing enough capacity to model residual instance-specific behavior. During deployment, the selected robot-instance LoRA can be merged into the base Action Expert weights. This design provides three practical advantages: 1. Unified deployment graph. After merging the selected robot-instance LoRA, every robot uses the same 18-layer Action Expert structure. The deployed model does not require 8
robot-specific computation graphs, so the same inference kernels and hardware-specific operator optimizations can be reused. 2. Sparse adapter activation. Although the training code may reserve multiple instance ids, each sample is hard-routed by instance_id to one robot-instance LoRA. A forward pass therefore activates only the selected adapter, not all reserved adapters. 3. Low-cost robot extension. Adding a new robot does not require a new action head or changes to the unified 72D slot space, as long as the robot can be mapped to existing slots. The new robot only requires a small robot-instance LoRA and its normalization statistics. 3.3
Training Strategy
This section describes how the architecture above is trained. We first convert heterogeneous robot demonstrations into the shared visual and action interface, then train the policy with unified crossembodiment pretraining, and finally adapt the pretrained model to a target real robot with a small amount of task data. 3.3.1
Training Data and Standardization
The training mixture is assembled from multiple robot demonstration sources, including joint-space subsets from Open X-Embodiment [27], and AgiBotWorld [6]. These sources cover single-arm and dual-arm robots, parallel grippers, dexterous hands, and multiple manipulation tasks. Each sample is converted into the interface in Figure 3 before it reaches the model. Camera fields are mapped to View Registry. Native robot states and actions are mapped to the 72D physical slot space. State and action masks record which slots are valid for the current robot. The 72D space reserves 16 slots for each hand. These slots follow a 4-3-3-3-3 allocation from thumb to little finger: four active DoF for the thumb and three active DoF for each other finger. Hand actions are mapped to this layout according to the active-joint semantics, joint order, units, and limits specified by the corresponding hardware or SDK manual. This allocation matches the design pattern used by many five-finger dexterous hands, while lower-DoF hands can be represented by masking the missing finger joints. (Only motor-actuated active joints occupy hand slots; passive or mechanically coupled joints are not treated as valid action dimensions.) Only samples that can be reliably mapped to the 72D physical slot space and its corresponding masks are used for training. The current pretraining model does not supervise leg or foot joints, so those fields are excluded from the training targets when they appear in the source data. 3.3.2
Pre-training
RhinoVLA is trained as a cross-embodiment policy on the mixed robot demonstration corpus. The Qwen3-VL backbone is kept frozen, while three trainable components are optimized together: the VLM LoRA, the shared Action Expert, and the robot-instance LoRA inside the Action Expert. The VLM LoRA adapts the visual-language backbone to robot camera views and manipulation instructions. The shared Action Expert learns the common 72D action-generation policy across robots. The selected instance LoRA is routed by instance_id. Training batches are drawn from the mixed robot datasets with the same power-law balancing rule used in π-style VLA training, N 0.43 pi = P i 0.43 , j Nj where Ni is the number of training samples in dataset i. This gives larger datasets higher sampling probability without allowing them to dominate every batch. State and action masks follow the 72D slot convention defined above. They specify which physical slots are available for the current robot, and only active action slots contribute to the flow-matching objective. For a clean target chunk z ∈ RH×72 , Gaussian noise a ∼ N (0, I), and interpolation time t ∈ [0, 1], we construct xt = (1 − t)a + tz. The Action Expert predicts v̂θ = fθ (xt , t, s, ms , ma , cvlm , r), 9
where s denotes the 72D robot state, ms and ma are the state and action masks, and cvlm denotes the last-18-layer Qwen3-VL KV cache used as visual-language conditioning for the Action Expert. The variable r selects the robot-instance LoRA used by the current sample. The flow target is z − a, and the main masked flow-matching loss is P 2 h,d ma (d)w(h, d) ∥v̂θ (h, d) − (z(h, d) − a(h, d))∥2 P , LFM = h,d ma (d)w(h, d) + ϵ where w(h, d) is a per-slot weighting term used to balance action groups. During training, the base Action Expert prediction is also kept under direct supervision and the adapter residual is regularized. This prevents the instance LoRA from taking over the full action-generation problem: the shared Action Expert remains responsible for the cross-robot policy, while the instance LoRA captures smaller deviations caused by robot-specific hardware and control behavior. 3.3.3
Post-training and Real-Robot Transfer
After pretraining, RhinoVLA can be adapted to a target real-robot task without changing the model interface. The pretrained model already provides shared visual-language conditioning, the unified 72D state-action schema, and mask-conditioned action generation. Therefore, transfer only requires fitting the target-task behavior within the same View Registry, physical slot space, masks, and robot-instance routing. During post-training, the visual-language encoder, including the pretrained VLM LoRA, is frozen. Most Action Expert parameters are also frozen, and we update only the target robot’s instance LoRA. This reuses the same residual adaptation mechanism for task transfer: the shared base preserves the cross-robot policy learned during pretraining, while the target instance LoRA absorbs task- and robot-specific residual corrections from a small real-robot dataset. 3.4
Efficient deployment on Huixi R1
We deploy RhinoVLA on our Huixi R1. Figure 4 reports the runtime frequency of RhinoVLA on the R1 platform after applying a series of deployment optimizations, including compilation optimization, mixed-precision deployment, and parallel encoding. These techniques are implemented with consideration of the hardware characteristics of R1, enabling an end-to-end execution frequency of 11.69 Hz. In the following sections, we describe each optimization technique in detail and analyze its contribution to the overall acceleration.