Leoda

2026-Q3

21 min read

2026-09-21（周一） 至 2026-09-27（周日）

🧠 本周记录

  • [ ]

🚀 本周TODO

证明 实际值还有多少能到理想值，理想值还有多少可能到理论值

  • flagcx 采集真实推理的数据量和带宽 ✅ 2026-09-23
  • benchmark 用相同数据范围测试

starbridge 在 H200 验证最新合入 pr 后的代码的功能和性能

2026-09-14（周一） 至 2026-09-20（周日）

🧠 本周记录

  • [ ]

🚀 本周TODO

  • Fix mooncake 网卡问题， 跑通 flagcx/mooncake 基线， PTD 分析 flagcx， 确定 64k 问题为：GLM-5.2 的 MLA KV 在 TP 间复制不切分，decode 实例只有 198k tokens 容量， 跑通 1p2d并分析结果。 ✅ 2026-09-17
  • 等 C 组 2MB 的数据结论 ✅ 2026-09-17
  • 等 D 组的 512KB 结论 ✅ 2026-09-17
  • 等B 组的复测结论 ✅ 2026-09-17
  • release 第一版 starbridge ✅ 2026-09-17
  • 晚 7:30 和智谱讨论数据 ✅ 2026-09-18
  • 看一下 mooncake te 在 47834aea 到 7dee8db 内 rdma 层干了啥，结论：主要就是拆分独立的 CQ 给每个 worker，然后每个 worker 都可以自己推进 CQ。 ✅ 2026-09-18
    • starbridge beta1 的 workerpool 升级提交 rdma 线程的 pollwr 和 cq，H800 完成测试验证，latency 进一步降低。✅ 2026-09-18
  • flagcx 的性能比 mooncake 914 版本差 需要升级

2026-09-07（周一） 至 2026-09-13（周日）

🧠 本周记录

  • [ ]

🚀 本周TODO

infrawaves:

  • update starbridge进展 ✅ 2026-09-07 第一，使用北坡B300在MaaS正在准备的新方案1P（PP=8）1D（DCP enabled）测试验证炟哥代码的性能收益及稳定性； 结论：4. NPP→NDCP ，当前变更为保住 pp，放弃 dcp，进一步验证 starbridge 的收益。原因如下 之前 pp 打 dcp 今天跑通了 其中 starbridge 可以完成一千条压测 mooncake 中间请求传输失败 两者观察交换机带宽都低于 1Gb/s 因为 decode 开 dcp 会造成 prefill 的kv cache 无法按照 token1 token2 token3 类似连续的地址进行传输 导致真实情况以每 token 的每个 layer 去描述 wr 来传输 当前的过低带宽不足以造成 pfc，故无法拿到 starbridge 的收益。而解决 dcp 的根本问题在于解决上层 sglang 的 decode 的 kv cache 布局 layout，并且 prefill 侧需要 gather 不连续的数据到自己分配出来连续内存上会占用大量显存，所以暂时想解决该问题要投入的成本很大。 第二，晚上用户流量小的时候，可使用3机B300（2P1D）复现智谱case，打印trace验证流量行为符合代码期望。 结论：周日凌晨的实验和 maas 的经验来看 sglang bench 每次测试时 ttft 不同组的方差是本身存在的 但是 starbridge 在 90% 以上的指标和 case 下都有 20% 收益 所以之前sglang bench 得出的结论可信度很高 后续的性能验证会采取平哥 maas 这边的真实流量工具来直接验证端到端的收益

baai:

baai:

  • 合入: https://github.com/flagos-ai/FlagCX/pull/567 ✅ 2026-09-08
  • PPU 机器部署由阿里云提供网卡权限支持，目前工作给到阿里云平台运维去重启机器和备份数据，后续可以在镜像内完成推理的部署。 ✅ 2026-09-08
  • 独立出来 Starbridge，验证了编译和单测 benchmark，性能目前正常 ✅ 2026-09-09
  • 和智谱同步进展，后续需要做的 case，给到文档和代码权限给荣军，支持后续他们的真实流量测试。 ✅ 2026-09-10 智源 PPU GLM 5.2 pd 优化
  • 多台机器的docker环境ready，机器协调完毕并开启特权模式 ✅ 2026-09-10
  • 找到阿里云 accl + glm 适配的镜像 ✅ 2026-09-10
  • 单机二层镜像跑通
  • 智源 flagcx 一期验收 ✅ 2026-09-11

