-
metal-kernel：把 PyTorch 在 Apple Silicon 上的内核，从 MPSGraph 拉回原生 Metal
用 Apple Silicon 跑 PyTorch 的人，多半对 MPS 后端又爱又恨。爱的是它确实让 M1/M2/M3 那几颗芯片有了存在感，恨的是它总在关键时刻掉链子，要么算子不支持，要么数值对不上，要么性能比 CPU 还拉胯。 问题的根子，PyTorch 官方自己也承认，出在 MPSGraph 这套实现方式上。MPSGraph 是 Apple 的高层图 API，PyTorch 早期为了快速铺…- 1.1k
- 0
-
Aoti-debug：把 AOTI 崩溃排查，从玄学变成一张路由表
做过 PyTorch 模型 AOT 部署的人，多半见过这种场面：模型好不容易 aot_compile 过了，加载进推理服务的那一刻直接 segfault，报错信息要么是空指针，要么是一句看不懂的指针位置提示。这时候你盯着代码看半天，往往什么都查不出来，因为问题根本不在代码里。 PyTorch 官方在 Smithery 上发了个 skill 专门治这个，叫 aoti-debug，挂在 pytorch…- 1.2k
- 0
-
Triaging-issues：把 PyTorch issue 分诊的隐性规则，写成一条可执行的决策树
给 GitHub issue 分诊，听起来是件没技术含量的小事。读一眼标题，贴个标签，丢给对应团队，完事。PyTorch 这种一天几十个 issue 的仓库，居然专门为这事做了一个 skill，还上了 Smithery 平台。乍看是小题大做，读完才明白，分诊这事比想象中门槛高得多，贴错一个标签，issue 就得在错误的队列里躺上好几天。 多数人对 triage 的默认想象，就是「读标题、匹配关键词…- 1k
- 0
-
Add-uint-support ：给 PyTorch 算子补 uint 支持，是一个被低估的精细活
大部分写 PyTorch 的人一辈子不会碰“给算子加类型支持”这种事。你用 tensor.float()、tensor.int()，内核里那些 AT_DISPATCH 宏替你扛下了所有类型分支，你甚至感觉不到它们存在。直到某天你要跑一个 uint16 的张量。 然后你会撞上一堵墙。PyTorch 的 uint8（对应 kByte）支持得很完整，但 uint16、uint32、uint64 这三个所…- 1.1k
- 0
-
PyTorch PR Review：一个只报问题不夸人的代码审查员
给 PyTorch 提 PR 是什么体验？你花了两周写完一个算子优化，通过了所有 CI 检查，Lint 全绿，测试全过，然后等了两周没人 review。好不容易有人看了，留了一条评论：“LGTM”。 这不是段子，是 PyTorch 贡献者每天都在经历的现实。PyTorch 仓库有超过四千个贡献者，每天几十个 PR 涌入，而核心维护者的带宽是固定的。结果就是大量 PR 要么被粗放式 review 放…- 1.2k
- 0
-
PyTorch 构建 building 深度拆解：从环境准备到跨端编译
如果你试过从源码构建 ExecuTorch，应该对那种"卡在环境配置就花了半小时"的感觉不陌生。每一步都可能踩坑： conda 环境死活激活不了 cmake 版本不对，报错信息还看不出原因 submodule 没同步完整，第三方依赖的 CMakeLists.txt 找不到 交叉编译参数漏了一个，链接时符号全丢了 官方文档写得再详细，实际操作时总会有一些路径问题、权限错误、版本冲…- 974
- 0
-
Profile：PyTorch 边缘部署的性能瓶颈排查指南
模型跑通了，推理结果也对，就是慢得离谱。你打开各种 profiling 工具，日志里一堆时间戳，但每个算子到底吃了多少毫秒，瓶颈卡在模型哪一层，根本看不出来。换个场景重跑一遍，时间分布又变了，连复现都困难。 这不是个别问题。ExecuTorch 作为 PyTorch 的边缘端推理方案，性能分析一直是开发者最头疼的环节。官方文档确实有一套完整的开发者工具链，但配置步骤多、概念门槛高，很多人翻了半天文…- 1k
- 0