NInfer 算子开发指南如何为量化推理引擎贡献高性能 CUDA 算子【免费下载链接】ninferHigh-performance single-GPU inference for selected model checkpoints and GPUs.项目地址: https://gitcode.com/gh_mirrors/ni/ninferNInferREADME.md是一个从零构建的 C/CUDA 单 GPU 高性能推理引擎面向 RTX 5090 深度优化原生支持 BF16、INT8、FP8、NVFP4 等量化权重格式。本文是一份面向新手的 NInfer 算子开发指南带你了解量化推理引擎的算子分层规则、契约先行写法、数值资格化方法和性能基准流程掌握如何为它贡献一个正确且高性能的 CUDA 算子。上图是仓库中用于视觉推理验证的示例图表NInfer 除了文本算子外还为图像/视频输入提供了一批视觉算子如 vision_pos_embed.h它们同样遵循本文介绍的开发与验证流程。先看懂 NInfer 的算子分层NInfer 把引擎中的设备变换抽象为Op算子并严格区分语义层与实现层。这一分层是 op-development.md 的核心也是贡献代码前必须理解的规则。Op 是什么语义封闭的执行契约一个合法的 Op 满足逻辑效果计算或改变逻辑张量、显式局部状态语义封闭显式输入和元数据完全决定所有可观测输出与副作用实现无关接口中不出现 grid、warp、tile 或 CUDA 符号可独立调用不跑完整模型也能单独验证它。一个实用的准入测试如果把模型名和调用点拿掉这个变换还能被完整描述和验证吗能才是合格的 Op 边界。一条清晰的职责链每个 Op 都遵循同一责任链默认水平布局位于src/ops/{wrapper,launcher,kernel}复杂算子族则使用垂直子目录例如 src/ops/linear/ 按q4/q8/fp8/nvfp4等数值格式分目录层级目录职责契约include/ninfer/ops/family.h公式、逻辑形状、支持域、数值边界、副作用、workspace 约定Wrappersrc/ops/wrapper/语义校验、workspace 作用域、实现分派Launchersrc/ops/launcher/私有 CUDA 启动策略grid/block/共享内存Kernelsrc/ops/kernel/真正的__global__设备实现依赖方向被强制约束core - ops - model - runtime/product模型代码只允许包含契约头文件绝不能直接引用私有 launcher 或 kernel——这保证了同一契约下可以存在多条实现路线不同量化格式、不同 T 区间而互不污染。快速上手搭好 NInfer 开发环境NInfer 要求 64 位 Linux、RTX 5090、支持sm_120a的 CUDA 工具链、CMake 3.28 与 C20 编译器。测试和基准默认不参与构建需要用devpreset 显式开启git clone https://gitcode.com/gh_mirrors/ni/ninfer cd ninfer # 仅产品构建 cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPERelease # 开启测试 基准的开发构建 cmake --preset dev cmake --build build -j上图这类 1024×1024 的合成图像是 bench/fixtures/ttft/ 中 TTFT首 Token 延迟基准的视觉负载素材说明仓库中多模态测试与算子负载都是可复现的固定 fixture。贡献一个高性能 CUDA 算子的 5 步流程1️⃣ 先开 Issue再写代码按 CONTRIBUTING.md 的约定任何新功能、优化或架构提议都必须先开 Issue 确认范围再动手实现。这是最容易踩的坑没有链接已确认 Issue 的 PR 可能被直接关闭。Issue 里要写清楚问题、所属契约边界、期望的语义或性能声明。2️⃣ 契约先行写include/ninfer/ops/头文件在选任何 CUDA 实现之前先为算子写权威契约注释包含Math / indexing完整公式、算法或索引映射融合投影这种名字不算公式Logical shapes符号轴、有效范围、布局解释Supported domaindtype、数值格式、存储布局、几何约束Numeric / Effects / Workspace数值边界、副作用、workspace 容量约定。契约必须足以让他人写出独立实现和独立 oracle但不得冻结归约顺序、warp/CTA 划分、私有中间精度等实现细节——这是高性能路线能自由进化的关键。3️⃣ 实现wrapper 校验、launcher 分派、kernel 计算wrapper 做 dtype/rank/shape/对齐校验从语义变体 格式 几何 范围 设备能力做有限分派算子可以接受T1单 token GEMV、T4/8投机解码点、T128并发验证块等不同路线不同 T 区间允许完全不同的 kernel 家族这正是 linear-tuning.md 强调的调优哲学每个 kernel 的假设精确形状、SM 能力、tile、对齐都必须有 wrapper 或 launcher 中对应的谓词保护。4️⃣ 数值资格化独立 FP64 oracle 是硬门槛测试放在 tests/ops/直接调用公开契约而非模型路径。NInfer 的规则很明确数学算子用独立的朴素 FP32/FP64 oracle对逻辑值做全精度复算测试自己解码 packed 量化值精确变换/codec 用精确 oracle 逐位比较另一条 GPU 路线或模型输出看起来对不算oracle覆盖每个公开入口、每条可达生产路线的边界b-1/b/b1和内部代表点。5️⃣ 性能基准用bench/ops/的公开算子基准说话每个算子都有一个ninfer_op_bench可执行文件如 linear_bench.cu、rmsnorm_bench.cu它们只调用公开契约让生产分派自己选实现。对 Linear 类算子Linear 调优规范 定义了标准测量矩阵热区间T1..128每个有效整数逐一测量覆盖 8 并发 × 16 列投机验证块吞吐锚点T512与T1024分别报告候选比较是任务本地的临时 sweep定界后把胜者写进生产分派删除失败候选和临时入口。仓库保留了一份完整的真实案例——Q4 Linear 性能报告N6144K5120130 个实测点摘要如下T延迟 µs逻辑带宽 GB/s有效算力 TFLOP/sTensor Core 利用率115.6481069.44.02—GEMV823.744711.421.2010.12%12881.184241.499.2047.35%1024381.696104.2168.7880.57%注意 T1→2 出现 39% 的台阶——那是 GEMV 切换到 sliced-K 路线的交界。报告如实保留所有台阶和回退这正是 AGENTS.md 对性能证据的诚实性要求平均数不能掩盖局部回退看起来更快必须落到公开算子基准上。提交前的自查清单按 op-development.md 第 8 节的变更清单PR 前确认✅ 语义边界分类正确不是调度决策、不是裸传输、不是私有辅助步骤✅ 契约注释覆盖公式、形状、支持域、数值边界、副作用与 workspace✅ 校验在 wrapper、启动策略在 launcher、设备计算在 kernel✅ 所有受影响的公开入口都对新 oracle 直接验证过✅ 性能声明在所声称的层级测量过算子级改进用算子基准不要拿端到端结果冒充算子证据✅ 每个新源文件在src/ops/family/sources.cmake中登记有唯一构建归属✅ PR 描述包含链接的 Issue、验证命令与结果、硬件/工具链、未运行检查及影响。写在最后NInfer 的算子开发文化可以概括为一句话契约定义算什么实现自由决定怎么算快oracle 和公开基准共同守住对不对、快不快两条底线。只要遵守 Issue 先行、契约先行、独立 oracle、公开基准这四条主线你的第一个 CUDA 算子贡献就能融入这套量化推理引擎。祝开发顺利 【免费下载链接】ninferHigh-performance single-GPU inference for selected model checkpoints and GPUs.项目地址: https://gitcode.com/gh_mirrors/ni/ninfer创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考