2026-08-31（周一） 至 2026-09-06（周日）

🧠 本周记录

  • 确定 mooncake 原生的 pxn 是接收侧的 并且仍然会丢包 因为多gen6打一个 显存 ✅ 2026-08-31
  • 确定原生为什么 rank0 会有多的流量（dsa cache），会出现 1 打 8时，选的都是对端的 mlx5_0来传这个 dsa cache ✅ 2026-08-31
  • 开 prefix 后当前的 64k 512 输出的 4p1d(16)需要复测，分析为什么 e2e 更好传输更好的情况下ttft变差

🚀 本周TODO

2026-08-24（周一） 至 2026-08-30（周日）

🧠 本周记录

Starbridge(kv cache transfer plan of pp and cp)

  • 开发机内 rank 之间的 cpu共享内存注册，hbm 的 relay buffer alloc+register 以及完善的 RailResolver 初始化逻辑 ✅ 2026-08-23
    • 这里 cuda ipc 在 pp rank 之间传递放在 shm 内的哪里？ ✅ 2026-08-23
    • 修复不同 batch put 调用后导致的 relay 内的 counter 只增不减的 hang ✅ 2026-08-24
    • mooncake 选网卡逻辑变更为就只用最近的一张 nic(不然会我们的机内选同轨 nic 会选错) ✅ 2026-08-24、
    • 增加日志 判断 pxn 的数据流向 ✅ 2026-08-24
    • 增加 tebench 的测试，和 sglang 端到端的测试，并输出文档 ✅ 2026-08-24 https://infrawaves.feishu.cn/wiki/OquOwZ0QjifAqEkDPDmcXrrPnph?from=from_copylink

Inference optimization KT1+2

  • Pd分离工具找到最优配比，尝试H800 1PXD 0-PTD-monitor

    • 阅读现第一版 logger 代码，结论：当前的统计不考虑 batch 了多少请求，并发下会导致多条请求的时间直接累加，导致结果错误。 ✅ 2026-08-18 见： tools/disagg_perf_analyzer/pd_analyzer/analyzer.py 内的：
    tot_prompt = sum(r.num_prompt for r in node_reqs)
tot_prefill_time = sum(r.prefill_time for r in node_reqs)
C_p_node = tot_prompt / tot_prefill_time if tot_prefill_time > 0 else 0.0

  • 解决 zb 004 和 002 集群问题：

    • 加 nvidia-peermem、 去掉 mlx5_3（ibdev2netdev -v）, GPU003网卡配ipv4 ,统一两边的 mtu 为 4500 ✅ 2026-08-28
    • 003 重启，重新配置 ✅ 2026-08-28
    • 004 ssd 坏了 重下模型 ✅ 2026-08-28

🚀 本周TODO

Starbridge(kv cache transfer plan of pp and cp)

  • 开发机内 rank 之间的 cpu共享内存注册，hbm 的 relay buffer alloc+register 以及完善的 RailResolver 初始化逻辑 ✅ 2026-08-23
    • 这里 cuda ipc 在 pp rank 之间传递放在 shm 内的哪里？ ✅ 2026-08-23
    • 修复不同 batch put 调用后导致的 relay 内的 counter 只增不减的 hang ✅ 2026-08-24
    • mooncake 选网卡逻辑变更为就只用最近的一张 nic(不然会我们的机内选同轨 nic 会选错) ✅ 2026-08-24、
    • 增加日志 判断 pxn 的数据流向 ✅ 2026-08-24
    • 增加 tebench 的测试，和 sglang 端到端的测试，并输出文档 ✅ 2026-08-24 https://infrawaves.feishu.cn/wiki/OquOwZ0QjifAqEkDPDmcXrrPnph?from=from_copylink

