企业官网建设流程全解析

Warp 评估拒绝门（Rejection Gates）完全指南：如何在引入 NVIDIA Warp 前系统性地排除不适用场景

【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warp

导读：本文是 NVIDIA Warp（GPU 加速仿真与机器学习框架）评估技能warp-eval中拒绝门（Rejection Gates）参考文档的深度解读。该文档定义了一套 A–F 共六个精确的判定门，用于在性能优化场景中回答一个核心问题：某条现有代码热路径是否值得评估迁移到 Warp。读完本文，你将掌握每个 Gate 的触发条件、不触发条件、判定流程以及AWAITING INTENT状态的正确提问方式，并理解如何结合仓库源码与真实评估用例落地这套判定体系。

一、什么是 Rejection Gates：评估的“提前退出”机制

在warp-eval技能中，评估的目标是：为一个既有代码库中很窄的一段接缝（seam）收集可复现的证据，说明它在 NVIDIA Warp 中会如何表现，然后由用户自己决定是否采用，评估者不做任何采纳建议。

Rejection Gates 就是这一评估流程的"守门人"。每个 Gate 都回答同一个问题：

一个被陈述的事实，是否使这次 Warp 评估对本接缝或执行域（seam or regime）不适用？

每个 Gate 都是环境、工作负载形态或现有实现（incumbent）的属性——它绝不是关于"有多少证据可用"的判断。缺失测量数据不是一个 Gate，缺失的证据应当在下游报告中如实标注为缺失，而不是伪装成拒绝。

核心执行规则

• 执行时机：Gate A–E 在性能分析（profiling）之前运行；Gate F 只有在已有代表性证据时才在 profiling 前运行，否则留到已授权的第二阶段（stage 2）profile 之后判定。
• 一票否决：任何一个 Gate 解析为ABORT，整个评估直接终止，连 Warp 原型都不做。
• 精确性：不存在"近似""部分"或"类比"的 Gate。只有被陈述的每个条件全部成立，Gate 才会触发。
• 证据来源分层：Gate B、C、D 可以从代码和现有实现产物中直接可见；Gate F 需要代表性的测量或结构性证据；Gate A、E 是产品决策问题，只能由被陈述的事实触发。

从 SKILL.md 的 Hard rules 可以看到这套门体系的定位："Gates are exact, never adjacent or analogous. Fire a gate only when every condition in its definition is established."（第 5 条）以及"Never infer environment intent. NVIDIA deployment and ownership of an optional compiled dependency are product decisions. Abort only on a stated constraint; otherwise ask once and stop (AWAITING INTENT)."（第 10 条）。

下面逐个深入每个 Gate。

二、Gate A —— 部署环境排除 NVIDIA

定义

生产环境是纯 CPU，或者要求非 NVIDIA 加速器的可移植性，且不存在可接受的可选 CUDA 路径。

这条门背后的硬件事实来自 SKILL.md 的 Limitations：Warp 的 CPU kernel 是串行的，且不在本技能的评估范围内——"那就用 CPU 跑"不是性能上的退路（fallback）。

触发条件（Fires on）

触发 Gate A 的不是技术现状，而是被陈述的产品决策：

• 部署、支持或打包文档中写明目标硬件且不含任何 NVIDIA 部件；机群/设备 SKU 清单中没有 NVIDIA 设备；明确声明了硬件冻结（hardware freeze）；
• 跨厂商对等（cross-vendor parity）被承诺为产品属性——例如用一个源码在 CI 中覆盖多家厂商、或者给出"随处可跑（runs anywhere）"的保证；
• 本路径必须保留某个非 NVIDIA 加速器（TPU pod、Metal、纯 ROCm），且旁边不能有可接受的可选 CUDA 路径；
• 用户自己明确说出部署约束。

不触发条件（Does not fire on absence）

Gate A 绝不会仅因为"缺乏"而触发：

• 现在没有 GPU 代码、依赖列表里没有 CUDA、没有 Warp、CI 只在 CPU 上跑、现有实现是 NumPy、或者某个框架恰好在这台机器上用 CPU 运行——这些都不能证明产品"不允许"使用 NVIDIA GPU。

