Skip to content

docs(design): TLLM-DPA direct paged decode attention design package (TLLM-P0-004 设计门禁) - #5

Merged
holtwood merged 6 commits into
masterfrom
tllm-dpa-design-package
Sep 15, 2026
Merged

holtwood merged 6 commits into
masterfrom
tllm-dpa-design-package

Conversation

@holtwood

Copy link
Copy Markdown
Member

这是什么

TLLM-P0-004(direct paged decode attention kernel)实现前的设计门禁产物。

按 ai-infra-interview-prep/L3_L4_DESIGN_REVIEW_PACKAGES.md §3 的标准模板填充,
覆盖 G0–G8 全部通用门禁,并逐条回答 §4(TLLM-DPA)要求冻结的决策点。

Status: DRAFT —— 未批准。 §12 的 Decision 保持 pending。
按 NEXT_AGENT_START_HERE.md §12「实现 Agent 不应成为唯一 reviewer」,
作者不代签;请在 §12 末尾的 6 个问题下给出判定。

为什么现在写它

任务卡的前置写得很明确:

前置与范围:必须先通过 direct-paged design package 和 TLLM-P0-002;
第一 PR 只允许 kernel/header/tests/benchmark seam,禁止同时改 FFI 与 serving。

TLLM-P0-002(独立 oracle)已在 PR #4 完成;没有批准的设计包时,L3/L4 Agent
只能读代码、列方案,不能改生产 kernel 的算法。所以这份包是唯一的前置。

冻结了什么(对应 §4 的必答项)

§4.2 待决问题 本包结论
block_table per-request 还是 batch-flattened 第一阶段 per-request(batch=1);per-sequence 循环留在上层,不改架构
layer offset 谁算 caller 算,kernel 收本层指针(与现有 scatter/gather 一致)
table length 是否显式传入 显式传入 table_len,host 校验 >= ceil(visible/block_size)
visible_tokens 与 current position 的关系 冻结不变量:*device_visible_tokens == position + 1
是否只支持 batch=1、query_len=1 是(第一阶段)
支持几何 任何正 head_dim(smem 容量校验);正式测试集 {32,64,128}
output/logsumexp 仅 output;不产 logsumexp
unsupported 是 error 还是 fallback host 校验返回 Result;dispatch 回落 legacy 且计数/记日志

另外冻结了 §4.3 要求的完整线性地址公式与各级 stride、整数宽度(指针运算一律
size_t)、visible_tokens = 0 行为、以及 非法块 id 的语义。

三个值得 reviewer 注意的判断

  1. 非法块 id = 零行但仍参与 softmax。PagedKvTest.InvalidBlockIdIsGuardedNotDereferenced
    已冻结 gather 写 0;而「K 行 = 0」在 softmax 里并非无贡献条目。若 direct 跳过它,
    归一化就会和 legacy 不同。这是有意的 legacy 等价,不是可选优化。
  2. 不在 host 校验块 id。那需要 D2H 回读 → 破坏 CUDA Graph 捕获,而
    visible_tokens 走 device int 正是既有的 graph 前置条件。
  3. 要求 direct 与 legacy 逐元素相等(而不是容差比较)。两条路径共用同一 tile loop
    与同一输入,因此可以要求零差异——这比容差门禁强得多,也是定位寻址错误的主门禁。

本 PR 的范围

  • 只含设计文档 + docs 侧栏条目;不含任何 kernel 实现。
  • 不改 C ABI,不改 paged-serving。设计结论是 C ABI 无需变更(PR-4 计划为空)。

验证

  • docs: npm install && npm run build(vitepress 1.6.4)→ build complete in 10.93s,exit 0
  • 无源码改动,CI Format / Build and Test 应保持原状

依赖

设计引用的独立 oracle 来自 PR #4(TLLM-P0-002,未合并);PR-2 实现必须基于
PR #4 合并后的 master。

TLLM-P0-004(direct paged decode attention kernel)的设计门禁产物。按
L3_L4_DESIGN_REVIEW_PACKAGES.md §3 模板填充,覆盖 G0–G8 与 §4(TLLM-DPA)
要求冻结的全部决策点。

冻结内容:
- 内部 kernel API:flat 参数签名、batch=1/query_len=1、table_len 显式传入、
  layer 偏移由 caller 计算、不支持输入由 host 校验拦下而非 kernel 静默 return;
- 地址公式与 stride(layer/block/row/head/dim)、整数宽度(指针运算一律 size_t)、
  `visible_tokens == position + 1` 不变量、`visible_tokens = 0` 与非法块 id
  (零行但仍参与 softmax,与 legacy gather 语义对齐)的边界行为;
- 所有权(kernel 零分配)、stream(caller stream、无内部同步、CUDA Graph 可捕获)、
  错误分层与可观测 fallback;