Inference optimization KT1+2

  • Pd分离工具找到最优配比，尝试H800 1PXD 0-PTD-monitor

    • 阅读现在贾博的第一版 logger 代码，结论当前的统计不考虑 batch 了多少请求，并发下会导致多条请求的时间直接累加，导致结果错误。 ✅ 2026-08-18 见： tools/disagg_perf_analyzer/pd_analyzer/analyzer.py 内的：
    tot_prompt = sum(r.num_prompt for r in node_reqs)
tot_prefill_time = sum(r.prefill_time for r in node_reqs)
C_p_node = tot_prompt / tot_prefill_time if tot_prefill_time > 0 else 0.0

  • 优化现在的每个 wr 都要选择一个 lane 的逻辑（cache 起来） ✅ 2026-08-28

  • 变成独立的 engine

智源：

2026-08-17（周一） 至 2026-08-23（周日）

🧠 本周记录

  • 回复常涛的问题 pr526 里有对packaging部分进行更改，是否是必要的？ ✅ 2026-08-17
  • 周报写一下 ✅ 2026-08-17
  • PPU vllm PD分离（fc/mc）验证 qwen3.6 8+8 ibrc(vllm，基流的 ppu) ✅ 2026-08-19
  • PPU vllm PD分离验证 qwen3.6 8+8 barex transport（智源的 ppu，这个高优，跑完了需要合入 pr 代码） ✅ 2026-08-19
  • PPU sglang 重测 qwen3.6 8+8 ibrc（flagcx+mooncake） ✅ 2026-08-17
  • 推进 barex transport 代码合入 ✅ 2026-08-17
  • 沐曦 glm w4a8
  • sglang flagcx connector 的 pr 内增加 xpyd 使用文档 ✅ 2026-08-17
  • 学院的新集群使用 ✅ 2026-08-17
  • 开发机内 rank 之间的 cpu共享内存注册，hbm 的 relay buffer alloc+register 以及完善的 RailResolver 初始化逻辑 Starbridge(kv cache transfer plan of pp and cp)
  • 开发机内 rank 之间的 cpu共享内存注册，hbm 的 relay buffer alloc+register 以及完善的 RailResolver 初始化逻辑

Inference optimization KT1+2

  • Pd分离工具找到最优配比，尝试H800 1PXD

    • 阅读现在贾博的第一版 logger 代码，结论当前的统计不考虑 batch 了多少请求，并发下会导致多条请求的时间直接累加，导致结果错误。 ✅ 2026-08-18 见： tools/disagg_perf_analyzer/pd_analyzer/analyzer.py 内的：
    tot_prompt = sum(r.num_prompt for r in node_reqs)
tot_prefill_time = sum(r.prefill_time for r in node_reqs)
C_p_node = tot_prompt / tot_prefill_time if tot_prefill_time > 0 else 0.0

  • PPU vllm PD分离（fc/mc）验证 qwen3.6 8+8 ibrc(vllm，基流的 ppu) ✅ 2026-08-18

  • PPU vllm PD分离验证 qwen3.6 8+8 barex transport ✅ 2026-08-18

  • 沐曦 glm w4a8

  • 推进合入 sglang flagcx connector 的 pr ✅ 2026-08-18

  • 输出学院新集群使用文档 ✅ 2026-08-18 Starbridge(kv cache transfer plan of pp and cp)

  • 开发机内 rank 之间的 cpu共享内存注册，hbm 的 relay buffer alloc+register 以及完善的 RailResolver 初始化逻辑 ✅ 2026-08-20

  • 每个 lane pipeline 流水调度，cudaMemcpyBatchAysnc+doorbell

