来看一个最小例子：

代码语言：javascript

AI代码解释

task<int> foo() {
    co_await some_async_op();
    co_return 42;
}

编译器看到 co_await / co_return / co_yield，会把函数 foo 转换成一个状态机对象。这个对象里包含：

• PromiseType：协程的承诺（promise），负责管理协程的返回值、异常处理、生命周期。
• Handle：std::coroutine_handle，一个可以操控协程的指针。它能恢复、销毁、查询协程状态。
• 栈帧：不像线程那样分配大块栈内存，协程只为必要的局部变量分配空间，因此更轻量。

运行时，co_await 会触发三个钩子：

1. await_ready：是否需要挂起。
2. await_suspend：如果挂起，协程的上下文保存起来，交给调度器。
3. await_resume：恢复协程时，从这里继续执行。

这意味着协程切换完全在用户态完成，不像线程那样进入内核态，速度快到可以忽略。

一句话总结：协程是「编译器帮你写好的状态机」，既保留了同步逻辑的线性可读性，又具备异步执行的高性能。

---

二、协程在推理引擎中的角色

在 AI 推理引擎里，协程能承担几个核心职责。

1. 请求级调度

传统线程池模式下，每个请求对应一个线程。当并发数达到上万时，线程切换和内存占用会直接把系统拖垮。

协程提供了一种轻量方式：每个请求一个协程。

• CPU 上只有少量工作线程（比如 8~16 个），跑一个 event loop。
• 每个推理请求进来时，被包装成协程对象，挂到调度器上。
• 当协程 co_await 网络 I/O 或 GPU kernel 时，线程可以去干别的事情。

这样，上万请求也能被几十个线程高效调度，内存占用和上下文切换开销几乎不变。

2. 流水线化算子执行

一个推理模型通常是一个有向无环图（DAG），每个节点是算子，节点间有数据依赖。

在传统实现里，需要一个任务图调度器，复杂又难维护。

协程让代码像这样写：

代码语言：javascript

AI代码解释

co_await conv2d(input);
co_await relu();
co_await matmul(weights);

逻辑顺序写下来，底层却是异步流水线执行。算子一旦完成，就能自然地激活下游算子。

这种「线性代码 + DAG 并行」的结合方式，大大简化了调度逻辑。

3. 异步 I/O 与 GPU 协同

推理任务往往涉及：

• 从磁盘或网络读输入张量
• 把张量搬到 GPU 显存
• 执行 CUDA kernel
• 把结果搬回 CPU，再通过 RPC 返回

传统方式要么写回调，要么阻塞线程。协程让这条链路自然串起来：

代码语言：javascript

AI代码解释

auto input = co_await read_from_network(); 
auto gpu_input = co_await dma_to_gpu(input); 
auto output = co_await run_kernel(gpu_input); 
co_await send_to_client(output);

逻辑看似同步，但实际上每一步都是异步 I/O，CPU 不会被阻塞。

4. 错误处理与取消

协程支持异常传播，写法比回调清晰得多：

代码语言：javascript

AI代码解释

auto input = co_await read_from_network();
auto gpu_input = co_await dma_to_gpu(input);
auto output = co_await run_kernel(gpu_input);
co_await send_to_client(output);

此外，协程天然支持取消。比如请求超时，可以直接 handle.destroy()，比回调式的「多层 if 判断」优雅得多。

5. 零拷贝与内存优化

推理中最大的开销之一是 数据拷贝：

• RPC 框架 buffer → CPU 内存
• CPU → GPU 显存
• GPU → CPU → RPC 返回

多一次拷贝，就可能多几十甚至上百微秒。

协程虽然不能直接减少拷贝，但它能让 零拷贝 buffer 的使用更自然。

• 如果 RPC 框架支持 slice buffer 或 RDMA buffer，我们可以 co_await 一个 buffer view，而不是复制一份数据。
• GPU DMA 操作可以直接 await，不阻塞 CPU。

最终效果是：逻辑代码清晰，数据路径高效。