- 三层 correctness 门禁(direct vs 独立 oracle、direct vs legacy 逐元素相等、
  layer 级逐层 K/V)、sanitizer 与变异检验要求;
- 三路 kernel benchmark 计划(legacy / contiguous / direct)、六个 PR 的分层与
  回滚触发条件与步骤。

Status 为 DRAFT:§12 的 Decision 保持 pending,作者不代签;另列出 6 个需要
reviewer 明确回答的问题(含 flat 参数 vs POD view、是否抽取共享 tile loop、
能否把「非法块 id = 零行」冻结为稳定契约等)。

本提交只含设计文档与 docs 侧栏条目,不含任何 kernel 实现;文档站本地构建通过
(vitepress build, 10.93s)。

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
holtwood added a commit to open-infra-ai/ai-infra-interview-prep that referenced this pull request Sep 14, 2026
…r review

TLLM-P0-004 的设计门禁产物已提交(open-infra-ai/tiny-llm#5),本轮交接的下一步
从「写设计包」变为「评审设计包」。补充:

- 产物位置与状态(DRAFT / Decision = pending,作者不代签)
- 需要 reviewer 回答的 6 个问题摘要
- 明确实现(PR-1 之后)在设计获批前阻塞
- 验证方式(仅文档改动,docs 本地 vitepress build exit 0)

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
…ackage

按 owner 委托的决议,关闭 §4.2 与 §12 的全部待决项:

- Q1 保持 flat 参数签名;补上真正的理由——逐元素相等门禁已覆盖"传参顺序"
  这一失败模式,原先"POD 字段顺序成为跨 TU 契约"的反方论证站不住(C++17 下
  逐字段命名赋值本就与顺序无关)。
- Q2 抽取共享 tile loop;PR-1 增加硬性要求:必须附 attention_decode 的前后
  kernel_bench 对比证明无性能回归,出现可测回归则退回复制实现。
- Q3 冻结「非法块 id = 零行且参与 softmax」为稳定契约;可观测计数留作 follow-up。
- Q4 保持要求 direct 与 legacy 逐元素严格相等。
- Q5 修正原设计错误:原文称"连续版静默取整,属既有缺口"并提议在 forwardPaged
  校验,实际 Validator::validateModelConfig 早已实现该校验,只是不在 C ABI 路径上;
  正确修复位置是 tinyllm_load,已拆为独立 PR #6。新增 §7.1 记录证据链。
- Q6 保持"kernel 级收益不得外推为 TTFT/TPOT"的表述边界。
- Q7 新增:显式记录 direct 路径令 k_scratch/v_scratch 冗余(本任务保留分配,
  避免改 ffi.cpp;显存收益记为 follow-up)。
- Q8 删除不可达的"几何不支持则回落"分支——触发需 head_dim > 7800,既不可测试
  也不构成真实 fallback;fallback 只由 TLLM_PAGED_ATTENTION 开关表达。

§12 增加「决议」「独立性声明」「本轮修正的设计缺陷」三节,如实记录本包由作者
编写也由作者汇总决议,不满足独立 reviewer 要求,并指出 PR-1 是唯一有真实爆炸
半径的决定,合并前应经第二方复核。

验证:仅文档改动;docs 本地 npm run build exit 0(vitepress 1.6.4)。

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
@holtwood

Copy link
Copy Markdown
Member Author

修订:全部 8 项决议已关闭(2026-09-14)

按仓库 owner 委托,§12 的全部待决项已决议并回填进本设计包。

决议

# 议题 决议
Q1 flat vs POD view flat(补上真正的理由:逐元素相等门禁覆盖了传参顺序这一失败模式)
Q2 共享 tile loop vs 复制 抽取;PR-1 必须附 attention_decode 前后性能对比,有可测回归则退回复制
Q3 非法块 id = 零行 冻结为稳定契约;可观测计数留作 follow-up
Q4 逐元素相等 vs 容差 严格相等
Q5 GQA 校验位置 改在 C ABI 载入边界 → 独立 PR #6
Q6 收益表述边界 接受:不得外推为 TTFT/TPOT
Q7 direct 下 scratch 冗余 本任务保留分配,显存收益记为 follow-up
Q8 按几何自动回落 取消(不可达且不可测),fallback 只由开关表达

本轮修正了设计包自身的三个缺陷

  1. Q5 原表述是错的。原文写"连续版 attention_decode 静默取整,属既有缺口",
    并提议在 forwardPaged 新增校验。查证后:Validator::validateModelConfig
    早已实现这组校验,只是全仓只有 InferenceEngine::Load 调用它,C ABI 路径
    tinyllm_load 不调用。而且后果比我原描述严重得多——不是"映射错位",是越界读:
    已用最小复现 + Compute Sanitizer 证实(Hq=14/Hkv=3,13 errors,
    cudaDeviceSynchronize -> unknown error,CUDA 上下文被毒化)。修复已拆成
    独立 PR fix(ffi): validate model geometry at the C ABI load boundary #6(tinyllm_load 调用 validateModelConfig + Validator 首次有测试)。
    新增 §7.1 记录完整证据链。
  2. Q8 原来是死代码。"几何不被支持则回落"要 head_dim > 7800 才可达——既不可
    测试,也不构成真实 fallback。已删除,只保留 TLLM_PAGED_ATTENTION 开关。
  3. Q7 原未记录:direct 路径令 k_scratch/v_scratch 冗余,原文只写"保留校验"
    却没记录显存代价与 follow-up。

关于批准本身(需要你知情)

我把 Decision 记为 approved,因为决议是你的委托。但 §12 新增的独立性声明
如实写明:本包由作者编写、也由作者汇总决议,不满足「实现 Agent 不应成为唯一
reviewer」的要求
。残余风险收敛到一点:

Q2 是唯一有真实爆炸半径的决定(改现有热路径 kernel)。建议在 PR-1 合并前
由第二方复核其 diff 与前后性能数据。其余决定要么有门禁兜底,要么只影响新增代码。

当前 PR 依赖关系

验证:仅文档改动;docs npm run build exit 0(vitepress 1.6.4)。

设计包 §10 的 PR-1(抽取共享 decode tile loop)在执行阶段被它自己的门禁否决:
实测该抽取给生产 kernel attention_decode 带来可复现的回归,因此按门禁回退为
复制实现,PR-1 未提交。

新增 §10.1 完整记录:
- 测量方法的三次修正——GPU 空闲时 SM 时钟停在 900/3090 MHz(小 kernel 拉不动
  boost,逐次差异可达 50%);scratch 程序误编到 sm_75 而非生产的 sm_120;
  现成 harness 的 host-int 重载每次调用附带一次 4 字节 H2D memcpy;
  最终用「时钟预热 + native 架构 + device-int 重载 + 大 S + 顺序平衡交替 +
  新旧 kernel 编入同一进程交替调用」得到可信数据;
- 结果:两轮独立重复分别 7/8 与 6/8 几何为正,均值 +1.4% / +2.3%,
  D=128/S=512 达 +4.9%;SASS 指令数与寄存器完全相同但调度确有变化;
- 两种规避写法(策略按值/按引用、无效行返回零行以消除分支)均未改变结论,
  说明扰动来自抽取本身;
- 结论:PR-2 自持一份寻址实现,由 direct vs legacy 逐元素相等门禁守护一致性;
  该门禁比原计划的"纯寻址差分"更强(要求两份独立实现逐位一致)。

同步更新 §10 的 PR 表(PR-1 标记为已否决)与 §12 的 Q2 决议记录。

验证:仅文档改动;docs 本地 npm run build exit 0。

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
holtwood and others added 2 commits September 14, 2026 17:43
PR-1 的取舍按 issue #8 翻转:接受抽取带来的已测量回归,改回共享 decode 归约循环。

新增 §10.2,说明翻转与 §10.1 的原始记录并不矛盾——被质疑的是门禁**回退方案的收益**,
不是测量本身:

- 复制方案唯一的风险(两份实现漂移)已由 §8 的 direct vs legacy 逐位相同门禁自动覆盖,
  所以**安全来自门禁而非副本数量**,复制只换来双份维护成本;
- +1.4~2.3% 落在单个 kernel,端到端约 0.1~0.3%,不划算;
- 共享后差分退化为纯寻址测试,定位能力更强。

同时记录本次新增的验证:连续路径指纹逐位不变;变异检验第三项(在共享循环里丢掉
online rescale,两条路径同等出错)由**独立 oracle** 捕获而非逐位门禁——正面验证了
"共享归约 + 独立参考"分层门禁的必要性。

同步更新 §10 的 PR 表与 §12 的 Q2 决议。§10.1 的测量方法与回归量级保留为事实依据。

验证:仅文档改动;docs 本地 npm run build exit 0。

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
- §10 的 PR 表:PR-3 标记为已提交(#9),并写明开关的实际语义(auto 当前等价于
  direct、默认 legacy、非法取值显式报错、显式 legacy 打一次 TLLM_WARN);PR-5 的
  职责补上"通过后把默认值由 legacy 改为 auto"。
- §11 的 Feature flag 段落与实现对齐,并记录两个实现选择:不做进程级缓存(使 setenv
  在测试中即时生效,避免为测试暴露 reset seam);只影响 strategy 1 的 decode。
- **修正章节顺序**:§10.1 / §10.2 之前被插在 §11 之后,现移回 §10 之后。

验证:仅文档改动;docs 本地 npm run build exit 0。

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
…kage

# Conflicts:
#	docs/.vitepress/config.mts
@holtwood
holtwood merged commit b64ce9c into master Sep 15, 2026
2 checks passed
@holtwood
holtwood deleted the tllm-dpa-design-package branch September 16, 2026 06:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant