Inference Server
InferenceServer serves one or more local models behind an OpenAI-compatible endpoint on your Ray cluster. Choose a typed backend configuration for either Ray Serve or NVIDIA Dynamo; the client-facing endpoint and lifecycle API stay the same. Both backends support the serving capabilities described in this guide, so benchmark your workload and choose the backend based on measured performance.
In the tested 26.07 stack, Ray Serve uses vLLM 0.18.x from the base inference_server environment. Dynamo 1.1.0 uses Ray to create a separate actor environment with vLLM 0.19.x, so its first startup takes longer while Ray resolves and installs the environment. Ray Serve deployments can also be accessed through Ray Serve handles instead of the OpenAI-compatible endpoint; benchmark the approach for your workloads.
The old InferenceModelConfig class was removed. Migrate to the backend-specific types in Migrate from InferenceModelConfig.
Prerequisites
Install the inference-server extra:
Local GPU serving through this extra targets x86_64 Linux. The vLLM, ai-dynamo, and NIXL dependencies are not installed by the extra on aarch64 or macOS.
The tested 26.07 stack uses:
- CUDA 12.9.1 in the NeMo Curator container.
- PyTorch 2.10.
- Ray Serve 2.55.1 or later.
- vLLM 0.18.x for
inference_server(vllm<0.19). - ai-dynamo 1.1.0 and NIXL 0.10.0 or later for the Dynamo backend.
Start or connect to a Ray cluster before creating the server. The examples below use RayClient; an externally managed Ray cluster works as well.
Ray Serve Quickstart
Ray Serve is the default backend. Omitting backend= is equivalent to passing RayServeServerConfig().
The server waits for every configured model to appear at /v1/models before start() returns. server.endpoint contains the correct host and port for the selected backend.
Shared Server API
InferenceServer accepts a list of model configurations and one matching server configuration.
Only one InferenceServer can be active in a Python process at a time. Stop the current server before starting another.
Use a context manager for automatic cleanup:
For explicit lifecycle control:
Ray Serve Configuration
RayServeModelConfig
Use model_name when weights come from a local path but clients should use a stable API name:
Multiple Ray Serve Models
Each model can use a distinct deployment and runtime environment:
Clients select writer or reviewer in the OpenAI request’s model field.
Dynamo Aggregated Serving
Aggregated mode runs prefill and decode in the same vLLM worker. num_replicas creates static replicas; Dynamo does not use Ray Serve autoscaling configuration.
For aggregated models, a tensor-parallel replica can span multiple nodes when the tensor-parallel size divides evenly across available nodes. NeMo Curator prefers a single-node placement and otherwise uses equal GPU bundles on distinct nodes.
Dynamo Disaggregated Serving
Disaggregated mode runs independent prefill and decode workers. Configure both roles explicitly.
Role-level engine_kwargs shallow-merge over the model-level values. In this example, prefill uses tensor parallelism of 2 and decode uses 1; both inherit max_model_len.
Each disaggregated role’s tensor-parallel group must fit on a single node. Multi-node tensor parallelism is supported for aggregated replicas, not for a disaggregated prefill or decode worker.
Disaggregated serving uses the NIXL connector for KV transfer by default. kv_transfer_config and kv_events_config are managed by NeMo Curator and are not constructor parameters.
Dynamo Configuration Reference
DynamoVLLMModelConfig
All models in one server must have unique model_name values. Dynamo also rejects names that sanitize to the same component slug.
DynamoRoleConfig
DynamoServerConfig
Dynamo Routing
kv_events is valid only with KV routing. When you explicitly set mode="kv", kv_events=False uses approximate tree-based tracking. When mode=None auto-selects KV routing for a disaggregated model, NeMo Curator also enables exact event-backed routing even though the configured default is False. If a publishing role explicitly enables vLLM’s hybrid KV-cache manager, automatic routing instead keeps events disabled; explicitly requesting event-backed routing with that configuration raises an error.
Additional router_kwargs are forwarded to the Dynamo frontend. Do not put router_mode or router_kv_events in that dictionary; use the typed fields instead. Boolean false values are emitted as --no-* flags.
For multimodal OpenAI content arrays, the Dynamo frontend can require:
The worker also needs its model-specific multimodal settings, such as limit_mm_per_prompt in engine_kwargs and enable_multimodal in dynamo_kwargs.
Runtime Environments and Subprocess Variables
Both model types inherit runtime_env from BaseModelConfig:
NeMo Curator merges pip or uv package lists and environment variables instead of replacing the backend’s required packages. Dynamo automatically adds its tested ai-dynamo[vllm] actor environment and pins the actor’s Ray version to the cluster version. On a new cluster node, the first actor can take several minutes to create this cached environment.
Use DynamoServerConfig.subprocess_env for variables that must reach the Dynamo frontend and worker subprocesses:
Resource Placement
Before starting Dynamo, NeMo Curator checks the total requested GPUs and fails early when the cluster is too small.
- Aggregated GPU count is
num_replicas * tensor_parallel_sizeper model. - Disaggregated GPU count is the sum of each role’s
num_replicas * tensor_parallel_size. - Aggregated tensor-parallel groups prefer one node, then use an equal multi-node split.
- Each disaggregated role must fit on one node.
- Set
CURATOR_IGNORE_RAY_HEAD_NODE=1to keep model placement off the Ray head node when worker nodes are labeled for that policy.
Dynamo creates detached, named placement groups and actors. On startup, it removes stale resources with the same server-name prefix. On shutdown, it reacquires actor handles by name, terminates the subprocess groups, and removes the placement groups.
HAProxy Ingress
The NeMo Curator container includes HAProxy and socat. When both binaries are available, local Ray cluster initialization enables Ray Serve’s HAProxy ingress and assigns a free metrics port. If either binary is unavailable, Ray Serve uses its default Python proxy.
No HAProxy configuration is required in InferenceServer. To confirm the optimized path, check startup logs for Ray Serve HAProxy ingress enabled.
Use with NeMo Curator Clients
Point any OpenAI-compatible client at server.endpoint:
For Dynamo, the endpoint host is the node running the frontend placement-group bundle. Use server.endpoint instead of assuming localhost.
Run Pipelines While Serving
Ray Data and Ray Actor Pool executors honor Ray’s GPU accounting and schedule GPU stages away from GPUs held by either inference backend. Xenna manages GPU assignment independently and is rejected when an active InferenceServer and a GPU pipeline stage would conflict.
CPU-only pipelines can use any executor while the server is active.
Migrate from InferenceModelConfig
Before:
After, using Ray Serve:
Or, using static Dynamo replicas:
Do not pass Ray Serve’s deployment_config to DynamoVLLMModelConfig. Use num_replicas or the disaggregated role counts instead.
Troubleshooting
Model Does Not Become Healthy
- Increase
health_check_timeout_sfor large model downloads or slow actor-environment creation. - Check the model name returned by
/v1/models; local paths often need an explicitmodel_namealias. - Confirm the requested tensor-parallel groups fit the cluster topology.
- For Dynamo, inspect subprocess logs under the Ray session’s
nemo_curator_dynamo_<id>directory.
Dynamo Cannot Start etcd or NATS
Install the NeMo Curator container dependencies, or supply existing etcd_endpoint and nats_url values in DynamoServerConfig.
Local Multi-GPU Startup Hangs
On PCIe systems without peer-to-peer GPU access, restart Ray or the Python kernel and either set NCCL_P2P_DISABLE=1 before starting the cluster or reduce tensor_parallel_size to 1.
Runtime Environment Times Out
Ensure cluster nodes can reach the package index and share compatible Python, CUDA, and Ray versions. Dynamo actor setup uses a 600-second timeout; prebuild the NeMo Curator container when workers cannot install packages at runtime.