vllm-project/afd-plugin

Motivation Integrate FastAFD into afd-plugin through a dedicated FastAFDAFDConnector and a port of its FFN megakernel. This requires the standalone FFN as a Service architecture tracked in #391. The integration has two deliverables: the Attention–FFN communication path and the corresponding fused FFN execution path. Adding a connector while retaining ordinary FFN operator execution would not complete the FastAFD integration. Proposed change 1. Architecture and relationship to #391 flowchart LR A[AFD Attention runtime] --> AC[FastAFDAFDConnector: Attention half] AC <-->|FastAFD dispatch / combine| FC[FastAFDAFDConnector: FFN half] subgraph F[FFN Server from RFC 391] S[Lifecycle and execution control] --> E[FastAFD fused execution adapter] E --- FC E --> K[Ported FastAFD FFN megakernel] end Loading #391 owns the common architecture: standalone FFN Server, process lifecycle, backend isolation

Purpose This issue is the execution-level index for active afd-plugin work. Project direction, support policy, and long-term workstreams remain in #155. Detailed design and acceptance criteria remain in the linked RFCs and issues. The linked issue or PR is the source of truth for status; this checklist is a maintainer-facing snapshot. Last reviewed: 2026-09-23 Upstream alignment GPU backend alignment with vLLM 0.26.0 — #167 GPU backend alignment with vLLM 0.30.0 — #389 NPU backend alignment with vLLM/vLLM-Ascend 0.26.0 — #168 NPU backend alignment with vLLM 0.30.0 and a pinned compatible vLLM-Ascend runtime — #390 ModelRunnerV2 GPU ModelRunnerV2 support — #223 @jiaran-king Implementation: #245 DBO support (vllm-project/vllm#50945) vllm-project/vllm#51700 Ascend NPU ModelRunnerV2 support — #240 @lirx-pd Implementation: #257 DBO support #265 Native MoERunner forward refactor Refactor AFD MoE forward around native MoERunner injection — #225 Phase 1: Atte

Summary Request to initialize a repository-backed agent workflow for afd-plugin, aligned with the repository-backed agent skills workstream in #155. The goal is to make repository maintenance and review repeatable across AFD compatibility work, model adaptation, connector/distributed changes, hardware recipes, E2E validation, and releases. Current repository assets The repository already has useful sources of truth: AGENTS.md with patching, upstream-compatibility, and review requirements; CLAUDE.md, which delegates to AGENTS.md; .agents/skills/run-e2e; CPU-safe checks and hardware-gated E2E workflows. These files should remain authoritative; agent integration should orchestrate them instead of duplicating deterministic logic. Proposed initialization 1. Repository profile and adapter Register vllm-project/afd-plugin as a first-class target in InferMatrixCopilot with: a human-reviewed repository adapter and protected-branch policy; an evidence-cited profile generated from the existing

Summary AFD is an external vLLM plugin for Attention–FFN Disaggregation. The roadmap has six workstreams: compatibility, CI/CD, and release foundation; DeepSeek-V4 and GLM-5.2 model expansion; prefill workloads and chunked-prefill/prefix-cache compatibility; NVIDIA and AMD large-scale serving recipes; Kimi-K3 prefill feasibility; repository-backed agent skills. These are workstreams, not release phases. Dependencies determine when a support claim is ready, while independent work may proceed in parallel. Goals Keep AFD aligned with a deliberate, maintainable vLLM compatibility window. Make support claims precise and backed by model-, backend-, and topology-specific evidence. Provide reproducible NVIDIA and AMD large-scale serving recipes. Expand model support without silently coupling all backend lanes. Validate realistic long-prefill and agentic workloads, including chunked prefill and prefix caching. Establish basic every-PR CI and tag-triggered GitHub/PyPI releases. Provide thin