Nvidia nixl
Claude Code plugin marketplace — 58 installable reference skills across vLLM/SGLang inference, Kubernetes & Harvester, GPU host bring-up, observability, security, and agent workflows.
npx -y skills add air-gapped/skills --skill nvidia-nixlAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
NVIDIA Inference Xfer Library (NIXL) operator + developer reference. Point-to-point KV-cache and tensor transport for distributed inference (Dynamo, vLLM, SGLang). Covers the agent API (full Python reference; C++/Rust via upstream pointers), all 15 backend plugins (UCX, GDS, GDS_MT, libfabric, mooncake, posix, hf3fs, obj/S3, azure_blob, infinia/DDN, gusli, uccl, gpunetio/DOCA, telemetry, tracing), AMD ROCm/HIP support, build paths (pip nixl-cu12/cu13, meson+ninja from source), ETCD vs side-channel metadata, telemetry (Prometheus + cyclic shared-memory), NIXL-EP elastic MoE device kernels, and Dynamo / vLLM NixlConnector / SGLang integration patterns.
SKILL.md
19.5 KB, ~5.1k tokens by cl100k_base, as published. Nobody here has run it
NVIDIA Inference Xfer Library (NIXL)
Target audience: operators wiring NIXL into Dynamo/vLLM/SGLang clusters, plugin authors writing new backends, developers using the agent API directly from Python (references/python-api.md). C++/Rust developers: consult src/api/cpp/ headers and examples/{cpp,rust}/ upstream directly — this skill does not carry a C++/Rust API reference. Assumes datacenter-class GPUs (H100/H200/B200/B300) with NVIDIA driver, CUDA 12.8+, RDMA NIC (Mellanox/EFA) for cross-node, and Linux (Ubuntu 22.04/24.04 or Fedora). macOS and Windows are not supported.
What NIXL is — one paragraph
NIXL is the transport, not a cache. If the goal is a KV cache that outlives a
single vLLM process, the thing being configured is lmcache-mp (same
inference-cache plugin) — a standalone LMCache server that can use NIXL as one
of its backends. Come here for the agent API, plugins, and wire-level
behaviour; go there for the cache server's deployment, sizing, and ZMQ wiring.
NIXL is a thin abstraction over heterogeneous transport backends. A nixlAgent registers memory regions (DRAM, VRAM, FILE, BLOCK, OBJ), exchanges metadata with peer agents via either ETCD or socket side-channel, then issues asynchronous one-sided READ/WRITE transfers between local and remote registered memory. The agent picks the best backend (UCX for network, GDS for storage, etc.) based on memory types and what both sides have loaded. Same-process loopback, intra-node GPU-to-GPU, and cross-node RDMA are all the same API. Two operations only — read and write — and both are non-blocking with optional notifications.
Version snapshot — verify before recommending
| Item | Value | Source |
|---|---|---|
| Latest release | v1.3.1 (2026-07-08) | gh release list --repo ai-dynamo/nixl |
| Previous releases | v1.3.0 (2026-06-15) — AMD ROCm/HIP, C++20, DDN Infinia backend, path-based file registration; v1.2.0 (2026-05-30) — OS-assigned listener port, libfabric FI_MORE batching; v1.1.0 (2026-05-12); v1.0.1 (2026-04-14); v1.0.0 (2026-03-13) — first stable | release notes |
| HEAD pyproject version | 1.4.0 | pyproject.toml |
| What vLLM pins | nixl == 1.3.0 (exact) at vLLM v0.25.1 | requirements/kv_connectors.txt |
| PyPI wheels | nixl-cu12, nixl-cu13 (auto-selects at runtime via PyTorch CUDA version since 1.0.1) | pip install nixl |
| Torch dep pin | torch==2.11.*; nixl_ep wheels build against 2.11/2.12/2.13 and select by installed Torch at import (1.3.1, #1775) | pyproject.toml, contrib/Dockerfile |
| C++ standard | C++20 since v1.3.0 (#1571) — building NIXL or a plugin from source now needs a C++20 toolchain | release notes |
| UCX version | 1.20.x tested; UCX_MAX_HCA_PER_GPU=auto set automatically on UCX ≥ 1.21 (1.2.0, #1637) | repo README.md, src/plugins/ucx/ucx_utils.cpp |
| GPU vendors | NVIDIA; AMD Instinct (MI300X/MI325X gfx942, MI350X/MI355X gfx950) via ROCm/HIP since v1.3.0 (#1642, #1647), nixlbench included | release notes |
| Plugins | 15: ucx, libfabric, mooncake, uccl, gpunetio, cuda_gds, gds_mt, posix, hf3fs, obj (S3), azure_blob, gusli, telemetry, infinia (DDN, new in 1.3.0), tracing | src/plugins/ at tag v1.3.1 |
| Memory types | DRAM, VRAM, FILE, BLOCK, OBJ | src/api/python/_api.py |
| Operations | READ, WRITE | (no SEND/RECV — one-sided) |
For staleness — see references/sources.md for verified URLs. Run freshen mode of skill-improver to refresh.
Decision tree — picking a backend
Is the transfer across nodes?
├─ Yes → Network backend
│ ├─ Standard RDMA (RoCE / IB) on Mellanox NICs? → UCX
│ ├─ AWS EFA? → libfabric (validated) or UCX
│ ├─ Heterogeneous GPU/NIC, software transport (no RDMA)? → UCCL [Preview]
│ ├─ KVCache-centric workload, multi-protocol (TCP/RDMA/CXL/NVMe-oF)? → mooncake [Preview]
│ └─ GPU-driven RDMA (GDAKI, kernel-launched)? → gpunetio (DOCA)
└─ No → Local / storage backend
├─ NVMe / parallel FS via GPUDirect Storage? → cuda_gds (single-thread) or gds_mt (multi-thread)
├─ Plain POSIX file (libaio default, liburing opt)? → posix
├─ DeepSeek 3FS distributed FS? → hf3fs
├─ Block storage via GUSLI shared-mem client? → gusli
├─ S3 (or S3-compatible) object store? → obj (with optional cuobjclient accelerated engine)
├─ DDN Infinia storage? → infinia (v1.3.0+)
└─ Azure Blob? → azure_blob
The published manylinux wheels bundle libplugin_INFINIA.so by default as of v1.3.1 (#1832); the proprietary DDN libred_* runtime libraries are deliberately not vendored and are loaded from the customer's DDN install at /opt/ddn/red.
A single agent can instantiate multiple backends; per-transfer the agent chooses one based on the memory types involved and what the remote side advertises. Pass backends=["UCX","GDS"] to nixl_agent_config (Python) or createBackend calls (C++) to constrain candidates.
Quick start (Python)
import torch
from nixl import nixl_agent, nixl_agent_config
# Agent on each side
config = nixl_agent_config(
enable_prog_thread=True,
enable_listen_thread=True, # socket side-channel
listen_port=5555,
capture_telemetry=False,
backends=["UCX"], # default; use ["UCX","GDS"] etc. to add more
)
agent = nixl_agent("agent-1", config)
# Register a tensor (auto-detects DRAM vs VRAM)
tensor = torch.zeros((10, 16), dtype=torch.float32)
reg = agent.register_memory(tensor)
# After exchanging metadata (see references/python-api.md):
local_descs = agent.get_xfer_descs([tensor[i, :] for i in range(10)])
xfer = agent.initialize_xfer("READ", local_descs, target_descs, "agent-2", b"done")
agent.transfer(xfer)
while agent.check_xfer_state(xfer) == "PROC":
pass # spin or do other work
End-to-end working programs in examples/python/basic_two_peers.py, expanded_two_peers.py, partial_md_example.py. Full surface in references/python-api.md.
Metadata exchange — choose ONE of two modes
Side-channel (default). Each agent runs a TCP listener (enable_listen_thread=True, listen_port=N). One agent calls fetch_remote_metadata(remote_name, ip, port) to pull, or send_local_metadata(ip, port) to push. Good for fixed-pair setups, lab environments. Defaults to port 5555.
Since v1.2.0 (#1439) you can pass listen_port=0 to let the OS assign a free port; the bound port is recovered via getsockname() and logged at NIXL_INFO. Use this when several agents share a host and would otherwise collide on a hard-coded port — the peer then needs the port out-of-band. The same release widened the port fields (listenPort / listen_port) from int to uint16_t in nixl_params.h / nixl_types.h, and the Rust bindings gained a DEFAULT_COMM_PORT constant.
ETCD. Set NIXL_ETCD_ENDPOINTS=http://etcd:2379 (comma-separated for HA). Each agent calls sendLocalMD() / fetchRemoteMD(remote_name) (no IP/port args). Required for elastic / dynamic-scaling clusters where peers are not known upfront. ETCD is also how nixlbench discovers workers.
Both modes support send_partial_agent_metadata(descs, inc_conn_info, backends, label=...) — only register-then-send the metadata for specific descriptor lists, useful when memory regions are dynamic or to avoid advertising everything. Example: examples/python/partial_md_example.py.
Plugin Manager + plugin search path
The plugin manager defers loading until first use (#1546, in v1.0.0+) and reads NIXL_PLUGIN_DIR to find dynamic plugins on disk. Static plugins are compiled in. Set this env var explicitly when running from non-system paths:
export NIXL_PLUGIN_DIR=/path/to/nixl/lib/x86_64-linux-gnu/plugins
agent.getAvailPlugins() lists what was discovered. agent.getPluginParams("UCX") returns the param schema + supported memory types for that plugin (use this to discover what to pass to createBackend).
NIXL-EP — elastic Expert Parallel device kernels
examples/device/ep/csrc/ ships device-side CUDA kernels for MoE all-to-all dispatch — nixl_ep_ll.cu (low-latency) and nixl_ep_ht.cu (high-throughput). Two API surfaces, one mode per agent: mixing LL and HT calls on the same agent is a hard error (mode guards added in v1.0.1, #1538). NIXL-EP also supports elastic scale-up (new nodes joining a running deploy), with signaling-buffer fixes in v1.0.1 (#1453). GPU timeouts are configurable (#1520). NIXL-EP is the layer Dynamo's MoE plane will land on; for plain disaggregated prefill (single tensor transfer), use the regular agent API.
Breaking change in v1.3.0 (#1693): rank/expert semantics were refactored for elastic rank handling — dispatch/combine now take an active-rank bound plus experts-per-rank parameterization, buffers/layouts moved to an active-range model, mask updates became public with host-side active-rank tracking, and the legacy mask-clean API was removed. Code written against 1.2.x NIXL-EP needs porting. vLLM has been consuming this: NIXL EP + DBO (#45275), elastic-EP communicator (#45013), and NVFP4 post-receive quantization skip (#45606) all landed in vLLM v0.24.0.
Telemetry — two exporters, environment-driven
| Env var | Purpose | Default |
|---|---|---|
NIXL_TELEMETRY_ENABLE | Master switch (y/yes/1 to enable) | false |
NIXL_TELEMETRY_EXPORTER | Plugin name; empty falls back to cyclic buffer if NIXL_TELEMETRY_DIR set | unset |
NIXL_TELEMETRY_DIR | Output dir for cyclic buffer files (one file per agent) | unset |
NIXL_TELEMETRY_BUFFER_SIZE | Events in cyclic buffer | 4096 |
NIXL_TELEMETRY_RUN_INTERVAL | Flush interval ms | 100 |
Cyclic buffer = static plugin, shared-memory ring; readers in examples/python/telemetry_reader.py and examples/cpp/telemetry_reader.cpp. Prometheus exporter is dynamic + experimental (beta) as of v1.0.x — see src/plugins/telemetry/prometheus/README.md. The Prometheus Exposer is shared across agents in the same process (v1.0.0 PR #1470). Built-in metrics: agent_tx_bytes, agent_rx_bytes, agent_xfer_time (µs), agent_xfer_post_time (µs), agent_memory_registered, etc. — full table in references/architecture.md and per-transfer telemetry via agent.get_xfer_telemetry(handle).
Common gotchas — read before deploying
UCX_TLSis the #1 source of segfaults in vLLM+NIXL deploys.UCX_TLS=tcpalone segfaultsnixlUcxSharedThread::run()after prefill on CUDA-capable images that haven't been told the GPU is reachable. UseUCX_TLS=cuda_copy,sm,tcp(or fullcuda_copy,cuda_ipc,sm,tcp,rcfor cross-node). Symptom:W ucx_utils.cpp:581: memory is detected as host. (Verified invllm-cachingskill 2026-04-25.)- First transfer after pod-ready may fail with
NIXL_ERR_REMOTE_DISCONNECT— handshake race. Retry the second request. Side-channel listener takes a few seconds to bind. - Side-channel host MUST be a real interface, not a service VIP. In Kubernetes, set
VLLM_NIXL_SIDE_CHANNEL_HOST=$(POD_IP)via downward API and use a headless Service (clusterIP: None,publishNotReadyAddresses: true). Same applies to ETCD-mode if pods advertise their own addr. NIXL_PLUGIN_DIRdefaults aren't reliable in non-pip installs. Ifagent.getAvailPlugins()returns[]and an exception fires (No plugins available for NIXL), the env var is wrong. Verify withls $NIXL_PLUGIN_DIR/libplugin_*.so.- Mooncake plugin disables progress thread, has its own metadata system that bypasses NIXL's, and caps transfer requests per handle at 1024 (
kMaxRequestCount). It's[Preview]. Don't compose with strict NIXL-only metadata flows. - GDS requires
cufile.jsonwithallow_compat_mode: trueunless full GDS is wired (kernel module + supported FS). The plugin README has the canonical config andCUFILE_ENV_PATH_JSONexport. - HF3FS needs page-aligned, page-size-multiple memory for the zero-copy
mmap()shared-memory path; otherwise it copies. Passmem_config=dram_zcto fail loud if alignment is wrong. - gpunetio (DOCA) is single-NIC + single-GPU per backend. To use 2 NICs, instantiate 2 backends with different
network_devices.nvshmem-aware bench mode supports VRAM-only transfers. - EFA-only configs in UCX were gated to not poison non-EFA setups in v1.0.1 (#1527). Below that, UCX with EFA-tuned defaults could degrade other systems.
- Telemetry timestamps were removed from events in v1.0.0 (#1522) — readers must derive ordering from ring-insertion order, not event timestamp fields. The
categoryfield was also removed in v1.3.0 (#1649); consumers parsing telemetry events must drop it. - Path-mode
FILE_SEGregistrations need a uniquedevIdeach (v1.3.1, #1790). v1.3.0 added path-based file registration — declare a file by path innixlBlobDesc::metaInfoas<modes>:<path>(ro/rwplusdirect/sync/noatime/create), and POSIX / HF3FS / CUDA_GDS / GDS_MT open it inregisterMemand close it inderegisterMem. Reusing an in-usedevIdacross distinct path-mode files caused a double-free on deregister and is now rejected withNIXL_ERR_INVALID_PARAM. The older fd-in-devIdmode is unchanged — one fd may still back multiple descriptors at different offsets. - Building from source requires a C++20 toolchain since v1.3.0 (#1571). Full-sweep CUDA builds are slow; pass
-Dnixl_cuda_arch_list=90,100(or your SM list) instead of the defaultsm_80,86,89,90,100,103,120.
Full debugging cookbook in references/gotchas.md.
What this skill does NOT cover (and where to go)
- vLLM
NixlConnectorconfiguration (--kv-transfer-config,kv_role, K8s pod shape, the proxy server) — covered invllm-cachingskill, especiallyreferences/connectors.md"NixlConnector" section. The vllm-caching skill has live-lab-verified recipes for 1P1D Qwen3-4B on consumer hardware including the six non-obvious env vars. - Dynamo deployment and disaggregation orchestration — Dynamo docs at
https://docs.nvidia.com/dynamo/. NIXL is the data plane; Dynamo handles request routing, scheduling, and the rest of the control plane. - vLLM-stack production deploy (LMCache, MooncakeConnector etc.) —
vllm-deploymentandvllm-cachingskills. - SGLang KV transport — SGLang has its own connector; NIXL is one of the available backends. Consult SGLang docs.
When the user is stuck — diagnostic flow
Quick first pass: run python ${CLAUDE_SKILL_DIR}/scripts/check_install.py --backends UCX,LIBFABRIC,GDS (substitute backends used). Validates wheel/CUDA match, plugin discovery, UCX_TLS, ETCD reachability, cufile.json — covers gotchas #1, #2, #4, #5, #7 in references/gotchas.md.
nixl_agentraisesRuntimeError("No plugins available")→NIXL_PLUGIN_DIRis wrong, OR pip wheel mismatch (nixl-cu13on CUDA 12 host etc.). Confirmpip show nixl-cu12 nixl-cu13and which one PyTorch CUDA matches.- Hangs on
fetch_remote_metadata→ side-channel listener didn't start. Checkenable_listen_thread=Trueon the target, port not collided, firewall open. Add a 5 s sleep before fetching. NIXL_ERR_REMOTE_DISCONNECT→ handshake race or network ACL. Retry. CheckUCX_TLS. Confirm peer is listening withss -tlnp | grep <port>.Posting transfer failed.(state == "ERR") → the agent rejected the request. Common causes: descriptor not within registered region, remote agent metadata not loaded yet (callcheck_remote_metadata(name)first), or backend not available on both sides. Checkagent.query_xfer_backend(handle)if it's prepped.- Throughput nowhere near line rate → run
nixlbench --backend UCX --etcd-endpoints ... --initiator_seg_type=VRAM --target_seg_type=VRAMto isolate. Compare against AWS/Mellanox-published numbers. CheckUCX_TLS,UCX_NET_DEVICES,cudaDeviceCanAccessPeer, GDS path withgdscheck. - Correctness bug after upgrade →
git log v1.0.0..v1.0.1and search for the relevant subsystem; the libfabric / NIXL-EP subsystems had several correctness fixes in 1.0.1.
references/gotchas.md has the full diagnostic flow with commands.
References
references/architecture.md— Agent + Memory Section + South Bound API (SB API) + Plugin Manager + descriptor lists + NIXL-EP device kernels + telemetry event catalog.references/plugins.md— All plugins with deps, parameters, capabilities, when-to-pick (13 documented in depth;infiniaandtracingadded in the 1.3 line — read theirsrc/plugins/<name>/README.mddirectly).references/python-api.md—nixl_agentPython surface with worked examples for every common operation.references/deployment.md— pip install, source build (meson+ninja), Docker, K8s, ETCD setup, env vars,nixlbench,kvbench.references/integrations.md— Dynamo, vLLMNixlConnector, SGLang, observability stack pointers.references/gotchas.md— Debugging cookbook, error catalog, threading/sync model, build pitfalls.references/sources.md— Verified URLs withLast verifieddates.scripts/check_install.py— Sanity-check script: wheel/CUDA match, plugin discovery, UCX_TLS, ETCD reach, cufile.json. Run before debugging deeper.
Authoritative upstream sources
Primary: https://github.com/ai-dynamo/nixl (releases via gh release list --repo ai-dynamo/nixl). Canonical docs live in-tree under docs/ (nixl.md, BackendGuide.md, telemetry.md, python_api.md); Python API source src/api/python/_api.py; per-plugin docs src/plugins/<name>/README.md; examples examples/{python,cpp,rust,device/ep}/; benchmarks benchmark/{nixlbench,kvbench}/. Full URL list with verification dates in references/sources.md.
When asked about a specific backend, read the plugin's README.md under src/plugins/<name>/ first — every plugin documents its own deps, params, and gotchas there. Then map to references/plugins.md for the cross-cutting matrix.
Gives 0 of the 12 instructions most monitoring observability skills give in ~5.1k tokens
Counted across 481 of the 483 authors here whose files we hold, read 2026-08-06
- link every alert to a runbookin 43 of 481, across 35 files
- use structured json loggingin 36 of 481, across 31 files
- alert on user-facing symptomsin 20 of 481, across 15 files
- emit structured JSON logs with stable event namesin 18 of 481, across 13 files
- propagate trace context across boundariesin 16 of 481
- use histograms for latency trackingin 14 of 481, across 9 files
- use OpenTelemetry for distributed tracingin 13 of 481, across 8 files
- include a correlation ID on every log linein 13 of 481, across 8 files
- Define service level objectivesin 10 of 481, across 7 files
- Call useAzureMonitor before importing other modulesin 9 of 481, across 2 files
- stop and ask for clarification if inputs are missingin 9 of 481, across 2 files
- define on-call questions before adding telemetryin 9 of 481, across 4 files
Said here and by no other author read
- use c++20 toolchain for source builds
- use a real network interface for side-channel host
- use headless services in kubernetes
- retry the second request on initial disconnect
- set listen_port to zero to assign a free port
- set nixl_plugin_dir for non-pip installs
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.