1. 并发无上限是个假象：先看清深度计算硬件的真实执行模型1.1 从“线程并发”到“任务并发”的思维转换做深度计算 Runtime 这些年，我见过太多团队在“并发”这件事上栽跟头。最常见的想法是：任务能塞就塞，队列能开多深就开多深，仿佛只要同时提交的任务足够多，硬件就一定满载。这个直觉在 CPU 程序里大体成立，但放到深度计算场景就完全不对了。先界定一个概念：我们说的并发，不是 CPU 多线程并发，而是任务层面的并发。一个神经网络推理过程通常包含几十个算子，每个算子内部可能又有大量计算单元要干活。Runtime 要做的事，是把这些算子拆成一个个可提交的任务，按照依赖关系送入加速卡硬件队列。加速卡不同于 CPU，它天生是吞吐式设计——单个任务延迟未必低，但大量任务堆叠起来，计算单元始终有事可干，整体吞吐就上去了。所以这里有一个思维转换：Runtime 调度器的核心职责，不是“计算”本身，而是让计算任务在正确的时间、以正确的顺序、落在正确的硬件引擎上。判断一个 Runtime 好不好的关键，不是单算子跑得多快，而是整张计算图跑下来，硬件的执行单元有没有持续被喂满。“喂满”这件事，牵涉到硬件队列、执行流、事件同步、任务粒度，远比想象中复杂。1.2 硬件执行单元：一个任务在设备上到底经历了什么把视角降到一个任务上，我在设计 Runtime 时习惯把任务的设备侧生命周期分成四个阶段：CPU 侧创建任务：准备算子参数、分配输入输出内存、确定使用的流。提交阶段：把任务命令写入硬件可感知的内存队列，这是一个 CPU 到设备的消息传递过程。硬件调度阶段：设备端调度器从队列取命令，解析资源需求，分配到计算引擎（矩阵单元、向量单元、张量单元等）。完成写回：任务执行完毕后，硬件通过中断或状态标记通知 CPU。这段链路里藏着好几个并发瓶颈。第一个是同步提交。很多 Runtime 初版实现都在算子执行完后立刻调用设备同步等待，下一次提交要等这次完全结束才开始。结果是硬件干活的时间可能只有百分之几十，剩下的时间都在等待 CPU 发下一个任务。第二个是任务粒度。如果每个小算子都单独提交一次，命令本身的固定开销可能超过计算时间。比如一个简单的逐元素相加，计算可能只要微秒级，但命令创建、提交、解析的固定开销很可能同样在微秒级，这时候“极致并发”就变成“极致命令开销”了。我常用一个生活化类比：硬件就像一条工厂流水线，每个任务是一批待加工零件。如果工头每送一个零件就停下等这台机器完工再送下一个，流水线就废了。但如果工头把几万个小零件一个个单独送过去，传送带也会被堵死。好的调度是让零件按正确批次、正确顺序持续快速流入。1.3 并发“极致”的衡量标准“极致任务并发”到底怎么量化？我建议用三个指标，而不是只看设备利用率。第一是端到端时延，也就是一个请求从进来到结果出去的总时间，这是对用户最直接的指标。第二是气泡率，可以理解为硬件执行单元空闲的时间占比。第三是提交吞吐，单位时间内 Runtime 能向设备提交多少任务，这里反映的是 CPU 侧调度开销。三个指标经常是矛盾的。为了让硬件不空转，可能需要同时提交更多独立任务；但任务多了，提交开销增大，CPU 侧可能反而成为瓶颈。为了降低时延，应尽量缩减队列长度；但队列太短，硬件又可能出现气泡。所以“极致并发”不是一个绝对状态，而是在目标任务下，把三个指标优化到可接受区间。我在排查一个推理引擎的并发问题时，先看 profiler 输出的设备时间轴。如果发现明显的“锯齿”——设备忙一下、闲一下、忙一下、闲一下，基本可以断定是任务提交不够连续，或者依赖关系导致硬件在空等。此时优化的方向往往不是“再加并发任务”，而是“消除依赖上的等待”。这个思路后面会反复用到。2. 执行流（Stream）的语义边界：哪些任务真的能并行，哪些不能2.1 流是什么：硬件视角的操作序列主流加速卡 SDK 都提供“流”这个概念，英文叫 Stream 或 Queue。流本质上是一条按提交顺序执行的操作序列。同一流里的任务必须串行，不同流里的任务在无依赖的情况下允许并行。这个语义极其重要，但经常被错误理解。很多人以为“多开几条流就等于多几路并行”，于是把一个模型的一条执行路径上所有算子分散到几条流里，结果反而更慢了。原因很简单：流只是提供了并行的可能性，硬件是否真的并行，还要看任务之间有没有真实依赖、硬件资源是否足够、调度器的分配策略是否允许。深度计算场景的依赖主要有三类。第一类是数据依赖：下一个算子要读上一个算子的输出，这必须等待。第二类是内存依赖：两块张量可能共用一块内存池，前一个任务还没读完，内存就被后一个任务覆盖了。第三类是控制依赖：比如 if 分支后的算子，要等条件计算完才知道执行哪个分支。2.2 事件（Event）与同步：并行不是免费的流本身解决不了跨流依赖。假设算子 A 在流 1 上执行，算子 B 在流 2 上执行，但 B 需要 A 的输出，那就必须用事件机制：A 完成后发出一个事件标记，B 所在流等待这个事件后再执行。这是跨流同步的标准做法。事件同步的代价很容易被低估。每次等待事件，都可能让 CPU 侧阻塞或者让设备侧某个流空转。极端情况下会出现死锁：流 1 在等流 2 的事件，同时流 2 又在等流 1 的事件，两边都等不到，设备一直空转到超时。我做过一个实验：在一个模型里把所有算子放到 8 条流上，每条流之间用事件严格按依赖顺序串联。结果和单流执行几乎一模一样，因为所有任务最终还是被事件排成了一条全序链。流开得多，不代表并行度高；真正的并行度取决于“可重叠执行的任务”数量。2.3 深度计算场景下的流分配策略那么流到底怎么分配？我的经验是，先画出整张计算图，找出哪些部分天然可以重叠。深度计算里最常见的重叠场景有三类：通信与计算重叠：在分布式场景，权重同步通信可以和本地前向或反向计算同时进行。数据搬运与计算重叠：输入样本从内存拷到设备显存时，前一个 batch 的计算还在进行。并行分支重叠：某些大模型输入经过不同的注意力头或专家分支，各分支间没有依赖。这三类场景才配得上“独立流”。其余大多数算子之间的依赖都是线性的，老老实实排在同一流里但并不一定串行，因为同一流里的提交是 CPU 异步的，硬件忙的时候后续命令已排队，设备侧能连续消费，这本身就是一种流水线并发。所以我在设计流分配时遵循一个简单原则：能合则合，该分才分。把没有重叠机会的算子合并到少数几条流里，减少命令的分散度；把确实需要重叠的计算放不同流，再用事件精确同步交界面。有人问我到底开几条流合适，我的回答是：先根据重叠需求定流数上限，再根据硬件提交队列深度往下压，通常从 2 到 8 条之间试，不要一上来就开几十条。3. 硬件调度器与 Runtime 的配合：谁来决定“下一步执行什么”3.1 硬件调度队列的内部逻辑很多 Runtime 设计者把硬件调度器当黑盒，以为只要把命令丢进去就不用管了。实际上硬件队列的调度策略非常有限，大多数加速卡的设备队列本质上是近似 FIFO，也就是先提交先执行。这意味着 Runtime 提交任务的顺序，基本决定了硬件执行的大致顺序。硬件调度器能做的最多是在 FIFO 基础上做资源适配：当一个任务需要的执行单元忙不过来，它可能让另一个不冲突的任务先上。但这里有一个前提——所有候选任务必须在队列里可见。如果 Runtime 在等待某个事件完成前，根本没把后续任务提交到硬件队列，那么硬件调度器能做的事情就非常有限了，一旦前面的任务执行完，队列空了，硬件就只能空转。所以关键结论是：Runtime 的软件调度，负责在正确时机把候选任务提前送入硬件队列；硬件调度只负责在已可见任务之间做资源分配。真正决定并发上限的，是 Runtime 的“可见性管理”。3.2 优先级、抢占与时间片在深度计算里的作用深度计算任务并不总是同样重要。在线推理请求通常要求低延迟，训练任务则更看重吞吐；前台交互式任务要快速响应，后台预计算任务可以慢慢跑。这些诉求反映到 Runtime 层，就是优先级和多级队列设计。但硬件队列数量有限，优先级机制也未必完善。我见过一个做法：Runtime 维护多个软件任务队列，高优先级队列的任务在提交时优先进入硬件队列；低优先级任务只能在高优先级队列空闲时提交。这个框架简单有效，关键是提交循环要设计得好，不能让低优先级任务饿死。抢占在深度计算里更棘手。设备上的计算一旦开始执行，基本不能像 CPU 线程那样随时中断。如果是一个超大矩阵乘法占了执行单元几毫秒，高优先级的推理请求也只能在它后面排队。一个缓解思路是切分任务粒度：把大算子切分成多个小块任务，交错提交高优先级任务。比如一个 4096 大小的矩阵乘法，可以分成多个子块任务，每块执行完后的边界处，调度器都可以插入优先任务。代价是切分可能降低计算效率，因为矩阵分块会引入额外内存访问，这个就需要根据实际卡型做取舍了。3.3 一个实用的调度模型：从任务图到硬件命令的映射我在内部自研 Runtime 时，最终采用的调度链是这么一条：计算图分析：拿到模型结构，识别每个算子的输入输出、内存需求、所在设备。图切分：把算子按设备、按重叠需求切成小组。拓扑排序：确定所有任务的总序，保证数据依赖不被破坏。流分配：决定每个任务落在哪条流上。事件插入：在跨流依赖处插入事件，并建立等待关系。命令提交：把任务批量写入硬件队列。这套链路最大的好处是“一次分析、多次执行”。模型结构不变时，第 1 到第 5 步只需要做一次，把调度计划缓存起来。每次推理请求进来，只需要把输入地址填进计划，按预定义的流和事件关系提交命令即可。这比每次请求都重新分析计算图快一个数量级以上。为什么图模式比单算子逐发更有利于并发？因为单算子逐发时，每次只能基于当前算子的依赖做判断，无法看到后面几十个算子里有多少可以提前准备。图模式则能看到全局，可以提前把独立分支的命令推入硬件队列，形成持续的“命令洪流”，把硬件气泡压到最低。4. 驱动执行流的实战设计：一个深度计算 Runtime 的并发调度实现4.1 核心数据流设计我按一个最小可运行的 Runtime 结构来说明。核心数据结构就两样：任务节点任务图。任务节点包含：算子类型、输入输出张量引用、所在流 ID、依赖事件集合、完成事件集合。依赖事件集合表示这个任务开始前必须等待哪些事件，完成事件集合表示这个任务结束后会发出哪些事件。任务图就是节点和边的集合。边的含义可以分两种：数据边表示张量依赖，调度边表示流间同步。数据边决定拓扑顺序，调度边决定事件插入位置。我在实现时把这两种边分开存，因为数据边是模型自带的，调度边是流分配算法根据数据边推导出来的。struct TaskNode { int op_id; // 算子编号 int stream_id; // 流编号 std::vector<Event*> wait_events; // 开始前等待 std::vector<Event*> emit_events; // 完成后发出 std::vector<Tensor*> inputs; std::vector<Tensor*> outputs; }; struct TaskGraph { std::vector<TaskNode> nodes; // 数据边：指向依赖的上游节点 std::vector<std::vector<int>> data_edges; // 调度边：指向跨流等待的节点 std::vector<std::vector<int>> sync_edges; };4.2 流分配与事件插入的具体算法流分配的目的是把无依赖或弱依赖的任务分散到不同流上，让硬件可以重叠执行。我使用的是一种贪心启发式，思路很简单：遍历拓扑排序的任务，对每个任务尝试分配到某个流，使得该任务所需的依赖事件已经在该流上满足。听起来抽象，我拆解一下实现流程：为每条流维护一个“最后执行节点”和“最后发出事件”。遍历任务时，先找出所有尚未满足的上游节点事件。如果某个任务所有上游都在同一流，直接放到那条流的末尾，不增加事件。如果上游分散在多条流，则选择一个“最近完成时间期望最小”的流，并在该流上插入等待事件，在上游流上插入发出事件。如果某条流已经排了太多任务，后续任务又无依赖，则优先放到空闲流，形成负载均衡。伪代码大致长这样：void AssignStreamAndInsertEvents(TaskGraph& graph) { auto topo = TopoSort(graph); for (int node_id : topo) { auto& node = graph.nodes[node_id]; int best_stream = -1; int best_cost = INT_MAX; for (int s = 0; s < num_streams; s++) { int cost = EstimateSyncCost(node, s); // 计算跨流事件数量 if (cost < best_cost) { best_cost = cost; best_stream = s; } if (cost == 0) break; // 无跨流依赖，直接选这条流 } node.stream_id = best_stream; InsertSyncEvents(graph, node); // 根据上游流插入事件 } }EstimateSyncCost的计算方式是：统计该任务所有上游节点所在流与候选流的交集。上游全在当前流里，代价为 0；有几个上游在其他流，就要插入几组事件。事件插入总会有开销，所以算法天然倾向于把一条链上的任务排在同一个流里，只有在并行机会明显时才跨流，这正好符合前面说的“能合则合，该分才分”。4.3 流水线重叠与异步提交的落地有了任务图和流分配，接下来要解决 CPU 侧提交的异步性。我在早期版本里犯过一个错误：提交线程在把任务命令写入硬件队列后，立刻查一次事件状态，用来决定后续任务是否已经可以提交。结果每次查询都要和硬件打交道，CPU 侧很快就成了瓶颈。正确的做法是：CPU 侧提交线程只负责“按计划把命令写入硬件队列”，完全不等待完成状态。等待逻辑通过事件机制由硬件去处理。也就是说，Runtime 的任务提交是纯异步的，事件的发出和等待由设备侧完成，CPU 线程可以连续不断地产出命令，形成一个生产-消费环形队列，把任务命令批量推给硬件。这样做后效果非常明显。以单流的连续卷积链为例，不修改任何算子，只把提交从同步改成异步，设备利用率就可以提升近一倍。原因在于，原先 CPU 在每次算子后等待硬件完成，白白浪费了几百微秒；改后 CPU 持续提交，硬件流水线基本没有气泡。4.4 实测对比与效果我在自研 Runtime 上做了一组对比测试，使用一个有 20 多个算子的典型视觉模型，输入固定尺寸。三种执行方式：方案 A：逐算子同步执行，每个算子执行完都等待完成。方案 B：逐算子异步提交，使用单条流。方案 C：任务图分析后多流异步提交，自动插入事件。在我使用的加速卡上，端到端时延大致是 A 的 1.4 倍于 B，B 的 1.25 倍于 C。也就是说，从 A 到 C 整体优化了超过 40% 的时延。其中最大提升来自异步提交，其次来自多流重叠。这样的测试结果和很多公开框架的优化趋势一致。需要特别说明的是，具体倍速高度依赖模型结构和硬件类型。如果一个模型本身几乎全是串行算子，多流优化的空间就很小，C 比 B 提升可能只有几个百分点；如果模型有大量独立分支，C 比 B 的差距会拉到 30% 以上。所以我的建议是，先做 profiler 看时间轴，确认有没有明显的可重叠区域，再投入精力做多流调度。5. 真正难的不是“加流”，而是这几个细节5.1 内存分配与生命周期对并发的隐形限制当任务真正并行执行后，内存管理会变成新的约束。张量生命周期必须被精确跟踪：一个张量可能在流 1 上被写入，同时在流 2 上被读取，两边的任务必须同步在正确的事件上，否则就会出现数据竞争。更隐蔽的是内存池复用问题。为了减少分配开销，Runtime 通常会维护张量内存池，一个张量用完就归还，后续张量复用同一块显存。但如果并发任务变多，内存生命周期难以准确判断，归还时机就变得模糊。我见过一个案例：两个独立分支的算子在两条流上运行，输出张量大小相近，内存池把它们的输出指向同一块显存，结果后写的任务覆盖了先写的任务，模型结果完全错误。解决办法是采用“按流顺序分配”的内存池策略：每个流维护自己的分配位置，回收时依赖事件确认所有引用该内存的任务都已完成。这会让内存池设计复杂很多，但这是并发调度不可绕过的问题。5.2 小算子的噩梦：命令开销淹没计算收益深度计算模型里大量存在逐元素加法、激活函数、归一化这类小算子。单个算子计算时间只有几微秒，但提交命令的固定开销可能也有几微秒。如果完全依赖流调度，就算并行调度做得再好，命令开销也降不下来。这类问题的正解在 Runtime 上层，也就是算子融合。把多个小算子合成一个更大的算子，减少任务数量，降低整体命令开销。这块工作不是调度器能替代的，它需要分析算子的构成和数据类型。比如卷积后接偏置加再接激活，三个算子可以合并为一个自定义算子，命令数量直接少了三分之二。5.3 从一机多卡到多机：执行流驱动机制扩展到分布式单机多卡场景里，跨卡数据传输通常通过设备间点对点通信完成，通信任务的执行流语义和计算任务类似，可以投递到通信相关的流上。这里最容易出问题的是同步粒度：如果每个张量传输都插入事件，事件数量和同步开销会很大；如果大批量传输后才同步，又可能让计算流长时间等待。我的实践是，把多卡同步点尽量放在“计算边界”。比如在每个梯度聚合开始时，一次性等待所有本地计算完成，然后启动通信；通信未完成时，下一阶段计算可以先启动与通信无关的部分。这个思路可以扩展到多机场景，只不过网络通信的延迟更大，更需要把通信与计算放在不同的流上，并且提前批量提交通信任务。5.4 我的几点实操体会先说最核心的一条：不要为了并发而并发。我见过太多团队把“多流调度”当作目标，加了十几条流，跑出来性能没涨，反而引入一堆内存同步问题。正确顺序永远是：先 profile，把时间轴拉出来看，找到硬件空闲的具体位置；再问为什么空，是 CPU 提交慢，还是任务依赖等得太久，还是内存分配阻塞；最后才决定用流、事件还是融合去解决。第二条体会是，执行流和事件不要用成“锁”。有些 Runtime 实现里，事件等待被当作线程同步工具来用，甚至拿事件去保护一段 CPU 代码的临界区，这是把硬件事件机制用错了地方。事件是设备侧任务的执行条件，不是 CPU 侧的互斥锁。CPU 线程之间的同步应该用普通的条件变量和互斥量，让事件专心处理设备侧依赖关系。第三条体会比较隐性：如果调用硬件厂商的底层 API，一定要先搞清楚 API 是同步语义还是异步语义。很多“性能问题”其实是 API 误用导致的。有些 API 明明可以异步提交，默认实现却会做隐式同步；有些 API 在调试模式下会强制同步。写并发调度之前，先把这些 API 的真实行为摸清楚，否则后面所有优化都等于在沙子上建楼。最后，保持好性能回归测试。并发改动非常容易引发时隐时现的问题，我一般会在每次调度策略调整后，固定跑一组标准模型，记录端到端时延、设备占用率和事件数量。这三项数据的联动变化，能很快帮我判断改动方向是否正确。遇到问题时，把流数量调到 1，再逐步增加，往往能最快定位是哪条流的哪段同步出了问题。做 Runtime 调度没有银弹，硬件特性、模型结构、数据规模都会影响最终方案。但把“执行流驱动”这个思路扎扎实实落到任务图和事件机制上，再配合异步提交和合理的流分配，绝大多数深度计算场景都能拿到明显的性能收益。我的体会是，调度器的价值不在炫技，而在把并发这件事做得克制且精准。
1. 并发无上限是个假象：先看清深度计算硬件的真实执行模型1.1 从“线程并发”到“任务并发”的思维转换做深度计算 Runtime 这些年，我见过太多团队在“并发”这件事上栽跟头。最常见的想法是：任务能塞就塞，队列能开多深就开多深，仿佛只要同时提交的任务足够多，硬件就一定满载。这个直觉在 CPU 程序里大体成立，但放到深度计算场景就完全不对了。先界定一个概念：我们说的并发，不是 CPU 多线程并发，而是任务层面的并发。一个神经网络推理过程通常包含几十个算子，每个算子内部可能又有大量计算单元要干活。Runtime 要做的事，是把这些算子拆成一个个可提交的任务，按照依赖关系送入加速卡硬件队列。加速卡不同于 CPU，它天生是吞吐式设计——单个任务延迟未必低，但大量任务堆叠起来，计算单元始终有事可干，整体吞吐就上去了。所以这里有一个思维转换：Runtime 调度器的核心职责，不是“计算”本身，而是让计算任务在正确的时间、以正确的顺序、落在正确的硬件引擎上。判断一个 Runtime 好不好的关键，不是单算子跑得多快，而是整张计算图跑下来，硬件的执行单元有没有持续被喂满。“喂满”这件事，牵涉到硬件队列、执行流、事件同步、任务粒度，远比想象中复杂。1.2 硬件执行单元：一个任务在设备上到底经历了什么把视角降到一个任务上，我在设计 Runtime 时习惯把任务的设备侧生命周期分成四个阶段：CPU 侧创建任务：准备算子参数、分配输入输出内存、确定使用的流。提交阶段：把任务命令写入硬件可感知的内存队列，这是一个 CPU 到设备的消息传递过程。硬件调度阶段：设备端调度器从队列取命令，解析资源需求，分配到计算引擎（矩阵单元、向量单元、张量单元等）。完成写回：任务执行完毕后，硬件通过中断或状态标记通知 CPU。这段链路里藏着好几个并发瓶颈。第一个是同步提交。很多 Runtime 初版实现都在算子执行完后立刻调用设备同步等待，下一次提交要等这次完全结束才开始。结果是硬件干活的时间可能只有百分之几十，剩下的时间都在等待 CPU 发下一个任务。第二个是任务粒度。如果每个小算子都单独提交一次，命令本身的固定开销可能超过计算时间。比如一个简单的逐元素相加，计算可能只要微秒级，但命令创建、提交、解析的固定开销很可能同样在微秒级，这时候“极致并发”就变成“极致命令开销”了。我常用一个生活化类比：硬件就像一条工厂流水线，每个任务是一批待加工零件。如果工头每送一个零件就停下等这台机器完工再送下一个，流水线就废了。但如果工头把几万个小零件一个个单独送过去，传送带也会被堵死。好的调度是让零件按正确批次、正确顺序持续快速流入。1.3 并发“极致”的衡量标准“极致任务并发”到底怎么量化？我建议用三个指标，而不是只看设备利用率。第一是端到端时延，也就是一个请求从进来到结果出去的总时间，这是对用户最直接的指标。第二是气泡率，可以理解为硬件执行单元空闲的时间占比。第三是提交吞吐，单位时间内 Runtime 能向设备提交多少任务，这里反映的是 CPU 侧调度开销。三个指标经常是矛盾的。为了让硬件不空转，可能需要同时提交更多独立任务；但任务多了，提交开销增大，CPU 侧可能反而成为瓶颈。为了降低时延，应尽量缩减队列长度；但队列太短，硬件又可能出现气泡。所以“极致并发”不是一个绝对状态，而是在目标任务下，把三个指标优化到可接受区间。我在排查一个推理引擎的并发问题时，先看 profiler 输出的设备时间轴。如果发现明显的“锯齿”——设备忙一下、闲一下、忙一下、闲一下，基本可以断定是任务提交不够连续，或者依赖关系导致硬件在空等。此时优化的方向往往不是“再加并发任务”，而是“消除依赖上的等待”。这个思路后面会反复用到。2. 执行流（Stream）的语义边界：哪些任务真的能并行，哪些不能2.1 流是什么：硬件视角的操作序列主流加速卡 SDK 都提供“流”这个概念，英文叫 Stream 或 Queue。流本质上是一条按提交顺序执行的操作序列。同一流里的任务必须串行，不同流里的任务在无依赖的情况下允许并行。这个语义极其重要，但经常被错误理解。很多人以为“多开几条流就等于多几路并行”，于是把一个模型的一条执行路径上所有算子分散到几条流里，结果反而更慢了。原因很简单：流只是提供了并行的可能性，硬件是否真的并行，还要看任务之间有没有真实依赖、硬件资源是否足够、调度器的分配策略是否允许。深度计算场景的依赖主要有三类。第一类是数据依赖：下一个算子要读上一个算子的输出，这必须等待。第二类是内存依赖：两块张量可能共用一块内存池，前一个任务还没读完，内存就被后一个任务覆盖了。第三类是控制依赖：比如 if 分支后的算子，要等条件计算完才知道执行哪个分支。2.2 事件（Event）与同步：并行不是免费的流本身解决不了跨流依赖。假设算子 A 在流 1 上执行，算子 B 在流 2 上执行，但 B 需要 A 的输出，那就必须用事件机制：A 完成后发出一个事件标记，B 所在流等待这个事件后再执行。这是跨流同步的标准做法。事件同步的代价很容易被低估。每次等待事件，都可能让 CPU 侧阻塞或者让设备侧某个流空转。极端情况下会出现死锁：流 1 在等流 2 的事件，同时流 2 又在等流 1 的事件，两边都等不到，设备一直空转到超时。我做过一个实验：在一个模型里把所有算子放到 8 条流上，每条流之间用事件严格按依赖顺序串联。结果和单流执行几乎一模一样，因为所有任务最终还是被事件排成了一条全序链。流开得多，不代表并行度高；真正的并行度取决于“可重叠执行的任务”数量。2.3 深度计算场景下的流分配策略那么流到底怎么分配？我的经验是，先画出整张计算图，找出哪些部分天然可以重叠。深度计算里最常见的重叠场景有三类：通信与计算重叠：在分布式场景，权重同步通信可以和本地前向或反向计算同时进行。数据搬运与计算重叠：输入样本从内存拷到设备显存时，前一个 batch 的计算还在进行。并行分支重叠：某些大模型输入经过不同的注意力头或专家分支，各分支间没有依赖。这三类场景才配得上“独立流”。其余大多数算子之间的依赖都是线性的，老老实实排在同一流里但并不一定串行，因为同一流里的提交是 CPU 异步的，硬件忙的时候后续命令已排队，设备侧能连续消费，这本身就是一种流水线并发。所以我在设计流分配时遵循一个简单原则：能合则合，该分才分。把没有重叠机会的算子合并到少数几条流里，减少命令的分散度；把确实需要重叠的计算放不同流，再用事件精确同步交界面。有人问我到底开几条流合适，我的回答是：先根据重叠需求定流数上限，再根据硬件提交队列深度往下压，通常从 2 到 8 条之间试，不要一上来就开几十条。3. 硬件调度器与 Runtime 的配合：谁来决定“下一步执行什么”3.1 硬件调度队列的内部逻辑很多 Runtime 设计者把硬件调度器当黑盒，以为只要把命令丢进去就不用管了。实际上硬件队列的调度策略非常有限，大多数加速卡的设备队列本质上是近似 FIFO，也就是先提交先执行。这意味着 Runtime 提交任务的顺序，基本决定了硬件执行的大致顺序。硬件调度器能做的最多是在 FIFO 基础上做资源适配：当一个任务需要的执行单元忙不过来，它可能让另一个不冲突的任务先上。但这里有一个前提——所有候选任务必须在队列里可见。如果 Runtime 在等待某个事件完成前，根本没把后续任务提交到硬件队列，那么硬件调度器能做的事情就非常有限了，一旦前面的任务执行完，队列空了，硬件就只能空转。所以关键结论是：Runtime 的软件调度，负责在正确时机把候选任务提前送入硬件队列；硬件调度只负责在已可见任务之间做资源分配。真正决定并发上限的，是 Runtime 的“可见性管理”。3.2 优先级、抢占与时间片在深度计算里的作用深度计算任务并不总是同样重要。在线推理请求通常要求低延迟，训练任务则更看重吞吐；前台交互式任务要快速响应，后台预计算任务可以慢慢跑。这些诉求反映到 Runtime 层，就是优先级和多级队列设计。但硬件队列数量有限，优先级机制也未必完善。我见过一个做法：Runtime 维护多个软件任务队列，高优先级队列的任务在提交时优先进入硬件队列；低优先级任务只能在高优先级队列空闲时提交。这个框架简单有效，关键是提交循环要设计得好，不能让低优先级任务饿死。抢占在深度计算里更棘手。设备上的计算一旦开始执行，基本不能像 CPU 线程那样随时中断。如果是一个超大矩阵乘法占了执行单元几毫秒，高优先级的推理请求也只能在它后面排队。一个缓解思路是切分任务粒度：把大算子切分成多个小块任务，交错提交高优先级任务。比如一个 4096 大小的矩阵乘法，可以分成多个子块任务，每块执行完后的边界处，调度器都可以插入优先任务。代价是切分可能降低计算效率，因为矩阵分块会引入额外内存访问，这个就需要根据实际卡型做取舍了。3.3 一个实用的调度模型：从任务图到硬件命令的映射我在内部自研 Runtime 时，最终采用的调度链是这么一条：计算图分析：拿到模型结构，识别每个算子的输入输出、内存需求、所在设备。图切分：把算子按设备、按重叠需求切成小组。拓扑排序：确定所有任务的总序，保证数据依赖不被破坏。流分配：决定每个任务落在哪条流上。事件插入：在跨流依赖处插入事件，并建立等待关系。命令提交：把任务批量写入硬件队列。这套链路最大的好处是“一次分析、多次执行”。模型结构不变时，第 1 到第 5 步只需要做一次，把调度计划缓存起来。每次推理请求进来，只需要把输入地址填进计划，按预定义的流和事件关系提交命令即可。这比每次请求都重新分析计算图快一个数量级以上。为什么图模式比单算子逐发更有利于并发？因为单算子逐发时，每次只能基于当前算子的依赖做判断，无法看到后面几十个算子里有多少可以提前准备。图模式则能看到全局，可以提前把独立分支的命令推入硬件队列，形成持续的“命令洪流”，把硬件气泡压到最低。4. 驱动执行流的实战设计：一个深度计算 Runtime 的并发调度实现4.1 核心数据流设计我按一个最小可运行的 Runtime 结构来说明。核心数据结构就两样：任务节点任务图。任务节点包含：算子类型、输入输出张量引用、所在流 ID、依赖事件集合、完成事件集合。依赖事件集合表示这个任务开始前必须等待哪些事件，完成事件集合表示这个任务结束后会发出哪些事件。任务图就是节点和边的集合。边的含义可以分两种：数据边表示张量依赖，调度边表示流间同步。数据边决定拓扑顺序，调度边决定事件插入位置。我在实现时把这两种边分开存，因为数据边是模型自带的，调度边是流分配算法根据数据边推导出来的。struct TaskNode { int op_id; // 算子编号 int stream_id; // 流编号 std::vector<Event*> wait_events; // 开始前等待 std::vector<Event*> emit_events; // 完成后发出 std::vector<Tensor*> inputs; std::vector<Tensor*> outputs; }; struct TaskGraph { std::vector<TaskNode> nodes; // 数据边：指向依赖的上游节点 std::vector<std::vector<int>> data_edges; // 调度边：指向跨流等待的节点 std::vector<std::vector<int>> sync_edges; };4.2 流分配与事件插入的具体算法流分配的目的是把无依赖或弱依赖的任务分散到不同流上，让硬件可以重叠执行。我使用的是一种贪心启发式，思路很简单：遍历拓扑排序的任务，对每个任务尝试分配到某个流，使得该任务所需的依赖事件已经在该流上满足。听起来抽象，我拆解一下实现流程：为每条流维护一个“最后执行节点”和“最后发出事件”。遍历任务时，先找出所有尚未满足的上游节点事件。如果某个任务所有上游都在同一流，直接放到那条流的末尾，不增加事件。如果上游分散在多条流，则选择一个“最近完成时间期望最小”的流，并在该流上插入等待事件，在上游流上插入发出事件。如果某条流已经排了太多任务，后续任务又无依赖，则优先放到空闲流，形成负载均衡。伪代码大致长这样：void AssignStreamAndInsertEvents(TaskGraph& graph) { auto topo = TopoSort(graph); for (int node_id : topo) { auto& node = graph.nodes[node_id]; int best_stream = -1; int best_cost = INT_MAX; for (int s = 0; s < num_streams; s++) { int cost = EstimateSyncCost(node, s); // 计算跨流事件数量 if (cost < best_cost) { best_cost = cost; best_stream = s; } if (cost == 0) break; // 无跨流依赖，直接选这条流 } node.stream_id = best_stream; InsertSyncEvents(graph, node); // 根据上游流插入事件 } }EstimateSyncCost的计算方式是：统计该任务所有上游节点所在流与候选流的交集。上游全在当前流里，代价为 0；有几个上游在其他流，就要插入几组事件。事件插入总会有开销，所以算法天然倾向于把一条链上的任务排在同一个流里，只有在并行机会明显时才跨流，这正好符合前面说的“能合则合，该分才分”。4.3 流水线重叠与异步提交的落地有了任务图和流分配，接下来要解决 CPU 侧提交的异步性。我在早期版本里犯过一个错误：提交线程在把任务命令写入硬件队列后，立刻查一次事件状态，用来决定后续任务是否已经可以提交。结果每次查询都要和硬件打交道，CPU 侧很快就成了瓶颈。正确的做法是：CPU 侧提交线程只负责“按计划把命令写入硬件队列”，完全不等待完成状态。等待逻辑通过事件机制由硬件去处理。也就是说，Runtime 的任务提交是纯异步的，事件的发出和等待由设备侧完成，CPU 线程可以连续不断地产出命令，形成一个生产-消费环形队列，把任务命令批量推给硬件。这样做后效果非常明显。以单流的连续卷积链为例，不修改任何算子，只把提交从同步改成异步，设备利用率就可以提升近一倍。原因在于，原先 CPU 在每次算子后等待硬件完成，白白浪费了几百微秒；改后 CPU 持续提交，硬件流水线基本没有气泡。4.4 实测对比与效果我在自研 Runtime 上做了一组对比测试，使用一个有 20 多个算子的典型视觉模型，输入固定尺寸。三种执行方式：方案 A：逐算子同步执行，每个算子执行完都等待完成。方案 B：逐算子异步提交，使用单条流。方案 C：任务图分析后多流异步提交，自动插入事件。在我使用的加速卡上，端到端时延大致是 A 的 1.4 倍于 B，B 的 1.25 倍于 C。也就是说，从 A 到 C 整体优化了超过 40% 的时延。其中最大提升来自异步提交，其次来自多流重叠。这样的测试结果和很多公开框架的优化趋势一致。需要特别说明的是，具体倍速高度依赖模型结构和硬件类型。如果一个模型本身几乎全是串行算子，多流优化的空间就很小，C 比 B 提升可能只有几个百分点；如果模型有大量独立分支，C 比 B 的差距会拉到 30% 以上。所以我的建议是，先做 profiler 看时间轴，确认有没有明显的可重叠区域，再投入精力做多流调度。5. 真正难的不是“加流”，而是这几个细节5.1 内存分配与生命周期对并发的隐形限制当任务真正并行执行后，内存管理会变成新的约束。张量生命周期必须被精确跟踪：一个张量可能在流 1 上被写入，同时在流 2 上被读取，两边的任务必须同步在正确的事件上，否则就会出现数据竞争。更隐蔽的是内存池复用问题。为了减少分配开销，Runtime 通常会维护张量内存池，一个张量用完就归还，后续张量复用同一块显存。但如果并发任务变多，内存生命周期难以准确判断，归还时机就变得模糊。我见过一个案例：两个独立分支的算子在两条流上运行，输出张量大小相近，内存池把它们的输出指向同一块显存，结果后写的任务覆盖了先写的任务，模型结果完全错误。解决办法是采用“按流顺序分配”的内存池策略：每个流维护自己的分配位置，回收时依赖事件确认所有引用该内存的任务都已完成。这会让内存池设计复杂很多，但这是并发调度不可绕过的问题。5.2 小算子的噩梦：命令开销淹没计算收益深度计算模型里大量存在逐元素加法、激活函数、归一化这类小算子。单个算子计算时间只有几微秒，但提交命令的固定开销可能也有几微秒。如果完全依赖流调度，就算并行调度做得再好，命令开销也降不下来。这类问题的正解在 Runtime 上层，也就是算子融合。把多个小算子合成一个更大的算子，减少任务数量，降低整体命令开销。这块工作不是调度器能替代的，它需要分析算子的构成和数据类型。比如卷积后接偏置加再接激活，三个算子可以合并为一个自定义算子，命令数量直接少了三分之二。5.3 从一机多卡到多机：执行流驱动机制扩展到分布式单机多卡场景里，跨卡数据传输通常通过设备间点对点通信完成，通信任务的执行流语义和计算任务类似，可以投递到通信相关的流上。这里最容易出问题的是同步粒度：如果每个张量传输都插入事件，事件数量和同步开销会很大；如果大批量传输后才同步，又可能让计算流长时间等待。我的实践是，把多卡同步点尽量放在“计算边界”。比如在每个梯度聚合开始时，一次性等待所有本地计算完成，然后启动通信；通信未完成时，下一阶段计算可以先启动与通信无关的部分。这个思路可以扩展到多机场景，只不过网络通信的延迟更大，更需要把通信与计算放在不同的流上，并且提前批量提交通信任务。5.4 我的几点实操体会先说最核心的一条：不要为了并发而并发。我见过太多团队把“多流调度”当作目标，加了十几条流，跑出来性能没涨，反而引入一堆内存同步问题。正确顺序永远是：先 profile，把时间轴拉出来看，找到硬件空闲的具体位置；再问为什么空，是 CPU 提交慢，还是任务依赖等得太久，还是内存分配阻塞；最后才决定用流、事件还是融合去解决。第二条体会是，执行流和事件不要用成“锁”。有些 Runtime 实现里，事件等待被当作线程同步工具来用，甚至拿事件去保护一段 CPU 代码的临界区，这是把硬件事件机制用错了地方。事件是设备侧任务的执行条件，不是 CPU 侧的互斥锁。CPU 线程之间的同步应该用普通的条件变量和互斥量，让事件专心处理设备侧依赖关系。第三条体会比较隐性：如果调用硬件厂商的底层 API，一定要先搞清楚 API 是同步语义还是异步语义。很多“性能问题”其实是 API 误用导致的。有些 API 明明可以异步提交，默认实现却会做隐式同步；有些 API 在调试模式下会强制同步。写并发调度之前，先把这些 API 的真实行为摸清楚，否则后面所有优化都等于在沙子上建楼。最后，保持好性能回归测试。并发改动非常容易引发时隐时现的问题，我一般会在每次调度策略调整后，固定跑一组标准模型，记录端到端时延、设备占用率和事件数量。这三项数据的联动变化，能很快帮我判断改动方向是否正确。遇到问题时，把流数量调到 1，再逐步增加，往往能最快定位是哪条流的哪段同步出了问题。做 Runtime 调度没有银弹，硬件特性、模型结构、数据规模都会影响最终方案。但把“执行流驱动”这个思路扎扎实实落到任务图和事件机制上，再配合异步提交和合理的流分配，绝大多数深度计算场景都能拿到明显的性能收益。我的体会是，调度器的价值不在炫技，而在把并发这件事做得克制且精准。