AFD Plugin Explained

Glossary

Referenceabout 12 min read

Code version: afd-plugin @ 7452d52 · 2026-10-27 · vLLM @ ced6857

This page lists every term that has a tooltip on this site. Each entry gives a short definition. Many entries link to a page with the full explanation.

A B C D E F G H L M P R S U V W X

A#

ACL graph also: ACL graph mode, Ascend graph

The Ascend NPU form of a captured graph, the NPU counterpart of a CUDA graph. The NPU validator accepts the FULL and FULL_DECODE_ONLY modes.

The NPU runtime is covered on Ascend NPU overview: the same contract, different transports. The mode check is afd_plugin/validation.py:233-239.

Read more: Ascend NPU overview: the same contract, different transports

additional_config also: --additional-config

A vLLM config field. The plugin reads its "afd" key for the role, the connector, the topology sizes and the host/port.

Read more: AFD configuration: additional_config["afd"]

AFD also: Attention-FFN Disaggregation, attention-ffn disaggregation

Attention-FFN Disaggregation. The attention part and the feed-forward (FFN/MoE) part of a model run in separate server processes and exchange hidden states.

Read more: What is AFD?

AFD forward metadata also: AFDForwardContextMetadata, afd_metadata, forward-context sidecar

A sidecar object that AFD attaches to the vLLM forward context. It holds the connector, the stage index and count, the transaction id, and the token offsets and lengths.

Model wrappers read it with get_afd_metadata_from_forward_context; the runner installs it as vLLM makes each forward context (afd_plugin/model_executor/models/forward_context.py:18-67).

Read more: The attention runtime: a seam over Model Runner V2

AFD world also: AFD NCCL world, afd world, AFD world group

The connector's process group across both roles. The P2P connector orders it [F0..A0..]: FFN ranks first, then attention ranks.

The GPU connector creates it as the "afd" NCCL group with world size ffn_size + attention_size (afd_plugin/connectors/gpu/p2p.py:269-276).

Read more: Topology and role ranks: the AFD world

afd-plugin also: the plugin, afd plugin

The vLLM external plugin that adds AFD. vLLM loads it; it changes no vLLM source file.

Read more: AFD Plugin Explained

afd_balanced routing also: AFDBalancedRoutingStrategy, routing simulator

A deterministic, EP-balanced MoE routing strategy for benchmarks. It returns uniform weights and fixed expert ids, so it changes model outputs.

Opt in with vLLM's VLLM_MOE_ROUTING_SIMULATION_STRATEGY (afd_plugin/model_executor/routing_simulator.py:122-171). It is for benchmark and profiling runs only.

Read more: The MoE handoff: where the gate runs

AFDConfig

The plugin's own configuration object. It holds the role, the connector name, the topology sizes and the rendezvous host/port.

A dataclass defined in config.py (afd_plugin/config.py:42).

Read more: AFD configuration: additional_config["afd"]

async_dp

An AFD config flag. It is NPU-only: it turns on the async data-parallel patches, is gated at run time, and must be false on GPU.

Read by is_afd_async_dp (afd_plugin/config.py:295-308); it needs the async CAM connector.

Read more: AFD configuration: additional_config["afd"]

attention role also: attention side

The side that runs attention and sends hidden states to the FFN side. The default role of a process.

The role is set in AFDConfig.role; the default is "attention" (afd_plugin/config.py:56).

Read more: Attention and FFN roles: what each server owns

attention server

The vllm serve process that plays the attention role. It owns the API server, the scheduler and the KV cache.

Read more: Attention and FFN roles: what each server owns

B#

BATCH_SIZE_FACTOR also: CAM receive capacity

An Ascend NPU environment variable that multiplies the CAM receive capacity (base 262144 tokens), with native float rounding. Default 1.

Read in afd_plugin/validation.py:45-54 and afd_plugin/compat/npu/feature_validation.py:245-249. It has no effect on GPU.

Read more: Tuning: the knobs the repo exposes

C#

CAM

The Ascend NPU communication operators used by the NPU connectors. One connector is synchronous, the other asynchronous.

Read more: Ascend NPU overview: the same contract, different transports

citation

A link to a file and line in the code. Every claim about the code on this site has one.

Read more: AFD Plugin Explained

commit

One saved version of a git repository. A 40-character id names it. This site explains one pinned commit of each repository.

Read more: AFD Plugin Explained

compute_gate_on_attention

An AFD config flag. When true, the attention side computes the MoE gate and sends the router logits to the FFN side.

The flag defaults to false (afd_plugin/config.py:66).

Read more: The MoE handoff: where the gate runs

connector also: AFD connector

The object that moves hidden states between the attention role and the FFN role. Each connector picks one transport.

Connectors subclass AFDConnectorBase (afd_plugin/connectors/base.py:37).

Read more: The connector contract: the Attention/FFN transport

connector_extra_config also: connector extra config

A mapping of connector-specific options inside the AFD config. Each connector declares which keys it accepts, and rejects the rest.

