资讯动态

TokenSpeed 数值一致性指南:如何用一行 trait 声明实现跨后端逐字节一致

发布时间:2026/10/18 1:54:38 来源:尧图企业网站定制
人工智能大模型推理引擎模型推理服务后端【免费下载链接】tokenspeedTokenSpeed is a speed-of-light LLM inference engine.项目地址https://gitcode.com/GitHub_Trending/to/tokenspeed点击查看免费下载在 LLM 推理引擎 TokenSpeed 中同一份请求经过不同的 kernel 后端Triton、FlashInfer、Cutlass 等计算时浮点求和顺序的细微差异会产生最后一位不同——听起来无害但在注意力张量并行下一行结果的末位差异会改写 KV 缓存污染该请求后续每一个 token。TokenSpeed 通过--numerics rl-bitwise数值信封numerics envelope与 kernel 注册表中的 trait/feature 声明机制让跨后端的输出做到逐字节一致bitwise identical并用自动化不变性测试保证这份承诺不被悄悄打破。本文带你完整理解这套机制为什么数值一致性测试对 RL rollout 至关重要、trait 声明如何把性能优先和结果可复现分离到两条路线、以及验证是如何端到端执行的。为什么推理引擎需要逐字节一致性普通在线推理只关心答案对不对但 RL强化学习rollout 场景提出了更苛刻的要求训练器要按 token 重放推理引擎产生的序列并逐位复现每个 token 的 logprob。任何一个 logprob 差了一个 ulp训练信号就失效了。TokenSpeed 的设计文档 docs/design/numerics.md 把rl-bitwise信封承诺的不变性分为三层运行不变性Run invariance同一请求在不同次运行中产生逐位相同的 token 与 logprobs批量不变性Batch invariance结果的比特不取决于同批里还有哪些请求、调度器如何切分批次训练器对齐Trainer alignment前向计算顺序与训练框架一致teacher-forced 重放能逐位复现训练器 logprobs。文档中有一个很生动的实测案例在 8xH20、TP8 部署上NVLS switch 内归约in-switch reduction对同一行数据在不同批次中的结合顺序不同导致约 25% 的 decode logprobs 与 prefill 重打分不一致换成固定 rank 顺序的 fp32 fold 后全部逐位相等。百万分之一行的末位差异就足以让整条生成序列分叉——这就是为什么必须用测试把一致性钉死。上图展示了不同 attention kernel 实现的性能差异。性能路线追求最快数值路线要求可复现——两套诉求由同一份 kernel 注册表管理靠声明区分。trait 与 feature注册表的卖家声明与买家要求TokenSpeed 的 kernel 注册表registry.py中每个 kernel 通过KernelSpec声明自己是谁、擅长什么features: frozenset[str] # 正交能力如 {paged, batch_invariant} traits: dict[str, frozenset[Any]] # 算子专属特征如 head_dim 取值选择逻辑selection.py 的select_kernel/spec_matches_traits把两者分开处理这是整个数值一致性机制的核心机制谁声明匹配规则作用trait特质卖家kernel自报请求的 trait 值必须在 kernel 声明的集合内未声明者跳过精确过滤如按head_dim128、ispp对齐选 kernel适合排序不足以做保证feature特性买家调用方要求子集测试请求要求{batch_invariant}时只有显式声明features{batch_invariant}的 kernel 有资格入选静默未声明者直接排除硬保证缺一个特性就拒绝关键纪律是不静默回退在rl-bitwise模式下每个选择点会把候选钉在solutionaok固定求和顺序的算子套件上如果该 solution 下没有注册 kernel引擎在启动时直接报错而不是悄悄换用某个大概率没问题的实现。一个不满足 feature 要求的 kernel 会在选择阶段被点名拒绝错误信息会列出缺失的 feature。举个真实例子sampling.block_sumexp词表分块 log-softmax 的叶子算子在 ops/sampling/torch.py 中注册时带上了features{batch_invariant}且位于Priority.PORTABLE优先级带——--numerics auto时它不会被选中性能路线优先但一旦要求 batch invariant它就是被买家点名要的那种实现。--numerics rl-bitwise一组开关的一致性信封单个确定性开关关 TF32、关 autotune、换 NCCL 归约算法……很容易漏配——少开一个训练信号就悄悄失效。--numerics参数把这一整套开关打包成信封numerics.mode --numerics {auto, rl-bitwise} ├── kernels.deterministic 固定求和顺序 禁用 TF32/PDL/autotune ├── collectives.deterministic 归约走固定 rank 顺序的 fp32 fold ├── sampling.deterministic 采样流按 (请求种子, 位置) 键控 ├── invariance.batch 行独立归约无 split-KV、行内 top-k、 │ 按位置顺序而非物理槽位归约 └── alignment.trainer 逐开关对齐训练器操作顺序信封只会收紧开关从不放松任何它无法收紧的显式配置都会被拒绝。单元测试 test/runtime/test_numerics_mode.py 把这些行为写成了可回归的断言例如rl-bitwise下moe_backend自动折成aok若用户显式指定--moe-backend triton则直接抛ValueErrorsampling_stream折成per-request按请求种子 位置键控随机流而不是按 batch 行号自动开启的 all-reduce fusion 会被信封否决——融合核不做逐位承诺。这套信封收紧一切的逻辑在ServerArgs的resolve_numerics中一次性完成校验启动即定生死运行期不再检查。上图是 TokenSpeed 在 Kimi K2.5 上的端到端性能数据。值得注意的是rl-bitwise的 fold 归约会带来world_size倍的通信量——文档明确说这是买确定性付的账单如果部署无法承受应换用更弱的布局如--tp-batch-invariant而不是拆开信封。验收测试不变性 harness 与训练器对齐 harness一致性不是靠看起来对而是靠 docs/design/numerics.md 中 Acceptance 一节定义的两套 harness 端到端验证1. 不变性 harness对同一组 prompt 以返回 logprobs 的方式生成三次——(a) 单独运行batch size 1(b) 与随机共批打包运行(c) 重复运行然后对 token ids 和 logprobs 断言torch.equal逐位相等非近似比较。基础模型与投机解码各测一轮greedy 与temperature1.0固定种子各测一轮。通过才允许对外宣称该承诺失败意味着有 bug而不是容忍度问题。2. 训练器对齐 harness训练器对固定 prompt 集跑前向产出 teacher dumptoken ids、逐位 logprob、布局、commit推理引擎在rl-bitwise下对同一ids做 teacher-forcing断言input_token_logprobs与 dump 的 fp32 向量torch.equal失败则报告首个分歧位置。文档特别强调允许容差的一致是待二分排查的发现finding to bisect不是通过。声明本身也由模型画像把关模型在ModelProfile.numerics_envelopes中声明自己通过了哪些信封启动非auto信封时未声明者一律拒启require_verified_numerics——量化 checkpoint 与词表非MEGATRON_VOCAB_BLOCK整数倍的模型无条件拒绝。上图是 MLA prefill 阶段不同 kernel 路线的延迟对比。不同路线的性能差异正是多后端存在的原因而 trait/feature 声明机制让这些性能路线与数值路线在同一注册表内各司其职、互不污染。总结把可复现变成一张可测试的契约TokenSpeed 的跨后端数值一致性方案可以浓缩为三条原则声明而非假设kernel 通过 trait 自报能力、通过 feature 应允强保证买家按 feature 子集测试硬性过滤静默未声明者出局失败前置钉死的 solution 没有实现时启动即报错杜绝静默回退无法收紧的显式配置直接拒绝验证端到端不变性 harnesstorch.equal逐位断言 训练器对齐 harnessteacher dump 比对声明是承诺测试让承诺兑现。这套机制让逐字节一致从一句口号变成了注册表里可查询、启动时可校验、CI 中可回归的工程契约。赞分享人工智能大模型推理引擎模型推理服务后端【免费下载链接】tokenspeedTokenSpeed is a speed-of-light LLM inference engine.项目地址https://gitcode.com/GitHub_Trending/to/tokenspeed点击查看免费下载相关推荐Terrain3D纹理系统完整教程32种纹理混合与材质制作Terrain3D纹理系统完整教程32种纹理混合与材质制作 Terrain3D是Godot 4引擎的高性能可编辑地形系统提供强大的32种纹理混合能力与材质制联想拯救者不同型号适配指南LEGION_Y7000Series_Hackintosh各版本差异解析联想拯救者不同型号适配指南LEGION_Y7000Series_Hackintosh各版本差异解析 想要在联想拯救者笔记本电脑上体验完美的macOS系统吗L跨语言一致性确保Java/C/JavaScript三端行为一致跨语言一致性确保Java/C/JavaScript三端行为一致 引言多语言开发的挑战与机遇 在现代软件开发中跨平台、多语言开发已成为常态。Google后端上一篇SteamAutoCrack终极指南一键破解Steam游戏DRM保护的专业解决方案下一篇DGL 复现 Dynamic EdgeConv 点云分类基于 ModelNet40 的 Dynamic Graph CNN 完整实现解析创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