Sixteen milliseconds makes a good headline. Twenty milliseconds makes a more interesting engineering story.
In Liquid AI’s October 7 release, d1-3B answers one question on NVIDIA’s Jetson AGX Thor in 16 milliseconds. Three questions about the same state take 20 milliseconds. The model selects answers in one forward pass rather than generating a stream of words. Liquid and NVIDIA also show navigation in Isaac Sim with the model running on Jetson hardware.
That small increase suggests a useful design opportunity for robots: organise decisions around a shared observation. A machine examining a work surface may need to decide whether an object is present, whether a hand is nearby and whether to proceed. Treating each as an unrelated request can make it pay repeatedly to interpret the same scene.
The expensive part can move to the input
The release’s latency table supplies its own qualification. On Thor, the 384-pixel image workload takes 35 milliseconds and a 3,400-token state takes 220. On Orin Nano, those measurements are 202 milliseconds and 1,640 milliseconds. These are different input workloads, not interchangeable robot control rates. NVIDIA’s deployment guide describes d1-3B as a classification model accepting text and images.
Removing generated text leaves an input bill. A fast answer to a short question does not tell an engineer how quickly a system will process camera frames, assemble context, make a choice and deliver it to a controller. Nor does an average measurement say whether occasional delays will collide with a control deadline.
This changes how a team might design the interface. Instead of passing an ever-growing scene description into every request, it could identify the few decisions that need a fresh image, separate them from slower planning and reuse state where the situation permits. That is an architectural hypothesis to test, rather than a performance claim about d1.
A decision needs an escape route
A fixed choice also puts responsibility on whoever defines the options. If a robot can answer only “continue” or “stop,” an unfamiliar scene still has to land somewhere. An uncertainty response, a request for another view or a handoff to a slower model may be more useful than a forced choice with an impressive latency.
The compelling prospect is a layered controller: frequent, tightly specified decisions near the hardware, with more expensive interpretation when the scene demands it. The hard part is deciding which observations justify leaving that fast path. A benchmark can time the answer; deployment has to decide whether the question was adequate.
Liquid’s table points toward a practical experiment. Compare three separate calls with a shared-state call, using the actual cameras and the same decision set. Measure the age of the observation when the robot acts. The number that matters may turn out to be how often the system has to read the world again.
Questions, news tips or corrections? Contact [email protected].