Parsed by each connector's parse_extra_config class method (afd_plugin/connectors/base.py:64-72).

Read more: AFD config reference: the additional_config["afd"] keys

control plane

The path that carries DP metadata (per-stage token counts) from the attention side to the FFN side. It is optional.

The control plane is an AFDControlPlane (afd_plugin/connectors/base.py:258); a connector exposes it as control_plane, or sets it to None.

Read more: The control plane: DP metadata once per step

custom op

A function registered as torch.ops.vllm.* so torch.compile and CUDA graphs can trace it. The P2P sends and receives are custom ops.

Read more: The connector contract: the Attention/FFN transport

D#

data plane

The path that carries the hidden-state tensors between the two roles. It is the connector's send and receive calls.

Read more: Data on the wire: tensors per layer and stage

DBO also: dual-batch overlap

Dual-batch overlap. The step is split into two microbatches so compute and communication overlap. AFD uses exactly two.

Read more: Dual-batch overlap (DBO): two stages per step

DBO yield also: manual_dbo_yield, dbo yield

A custom op that hands control to the other ubatch thread. The AFD proxy calls it between the send and the receive, so the second stage runs while the first waits.

Registered as torch.ops.vllm.manual_dbo_yield (afd_plugin/v1/worker/dbo.py:27-49). It yields only when vLLM DBO is active (afd_plugin/v1/worker/dbo.py:52-54).

Read more: Dual-batch overlap (DBO): two stages per step

DP metadata also: data-parallel metadata

The per-step data-parallel metadata the attention side sends to the FFN side on the control plane. It carries the per-stage token counts that set the tensor shapes.

Read more: The control plane: DP metadata once per step

E#

EngineCore

The vLLM v1 engine core process. On the FFN role it returns early after the executor is built: no scheduler, no loop.

Read more: Attention and FFN roles: what each server owns

entry point

A Python packaging hook. vLLM reads the vllm.general_plugins entry points and calls each one at start-up.

afd-plugin declares afd = "afd_plugin:register_afd" under vllm.general_plugins (pyproject.toml:45-46).

Read more: How vLLM plugins work

F#

FFN graph key also: make_ffn_graph_key, graph key

A hashable key built from the per-stage DP metadata. The FFN runner uses it to store and look up one captured CUDA graph per token shape.

Built by make_ffn_graph_key (afd_plugin/v1/worker/cuda_graph.py:104-133).

Read more: CUDA graphs in AFD: FULL_DECODE_ONLY on both roles

FFN role also: FFN side

The side that runs the feed-forward and MoE experts. It receives hidden states, computes, and sends the result back.

Read more: Attention and FFN roles: what each server owns

FFN server

The vllm serve process that plays the FFN role. It has no API server, no scheduler and no KV cache; a connector loop drives it.

Read more: Attention and FFN roles: what each server owns

FFN server loop also: FFN loop, server loop

The connector-driven daemon thread on the FFN worker. It waits for DP metadata, then runs the FFN compute for one step. No scheduler drives it.

Started in AFDFFNWorker.start_ffn_server_loop (afd_plugin/v1/worker/ffn_worker.py:133); the loop body is _run_ffn_server_loop (afd_plugin/v1/worker/ffn_worker.py:160).

Read more: Tour: Life of a request

FULL_DECODE_ONLY

The only CUDA graph mode that AFD supports on GPU. Graphs capture decode steps only; other batches run eager.

The GPU set of supported modes has this one member (afd_plugin/v1/worker/cuda_graph.py:20-21). The NPU runner accepts FULL and FULL_DECODE_ONLY (afd_plugin/validation.py:235-238).

Read more: CUDA graphs in AFD: FULL_DECODE_ONLY on both roles

G#

general plugin

A vLLM plugin in the vllm.general_plugins group. vLLM loads it with load_general_plugins in several processes.

Read more: How vLLM plugins work

H#

HCCL also: Huawei Collective Communication Library

Huawei Collective Communication Library, the Ascend NPU collective transport. The CAMP2p connector carries hidden states over HCCL and DP metadata over a smaller Gloo group.

Read more: Ascend NPU overview: the same contract, different transports

L#

load_general_plugins also: load_general_plugins()

The vLLM function that loads every plugin in the vllm.general_plugins group, then calls each one. It runs once per process.

Defined in vLLM (vllm:vllm/plugins/__init__.py:77-90); a guard stops a second run in the same process.

Read more: How vLLM plugins work

M#

Model Runner V2

The vLLM v1 model runner, version 2. Both AFD roles need it on; the README sets VLLM_USE_V2_MODEL_RUNNER=1. AFD adds a seam over it.

Read more: The attention runtime: a seam over Model Runner V2

model wrapper

An AFD<arch> model class that makes a model role-aware. On the attention side the FFN stage becomes a remote proxy.

Read more: Model wrappers: the role-aware decoder layer

ModelRegistry also: ModelRegistry.register_model

vLLM's registry of model architectures. A plugin adds a model with register_model, using a lazy "module:Class" string.

