1. 从 page784 到 page832长上下文 Attention 为什么卡在页边界海光 DCU 上跑 vLLM 长上下文推理时Attention 的数学公式往往不是瓶颈真正决定吞吐的是 K/V 数据在显存里怎么摆、硬件一次能按什么粒度取。vLLM 的 paged attention 把 KV Cache 切成固定大小的物理页用 block table 做逻辑页到物理页的映射。这个设计解决了显存碎片和动态请求管理但也把BLOCK_SIZE从一个调度器整数变成了 kernel 内部的循环边界和向量化前提。问题出在 Qwen3.5 的 prefix-off 长上下文路径上默认物理 KV Cache page 是 784 tokens而海光 DCU gfx936 上的 vendor paged-attention 路径要求 page 长度满足 64-token 对齐。784 拆开是12 × 64 16每个物理页尾部会留下一个 16-token 的非规整尾块。短请求时这点浪费不明显但长上下文下页表解析和 K/V 读取被重复很多次访存效率就掉下来了。这篇面向在自有 DCU 环境跑 vLLM 的工程师交付可复制的启动参数、config.toml 骨架、page 对齐验证动作和访存指标对比方法。核心结论是把 page 从 784 自动推导到最小兼容值 832让每个物理页由 13 个完整的 64-token 访问组组成kernel 才具备被调用的前提。832 不是“越大越快”的经验值1024 也满足对齐但多出约 30.6% 的 token 容量832 只增加约 6.1%是显存紧张场景下更合适的选择。2. TaoToken 前置先把模型对话和 API Key 跑通在动 DCU 的 kernel 之前建议先用 TaoToken 把模型调用链路验证一遍确认你的 prompt 和长上下文行为符合预期再去调底层访存。这样能把“模型本身的问题”和“DCU 布局的问题”分开。TaoToken 是一个聚合多家大模型能力的 API 平台适合做长上下文 prompt 的快速验证、coding 场景的日常调用以及给 Agent 提供稳定的模型入口。你可以先到模型对话页面直接试长文本输入观察模型在 8K、16K、32K 上下文下的输出是否稳定确认没问题后再到 API Keys 页面生成密钥用于脚本化压测。具体入口模型对话https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite控制台https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI 基地址是https://taotoken.net/api兼容 OpenAI 风格的调用方式。如果你后面要写长上下文压测脚本可以直接用这个地址不用改太多代码。3. 可复制配置vLLM 启动参数与 config.toml 骨架3.1 先确认硬件与形状约束在改任何参数之前先把下面这些事实确认清楚否则后面所有性能数字都可能属于错误路径目标架构是 gfx936 对应的 DCU 型号执行粒度为 wave64vendor paged-attention 接口要求物理 page 长度满足 64-token 对齐模型形状为 BF16、24 个 query heads、4 个 KV heads、head size 256、GQA ratio 6prefix caching 状态会直接影响最终 block size必须打印确认。3.2 vLLM 启动参数下面是一份可直接改用的启动骨架重点是--block-size不要硬编码成 784而是让 backend 的对齐逻辑推导出 832python -m vllm.entrypoints.openai.api_server \ --model /path/to/Qwen3.5-27B \ --served-model-name qwen3.5-dcu \ --dtype bfloat16 \ --tensor-parallel-size 1 \ --max-model-len 32768 \ --gpu-memory-utilization 0.90 \ --enable-chunked-prefill \ --max-num-batched-tokens 4096 \ --no-enable-prefix-caching \ --disable-log-requests \ --port 8000注意这里显式关闭了 prefix caching。原因是 prefix caching 打开后Mamba align 逻辑可能把页面抬到 1024导致你看到的不是官方 prefix-off 路径的 832。如果你确实需要 prefix caching要单独确认最终 block size。3.3 config.toml 骨架如果你用配置文件管理 backend 适配可以按下面的结构组织。关键是把 alignment_tokens 从通用 16 提升到 64并让页面计算沿 vLLM 原有的混合 Attention/Mamba 逻辑走[model] name Qwen3.5-27B dtype bfloat16 max_model_len 32768 [attention] backend vendor_paged_attention query_heads 24 kv_heads 4 head_size 256 gqa_ratio 6 causal true sliding_window false alibi false softcap false [cache] enable_prefix_caching false alignment_tokens 64 min_page_tokens 784 target_page_tokens 832 [dispatch] vendor_prefill_min_q 2 vendor_prefill_max_q 4096 vendor_prefill_require_single_seq true decode_path page_contiguous页面计算可以抽象成attn_page_size_1_token FullAttentionSpec(...).page_size_bytes required_page ceil(mamba_page_bytes / (alignment_tokens * attn_page_size_1_token)) * alignment_tokens对 Qwen3.5/DCU 这个形状alignment_tokens 取 64 后默认页从 784 向上取整到 832。这和直接在 scheduler 里写block_size 832是两件事计算仍由模型配置和缓存规格数据流完成scheduler 的 token budget 和调度语义不变。3.4 vendor dispatch 的严格条件vendor kernel 只接管它真正擅长的形状条件要写严1 num_actual_tokens 4096 max_seqlen_q num_actual_tokens single sequence decoder attention BF16 Q/K/V/output Qwen3.5: 24 Q heads, 4 KV heads, head size 256 page size 832 GQA ratio 6 causal true no sliding window no ALiBi / sinks / softcap no multimodal满足条件时调用 vendor 的varlen_fwd_unified不满足就回退到原有 unified Triton attention。这样新路径即使在某个边界上不适合也不会污染通用 attention。4. 验证请求与成功结果page 对齐和访存指标怎么测4.1 打印运行时 block size启动后第一件事是确认运行时真实的 block size而不是相信配置文件grep -i block size /var/log/vllm/server.log grep -i prefix caching /var/log/vllm/server.log期望看到prefix caching False block size 832如果看到 784说明布局改动没生效如果看到 1024说明 prefix caching 或 Mamba align 把页面抬高了。4.2 确认 vendor marker 命中在日志里搜 vendor prefill 和 decode markergrep -i vendor.*prefill /var/log/vllm/server.log grep -i page.contiguous.*decode /var/log/vllm/server.log期望看到类似vendor q4096 prefill marker: hit page832 decode marker: hit如果 marker 没出现先检查 page size 是否真的是 832再检查 dispatch 条件是否被某个形状字段挡住。4.3 发一个长上下文请求用 curl 发一个 16K 上下文的请求确认服务能正常返回curl -s http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen3.5-dcu, messages: [{role: user, content: 你的长文本}], max_tokens: 256, temperature: 0 } | head -c 5004.4 访存指标对比方法对比 page784 和 page832 时建议按下面的口径分开记录不要混在一起指标口径含义用途standalone kernel 耗时单独跑 vendor prefill 或 decode kernel判断 kernel 本身是否变快profile Attention 总桶8K profile 下 Attention 总耗时判断 Attention 层整体变化端到端 A/B 吞吐同容器、同模型、同数据集判断服务层真实收益实测下来q4096 vendor prefill standalone 相对 page784 Triton 路径约为 2.75x–2.92x完整服务的提升明显小于这个数字。本地三档 A/B 的相对变化大致是4K–8K 档 0.62%8K–16K 档 2.67%16K–32K 档 13.78%。长档收益更明显是因为该 workload 中 q4096 chunk 和长序列 paged-KV 访问占比更高。在 page832、prefix-off、all-Tail-Q 的官方 8K profile 中q4096 prefill 的 Attention 总桶从 681.071 ms 降到 238.718 ms。注意这不是单个 vendor kernel 的 standalone 耗时端到端服务还要支付 GEMM、GDN、decode 和调度成本。4.5 数值正确性检查vendor BF16 attention 与 Triton attention 计算的是同一个完整因果 Attention但并行归约顺序可能不同。所以快不等于逐位相同必须同时做kernel 输出 finite 检查重复运行一致性检查相对误差与参考 kernel 对比vendor 与 Triton 的相对 L2 误差约 0.0058–0.0064四类任务级 accuracy smoke逐请求记录生成文本和 token 数。5. 本篇常见错排查5.1 改了 kernel 但 page 还是 784这是最典型的坑。旧实验只提交了 attention dispatch 改动却没有同时提交 page-layout 对齐逻辑官方 loader 关闭 prefix caching 后实际运行时仍是 page784。784 不满足 vendor kernel 的 64-token 页要求vendor 路径根本没命中于是出现“standalone 很快、官方提交几乎没收益”的矛盾。排查顺序先确认源码是否真的包含布局改动再确认运行时 block size再确认 vendor marker 是否出现最后确认 prefix caching 是否改变了页面。5.2 prefix caching 把页面抬到 1024旧 fast-start 脚本打开了 prefix cachingMamba align 又把页面抬到了 1024。本地看到的结果因此是 page1024不是官方路径的 page832。如果你要复现 832先关掉 prefix caching或者单独确认最终 block size。5.3 vendor marker 不出现检查 dispatch 条件里的每一个字段num_actual_tokens是否在(1, 4096]max_seqlen_q是否等于num_actual_tokens是否单序列dtype 是否 BF16head 形状是否匹配page size 是否 832causal 是否为 true有没有 sliding window、ALiBi、sinks、softcap 或 multimodal。任何一个不满足都会回退到 Triton。5.4 decode 路径没走 page-contiguousdecode 的 q 通常为 1主要问题是从大量历史 page 中读 K/V。page-contiguous decode kernel 仍然解析 block table没有跳过任何逻辑 page也没有改变因果范围只是针对 q1、GQA6、head size 256 的访问几何减少通用调度开销。如果 decode marker 没命中检查 decode 路径配置和形状条件。5.5 把 standalone 加速比当成端到端加速比独立 kernel 的加速比不能直接当成端到端服务加速比因为 decode 还会被 Linear、采样、图 replay 和 Python/调度边界包围。记录数字时一定要标清口径否则很容易得出错误结论。6. 继续验证与长期编码接入如果你已经跑通 page832 的对齐验证下一步建议把长上下文压测脚本化用固定数据集跑三档吞吐记录 TTFT、TPOT、输出 token 数和 accuracy smoke。需要长期做 coding 或 Agent 场景的可以到 Coding Plan 页面看适合的套餐把模型调用和本地 DCU 推理分开管理Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite模型对话https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewriteAPI Keyshttps://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 基地址保持https://taotoken.net/api官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。把模型调用链路和 DCU 访存优化分开验证出问题时能更快定位是模型侧还是 kernel 侧。