Inference optimization KT1+2

  • Pd分离工具找到最优配比，尝试H800 1PXD 0-PTD-monitor

    • 阅读现在贾博的第一版 logger 代码，结论当前的统计不考虑 batch 了多少请求，并发下会导致多条请求的时间直接累加，导致结果错误。 ✅ 2026-08-18 见： tools/disagg_perf_analyzer/pd_analyzer/analyzer.py 内的：
    tot_prompt = sum(r.num_prompt for r in node_reqs)
tot_prefill_time = sum(r.prefill_time for r in node_reqs)
C_p_node = tot_prompt / tot_prefill_time if tot_prefill_time > 0 else 0.0

  • 开发机内 rank 之间的 cpu共享内存注册，hbm 的 relay buffer alloc+register 以及完善的 RailResolver 初始化逻辑 ✅ 2026-08-23

    • 这里 cuda ipc 在 pp rank 之间传递放在 shm 内的哪里？ ✅ 2026-08-23

Inference optimization KT1+2

  • Pd分离工具找到最优配比，尝试H800 1PXD 0-PTD-monitor

    • 阅读现在贾博的第一版 logger 代码，结论当前的统计不考虑 batch 了多少请求，并发下会导致多条请求的时间直接累加，导致结果错误。 ✅ 2026-08-18 见： tools/disagg_perf_analyzer/pd_analyzer/analyzer.py 内的：
    tot_prompt = sum(r.num_prompt for r in node_reqs)
tot_prefill_time = sum(r.prefill_time for r in node_reqs)
C_p_node = tot_prompt / tot_prefill_time if tot_prefill_time > 0 else 0.0
    • 跑通 promethues+grafana ✅ 2026-08-20

🚀 本周TODO

  • 推进合入 sglang flagcx connector 的 pr
  • 推进 barex transport 代码合入 ✅ 2026-08-17
  • 给 flagcx connector 增加kvConnectorStat ✅ 2026-08-20
  • 给 flagcx connector 增加kvConnectorStat ✅ 2026-08-20

2026-08-10（周一） 至 2026-08-16（周日）