关键区分：第二加速器存在 ≠ 触发

一个 JAX-on-TPU 代码库，或者带 Metal 路径的项目，依然要回答的问题是：在这条路径上，一个 NVIDIA 路径是否可接受？"要求各目标对等"才触发 Gate A；而"存在第二个目标"只是一个需要记录的可移植性与所有权事实。

仓库中的实证案例

gate-a-required-portability 评估用例的 deployment.md 是一个典型的 Gate A 触发场景：

"Every accelerated feature in that core must use one source implementation and must pass the same correctness and performance qualification on NVIDIA CUDA, AMD ROCm, and Apple Metal devices. Backend-specific optional paths are not accepted for this component. In particular, a CUDA-only implementation cannot ship alongside the portable path, even as an opt-in extra."

该文档明确承诺 NVIDIA CUDA、AMD ROCm、Apple Metal 三端对等，且明确拒绝 CUDA-only 实现作为可选附加（opt-in extra）随便携路径一同发布——这是产品层面的硬性陈述，直接满足 Gate A 的全部条件，评估应立即以ABORT — Gate A: ...退出，无需任何原型。

三、Gate B —— 主机/设备边界主导开销

定义

数据必须在每次小规模或不频繁的调用中跨越主机/设备边界（host/device），且边界无法加宽（cannot be widened）。

例如：每次调用只传 1 个点和至多 192 条线段，走共享主机内存，返回一个 JSON 标量；进程隔离和公共插件 ABI 是硬性要求；宿主应用既不能把设备分配交给 worker，也不能批量请求或保活 worker 状态——那么每个调用都必须"初始化运行时 → 拷贝输入到设备 → 拷贝结果回来"，这种结构的 GPU 实现只会比现状更慢。

一旦触发 →ABORT，除非调用方能被重构为让数据保持驻留（resident）。

触发要点

• 每次小调用或不频繁调用时数据必须过边界；
• 边界无法被加宽（无法批量、无法驻留）。

仓库中的实证案例

gate-b-unwidenable-host-boundary 评估用例的 architecture.md 精确描述了这一场景：短生命周期隔离 worker 进程、每次最多 192 条线段、每分钟调用不超过 3 次、现有 NumPy 实现耗时 45–80 微秒。冷启动 + 每次拷贝的开销远超 80 微秒量级，且产品对该阶段没有任何内存/容量目标——符合 Gate B 的"边界不可加宽"条件，直接ABORT。

四、Gate C —— 普通稠密张量代数

定义

稠密线性代数、卷积、FFT、归约（reduction）、标准神经网络层，或任何已被框架或厂商库高效降低（lowered）的运算。

这类工作负载的正确基线是调优后的框架或厂商路径（vendor library），而不是手写 Warp kernel。→ABORT。

判断依据

Gate C 的判定关键不是代码长什么样，而是这项工作是否已经被现有框架的编译器或厂商库高效地映射到硬件。从 target-patterns.md 的 "Patterns that fire an early gate" 可以看到："dense linear algebra, convolution, FFT, reductions and neural-network layers already lowered onto vendor libraries or a framework compiler (gate C)"。

仓库中的实证案例

gate-c-dense-vendor-lowered 评估用例的 feature_stage.py 是一个教科书级的 Gate C 场景：

features = F.conv2d(images, convolution_weight, padding=1) features = F.layer_norm(features, features.shape[-3:]) pooled = F.adaptive_avg_pool2d(F.gelu(features), output_size=1).flatten(1) return pooled @ projection_weight

卷积 + LayerNorm + GELU + 自适应平均池化 + 投影矩阵乘法——每一行都是 PyTorch（以及 cuDNN/cuBLAS 等厂商库）早已高度调优的标准稠密算子。这类代码再"慢"，瓶颈也几乎不可能在算子本身，而评估 Warp 也无法超越厂商库。无需原型，直接ABORT — Gate C。

反向提醒

与 Gate C 相对，target-patterns.md 的 "Common false positives" 特别警告："Replacing tuned dense algebra with a naive per-thread kernel"（用朴素逐线程 kernel 替换调优稠密代数）是常见误报——不要因为"能用 Warp 写"就以为存在优化机会。

