Skip to main content

Connex

Endpoint mobility primitives for dynamic LLM serving
communication endpoints that join, leave, fail and migrate with traffic in flight

CI License: Apache-2.0 Python 3.10 | 3.11 | 3.12 PyPI: connex-ai data plane: connex-rs (Rust over UCX) SIGCOMM 2026

Connex is a communication library for distributed LLM serving in which the set of peers keeps changing: replicas scale up and down, processes die and come back, work moves between instances. Every endpoint has a stable logical identity that a control plane resolves to its current address, and senders keep in-flight work correct when the endpoint behind an identity changes. Requests hand over to another replica on failure, and new replicas take traffic as soon as they join. Connex is the system described in our SIGCOMM 2026 paper (Citation).

Supported scenarios

Scenario Engines Status
🔗 Multi-replica pipeline parallelism, in-flight failover vLLM (upstream, with 3 proposed changes; legacy fork optional) ✅ validated, across hosts
📈 Elastic scale up / down vLLM ✅ validated
🔀 Prefill-decode disaggregation, elastic P/D pools vLLM, SGLang ✅ validated, across hosts
🧩 Tensor parallelism: a TP group is one endpoint vLLM, SGLang ✅ validated, groups within a host
🧠 Expert parallelism (MoE): expert placement, migration, failover vLLM, SGLang ✅ validated (vLLM across 2 hosts)
🎯 RL post-training: elastic weight sync vLLM, SGLang ✅ validated
🤖 Agent session migration vLLM, SGLang ✅ validated (re-prefill)
🧬 Heterogeneous transports and GPUs: RDMA, TCP, GPUDirect, host staging any; mixed GPUs: vLLM PD ✅ validated
🪓 Attention-FFN disaggregation 🗺️ roadmap

PP, PD, TP, EP, RL and agent support run on upstream engines as plugins, without a fork. Upstream PRs: vLLM ConnexConnector for PD (vllm#63804), vLLM Connex weight transfer backend for RL (vllm#63805), SGLang connex KV transfer backend (sglang#46599), vLLM pluggable PP group via --pp-group-cls (vllm#63897), vLLM --pipeline-stage-rank for external PP stages (vllm#63898), vLLM recompute of lost KV requests (vllm#63899). Pipeline parallelism is proposed in vllm#63818 (RFC: pluggable PP transport); the plugin connex.adapters.vllm.pp runs on the latest vLLM main with the three changes it proposes, and the Docker image builds that by default (integrations/vllm/README.md, results in docs/results.md). Limits per scenario: Scenarios and status.

Quick start

pip install connex-ai                 # core (import name: connex)
pip install "connex-ai[rs]"           # + connex-rs, the RDMA data plane
pip install "connex-ai[vllm,rs]"      # + vLLM plugins (PP, PD, TP, EP, RL)
pip install "connex-ai[sglang,rs]"    # + SGLang plugins

A CPU-only example: a sender talks to two replicas of one logical group and keeps working while one dies, rejoins, migrates to a new address and leaves (examples/mobile_endpoints.py):

peers = ElasticPeerSet(owner, transport, stage_idx=1)   # resolved through the directory
peers.send(peers.pick(), b"step")
peers.mark_failed(("demo", 1, 0, 1))    # replica 1 died
peers.send(peers.pick(), b"step-42")    # in-flight step handed over to replica 0
b.register()                            # replica 1 rejoins
a.register(addresses=[new_addr_a])      # replica 0 migrates, same identity

Prefill-decode disaggregation on upstream vLLM:

# prefill and decode instances; the connector is registered by the connex-ai plugin
vllm serve <model> --port 8100 --kv-transfer-config '{"kv_connector":"ConnexConnector",
  "kv_role":"kv_producer","kv_connector_extra_config":{"ctrl_port":17100}}'
vllm serve <model> --port 8200 --kv-transfer-config '{"kv_connector":"ConnexConnector",
  "kv_role":"kv_consumer"}'
connex-pd-router --port 8000 --prefill http://<p-host>:8100 --decode http://<d-host>:8200

Every scenario has its own guide (links in the table above). Deployment from a CPU demo to Kubernetes: docs/deploy.md.

How it works

Connex control plane (front router / directory, mobility, step protocol) and the pluggable data plane (connex-rs, Mooncake TE, UCX, ZeroMQ)

Connex separates who talks to whom, and what happens when that changes from how the bytes move. The control plane holds logical identities, leases and membership events. The delivery contract (correlation ids, idempotent retries, stale-reply filtering) makes it safe to resend in-flight work to another replica. Bytes move through a pluggable data plane: on RDMA hosts the default is connex-rs, our Rust data plane over UCX, which reports a dead peer within milliseconds and lets a restarted process rejoin under the same identity. Mooncake Transfer Engine, UCX and ZeroMQ also work. Details: docs/overview.md.

Results

Handover time (kill a stage to next token) and steady-state mean latency, connex-rs vs Mooncake TE

Llama-3-8B on A40 GPUs (OLMoE-1B-7B for EP); every request completed and no token differed from the greedy reference in any failure run.

