What is inference frequency? How fast a policy runs, defined

Inference frequency is how many times per second a robot policy computes a fresh set of actions, printed in hertz. It is the number behind every claim that a model runs at 50 Hz or at 6 Hz. One term hides several rates. The latency of one call is one. The rate of the robot's control loop is another. Execution, the pace the arm actually follows, is a third. Underneath sit faster loops still. This page defines the term and splits those rates apart. It shows the bars the field prints and where the bars come from. It lists the rates named models claim, each with its date and its hardware. Every check on this page is dated October 27 2026.

The short answer first. Inference frequency counts complete policy calls per second on one robot. The measurement study behind the field's printed bars defines it precisely. That study is a February 2026 paper from NVIDIA Research called VLA-Perf. It defines the number as throughput in hertz at a batch size of one, meaning one robot. It also sets the bars: 10 Hz counts as acceptable, and 100 Hz counts as high performance. Both bars hang on one anchor, the 24 to 60 Hz rate of ordinary RGB cameras. Below that, the term forks. A policy can infer at 2 Hz while the arm executes at 50. Chunking makes that possible by handing the robot a run of future actions per call. And the loops under the policy run 10 to 1000 times faster. They never pause for the model. A reader who cannot split those rates cannot read a vendor claim either. Each section below splits one.

Last verified: 2026-10-27

Inference frequency

Inference frequency is the number of complete policy passes a robot runs in one second. One pass means the full trip. Cameras and joint state go in. Actions come back. The robot has something new to act on. The unit is hertz, written Hz. One Hz is one pass per second. Fifty Hz is fifty. When a paper says a model controls a robot at up to 50 Hz, fifty fresh actions reach the robot each second; whether fifty policy passes produced them is the question the next sections untangle.

The definition used by measurement work is tighter than it looks. VLA-Perf, a February 2026 study from NVIDIA Research, reports "throughput in Hertz (Hz), defined as the number of inferences that can be executed per second at a batch size of one (i.e., a single robot)" (VLA-Perf paper). Two clauses carry the weight. Batch size one pins the number to a single robot. A server juggling many robots cannot average its way to a flattering figure. And only complete inferences count. A call that fails or arrives late adds nothing.

The same paper draws one boundary that buyers trip over. Its numbers cover inference latency and throughput, not task success rate. A faster policy is a faster policy. Whether it grasps better is a different measurement on a different scoreboard. Hold that split. Half the marketing in this field quietly swaps one for the other.

Inference latency, the twin term

Latency is the time one inference takes. Frequency is how many fit in a second. A plain synchronous loop waits for each answer before moving. There, the two are inverses of each other, and the study says so exactly. Throughput is the inverse of inference latency. Divide 1000 milliseconds by the latency and you have the frequency. A 52.57 millisecond pass is 19 Hz. A 3.18 millisecond pass is 314.4 Hz. Those two real numbers are the same model, pi 0, on an edge module versus a datacenter GPU. Both come from the VLA-Perf tables (VLA-Perf paper).

The measured window matters as much as the number. The study defines its latency as the time from perception to action prediction. It reports that window without network time and without robot execution time. Someone else's "50 Hz" might include image resize, a wireless hop, or the robot's own overhead. Two honest numbers with different windows do not compare. When you read a rate, ask what the clock covered.

Asynchronous execution bends the inverse rule. That is where the twin terms part ways. With async inference, the robot executes one chunk while the next one computes. The study notes that asynchronous throughput can exceed the inverse of latency. The same paper adds the honest caveat. Async improves throughput but does not cut end-to-end latency. Acting on stale observations may degrade action quality. More hertz, bought by letting observations age, is not free.

Control frequency, the robot's clock

Control frequency is the rate of the robot's own loop. That clock demands a new command at fixed intervals. It belongs to the robot, not the model. At 50 Hz a command is due every 20 milliseconds. At 30 Hz, every 33. The loop does not slow down because the model is thinking. It either has a fresh action or it does not.

The biggest open robot stack names this knob plainly. LeRobot's deployment docs list the rollout flag --fps as "Control loop frequency", default 30. The camera configs in the same docs run at fps 30 (LeRobot rollout docs). That one flag is the number this section is about. The async docs add the tuning law in one sentence. Adjust your fps based on inference latency. Reduce your fps if you consistently run out of actions in the queue (LeRobot async docs). Control frequency is a choice. Inference frequency is a measurement. The two meet only when the loop's budget covers the model's latency.

This is the rate people usually mean when they say a robot "runs at 50 Hz". The ALOHA rigs that taught the field dexterity run at 50 Hz. OpenVLA's authors cite those rigs when explaining why a 6 Hz model cannot serve such loops directly (OpenVLA paper). The robot's clock sets the deadline. The policy's frequency says whether the model makes it.

Effective execution frequency, what chunking buys