五、Gate D —— 成熟的 CUDA 实现已满足契约

定义

同时满足以下三个条件才触发：

1. 存在一个被维护的实现，且已确认通过 CUDA 在 NVIDIA GPU 上执行；
2. 它已经满足语义契约（correctness semantics）；
3. 它已接近相关 GPU 的硬件极限。

三个条件全部成立 →ABORT，除非用户明确请求了一个被允许的非性能目标，并且定义了可接受的性能回退预算（performance-regression budget）。

关键澄清：CPU 上的实现绝不等于 Gate D

Gate D 不会因为现有实现跑在 CPU 上而触发——无论它跑得多快。

• 原生扩展、向量化代码、多线程代码、CPU JIT 都是"最强基线（strongest-baseline）"的候选，不是 CUDA 路径；
• 不得从实现语言、包类型或性能表现推断 CUDA 执行；
• 如果现有实现不在 NVIDIA GPU 上执行，Gate D 根本不可用（unavailable）。

这一点与 SKILL.md Hard rules 第 5 条完全呼应："Gate D requires a maintained implementation confirmed to execute with CUDA on an NVIDIA GPU; a fast native CPU library is a baseline, not Gate D."

仓库中的实证案例

两个评估用例从正反两面演示了 Gate D：

• gate-d-mature-incumbent 的 baseline.md（触发）：contact_cuda.compact_contacts是生产实现，CUDA 团队维护、在每个支持的 GPU 上测试、ABI 保持了四个版本；在 H100 SXM 上端到端延迟 0.82 ms，有效带宽 2.7 TB/s 达到该表示法拷贝/扫描 roofline（3.1 TB/s）的 87%；且请求方没有可维护性、人体工学、打包、自动微分或新功能目标，性能是唯一目标。→ 三个条件全部成立，ABORT — Gate D。
• gate-d-cpu-incumbent-not-cuda（不触发）：现有实现虽然快，但被确认执行在 CPU 上——它只是最强基线候选，Gate D 不可用，评估继续。

六、Gate E —— 项目无法承担引入 Warp 的义务

定义

引入 Warp 会给项目带来一系列运行时义务：可选的额外依赖（optional dependency）、运行时编译（runtime compilation）、kernel 缓存、版本资格矩阵（version-qualification matrix）、平台特定测试、以及一条回退路径（fallback path）。

触发条件（Fires on a stated policy）——必须是项目明文声明的政策：

• 禁止运行时代码生成；
• 镜像内不允许编译器或工具链；
• 只读或气隙（air-gapped）部署，没有可写缓存位置；
• 只允许 vendored 预编译二进制；
• 保证纯 Python wheel；
• 依赖政策明确排除编译依赖。

不触发条件——仅仅"现状如此"不算数：

• 项目碰巧目前是纯 Python、依赖列表很小、还没有编译扩展——这是一个需要提出的成本，不是仓库已经做出的决策；
• 贡献政策要求新增依赖先讨论、或说明不太可能被合并——那只是规定变更如何被提出、由谁提出，不能证明项目无法承担义务。

提问方式：与 Gate A 合并为一个决策

SKILL.md 强调 Gate E 要与 Gate A 的问题一起问——对用户而言，这是一个决策的两面。提问时必须给出具体的可选路径形态：

一个命名的可选依赖组（optional dependency group）、一个软导入（soft import）、一个对现有实现的回退——默认安装保持不变，只有选择加入（opt-in）的用户承担运行时义务。

不要假设项目会接受它。

仓库中的实证案例

gate-e-runtime-obligations-forbidden 的 packaging-policy.md 是一个完整的 Gate E 触发文档：audited 只读 appliance 镜像、所有包与可选扩展必须保持纯 Python、禁止编译依赖与平台特定二进制、禁止运行时代码生成与编译器/工具链、应用没有任何可写位置存放生成代码或 kernel 缓存、且加速器特定可选后端不被批准为例外——最后一句"These are product requirements, not observations about the current dependency list"（这是产品要求，不是对当前依赖列表的观察）直接封死了"现状不等于决策"的辩解空间。→ABORT — Gate E。

