Endpoint mobility primitives for dynamic LLM serving
communication endpoints that join, leave, fail and migrate with traffic in flight
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 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
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)
| 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)
| File | Interpreter | ABI | Platform | Actions Reset |
|---|---|---|---|---|
| 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.