Most modern policies do not infer once per action. They predict a run of future actions in one pass, hand the run to the robot, and infer again before the run ends. The run is the action chunk. Its length is the chunk size. The VLA-Perf paper defines the companion knob too. The execution horizon is the number of actions actually executed before the next inference. It is never larger than the chunk. NVIDIA hit this confusion in practice. The Isaac GR00T README notes its rollout flag was renamed from action horizon to execution horizon "to clarify how many predicted actions are executed per policy call" (Isaac GR00T README).

Chunking is why a policy can be slow while the robot runs fast. The study's phrasing is the definition worth keeping. The effective action execution frequency may exceed the inference frequency due to action chunking. With a chunk size of five, the robot can execute up to five actions from one inference (VLA-Perf paper).

Worked example, printed in the pi 0 paper itself. On the 20 Hz UR5e and Franka robots, the team ran inference every 0.8 seconds. Each call handed over 16 actions. On the other robots, which run at 50 Hz, they ran inference every 0.5 seconds with 25 actions per call (pi 0 paper). Do the division and both rates appear. Inference ran at 1.25 Hz and at 2 Hz. Execution ran at 20 Hz and at 50 Hz. The arm moved at full clock while the model decided twice a second. When someone quotes "50 Hz" for pi 0, that number is the control side of this split. The inference side, unchunked, is far lower.

The faster loops under the policy

A policy's frequency sits between the cameras that feed it from above and faster loops below. Cameras deliver frames at 24 to 60 Hz; that is the anchor the VLA-Perf bars lean on. At the policy layer, tens of Hz is the working range for manipulation models today. Below the policy, whole-body controllers run at hundreds of cycles per second, roughly 500 Hz to 1 kHz. The servo loops that drive each joint run faster still. The innermost current loops in the drives reach tens of kilohertz. None of those lower layers wait for the model. They track whatever target the slower layers last handed down.

The split explains one design pattern. Figure's Helix runs its System 1 action policy at 200 Hz for full upper-body control. Its System 2 language-vision model operates at 7 to 9 Hz (Figure Helix). Two frequencies, one robot, by design. The fast loop keeps motion smooth. The slow loop does the thinking. When you meet a "dual system" claim, the claim is really about running two inference frequencies at once.

So the polite question, whenever a rate is quoted, is which loop the number belongs to. A camera rate, a policy rate, a control rate, an execution rate, and a joint-loop rate can all appear in one paragraph about one robot. Only one of them is inference frequency.

What counts as fast: the bars and their anchor

The field's printed bars come from one place, and they carry their reasoning on their face. The VLA-Perf paper writes: "Given that standard RGB camera frame rates typically range from 24 to 60 Hz, we define a 10 Hz inference frequency as acceptable (not too far from video ingestion rates) and 100 Hz as high-performance (exceeding common ingestion rates)" (VLA-Perf paper). Read the anchor, not just the bars. Ten is acceptable because it stays near what cameras deliver. One hundred is high performance because it outruns them. A bar without an anchor is just a number.

Not every source anchors its bars, and the spread is wide. The same search that surfaces the VLA-Perf paper surfaces vendor posts demanding 30 to 100 Hz with no stated basis. Benchmark pages treat 50 Hz as the floor for one task or another. The task genuinely moves the need. Dexterity rigs run 50 Hz. The study's acceptable bar is 10. Plenty of useful slow work happens at 5. When two sources disagree, check which one says why.

The same study maps how hard each bar is to hit, in three settings. On device, a Jetson Thor already delivers 19 Hz for pi 0, past the acceptable bar. Reaching 100 Hz would need model changes such as fewer denoising steps or lower precision. On an edge server, 10 Hz is reachable with a consumer GPU even over a slow wireless network. Reaching 100 Hz there wants a datacenter GPU and a fast network. In the cloud, 10 Hz needs good networking. Reaching 100 Hz generally requires asynchronous inference, because the network round trip alone eats the budget (VLA-Perf paper). That ladder is the honest shape of the answer. The bar you can hit depends on where the model runs.

The rates named models print, dated

Every row below was read from the named source on October 27 2026. Each rate is its maker's own claim, for the hardware named, on the date named. Rates age fast in this field.

For scale across hardware, the VLA-Perf tables run one model, pi 0, with one set of settings across five devices. It scores 19.0 Hz on Jetson Thor, 32.2 on an RTX 4090, 61.7 on an A100, 162.5 on an H100, and 314.4 on a B100. That is a more than 16-fold spread with nothing changed but where the model runs. That spread is the reason to never quote a rate without its hardware.

Three audit rules read that table honestly. One, the date. RT-2, the model that named the category, shipped at 1 to 3 Hz in 2023. Three years later, a compact model prints 32 Hz in its own title. Any bar older than a year is history, not advice. Two, the window. The 6 Hz and the 32 Hz figures are model computation, not the robot's loop. Three, the sense. GR00T's 40 Hz is policy throughput on a benchmark. Helix's 200 Hz is its fast action layer, with a second model running slower behind it. Same column, three meanings.

Who owns the definition today

