Liquid AI has released two open-weight models designed for local, real-time multimodal decision-making: d1-3B and d1-omni-600M. The models process text, vision and audio inputs, targeting applications in which an AI system must turn sensor data into an action or decision without waiting for a cloud round trip.
The notable claim is speed rather than general-purpose chatbot performance. Liquid AI says its 3-billion-parameter d1-3B reaches 48.57 on the company’s Decision Index and can respond in 16 milliseconds on Nvidia’s Jetson AGX Thor, or 50 milliseconds on a Jetson Orin Nano. If those measurements hold under representative production conditions, they point toward a more practical local AI control layer for robots, industrial systems and vehicles. But the reported results also leave important questions about workload definitions, safety behavior and reproducibility that must be answered before the models can be trusted in safety-relevant machines. [1]
By the numbers
- 3 billion: Parameters in Liquid AI’s d1-3B model.
- 600 million: Parameters in d1-omni-600M.
- 48.57: d1-3B’s reported score on Liquid AI’s Decision Index.
- 16 milliseconds: Reported d1-3B response time on a Jetson AGX Thor.
- 50 milliseconds: Reported d1-3B response time on a Jetson Orin Nano.
A bid to move multimodal reasoning onto the machine
Most current AI deployments treat an edge device as a sensor endpoint and a cloud service as the intelligence layer. Cameras, microphones and telemetry are collected locally, transmitted to a remote model, and returned as text, alerts or commands. That arrangement can work well for post-event analysis, fleet management and many consumer assistants. It is less attractive where network access is intermittent, bandwidth is expensive, data cannot readily leave a site, or the useful response window is measured in tens of milliseconds.
Liquid AI is positioning the d1 family around that latter category. The company’s release covers text, visual and audio decision tasks, which matters because physical systems rarely operate from one modality alone. A mobile robot may need to combine a camera view with a spoken instruction and its current task state. A vehicle system may need to interpret a visual scene alongside audio warnings and internally generated status messages. A factory inspection cell could combine imagery, equipment sounds and operator commands.
In those settings, a model does not need to replace low-level deterministic control software. Motor loops, braking controls and collision interlocks generally require highly bounded systems with known timing properties. A compact multimodal model could instead sit above those layers: classifying a situation, selecting among permitted procedures, escalating uncertainty to a human operator, or producing structured recommendations for conventional control software.
That distinction is central to the opportunity. The most credible near-term use is not an unconstrained language model directly steering machinery. It is a fast local decision component with a narrow operational role, explicit interfaces and hard safety constraints around it.
Why 16 to 50 milliseconds could matter
A 16-millisecond response interval is roughly comparable to a 60 Hz processing cadence, while 50 milliseconds fits a 20 Hz cadence. Those comparisons do not establish end-to-end control performance: sensing, image capture, audio buffering, preprocessing, scheduling, post-processing, actuator communication and safety checks all add time. They do, however, show why Liquid AI’s reported latency is relevant to machine applications rather than merely a benchmark statistic.
At this range, an edge model could potentially participate in a live perception-and-decision pipeline instead of being relegated to background analytics. Examples include a warehouse robot deciding whether a detected obstruction warrants a stop, detour or request for assistance; an agricultural machine sorting ambiguous visual observations for an operator; or an industrial system detecting an abnormal sound and correlating it with camera data before triggering an inspection workflow.
For vehicles, the immediate opportunity is likely to be decision support and cabin or fleet operations rather than direct driving control. Local multimodal inference could support driver alerts, spoken interaction, incident documentation, cargo monitoring or maintenance triage without transmitting every camera frame and audio clip off the vehicle. In regulated or high-consequence functions, it would still need to operate alongside purpose-built perception, planning and safety systems.
The two stated hardware targets also matter commercially. Nvidia’s Jetson platforms are widely used as embedded AI computers in robotics and edge deployments. Reporting a result on both the higher-performance Jetson AGX Thor and the smaller Jetson Orin Nano suggests that Liquid AI is addressing a range of compute and power budgets. The gap between 16 and 50 milliseconds also illustrates a basic deployment trade-off: faster decisions depend on the available accelerator, memory bandwidth, thermal envelope and system design. [1]
Open weights change the deployment equation
Making model weights available can be as consequential as reducing inference time. Developers can run open-weight models within a facility, vehicle or device boundary, avoiding an external inference dependency for each request. That can reduce recurring cloud costs, simplify operation during connectivity failures and help organizations maintain control of sensitive visual or audio data.
For robotics developers, access to weights also creates room for task-specific evaluation and adaptation. A company can test the model against its own factory floor lighting, equipment acoustics, operating vocabulary and failure cases rather than relying solely on a vendor-hosted demonstration. It can profile performance on its selected embedded hardware, inspect outputs in simulation and create a constrained output schema that downstream software can verify.
Open weights are not the same thing as guaranteed deployability. Licensing terms, redistribution rights, training-data provenance, model-card documentation and security practices all affect whether a model can be used in a commercial product. The announcement establishes that the weights are open, but organizations evaluating the release will need to examine the accompanying license and technical documentation for their particular use case. [1]
The Decision Index needs outside scrutiny
Liquid AI reports a score of 48.57 for d1-3B on its Decision Index. The metric is aligned with the company’s product thesis: a model intended to make real-world decisions should be evaluated on more than broad language generation or visual question answering. Yet a company-defined index is useful to buyers only to the extent that its task composition, scoring rules, baselines and contamination controls are transparent.
Independent testing should establish what kinds of decisions the index measures. A benchmark can reward correct selection from a fixed set of actions while saying relatively little about behavior when sensor data are degraded, an instruction conflicts with site rules, a camera view is occluded, an audio signal is noisy or no available action is safe. Those are ordinary conditions for deployed machines.
Latency requires equally careful interpretation. The company’s 16-millisecond and 50-millisecond figures should be accompanied by details including model precision and quantization, input resolution, audio duration, prompt and output lengths, batch size, warm-up behavior, software stack, power mode and whether the number measures time to first output or completion of a full decision. Multimodal pipelines can shift substantial work into preprocessing, so model-only timing may differ materially from sensor-to-action latency.
For safety-sensitive uses, the decisive tests are not aggregate averages. Developers need tail-latency measurements, error rates by environmental condition, calibrated uncertainty behavior, failure-mode analysis and evidence that a model defers or triggers a safe fallback when its inputs fall outside its operating domain. A model that is quick on a clean benchmark but unpredictably slow or overconfident in edge cases is not ready to become a control-layer dependency.
Market implications: smaller models, closer to the action
The release arrives as AI suppliers compete not only on the scale of foundation models but also on the cost, responsiveness and controllability of models deployed closer to data sources. Cloud-scale models remain valuable for broad knowledge tasks and difficult long-context workloads. Edge models address a different product requirement: dependable local operation within a bounded compute envelope.
Liquid AI’s stated model sizes place the d1 release in the part of the market where embedded deployment is plausible, subject to quantization and system requirements. The 600-million-parameter d1-omni-600M may appeal to developers working under tighter memory and power constraints, while the 3-billion-parameter model is positioned for higher-capability decisions where a more capable Jetson-class computer is available. Neither parameter count nor a single benchmark result is sufficient to determine suitability; the relevant comparison is accuracy, latency, energy use and failure behavior on the actual task.
The key organizations in this rollout are Liquid AI, which developed and released the models, and Nvidia, whose Jetson AGX Thor and Jetson Orin Nano hardware anchors the stated performance claims. The wider beneficiaries could include robotics integrators, industrial automation vendors, vehicle software developers and enterprises building private edge AI systems. Their incentive is straightforward: move routine perception and decision tasks closer to the machine without needing to operate a large proprietary model program.
That opportunity will also increase pressure on model vendors to publish deployment-grade evidence. For an edge model, buyers need reproducible throughput and power measurements at least as much as leaderboard rankings. For a multimodal decision model, they need evaluation suites that reflect physical environments rather than only curated internet-style prompts.
What would turn a promising release into a deployable platform
Liquid AI’s announcement is a meaningful signal that the market is moving toward models optimized for action-oriented, local multimodal workloads. The next milestone is independent replication. Robotics labs, systems integrators and hardware partners should test d1-3B and d1-omni-600M on published workloads and on representative sensor streams, comparing the reported timing against complete application latency.
Buyers should also demand task-level evidence. A useful evaluation would specify the model’s allowed actions, the validator that checks its output, the fallback when confidence is low, and the measured outcome under normal and adverse conditions. In a warehouse, that could mean obstacle-handling accuracy across lighting conditions. In a vehicle, it could mean the rate of correct escalation for cabin alerts without distracting the driver. In a factory, it could mean whether the model distinguishes a genuine equipment anomaly from ordinary background noise.
The long-term effect may be to split AI architectures more clearly into layers. Large cloud models can handle planning, engineering support, fleet-wide learning and exception review. Smaller local models can manage immediate, privacy-sensitive and connectivity-dependent judgments. Liquid AI’s release does not settle whether its models are the best implementation of that approach. It does put a concrete, open-weight performance claim in front of a market that increasingly needs AI to respond where the physical world is happening.
Editor’s Take
I think Liquid AI is aiming at the right bottleneck. In a real robot or vehicle product, a model that produces a useful, structured local decision in tens of milliseconds can be more valuable than a far larger model that requires a network call. Open weights make that proposition much more actionable: teams can profile the model on their own cameras, microphones and embedded computers, then build guardrails around a specific operational job.
The 16-millisecond figure is promising, but it is not yet a safety case. I would watch for a reproducible benchmark package, full sensor-to-action measurements, power draw, worst-case latency and tests on degraded inputs. The winners in this category will not be the teams with the most impressive isolated response time; they will be the teams that prove their models know when to make a decision, when to hand off to deterministic software and when to say they do not know.
References
- Liquid AI — https://www.liquid.ai/blog/d1-open
_-_front.jpg){kind=link}