Scenario Steady state Kill a process under load
Pipeline, 4 stages × 2 replicas same latency as Mooncake TE next token 0.01-0.83 s after the kill (Mooncake: 2-3 s)
Pipeline on upstream vLLM, one host or across hosts on par with NCCL at matched KV size: 2 hosts, PP=2 TPOT 28.36 ms vs 28.28 ms at C=1, 41.6 ms vs 41.9 ms at C=32; PP2×TP2 15.60 vs 15.53 ms at C=1 and 23.1 vs 22.0 ms at C=32 (1179 vs 1184 tok/s); mean TTFT within 2 % of NCCL (PP2×TP2 at C=1: 76.5 ms vs 74-83 ms) every in-flight request completes, 0 greedy tokens off the argmax; largest no-token window across hosts 0.36-0.39 s at PP=2 (one run of 9 at 0.72 s) and 0.34-0.40 s at PP2×TP2, including the first failover onto a spare that never served, about 32 s restarted in place (NCCL: all in-flight requests lost, down 57-63 s)
PD disaggregation, one host or across nodes on par with NIXL (vLLM) and Mooncake (SGLang) decode kill: KV re-pulled, max stall 0.63 s
Tensor parallelism 2 PD 1061 tok/s, TPOT 16 ms one rank killed: whole group out in 0.16-0.57 s, stall 0.4 s
Expert parallelism 2,307 tok/s vs 2,338 for vLLM's EP rank failure detected in 0.05 s, max stall 0.18 s (across nodes: 0.29 s, 0.37 s)
Churn, replica killed every 60 s 99.2-99.6 % goodput, 100 % with the resume proxy

Full tables, setup and reproduction commands: docs/results.md (pipeline on upstream vLLM: section 13).

Documentation

Overview abstractions, scenario status, architecture, limitations
Deploy CPU demo, docker compose, multi-host, Kubernetes
Configuration every environment variable and flag
Results all measurements and how to reproduce them
vLLM integration pipeline parallelism on upstream vLLM (plugin); legacy external-PP fork with engine patches
Design notes rationale and engine contract

Contributing

See CONTRIBUTING.md. Changes are listed in CHANGELOG.md.

Citation

If you use Connex in your research, please cite our paper:

@inproceedings{lin2026connex,
  title={Connex: Endpoint Mobility Primitives for Dynamic LLM Serving},
  author={Lin, Yanying and Liu, Vincent and Luo, Tao and Xu, Chengzhong and Ye, Kejiang},
  booktitle={Proceedings of the ACM SIGCOMM 2026 Conference},
  pages={46--59},
  year={2026}
}

License

Apache-2.0, see LICENSE.

Metadata

Release files for connex-ai 0.2.1

For a detailed explanation of source distributions (sdists) and built distributions (wheels), please see the package formats documentation.

Source distribution (sdist)

Source distribution for connex-ai 0.2.1
File Size Uploaded Provenance Actions
connex_ai-0.2.1.tar.gz 471.0 kB Without provenance Details for connex_ai-0.2.1.tar.gz

Built distribution (wheel)

Table of built distributions (wheels) for connex-ai 0.2.1
File Interpreter ABI Platform Actions
connex_ai-0.2.1-py3-none-any.whl Python 3 none any Details for connex_ai-0.2.1-py3-none-any.whl

Total release size: 865.7 kB

Release files / connex_ai-0.2.1.tar.gz

Download URL connex_ai-0.2.1.tar.gz
Size 471.0 kB
Tags Source
SHA-256 checksum
How to use checksums
542015fa48e92cab14a673f5079d4349144d6e19382632ffaebfa4159530b334
BLAKE2b-256 checksum
How to use checksums
839cb2872b54899634764b9c8285b32eac0f08687c75de6b0b682c2e0abde8c5
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.10.12

Release files / connex_ai-0.2.1-py3-none-any.whl

Download URL connex_ai-0.2.1-py3-none-any.whl
Size 394.7 kB
Tags Python 3
SHA-256 checksum
How to use checksums
028ef95bf560e635456ec7bd0bb741a25ef04b3185788d02b350dd4a20168c13
BLAKE2b-256 checksum
How to use checksums
4da20722ea361a50cdf6ed46599fc180686ba64e1097f8149e89531cf6df741e
Upload date
Uploaded using Trusted Publishing?
What is trusted publishing?
No
Uploaded via twine/7.0.0 CPython/3.10.12

Security for connex-ai 0.2.1

Provenance

Provenance describes where a file came from. On PyPI, provenance is shared via attestations, which provide a verifiable record of the build or publishing details. View details, limitations and caveats.

No provenance found

None of the files in this release were uploaded with provenance metadata.

A note on package security

PyPI is a repository for distributing packages, not a service for auditing them. While third-party security researchers and our staff do their best to detect and remove malicious packages, PyPI cannot guarantee the quality, security or suitability of any given package.

To learn more about protecting yourself from malicious actors, visit our package security documentation.

Anthropic, PBC Visionary sponsor Bloomberg Visionary sponsor Hudson River Trading Visionary sponsor Meta Visionary sponsor NVIDIA Visionary sponsor Microsoft Sustainability sponsor Depot Continuous Integration AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Sentry Error logging StatusPage Status page