2026-Q4

2026-10-19（周一） 至 2026-10-25（周日）

🧠 本周记录

• [ ]

🚀 本周TODO

starridge

• 和贾博去智谱盯线上压测，确定当前的代码问题以及后续工作内容 ✅ 2026-10-16
• 排查为什么 decode rank 不正常退出，结论：https://github.com/sgl-project/sglang/pull/29984，怀疑和 aux 有关 ✅ 2026-10-16
• starbridge 的性能和状态需要能够被 profilling ✅ 2026-10-23
  • 在 sglang v0.5.18内增加了一个 load 我们的 metrics 埋点的函数，在 mooncake/starbridge 内增加了埋点，把内部的性能和状态数据交给 sglang ✅ 2026-10-22
  • 输出详细的使用说明，需要用户能够快速在自己的 maas 的 sglang+promethues/grafana 使用上 0-Starbridge Profiling & Metrics ✅ 2026-10-23
• prefill 的 alloc_paged_token_slots_extend 报 Prefill out of memory. Try to lower your batch size.的具体原因
  • 分析完日志后发现，完全没走 bridge，但是初始化是成功的，并且传输时也有要 relay 的流量，但是 mapPeer 失败，之前正好没在这个函数里面加日志，所以不知道为什么 return false。 ✅ 2026-10-19
  • 增加详细的日志，通过 export BRIDGE_LOG_LEVEL=INFO export GLOG_v=2 去观察 prefill.log或者 promethues 观察 starbridge 状态，添加了 ✅ 2026-10-23
• 支持网卡名匹配和最近pcie 两种匹配同轨方式 ✅ 2026-10-21
• aux 需要在 starbridge 内自动分流走同轨跨轨 rdma ✅ 2026-10-21
• 优化 ttft 长尾问题
  • 观察到 Transfer KV Cache Latency 存在问题，怀疑和 relay 的排队有关或者和 layer split 有关
• 传输 kv cache 时是否开启了 custom mempool，其中开启后如果按层传输 kv cache 时走 starbridge 是否会出现性能退化，是否和智谱的Layer split技术有关？ ✅ 2026-10-23
  • custom_mem_pool开了的话是走 mooncake 的NVLINK/BAREX/INTRA_NODE_NVLINK的内存分配，结论：这个肯定不走。 ✅ 2026-10-23
  • 分析 2-cp-layer-split ，结论传输量和传输路径一模一样。 ✅ 2026-10-23 智源：
• 沐曦 @颜明宇
• 跟梦思对一下 base 性能，以及当前 glm 的状态 ✅ 2026-10-20
• 确定 baseline 的数据性能 ✅ 2026-10-22
• promethues 观察到瓶颈在 D，尝试量化bf16→fp8，但是 fp8的 kernel 只有 triton native 实现，该 kernel 时间会拖慢 10 倍，decode 速度会更慢。 ✅ 2026-10-22
• PPU
• 优化单 ag/rs kernel
  • 看明白当前 sglang 内的 custom 的 ar 实现 0-custom-all-reduce ✅ 2026-10-10
  • 第一版我们的 ag 实现完成 ✅ 2026-10-10
  • 走ICN 表，3 个 round 完成所有的数据发送，结论：带宽到 116GB/s，和 pccl 的 ag 的 250 差很多。分析原因给出一个根本的 ppu 的 kernel 差的原因。 ✅ 2026-10-12
  • 拆分出来 one-shot 和 three-shot 两种 kernel ✅ 2026-10-13
  • 看 pccl 内的 ag 实现 ✅ 2026-10-14
  • pccl-test 和 dist.all_gather_into_tensor 性能差异 ✅ 2026-10-16
  • 给出优化 ag 的结论，无法优化传输，因为问题主要是 cpu bound 导致的同步问题，收尾设计和优化文档。 ✅ 2026-10-19
  • pccl 开源后看了一遍 pccl 最后的 ptx 指令，按照 ppu_remote_store_bulk 后走的传输链路在 one shot 上性能收益任然是 1k-32k 有提升，对推理场景没有提升。 ✅ 2026-10-23
  • 和 pccl / ppu 的人沟通了我们 ag 的问题，并确定为性能问题为 cpu bound 导致的同步问题，统计后 ag 的同步/传输占比为99.4%和0.5% https://infrawaves.feishu.cn/wiki/NqZowrxGciWGQEkoNsccfiwxnff ，尝试把 cpu 核按 rank 绑定后观察性能提升。
  • 调研 cpu 问题解决后的fuse kernel优化路线 TP + Norm + TP kernel fuse
    • fuse tp 和 norm 可以带来 2.2% 预估的收益，需要评估是走triton flagGems / cuda flagcx
    • sparse attn 会在 tp 切完 head 后依然把 head 给 padding 到 64 完成计算，评估这个是否可优化，这个kernel占一次 fwd 的时间76%

2026-10-12（周一） 至 2026-10-18（周日）

🧠 本周记录

• [ ]

🚀 本周TODO

内部：

• 周报填写 ✅ 2026-10-12

Starbridge：

• 协助智谱排查代码上线问题 ✅ 2026-10-14
• 确定网卡选择问题
• 协助看线上问题

智源：

• 沐曦 @颜明宇
• 跟梦思对一下 base 性能，以及当前 glm 的状态
• 对齐 bench_prefix.py，先抓 1k-64k 的 PTD 找出传输瓶颈的 case
• 调优 slice 和线程数量
• PPU
• 优化单 ag/rs kernel
  • 看明白当前 sglang 内的 custom 的 ar 实现 0-custom-all-reduce ✅ 2026-10-10
  • 第一版我们的 ag 实现完成 ✅ 2026-10-10
  • 走ICN 表，3 个 round 完成所有的数据发送，结论：带宽到 116GB/s，和 pccl 的 ag 的 250 差很多。分析原因给出一个根本的 ppu 的 kernel 差的原因。 ✅ 2026-10-12
  • 拆分出来 one-shot 和 three-shot 两种 kernel ✅ 2026-10-13
  • 看 pccl 内的 ag 实现 ✅ 2026-10-14
  • pccl-test 和 dist.all_gather_into_tensor 性能差异 ✅ 2026-10-16
  • 给出优化 ag 的结论，无法优化传输，因为问题主要是 cpu bound 导致的同步问题，收尾设计和优化文档。
  • 开始看 rs+norm+ag 的方案

2026-10-05（周一） 至 2026-10-11（周日）

🧠 本周记录

• [ ]

🚀 本周TODO

内部：

• 周报填写 ✅ 2026-10-08
• okr 对齐和填写

Starbridge：

• 约荣军对一下现在的 starbridge 现状以及后续的计划，周五晚上 7点半 ✅ 2026-10-08

智源：

• 沐曦 @颜明宇
• 对齐 bench_prefix.py，先抓 1k-64k 的 PTD 找出传输瓶颈的 case
• 调优 slice 和线程数量
• PPU
• ptd 抓 prefix log ✅ 2026-10-08
• sglang 业务侧 overlap 确定代码逻辑和实现 能加就加到 plugin 内判断收益 结论：见代码srt/environ.py:403，已经早就在 sglang 内默认开启与支持了
• 开 cp 确定 ag/rs 下 msg size 和 bw ✅ 2026-10-09
• 优化单 ag/rs kernel
  • 看明白当前 sglang 内的 custom 的 ar 实现 0-custom-all-reduce
  • 第一版我们的 ag 实现