Nobody, and the receipts are easy to check. The largest robotics glossary this page could find, almond.bot, carried 1,052 terms on October 27 2026. It has an entry for inference latency. That entry defines it as the time between a model receiving an observation and producing its output. It has one for asynchronous inference too. It has no entry for inference frequency. NVIDIA's own glossary returned no page for the term either, on the same day. Wikipedia has no article for it. Its vision-language-action article mentions hertz figures only as passing facts about specific models. The term is in heavy use, in papers, model titles, and vendor pages. It has no settled home.

That gap explains the search results. Ask for the definition and the top row is a systems paper. It defines its terms precisely, but it writes for researchers, not for the person holding one number and a question. The practical pages assume you already know what the number counts. A term this load-bearing deserves a plain definition page. The first spec anyone quotes when sizing a robot brain should not be a folk term. This is that page. What a VLA is in the first place is covered in our VLA models guide.

How to measure your own number

You do not need special instruments. Run one episode. Count completed inference calls. Divide by the episode's seconds. That quotient is your inference frequency, batch size one, in the same window the study uses. Then log the latency of individual calls alongside it. The pair tells you what the rate alone hides. A 20 Hz average built from 10 and 90 millisecond calls is not a 20 Hz system in any sense a control loop can use.

If you run an open stack, the numbers are already at hand. LeRobot's async docs tell you to watch the action queue. Reduce the loop's fps when the queue runs dry. That is the practitioner's version of the same law. Set the control clock from the measured worst case, not the average (LeRobot async docs). The openpi policy server helps too. It stamps every action message with a field carrying its inference time in milliseconds. A stock deployment logs its own latency without extra tooling.

Two failure modes show up in community threads, and both are frequency mistakes wearing costumes. One is the queue that empties mid-episode. The control clock is set above what the model sustains, and the fix is the fps knob, not the network. The other is the stutter at chunk boundaries. Execution outruns inference, the chunk runs out, and the arm pauses or jerks. The first is a control-frequency bug. The second is an inference-frequency bug. Its fix is chunking or async execution, the subject of our dropped-stream robot loop guide.

One call per action, hosted

This platform's robot action route takes one POST call per action step. Camera frames, instruction, and robot state go in. An action chunk comes back. The chunk's length is each model's own property, not a request setting. A loop built this way holds no long-lived socket. It picks its control frequency and spends one call per chunk. The pi 0.5 model page describes the family. As of October 27 2026, the robot models were not on the public list. The models index shows the current catalog, and the pricing page is the one place to look for rates. The way in is signup.

Common questions

What is VLA inference?

One full pass of a vision-language-action model. Camera images, robot state, and a language instruction go in. Actions for the robot come out. VLA inference frequency is how many of those passes finish per second on one robot. The model family is explained in the VLA models guide.

What inference frequency do I need?

It depends on the task, and the honest bars are anchored. The VLA-Perf definitions call 10 Hz acceptable and 100 Hz high performance. Both are pegged to the 24 to 60 Hz rate of ordinary cameras. Dexterity rigs like ALOHA run 50 Hz loops. Slow, cluttered tasks can work at a few hertz. Pick the bar your task's physics demands. Then check the ladder: on device, edge server, or cloud each buy a different rate for the same model.

Is a higher inference frequency always better?

No. Three limits bite. Cameras feed the model at 24 to 60 Hz, so inference far above the input rate reprocesses stale frames. Async execution raises throughput by letting observations age. The study warns that may degrade action quality. And frequency is not success. The VLA-Perf authors separate their performance numbers from task success rate. Buy the rate your task needs, not the biggest number on a card.

Why does my robot execute at 50 Hz when the policy infers at 2 Hz?

Because of action chunking. The pi 0 paper prints the exact cadence. On its 50 Hz robots, inference ran every 0.5 seconds with 25 actions executed per call. Two inference passes a second fed a 50 Hz execution clock. The execution frequency is the control rate. The inference frequency is the model's. Both are real, and they are different numbers.

How do I convert between Hz and milliseconds?

Divide 1000 by the rate. Fifty Hz is a 20 millisecond period. Thirty Hz is 33. Ten Hz is 100. Five Hz is 200. One Hz is 1000. The conversion runs the other way too. Divide 1000 by a latency in milliseconds and you have the synchronous ceiling for that call. A 25 millisecond pass cannot serve a 50 Hz loop. A chunk covers the gap.

Does an inference frequency number include the camera and the network?

Depends who printed it, and that is the trap. The VLA-Perf latency window runs from perception to action prediction. It excludes network and robot execution. A vendor's end-to-end figure may include image resize, a wireless hop, and the robot's own overhead. Two honest numbers with different windows do not compare. Ask what the clock covered before you compare any rate with your own budget.

Where this leaves you

Ask three questions of any rate you meet. Which loop does it count? What window did it measure? What hardware and date does it belong to? Those answers sort nearly every claim in this field. The policy server guide covers the serving pattern behind the number, and the dropped-stream guide covers what happens when the clock is missed. The ROS 2 latency guide takes the slow-node case. On where the model should run, the Jetson versus cloud guide weighs the two sides, and the hosted versus local guide runs the break-even math. For the platform itself, the models index shows the catalog. The pricing page carries the rates, and signup is the way in.

Last verified: 2026-10-27