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.0

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.0
File Size Uploaded Provenance Actions
connex_ai-0.2.0.tar.gz 461.5 kB Without provenance Details for connex_ai-0.2.0.tar.gz

Built distribution (wheel)

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

Total release size: 851.4 kB

Release files / connex_ai-0.2.0.tar.gz

Download URL connex_ai-0.2.0.tar.gz
Size 461.5 kB
Tags Source
SHA-256 checksum
How to use checksums
a86c16f77a7df236f583a817984360df4c1f005cfd7b2a3d60b04624928f8c26
BLAKE2b-256 checksum
How to use checksums
21de19081baa1aac883744d502ec00f19fc10d5f980ec0ffe20dad10c315a755
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.0-py3-none-any.whl

Download URL connex_ai-0.2.0-py3-none-any.whl
Size 389.9 kB
Tags Python 3
SHA-256 checksum
How to use checksums
313483505f759670f359d31073958daecb62036e73f58c4867f825a0d8bb48a0
BLAKE2b-256 checksum
How to use checksums
1dae01fdadd443429b41eabe09c3c240119f0d89e78cac41181665edf29575a0
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.0

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