七、Gate F —— 该区域从数学上不可能产生显著影响

定义

候选阶段（candidate stage）在所请求指标中的占比太小，任何后端都搬不动它。Gate F只能由以下三类证据触发：

1. 用户提供的 profile；
2. 明显的结构性上界（structural bound）；
3. 对用户引用数据的算术推算。

如果"不测量就说不清"，就让 Gate 保持打开（open），留到第二阶段用 profile 判定。第二阶段的 Gate F 结果无需再次授权即可中止已授权范围内的评估。

四条关键纪律

• profile 必须代表所请求的目标。只有 profile 的工作负载、执行域和指标与用户目标匹配时，测量份额才能触发 Gate。维护、合成、演示或其他无关工作负载的份额什么都不证明；目标频率或分布缺失是缺失证据，不是 Gate F。
• 针对该候选模式所消耗的指标应用，而不是研究的大标题指标。先分类，再用匹配到的目标模式所指名的资源。一个延迟研究里依然可能包含整个价值在内存或容量上的候选。
• 展示上限算术（ceiling arithmetic）：该阶段免费后，所请求指标会变成什么，以及这隐含的最大比率。Gate F 需要一个你能说出来的上限，不是一个印象。
• 说明 Gate 应用于哪个指标，以及计算假设的设备内存预算。

不触发条件

不可用的代表性覆盖不是 Gate F。记录那一个缺失的产物，以"缺失证据"状态停止；不要把缺失转化为ABORT。这与 SKILL.md 的 Troubleshooting 一致："No representative workload: mark the scopeINCOMPLETEand name the missing artifact; do not invent data or fire Gate F."

仓库中的实证案例

gate-f-immaterial-stage 的 profile.json 给出了完整的算术示例：

• 目标是p95_request_latency（目标 50 ms）；
• 总耗时 100.0 ms，其中decode占 68.0%（68 ms）、other占 30.8%（30.8 ms）、spatial_filter仅占 1.2%（1.2 ms）；
• spatial_filter峰值内存 14 MiB，内存预算 8192 MiB，非容量受限（capacity_limited: false）。

算术结论：即便spatial_filter完全免费，p95 延迟也只会从 100 ms 降到 98.8 ms，仍然远高于 50 ms 目标——它连自己的指标都搬不动。对延迟目标而言，这是一个可陈述、可计算的 ceiling，Gate F 触发，ABORT该范围。注意：如果spatial_filter是内存/容量类候选，则应对内存预算应用 Gate F，而 profile 中 14 MiB 对比 8 GiB 预算同样会触发——这正演示了"针对候选模式所消耗的指标应用"这一纪律。

八、AWAITING INTENT：如何询问意图

触发条件

Gate A 和 Gate E 不明确、至少有一个候选模式存续、且没有其他 Gate 触发——这时进入AWAITING INTENT状态：问一个问题，然后停止——在 profiling 之前、在创建报告目录之前、在任何原型之前。

一个好问题的标准

• 陈述你读到的东西，而不是你想要的东西——例如"仓库里没有任何内容说明纯 CPU 是硬性要求，还是仅仅恰好落在这里"，而不是"你有 GPU 吗？"（后者会引诱一个只有笔记本 GPU、根本没打算用它发布的人回答"有"）；
• 让两个分支都具体且完整——明确说明要么 Warp 会被测试，要么评估中止；
• 只问一次，并与授权检查点（authorization checkpoint）合并批处理；
• 不争辩。

标准提问与选项表

按 rejection-gates.md，提问是：

"May this evaluation prototype and benchmark a Warp implementation?"（本次评估是否可以对一个 Warp 实现进行原型化和基准测试？）

选项标签与描述必须明确陈述后续动作：

明确禁止与不询问条件

• 不要提供"仅 CPU 侧发现"或"仅现有实现 profiling"作为warp-eval的分支——那是另一项普通的优化任务，不属于本技能；
• 仓库已经回答了问题时不问；其他 Gate（B、C、D、F）已自行终结研究时不问；没有模式匹配时不问；无论如何你都会继续时不问——如果"请只用 CPU"的回答仍会让你继续评估 Warp，那么这个问题就是装饰。

