鄂奎阿1. RDMA的send/recv契约：为什么发送端会卡在对端recv上
很多刚接触RDMA的人都会遇到一个看似诡异的现象：明明网卡状态正常、链路up、IP能ping通，但你的send操作就是发不出去，或者发出去了对端收不到，程序卡在某一次send调用上半天不返回。翻日志一看，报的是retry exceeded或者timeout。这时候如果你去查RDMA的语义，会发现一个和TCP完全不同的核心约束：RDMA的send/recv是"显式握手"的，发送端必须知道接收端已经提前post好了一个recv缓冲区，数据才能真正从网卡发出去。
为什么会有这个限制？本质原因是RDMA网卡要绕过CPU和内核，直接做内存到内存的数据搬运。既然CPU不参与每笔数据的拷贝和转发，那数据到达对端以后放到哪里去，就必须在数据到达之前就确定。TCP的接收缓冲区是内核维护的、动态增长的，所以发送方只要把数据扔给内核就行，内核会替接收方把数据收进socket缓冲区，后续应用再取走。RDMA没有这个"中间人"，接收端的RDMA网卡必须提前知道"某个QPair上即将到达的数据，应该写到哪块内存地址"，这个信息就是接收端应用程序prepost到网卡队列里的recv work request。
换句话说，RDMA的send不是"发出去就行了"，而是"发出去且对端有地方放"。如果对端没有预先post recv，发送端的网卡会一直重试（假设启用了RTS/RNS重传机制），最终在超时后报错。这类行为在高性能计算里是不能接受的，因为HPC场景中通信动辄上千次迭代，任何一次阻塞都可能让整机训练或并行计算停摆。
那问题就来了：NCCL和MPI这些上层通信库，最终都要落到RDMA的send/recv原语上，它们是怎么解决"发送方知道接收方已就绪"这个问题的？这背后其实代表了两种完全不同的设计哲学。MPI走的是"库内统一调度、显式credit管理"的路线，而NCCL走的是"集合通信原语天然自带同步边界"的路线。理解清楚这两套思路，你不仅能把MPI和NCCL的性能差异想明白，以后写基于RDMA的自研通信层时，也不会再踩"recv没post就send"这种底层坑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. MPI的解法：Credit机制与MPI_Probe的"非对称同步"
2.1 MPI对单个send/recv的语义保障：匹配与credit
先说MPI。MPI_Send和MPI_Recv这一对接口是教科书里最经典的例子，但很多人没意识到的是，MPI标准本身并不保证MPI_Send一定不会阻塞。它把发送端的行为分成了"标准模式"（standard mode）、"缓冲模式"（buffered mode）和"就绪模式"（ready mode）。标准模式下，库可以选择先把数据缓冲起来立即返回，也可以选择等收到接收端的握手确认后再返回，具体行为由实现决定。这个"不确定"其实是MPI库留给自己做性能优化的空间。
在底层实现中，主流的MPI库（开源的OpenMPI、MPICH以及商业的Intel MPI）基于RDMA传输时，普遍采用credit（信用）机制来保证发送端不会在对端还没post recv的情况下就开始传输数据。这个credit机制很像网络协议里的滑动窗口：接收端每post一个recv请求，就会给发送端增多一个可用credits；发送端每发送一笔数据，就消耗一个credit；当credit归零时，发送端必须停下来等待接收端继续post新的recv请求。
这里要特别澄清一个常见误解：credit机制不是在发送端和接收端之间额外发控制消息来询问"你有没有post recv"，而是接收端在post recv的时候，会通过一个独立的、预先建立好的控制通道（通常也是RDMA的send/recv或者不可靠数据报UD）把credit信息异步通知给发送端。发送端维护的是本地的credit计数值，它不需要主动轮询接收端状态，只在credit耗尽时"没有资格"继续发送。
这就回答了一个关键问题：MPI是怎么知道对端准备好没有的？答案不是"知道"，而是"信任credit计数"。只要本地还有剩余credit，MPI就认为对端肯定有已post的recv在等待，于是放心地组织数据发送；如果credit已经归零，MPI就把send请求挂起，或者切换到内部缓冲路径，等后续credit到达再继续。这套机制的巧妙之处在于，它把"对端是否就绪"这个实时状态问题，转化成了本地计数器的管理问题，从而避免了每次send都需要一次额外的RTT往返确认。
2.2 MPI_Recv先发制人与MPI_Probe的辅助作用
链路层是credit在保驾护航，而应用层的编程模型也天然配合了这种机制。MPI的核心编程范式是"接收端先post recv，发送端后发数据"，即同步模式中的接收先行原则。只要你严格按照MPI的语义写代码——先MPI_Recv（或MPI_Irecv）再让对端MPI_Send——那么credit的增加永远会先于数据发送权的消耗，发送自然永远不会卡在对端未就绪上。
但实际工程中，接收端不一定总能提前知道要收多少数据、先从谁那里收。比如你做动态负载均衡，进