When Faster VLA Deployment Changes Closed-Loop Behavior: Task Success-Latency Analysis of SmolVLA Across PyTorch and ONNX Variants

Your inference service slows down when several customers send requests together.

What you would change

Replay a recorded request trace with only the proposed serving policy changed.

Replay a recorded request trace with only the proposed serving policy changed.

Compare against

Your current scheduler on the same model and hardware.

1. Locate the paper's implementation and check its license, model support, data needs, and hardware requirements. Stop here if you cannot obtain the required artifacts.
2. Save a small set of representative product tasks and expected outcomes. Keep evaluation tasks out of any training or tuning, and choose quality and cost limits before running.
3. Run the baseline and the proposed change on identical inputs. Keep other settings fixed and repeat paired runs to expose variation.
4. Save per-task outputs, failures, timings, and all usage costs. Review regressions before expanding the test.

What to measure

Requests meeting your latency target, throughput, failures, and cost per successful request.

When to keep it

Keep the change only if it meets your preselected quality and latency limits and improves the metric you care about after setup and operating costs. Otherwise retain the baseline. This is an exploration plan, not a validated recommendation.

recommendation

test

research area

serving and batching

technical change

ONNX Runtime export for VLA deployment with joint latency-success evaluation

published

2026-09-12

The roughly 2x latency reduction is achievable on constrained hardware, but the demonstrated success-rate collapse and the false-quantization artifact mean adoption is only safe after workload-specific closed-loop validation, which is exactly the paper's own recommendation.

1. claim 01Paperraft inference
   Read the brief interpretation

   Replaces the default PyTorch+AMP inference path of a vision-language-action policy with an ONNX Runtime CUDA EP export, tuned via a language-context-width ablation (16/24/32 tokens). Costs include export and validation effort plus a severe closed-loop quality risk: naive conversion dropped Spatial success from 70.0% to 41.0% even though Object success held near 89%, and latency on uniform benchmarks stayed flat across widths. Can fail silently because requested-FP16 and requested-INT8 artifacts were byte-identical FP32 graphs, so the advertised quantization never occurred and only artifact inspection plus closed-loop rollouts reveal the discrepancy.

   This is a Paperraft inference. It is not pinned to a verified PDF passage.

   Inspect the source
2. claim 02Paperraft inference

   ONNX Runtime CUDA EP reduces p99 inference latency from 1181 ms (PyTorch+AMP) to 601 ms (requested-FP16) and 532 ms (requested-INT8) on an RTX 2060, and a 24-token language-context width recovers Spatial task success to a level statistically comparable to the PyTorch baseline at roughly half the latency (chi-squared p=0.53).

   This is a Paperraft inference. It is not pinned to a verified PDF passage.

   Inspect the source