前言

最近 SDK 连续遇到两个很隐蔽的问题：

1. 链式调用 ServiceClient().create_xxx_client() 后，临时的根 Client 被析构，顺手关闭了派生 Client 还在使用的远程 Session。
2. 启动遥测后台线程时，如果 Python 线程 bootstrap 异常，ServiceClient 初始化会永久卡住。

前言

强化学习训练链路遇到一个很实际的问题：每个 step 更新完 LoRA 后，需要先把权重保存到磁盘，再让 vLLM 加载，才能开始下一轮 rollout。

这个文件链路看起来很绕，但它真的是 RL step 的主要瓶颈吗？

前言

SDK 发版后，文档仓库经常还停留在旧版本。靠人在 Release 之后记得去另一个仓库看 diff、补文档、跑构建和提 PR，次数少时没问题，次数多了早晚会漏。

最近梳理并验证了一条自动化链路：SDK 发布稳定版 GitHub Release 后，由 Webhook 触发脚本，创建独立 worktree，让 Codex 审计两个 tag 之间的改动并更新文档，最后自动提交分支和创建 PR。

前言

一次 BatchLoRA 任务把两个各 32 样本的事件合并后，四张 80G 训练卡同时 OOM：

1
2
3
4
5

64 samples
206729 raw tokens
206848 packed tokens
max_seq_len = 8447
每张卡还差约1.58 GiB

前言

训练服务曾经在一段处理 position_ids 的代码附近报：

1

CUDA error: device-side assert triggered

前言

一次 Qwen3.5-4B 训练在约 23.4 万 packed tokens 时触发：

1

CUDA error: an illegal memory access was encountered

前言

给推理和训练链路加入图片输入时，最先遇到的不是 Vision Encoder，而是图片到底怎么穿过 SDK、Router、Actor 和 vLLM。

常见选择有：

前言

事情的起点很简单，Qwen3.5-4B 在 Ascend 950PR 上可以正常启动，接口也能返回内容，但是输出完全是胡言乱语。

最麻烦的地方是服务看起来没有坏: 模型加载成功，显存正常，HTTP 也是 200，没有任何一个日志能看出来是某个融合算子算错了。只能从最终输出向前一层层比较中间值。

前言

最近在 Ascend 950PR 上部署 Qwen3.5-4B，最开始直连 vLLM 压测只有：

1
2

Total TPS：  2167.47 tok/s
Output TPS：  426.57 tok/s

前言

大 Batch 放不进显存时，最常见的做法是拆成几个 micro-batch，分别 forward/backward，最后只执行一次 optimizer step。

听起来就是“多调几次 backward”，但如果 micro-batch 大小不同、每个样本有效 token 数不同，或者 loss 本身按 token 归一化，直接累加得到的梯度并不一定等于完整 Batch。