从零开始在 Github 给 ROCm 社区提第一个 PR

从“只会跑 Demo到提交第一个 PR很多刚接触 AMD GPU 的朋友往往停留在“把环境配好、跑通官方示例”这一步。看着 Github 上 ROCm 生态里那些活跃的项目总觉得那是大神们的领地自己只能做个旁观者。其实开源社区的门槛远没有想象中那么高。最近我在尝试部署SGLang这个大模型推理框架时意外发现了一个显存利用率异常的痛点并顺势完成了一次从复现 Bug 到提交 PR 的完整闭环。这个过程不仅解决了实际问题更让我真切感受到了社区协作的魅力。今天就把这段经历拆解开来希望能给想参与共建但还在犹豫的你一点信心。发现问题当 SGLang 遇上 MI300X事情起因很简单我想在公司的 MI300X 服务器上测试 SGLang 对长上下文场景的支持。按照官方文档配置好 ROCm 7.x 环境后服务是跑起来了但在进行多轮对话压力测试时监控面板上的显存占用曲线却非常奇怪明明 Batch Size 还没打满HBM 却已经告急吞吐量也随之断崖式下跌。如果是以前我可能就会默默调小 Batch Size 凑合用或者去论坛发帖问“是不是我显卡坏了”。但这次我决定深挖一下。首先我排除了模型权重加载的问题确认是推理过程中的动态显存分配出了状况。为了拿到确凿证据我拿出了 ROCm 套件里的神器——rocprof。通过简单的命令注入rocprof --input-trace ./trace_output --hip-trace --roctx-trace python-msglang.launch_server...我抓取了内核执行的热力图。数据不会撒谎在特定的 Prompt 长度下某个负责内存管理的 Kernel 出现了频繁的 Bank Conflict导致内存访问效率极低进而引发了显存碎片化让系统误以为显存已满。定位到具体算子后问题就从“玄学”变成了明确的代码逻辑缺陷。社区协作在 Issue 中与 maintainer 过招拿着 profiling 数据和复现脚本我打开了 SGLang 的 Github 仓库。这里有个关键技巧不要只扔一句“报错了”。我新建了一个 Issue标题清晰地标明了硬件架构gfx942和软件版本正文中贴上了rocprof的关键截图、复现的最小代码片段以及我初步的分析结论。没想到发出不到两小时项目的核心维护者就回复了。他没有打官腔而是直接指出了我的盲点“你观察到的现象确实存在但这不仅仅是内存管理的问题还涉及到 TileLang 编译后端在处理该架构时的分块策略Block Size与 Wavefront 大小不匹配。”接下来的几天我们在 Issue 评论区展开了一场高效的技术讨论。他建议我尝试修改算子定义中的分块参数并推荐参考 TileLang 中针对 MI300 系列的最新优化案例。这种互动完全没有大神的架子大家的目标只有一个让代码跑得更快。在这个过程中我不仅学到了如何针对特定 GPU 架构调整 Kernel 配置还顺手复习了 HIP 编程中关于内存共存的细节。动手修复从本地验证到提交补丁有了方向剩下的就是硬功夫。我在本地克隆了仓库创建了一个新的分支fix/mi300x-memory-fragmentation。根据讨论结果我调整了相关算子的分块逻辑增加了一个针对gfx942架构的特化分支。修改完成后本地的压力测试结果显示显存利用率回到了正常水平同等配置下的吞吐量提升了近 30%。为了确保万无一失我又跑了一遍现有的单元测试确认没有引入回归错误。接下来就是最激动人心的时刻——提交 PR。在 Pull Request 的描述里我详细记录了问题背景MI300X 上长文本推理的显存异常。根因分析引用了之前的 profiling 数据和讨论结论。修改方案具体的代码变更逻辑。验证结果修复前后的性能对比数据。点击Create Pull Request的那一刻心里其实挺忐忑的担心自己的代码风格不符合规范或者逻辑有漏洞。但开源世界的可爱之处就在于 Code Review。维护者很快给出了几条关于变量命名和注释风格的微调建议我随即修正并推送。仅仅过了两天随着 CI 流水线全部变绿PR 被正式合并Merged。迈出第一步你也可以看着自己的 Commit ID 出现在主分支的提交历史里那种成就感是单纯“跑通代码”无法比拟的。你不再只是一个使用者而是成为了这个生态的建设者。你的代码可能会运行在全球成千上万台服务器上帮助其他开发者避开同样的坑。对于想参与 ROCm 社区的新人我的建议是别怕露怯。你不需要精通汇编也不需要是算法专家。哪怕只是完善一段文档、修复一个拼写错误或者像这样提供一个清晰的 Bug 复现路径都是极具价值的贡献。Github 上的每一个开源项目都在等待像你这样的新鲜血液。拿起键盘从关注一个感兴趣的 Issue 开始你的第一个 PR 也许就在今天诞生。