🧠 本周记录

  • 确定基流 ppu 上裸机只有 mlx 的 ofed，什么都不改，当前的 ibrc 就可以跑通。pr 的 accl 的适配需要裸机有阿里云的 eic 内核，并且网卡名字必须得是vsolar_* ✅ 2026-08-10
  • 看 sglang 内 prefill开 pp 后，一打多的流量拥塞 case ✅ 2026-08-11
  • 讨论后确定为从 send-side 设计 pxn 解决 pp incast ✅ 2026-08-14
  • 回答下面三个问题 ✅ 2026-08-14
  1. 现在缺少一个纯从 engine 视角看设计图，因为我们主改的还是 engine。现在是shm 内还是[Pasted text #2 +5 lines]这几个结构，此外我们还需要在 hbm 内开一个 1GB 固定 size 的relaybuffer，并且一切为 2，每个 relaybuffer 的 1/2 内需要再切点槽位，能够让当前2个的 ce write 和 rdma read 能并行在做。
  2. 之前的 slice 结构是放跨机的任务队列的，我们现在入口处得对跨轨的任务拆成机内+跨机，存在对应的数据结构内，这个结构我还没想好。
  3. 机间拷贝的任务正常还是会走 te 内的切分 slice 然后交给默认workers_per_ctx=2个 worker 处理，这俩 worker 应该负责轮询doorbell或者处理本来就直接同轨跨机的 rdma 任务，还需要一个单独的 ceworker，把自己的跨轨的任务传给机内的 rank，同时需要注意这里的顺序，可能必须得加锁。

🚀 本周TODO

2026-08-03（周一） 至 2026-08-09（周日）

🧠 本周记录

  • cuda api 调用失败原理： ✅ 2026-08-03 runtime 会把每次当前 api 调用的错误码记录在线程上，然后下一次 cuda 调用的时候不管什么都先返回这个错误码（比如cudaErrorInvalidValue=1）
  • 修复 https://github.com/flagos-ai/vllm-plugin-FL/pull/315 的 CICD 报错 ✅ 2026-08-05
  • https://github.com/ymmyys/FlagCX/pull/1 优化了代码 ✅ 2026-08-05
  • 基流 PPU 机器准备代理镜像环境模型文件等等
  • 同步明宇 PPU 侧 VLLM 跑通用 barex 的推理 ✅ 2026-08-05

🚀 本周TODO

2026-07-27（周一） 至 2026-08-02（周日）

🧠 本周记录

  • 和梦思讨论 https://github.com/flagos-ai/vllm-plugin-FL/pull/315/changes 代码的合入(修复关 flagGems 的报错，修复 flagcx.py的二次 * + &， 修复 flagcx connector 传乱请求)
  • 复现和定位 泽宇说的性能下降问题 cc 给常涛 ✅ 2026-07-27
  • 带明宇先开始基础的工作，先写一个pr 关于传 fd 给 dma register，并 review 代码✅ 2026-07-27
  • 写材料交给明月，ddl：今天 ✅ 2026-07-30
  • 改DModel debug 1f1b串行并验证，并 debug
  • review dmodel 代码
  • ppu 机器网卡问题待解决中
  • 和梦思讨论 https://github.com/flagos-ai/vllm-plugin-FL/pull/315/changes 代码的合入(修复关 flagGems 的报错，修复 flagcx.py的二次 * + &， 修复 flagcx connector 传乱请求) ✅ 2026-07-28
  • 复现和定位 泽宇说的性能下降问题 cc 给常涛 ✅ 2026-07-27
  • 带明宇先开始基础的工作，先写一个pr 关于传 fd 给 dma register，并 review 代码✅ 2026-07-27
  • 写材料交给明月，ddl：今天 ✅ 2026-07-28
  • 跟明宇交代 berax transport 内用 accl 注册 user mr以及后续如果用 flagcx p2p engine 完成 ppu 的传输 ✅ 2026-07-28
  • ppu 机器网卡问题待解决中 ✅ 2026-07-29
    • 已经与高鹏说了该问题 ✅ 2026-07-28
  • 学院 4 机 a2a 性能低排查 ✅ 2026-07-28
  • 确定 6 个相位为什么需要的显存比原本多了这么多 ✅ 2026-07-30

🚀 本周TODO

  • sglang 支持 flagcx connector
  • 改DModel debug 1f1b串行并验证，并 debug
  • review dmodel 代码
  • 改DModel debug 1f1b串行并验证，并 debug ✅ 2026-07-30
  • review dmodel 代码 ✅ 2026-07-29
  • 改DModel debug 1f1b串行并验证，并 debug ✅ 2026-07-30

2026-07-20（周一） 至 2026-07-26（周日）

🧠 本周记录

  • [ ]

🚀 本周TODO

  • 沐曦 Qwen3.6-35B 基线性能确认
  • 整理当前flagcx connector代码，提交到vllm-plugin-fl
  • 继续调试海光Qwen3.6-35B
  • 沐曦 Mooncake 基线对比

2026-07-13（周一） 至 2026-07-19（周日）

🧠 本周记录

  • [ ]

🚀 本周TODO

  • 验证新 flagcx connector与新 mooncake connector 在旧 qwen 上的 pd 分离性能 ✅ 2026-07-16
  • 给颜明宇安排工作 ✅ 2026-07-16
  • muxi 卡的 cudaGraph bug ✅ 2026-07-16
  • muxi 卡的选择网卡的 bug
  • DModel fwd+bwd切分相位的设计文档
  • 和治鑫约一下后续 DModel 的 2 microbatch overlap 的事宜 ✅ 2026-07-16

2026-07-06（周一） 至 2026-07-12（周日）

🧠 本周记录

  • .contents ： value→ref ✅ 2026-07-09
  • byref ✅ 2026-07-09
  • 确定一下 send_kv_to_decode 内的几次 for loop 看一下是不是可以打掉
  • 不同 te 的话 DModel 内的改动范围是？
  • VCCL manager 的简化，内存问题的优化？

🚀 本周TODO

Graph View