The singleton is defined in vLLM (vllm:vllm/model_executor/models/registry.py:1523-1531); register_afd calls it for each AFD model (afd_plugin/__init__.py:211-214).

Read more: Model registration: the AFD<arch> wrappers

multipod also: multi-pod, multipod deployment

A Kubernetes deployment that puts one AFD role per pod. Each vllm serve is gated on a POD environment variable, so with POD unset nothing runs.

Read more: Deployment topologies: how to place the roles

P#

P2P subgroup

In the GPU P2P connector, one FFN rank plus the attention ranks mapped to it. The FFN rank is subgroup rank 0.

Read more: Topology and role ranks: the AFD world

patch also: compat patch

A compat module that replaces a vLLM function at load time. The plugin applies a small set of patches.

Read more: Compat patches: how AFD changes vLLM without editing it

prefill/decode disaggregation also: PD disaggregation, prefill-decode disaggregation

A serving layout that runs prefill and decode in separate processes. Each process still runs the whole model. It splits by phase, not by model part.

Read more: What is AFD?

PyNccl also: PyNcclCommunicator

vLLM's thin NCCL wrapper, PyNcclCommunicator. The GPU P2P connector uses it to send and receive tensors.

The class is defined in vLLM (vllm:vllm/distributed/device_communicators/pynccl.py:91).

Read more: The connector contract: the Attention/FFN transport

R#

register_afd() also: register_afd

The plugin entry function. It applies the compat patches and registers the routing strategy, the DBO op and the model wrappers.

Defined in the package init (afd_plugin/__init__.py:142); it guards against a second run.

Read more: The plugin entry point: register_afd

remote experts also: remote experts shell, AFDDeepseekV2RemoteExpertsMoE

A parameter-free MoE shell on the attention role. It keeps the native MoE forward but sends the expert compute to the FFN role.

On CUDA, every MoE layer on the attention side builds AFDDeepseekV2RemoteExpertsMoE, a native DeepseekV2MoE with its experts replaced by a proxy (afd_plugin/model_executor/models/deepseek_v2.py:277-335).

Read more: Model wrappers: the role-aware decoder layer

RemoteFFNProxy

A parameter-free module on the attention side. It replaces the FFN stage of a decoder layer and uses the connector instead.

Defined for DeepSeek-V2 at afd_plugin/model_executor/models/deepseek_v2.py:117.

Read more: Model wrappers: the role-aware decoder layer

rendezvous

The host and port where the two roles meet to set up the connector process groups. Both servers use the same host and port.

The connector opens a TCP store at host:port (afd_plugin/connectors/gpu/p2p.py:271).

Read more: AFD config reference: the additional_config["afd"] keys

role rank

The rank of a process inside its own role group. It comes from the DP, PCP and TP placement.

Resolved by resolve_role_rank (afd_plugin/distributed/topology.py:61).

Read more: Topology and role ranks: the AFD world

S#

scoped patch also: scoped monkey-patch, context-manager patch

A patch that is active only inside a context manager, for the time of one AFD call. The code restores the original function on exit.

Example: use_gpu_mrv2_ubatch_factory and use_gpu_mrv2_dbo_dispatch scope the DP1 DBO seams (afd_plugin/compat/patches/gpu_mrv2_ubatching.py:263-282).

Read more: Compat patches: how AFD changes vLLM without editing it

stage

The DBO ubatch index of one transfer on the wire. A connector sends one transfer per layer and stage.

The transfer metadata carries stage_idx next to layer_idx (afd_plugin/connectors/metadata.py:188-190).

Read more: Data on the wire: tensors per layer and stage

step

One engine iteration on the attention server: the scheduler picks a batch, the model runs all layers once, and vLLM samples. The FFN server follows each step.

The attention-side EngineCore runs one step in EngineCore.step (vllm:vllm/v1/engine/core.py:589-601). The control plane runs once per step; the data plane runs once per layer and stage.

Read more: Tour: One decode step

U#

ubatch also: microbatch

A microbatch: one of the two token groups that DBO runs at the same time. On the wire its index is the stage.

Read more: Dual-batch overlap (DBO): two stages per step

V#

version gate also: is_target_vllm_compatible, install gate

A check that decides whether a patch installs. is_target_vllm_compatible allows the target vLLM release and any dev build; on a mismatch, no patch installs.

Defined in is_target_vllm_compatible (afd_plugin/compat/vllm.py:53-68). Different from the strict start-up check assert_vllm_version_supported (afd_plugin/compat/vllm.py:38-50).

Read more: Compat patches: how AFD changes vLLM without editing it

W#

worker_cls

The vLLM parallel-config field that names the worker class. The plugin rewrites it, but only when it is "auto".

Read more: Worker selection: choosing the role worker

X#

xAyF also: 2A2F, 4A4F

A topology name: x attention ranks and y FFN ranks, for example 2A2F. Use it only in topology names, not in prose.

Read more: Topology and role ranks: the AFD world