1. 为什么要在 softroce 上折腾带宽和延迟softroceSoft-RDMA over Ethernet是把 RDMA 的 verbs 语义用软件实现在普通以太网卡上的一套方案内核里对应的模块叫rdma_rxe。它最大的价值是你不需要买昂贵的 RoCE 网卡用两台普通机器加一块普通网卡就能把 RDMA 的编程接口、队列对QP、完成队列CQ这套东西跑起来。对于要验证分布式存储、MPI 集合通信、或者自己写 verbs 程序的开发者来说softroce 是一个成本极低的实验床。但问题也很直接软件实现意味着 CPU 要参与大量数据搬运带宽和延迟跟硬件 RoCE 差一个数量级。所以真正要做的不是能不能通而是通了多少、延迟多少、瓶颈在哪。这就必须有一套可复制的配置骨架加上标准的perftest测试命令再配合一个稳定的模型/API 通道来辅助你查文档、生成脚本、解读结果。这篇就按这个思路走先把 softroce 两端配好用ib_send_bw和ib_send_lat跑出带宽和延迟数字再讲怎么判读结果、怎么排掉最常见的坑。中间涉及查参数、生成测试脚本、对比不同 MTU 下的表现时我会用 TaoToken 的统一 Key 走 API 通道把模型对话和编码辅助串起来省得在多个平台之间来回切。适合谁看手里有两台 Linux 机器物理机或虚拟机都行、想快速搭一个 RDMA 软实现验证环境、并且需要拿到可对比的带宽/延迟基线的开发者。下面所有命令都可以直接复制。2. TaoToken 前置统一 Key 与 API 通道准备在开始配 softroce 之前先把辅助通道准备好。原因很实际softroce 的调参涉及大量内核模块参数、perftest选项、MTU 与 GID 索引的对应关系靠记忆很容易出错。用 TaoToken 的统一 Key可以在一个入口下调用不同模型来做三件事——查ib_send_bw参数含义、生成两端对齐的测试脚本、把测试输出的原始数字翻译成结论。TaoToken 的定位是统一模型接入层官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。它的好处是 Key 统一不用为每个模型单独申请和记额度对于边配环境边查资料这种碎片化场景比较顺手。具体操作分两步。第一步进控制台创建 API Key控制台地址https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content创建后拿到形如sk-xxxx的 Key先存到环境变量里后面所有请求都复用它export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api第二步验证通道是否可用。用一条最小的对话请求确认 Key 生效避免后面调模型时才发现鉴权失败curl -s $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 用一句话说明 ib_send_bw 的 -F 参数作用}], max_tokens: 200 }返回里能看到choices[0].message.content就说明通道正常。如果你更习惯在网页里直接问模型对话入口是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 效果一样只是不用自己拼 curl。注意Key 只放在环境变量或本地配置里不要写进会提交到仓库的脚本。测试脚本里用$TAOTOKEN_API_KEY引用即可。如果你后面要长期跑编码辅助、批量生成测试脚本可以看下 Coding Plan 的额度方式https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入细节和参数说明统一在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。3. softroce 可复制配置骨架这一节是全文的技术核心。目标是把两台机器下面叫 server 和 client都配成能用rxe设备跑 verbs 的状态。假设两块网卡分别是ens1f0server和ens1f1client实际替换成你自己的接口名。3.1 安装依赖与加载内核模块两台机器都要做。perftest提供ib_send_bw、ib_send_lat等工具rdma-core提供用户态库# Ubuntu / Debian sudo apt update sudo apt install -y rdma-core perftest iproute2 # RHEL / CentOS / Rocky sudo dnf install -y rdma-core perftest iproute加载 softroce 内核模块并确认设备出现sudo modprobe rdma_rxe sudo rdma link add rxe0 type rxe netdev ens1f0 rdma link show正常输出类似link rxe0/1 state ACTIVE physical_state LINK_UP netdev ens1f0看到state ACTIVE和LINK_UP才算成功。如果rdma link add报Operation not supported多半是内核没编rdma_rxe用modinfo rdma_rxe确认一下。3.2 关键参数MTU 与 GID 索引softroce 的性能对 MTU 非常敏感。默认 1500 时带宽会被小包拖死建议两端网卡都调到 9000前提是链路中间设备也支持直连或同一交换机下一般没问题sudo ip link set ens1f0 mtu 9000 ip link show ens1f0 | grep mtuGID 索引决定走 IPv4 还是 IPv6 映射。softroce 下通常-i 1对应 RoCEv2 的 IPv4 GID。用下面命令确认show_gids输出里找到rxe0那一行记下v2且是 IPv4 对应的索引号后面-i参数就填它。多数环境是 1但不要想当然以show_gids为准。3.3 用 TaoToken 生成两端对齐的测试脚本手工敲两端命令容易把参数写歪。我一般让模型按固定模板生成一份脚本保证 server 和 client 的-d、-i、-n、-F完全一致。请求示例curl -s $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 生成 softroce 带宽和延迟测试脚本设备 rxe0GID 索引 1消息数 10000输出用 Gb/sserver 和 client 参数必须一致client 需要传 server_ip 参数}], max_tokens: 800 }拿到脚本后自己核对一遍参数再执行。核心命令其实就是下面这几条可以直接用。4. 验证请求与成功结果判读4.1 带宽测试ib_send_bwserver 端先起监听ib_send_bw -n 10000 -d rxe0 -i 1 -F --report_gbitsclient 端连过去ib_send_bw -n 10000 -d rxe0 -i 1 -F --report_gbits server_ip参数含义-n 10000是消息数-d rxe0指定设备-i 1是 GID 索引-F允许在无 CPU 亲和性限制下运行--report_gbits让结果以 Gb/s 输出而不是 MB/s。成功时 client 端会打印类似--------------------------------------------------------------------------------------- #bytes #iterations BW peak[Gb/sec] BW average[Gb/sec] MsgRate[Mpps] 65536 10000 9.87 9.72 0.018535 ---------------------------------------------------------------------------------------BW average就是你要的带宽数字。softroce 在 9000 MTU、单 QP 下普通千兆网卡大概 0.9 Gb/s 左右万兆网卡能到 6–9 Gb/s具体取决于 CPU 主频和内存带宽。如果只有几百 Mb/s先查 MTU 是不是没生效。4.2 延迟测试ib_send_latserverib_send_lat -n 10000 -d rxe0 -i 1 -F --report_gbitsclientib_send_lat -n 10000 -d rxe0 -i 1 -F --report_gbits server_ip成功输出#bytes #iterations t_min[usec] t_max[usec] t_typical[usec] 2 10000 18.42 95.31 19.87t_typical是典型往返延迟。softroce 因为是软件路径单次往返通常在 15–40 微秒比硬件 RoCE 的 1–2 微秒高一个量级这是正常的不要拿硬件指标来对标。4.3 结果判读的三个要点第一看BW average是否随 MTU 变化。把两端 MTU 从 1500 改到 9000 再跑一次带宽应该有明显提升否则说明 MTU 没真正生效或链路中间有设备降了 MTU。第二看延迟的t_max和t_typical差距。如果t_max是t_typical的十几倍说明有抖动可能是 CPU 被其他进程抢占用taskset把测试进程绑到固定核上再测。第三多 QP 对比。加-q 4跑多队列观察带宽是否线性增长。softroce 下多 QP 能提升吞吐但受限于单核软中断处理能力增长往往不是线性的这个拐点就是你的环境瓶颈。5. 本篇常见错排查5.1 rdma link add 失败报Operation not supported或No such device。先modinfo rdma_rxe确认模块存在再确认网卡名拼写正确用ip link看。如果网卡是虚拟接口比如某些容器 vethsoftroce 可能不支持换成物理网卡或 macvlan。5.2 ib_send_bw 卡在 Waiting for clientserver 起来了但 client 连不上。九成是防火墙挡了 RDMA CM 的端口或者server_ip填错。先ping通再确认两端rdma link show都是 ACTIVE。softroce 走的是 UDP 4791 端口检查一下sudo ss -ulnp | grep 47915.3 带宽只有几百 Mb/s最常见原因是 MTU 没生效。用ip link show iface | grep mtu在两端都确认是 9000。另一个原因是 GID 索引选错走了 IPv6 路径导致额外开销用show_gids重新核对-i的值。5.4 延迟忽高忽低CPU 频率调节和中断亲和性都会影响。测试前把 CPU governor 设成 performancesudo cpupower frequency-set -g performance再用taskset -c 2 ib_send_lat ...把进程绑到固定核抖动会明显下降。5.5 用 TaoToken 辅助排障遇到不认识的报错把原始输出贴给模型让它给出排查顺序比自己在文档里翻快很多。请求时把rdma link show、show_gids、ib_send_bw的完整输出一起带上模型能直接定位到是 GID 问题还是 MTU 问题。通道还是用前面那个统一 Key模型对话入口 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 直接可用。6. 把配置和验证串成闭环整套流程走下来你手里应该有两组数字一组是ib_send_bw的BW average一组是ib_send_lat的t_typical。这两个数字就是你后续所有优化的基线。改一个参数MTU、QP 数、CPU 绑定就重跑一次对比基线才知道改动有没有用。如果后面要把这套环境接到自动化测试里或者用模型批量生成不同参数组合的测试脚本走 API 通道会更顺接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。长期做编码和 Agent 辅助的话Coding Plan 的额度方式可以看 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个实操建议softroce 的瓶颈几乎总在 CPU 软中断上与其反复调perftest参数不如先用mpstat -P ALL 1看一眼测试时哪个核跑满了把那个核上的其他负载挪走带宽往往立刻上一个台阶。这比换任何参数都直接。
softroce 带宽与延迟实测：用 TaoToken 统一 Key 跑通配置与验证
1. 为什么要在 softroce 上折腾带宽和延迟softroceSoft-RDMA over Ethernet是把 RDMA 的 verbs 语义用软件实现在普通以太网卡上的一套方案内核里对应的模块叫rdma_rxe。它最大的价值是你不需要买昂贵的 RoCE 网卡用两台普通机器加一块普通网卡就能把 RDMA 的编程接口、队列对QP、完成队列CQ这套东西跑起来。对于要验证分布式存储、MPI 集合通信、或者自己写 verbs 程序的开发者来说softroce 是一个成本极低的实验床。但问题也很直接软件实现意味着 CPU 要参与大量数据搬运带宽和延迟跟硬件 RoCE 差一个数量级。所以真正要做的不是能不能通而是通了多少、延迟多少、瓶颈在哪。这就必须有一套可复制的配置骨架加上标准的perftest测试命令再配合一个稳定的模型/API 通道来辅助你查文档、生成脚本、解读结果。这篇就按这个思路走先把 softroce 两端配好用ib_send_bw和ib_send_lat跑出带宽和延迟数字再讲怎么判读结果、怎么排掉最常见的坑。中间涉及查参数、生成测试脚本、对比不同 MTU 下的表现时我会用 TaoToken 的统一 Key 走 API 通道把模型对话和编码辅助串起来省得在多个平台之间来回切。适合谁看手里有两台 Linux 机器物理机或虚拟机都行、想快速搭一个 RDMA 软实现验证环境、并且需要拿到可对比的带宽/延迟基线的开发者。下面所有命令都可以直接复制。2. TaoToken 前置统一 Key 与 API 通道准备在开始配 softroce 之前先把辅助通道准备好。原因很实际softroce 的调参涉及大量内核模块参数、perftest选项、MTU 与 GID 索引的对应关系靠记忆很容易出错。用 TaoToken 的统一 Key可以在一个入口下调用不同模型来做三件事——查ib_send_bw参数含义、生成两端对齐的测试脚本、把测试输出的原始数字翻译成结论。TaoToken 的定位是统一模型接入层官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。它的好处是 Key 统一不用为每个模型单独申请和记额度对于边配环境边查资料这种碎片化场景比较顺手。具体操作分两步。第一步进控制台创建 API Key控制台地址https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentAPI Keys 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content创建后拿到形如sk-xxxx的 Key先存到环境变量里后面所有请求都复用它export TAOTOKEN_API_KEYsk-你的key export TAOTOKEN_BASE_URLhttps://taotoken.net/api第二步验证通道是否可用。用一条最小的对话请求确认 Key 生效避免后面调模型时才发现鉴权失败curl -s $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 用一句话说明 ib_send_bw 的 -F 参数作用}], max_tokens: 200 }返回里能看到choices[0].message.content就说明通道正常。如果你更习惯在网页里直接问模型对话入口是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 效果一样只是不用自己拼 curl。注意Key 只放在环境变量或本地配置里不要写进会提交到仓库的脚本。测试脚本里用$TAOTOKEN_API_KEY引用即可。如果你后面要长期跑编码辅助、批量生成测试脚本可以看下 Coding Plan 的额度方式https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入细节和参数说明统一在文档里https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。3. softroce 可复制配置骨架这一节是全文的技术核心。目标是把两台机器下面叫 server 和 client都配成能用rxe设备跑 verbs 的状态。假设两块网卡分别是ens1f0server和ens1f1client实际替换成你自己的接口名。3.1 安装依赖与加载内核模块两台机器都要做。perftest提供ib_send_bw、ib_send_lat等工具rdma-core提供用户态库# Ubuntu / Debian sudo apt update sudo apt install -y rdma-core perftest iproute2 # RHEL / CentOS / Rocky sudo dnf install -y rdma-core perftest iproute加载 softroce 内核模块并确认设备出现sudo modprobe rdma_rxe sudo rdma link add rxe0 type rxe netdev ens1f0 rdma link show正常输出类似link rxe0/1 state ACTIVE physical_state LINK_UP netdev ens1f0看到state ACTIVE和LINK_UP才算成功。如果rdma link add报Operation not supported多半是内核没编rdma_rxe用modinfo rdma_rxe确认一下。3.2 关键参数MTU 与 GID 索引softroce 的性能对 MTU 非常敏感。默认 1500 时带宽会被小包拖死建议两端网卡都调到 9000前提是链路中间设备也支持直连或同一交换机下一般没问题sudo ip link set ens1f0 mtu 9000 ip link show ens1f0 | grep mtuGID 索引决定走 IPv4 还是 IPv6 映射。softroce 下通常-i 1对应 RoCEv2 的 IPv4 GID。用下面命令确认show_gids输出里找到rxe0那一行记下v2且是 IPv4 对应的索引号后面-i参数就填它。多数环境是 1但不要想当然以show_gids为准。3.3 用 TaoToken 生成两端对齐的测试脚本手工敲两端命令容易把参数写歪。我一般让模型按固定模板生成一份脚本保证 server 和 client 的-d、-i、-n、-F完全一致。请求示例curl -s $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 生成 softroce 带宽和延迟测试脚本设备 rxe0GID 索引 1消息数 10000输出用 Gb/sserver 和 client 参数必须一致client 需要传 server_ip 参数}], max_tokens: 800 }拿到脚本后自己核对一遍参数再执行。核心命令其实就是下面这几条可以直接用。4. 验证请求与成功结果判读4.1 带宽测试ib_send_bwserver 端先起监听ib_send_bw -n 10000 -d rxe0 -i 1 -F --report_gbitsclient 端连过去ib_send_bw -n 10000 -d rxe0 -i 1 -F --report_gbits server_ip参数含义-n 10000是消息数-d rxe0指定设备-i 1是 GID 索引-F允许在无 CPU 亲和性限制下运行--report_gbits让结果以 Gb/s 输出而不是 MB/s。成功时 client 端会打印类似--------------------------------------------------------------------------------------- #bytes #iterations BW peak[Gb/sec] BW average[Gb/sec] MsgRate[Mpps] 65536 10000 9.87 9.72 0.018535 ---------------------------------------------------------------------------------------BW average就是你要的带宽数字。softroce 在 9000 MTU、单 QP 下普通千兆网卡大概 0.9 Gb/s 左右万兆网卡能到 6–9 Gb/s具体取决于 CPU 主频和内存带宽。如果只有几百 Mb/s先查 MTU 是不是没生效。4.2 延迟测试ib_send_latserverib_send_lat -n 10000 -d rxe0 -i 1 -F --report_gbitsclientib_send_lat -n 10000 -d rxe0 -i 1 -F --report_gbits server_ip成功输出#bytes #iterations t_min[usec] t_max[usec] t_typical[usec] 2 10000 18.42 95.31 19.87t_typical是典型往返延迟。softroce 因为是软件路径单次往返通常在 15–40 微秒比硬件 RoCE 的 1–2 微秒高一个量级这是正常的不要拿硬件指标来对标。4.3 结果判读的三个要点第一看BW average是否随 MTU 变化。把两端 MTU 从 1500 改到 9000 再跑一次带宽应该有明显提升否则说明 MTU 没真正生效或链路中间有设备降了 MTU。第二看延迟的t_max和t_typical差距。如果t_max是t_typical的十几倍说明有抖动可能是 CPU 被其他进程抢占用taskset把测试进程绑到固定核上再测。第三多 QP 对比。加-q 4跑多队列观察带宽是否线性增长。softroce 下多 QP 能提升吞吐但受限于单核软中断处理能力增长往往不是线性的这个拐点就是你的环境瓶颈。5. 本篇常见错排查5.1 rdma link add 失败报Operation not supported或No such device。先modinfo rdma_rxe确认模块存在再确认网卡名拼写正确用ip link看。如果网卡是虚拟接口比如某些容器 vethsoftroce 可能不支持换成物理网卡或 macvlan。5.2 ib_send_bw 卡在 Waiting for clientserver 起来了但 client 连不上。九成是防火墙挡了 RDMA CM 的端口或者server_ip填错。先ping通再确认两端rdma link show都是 ACTIVE。softroce 走的是 UDP 4791 端口检查一下sudo ss -ulnp | grep 47915.3 带宽只有几百 Mb/s最常见原因是 MTU 没生效。用ip link show iface | grep mtu在两端都确认是 9000。另一个原因是 GID 索引选错走了 IPv6 路径导致额外开销用show_gids重新核对-i的值。5.4 延迟忽高忽低CPU 频率调节和中断亲和性都会影响。测试前把 CPU governor 设成 performancesudo cpupower frequency-set -g performance再用taskset -c 2 ib_send_lat ...把进程绑到固定核抖动会明显下降。5.5 用 TaoToken 辅助排障遇到不认识的报错把原始输出贴给模型让它给出排查顺序比自己在文档里翻快很多。请求时把rdma link show、show_gids、ib_send_bw的完整输出一起带上模型能直接定位到是 GID 问题还是 MTU 问题。通道还是用前面那个统一 Key模型对话入口 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 直接可用。6. 把配置和验证串成闭环整套流程走下来你手里应该有两组数字一组是ib_send_bw的BW average一组是ib_send_lat的t_typical。这两个数字就是你后续所有优化的基线。改一个参数MTU、QP 数、CPU 绑定就重跑一次对比基线才知道改动有没有用。如果后面要把这套环境接到自动化测试里或者用模型批量生成不同参数组合的测试脚本走 API 通道会更顺接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。长期做编码和 Agent 辅助的话Coding Plan 的额度方式可以看 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个实操建议softroce 的瓶颈几乎总在 CPU 软中断上与其反复调perftest参数不如先用mpstat -P ALL 1看一眼测试时哪个核跑满了把那个核上的其他负载挪走带宽往往立刻上一个台阶。这比换任何参数都直接。