与授权检查点的衔接

从 authorization-checkpoint.md 可以看到：在阶段 1 找到至少一个候选模式后、任何测量/实验工作之前，必须经过授权检查点。其中特别规定："Keep the environment question (if unresolved) and the scope approval as separate structured choices, so packaging conditions cannot be mistaken for permission to omit Warp."——环境问题与范围批准必须是两个独立的结构化选项，防止"打包条件"被误读为"允许省略 Warp"。

意图问题未决时，"继续吧"只授权了工作本身，并不表示产品允许 NVIDIA GPU 或接受该依赖——需用一行再问一次并等待。

九、Gate 触发的正确退出姿势

当任意 Gate 触发时，按 SKILL.md 规定的精确格式输出早期退出（early exit）：

ABORT — Gate <letter>: <被引用的事实>; <为什么这次受限的 Warp 评估无法继续>

示例（来自 SKILL.md 的 Examples）：

ABORT — Gate A: deployment.md requires one implementation with AMD, Apple and NVIDIA parity; a Warp-specific path cannot satisfy this scope.

要点：

• 不点名替代方案；
• 若在测量工作开始前触发：一句话交回，说明 Gate、引用其来源、陈述不合格事实，不创建报告目录；
• 若在测量工作开始后触发：保留已收集的报告与产物，将受影响范围标记为aborted，记录失败标准，停止相关工作——详见 evidence-and-reporting.md 的 Procedural states。

十、完整判定流程图与决策速查表

综合 rejection-gates.md 与 SKILL.md 的阶段 1 检查表，一个典型评估的开端是：

识别候选接缝与指标（target-patterns） │ ▼ 推导契约（设备/驻留、dtype/形状、大小、频率、进程生命周期、梯度、打包） │ ▼ profiling 前依次检查 Gate A → B → C → D → E （Gate F 仅在已有代表性证据时此刻检查） │ ├── 任一 Gate 触发 → ABORT（无 Warp 原型） │ ├── Gate A/E 不明确但有存续模式 → 问意图（合并授权检查点），问一次后停止 │ └── 全部通过 → 提出候选 + 授权检查点 → 等待明确授权后进入 stage 2 profiling

决策速查表：

十一、常见误用与边界纪律

不要把"缺失"当成"拒绝"：

• 没有 GPU 代码、依赖里没有 CUDA、没有 Warp、CI 只在 CPU 跑、是 NumPy 实现——这些都不触发 Gate A；
• 项目目前是纯 Python、依赖列表小、没有编译扩展——这些都不触发 Gate E；
• 无法获得代表性覆盖——这是INCOMPLETE（缺失证据），不是 Gate F，更不是ABORT。

不要跨类别套用：

• 快的 CPU 原生库是"最强基线"，不是 Gate D；
• 第二个加速器的存在是"可移植性事实"，不是 Gate A；
• 稀疏/不规则负载（空间查询、粒子仿真、分支密集循环、许多小启动、大中间张量）才是 Warp 的候选域，稠密算子归 Gate C——这一划分在 SKILL.md 的 description 中已有明确定义。

永远记住评估的边界：评估只报告事实，由用户做采纳决策（SKILL.md Hard rules 第 12 条："Never recommend or rank adoption options"）；一次 Gate 触发即停止，不要为了收集"可能改变受限事实的证据"而继续测量（SKILL.md Instructions 开头："Stop as soon as a gate fires; do not gather evidence that cannot change the scoped facts."）。

参考资源

• 拒绝门完整定义（本文核心依据）
• warp-eval 技能主文档（Hard rules、阶段流程、输出格式）
• 目标模式与工作量分类（识别候选与早期 Gate 模式）
• 授权检查点（意图问题与范围批准的衔接）
• 证据与报告规范（ABORT 后的正确退出）
• 基准测试协议（stage 2 测量纪律）
• 评估用例：Gate A、Gate B、Gate C、Gate D 触发、Gate E、Gate F

【免费下载链接】warpA Python framework for GPU-accelerated simulation, robotics, and machine learning.项目地址: https://gitcode.com/GitHub_Trending/warp/warp