# Duo World Model: Offline vs Real-Time Setup, Hardware and License Checks

The new audiovisual preview has separate research and streaming paths, and downloading quantized weights does not settle deployment readiness.

By Paras Madan | 2026-11-14

InclusionAI released Duo's code and model bundles on November 13, including separate offline and real-time streaming pipelines. For developers evaluating an audiovisual assistant, the first decision is which pipeline to use. The default repository branch is an offline research path, not the live camera-and-microphone serving stack.

Before choosing hardware, check the model license: the quantized weights ship territorial restrictions, including the US, UK and EU, discussed below.

Duo is a preview. Its [official repository](https://github.com/inclusionAI/Duo) describes the current release as supporting basic audiovisual conversation; fuller visual interaction is planned for v2. That distinction matters when a demonstration makes the model look like a general-purpose interactive world simulator. Evaluate the released capability, not the roadmap.

## Choose the runtime before choosing weights

The repository's `main` branch provides offline inference. It expects Linux, Python 3.10 or newer, FFmpeg and FFprobe, with two CUDA GPUs in the default configuration. One handles Intent and codecs, while the other handles Realization. The README does not establish a universal minimum VRAM figure.

For live use, the repository points to dedicated vLLM-Omni and SGLang-Omni branches. Do not combine a main-branch installation tutorial with a serving-branch launch command and assume the components are interchangeable.

| Your evaluation question | Start with |
| --- | --- |
| Can the preview produce useful responses to recorded inputs? | Offline research pipeline |
| Can a live session handle camera, microphone and interruptions? | Dedicated streaming pipeline |
| Will it meet our latency and concurrency targets? | Measurements on the selected serving stack and hardware |

A useful first experiment is a short, repeatable conversation with known inputs. Keep the task identical across configurations, rather than comparing one polished recording with a different live interaction. This is an evaluation plan, not a benchmark I have run.

## The streaming example is an eight-GPU profile

The [vLLM-Omni branch README](https://github.com/inclusionAI/Duo/blob/inference/vllm-omni-duo/README.md) targets eight NVIDIA GPUs in its supplied deployment profile. It describes live audiovisual WebSocket interaction, BF16 and ModelOpt FP8 Realization checkpoints, and a browser demo. That is a reference configuration, not proof that eight GPUs are the minimum or that any eight cards will work.

The example admits one active session per replica by default. It also loads model components using `trust_remote_code`, so inspect and trust the checkpoint code before deployment. Browser camera access requires HTTPS or localhost.

If your intended product serves several callers at once, a successful single-session demo is only the beginning. Measure the number of sessions you can admit without unacceptable delay, and decide how the application rejects or queues additional users. A capacity plan needs session behavior, not just a model loading successfully.

## Quantized Realization is an overlay, not the whole system

The [Duo-1.0-distill-quant model card](https://huggingface.co/inclusionAI/Duo-1.0-distill-quant) identifies that download as an FP8, four-step distilled Realization overlay. It depends on the complete Duo 1.0 causal-base bundle, which supplies the shared Intent, codecs, speech components and Realization backbone.

Keep releases compatible. Treat the base bundle and overlay as a versioned pair, and record both in your experiment notes. Otherwise a missing or mismatched component can look like a model-quality problem when it is really a packaging mistake.

There is another trap: the main repository says its portable offline runtime dequantizes the quantized release. Optimized FP8 execution belongs to the dedicated serving branches. **An FP8 download does not mean every runtime executes it in FP8**, so do not budget memory or infer speed from the filename alone.

## Read the weight license before renting hardware

The code repository's Apache-2.0 label does not describe every model component. The quantized model ships a [MiniMax H3 Community License](https://huggingface.co/inclusionAI/Duo-1.0-distill-quant/blob/main/LICENSE). Its applicable territory excludes the United States, United Kingdom, European Union and Republic of Korea. It also specifies separate prior written authorization for commercial products and services exceeding $20 million in annual revenue.

These are reasons to review the actual terms and component licenses before deployment, not to assume a public download grants unrestricted use. Resolve eligibility before spending time on performance tuning.

## What to verify before calling it a working assistant

Use consented or synthetic recordings, then test interruptions, cancellation, session cleanup and a changed reference image. Check generated audio and video together. A plausible transcript does not establish that audiovisual output stayed synchronized or responded appropriately.

Start with a narrow acceptance question: can this preview complete one defined conversation reliably on our chosen stack? Expanding that into a product is a separate engineering decision. The runtime, checkpoint combination and deployment rights need to be settled before the impressive part of the demo becomes relevant.

I’m Paras. I work across AI, engineering and technical storytelling.

I help teams explain complex model releases and developer workflows without turning them into marketing summaries.

[Book a 30-minute call](https://cal.com/paras-madan/30min).