| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[fix] fix memory config testcase Co-authored-by: liujunzhu<liujunzhu@huawei.com> # message auto-generated for no-merge-commit merge: !41705 merge master into master [fix] fix memory config testcase Created-by: liujunzhu Commit-by: liujunzhu Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20260203 --> # 【合入来源】 > <font color="red">**如有社区issue，请关联issue链接**</font>\ > <font color="red">**请勿携带内部流程信息（需求链接、问题单、内部issue等）**</font> - [x] 需求 - [ ] 问题单 - [ ] issue/工单 - [ ] 重构优化 - [ ] 资料更新 # 【修改方案】 > 请描述修改内容的具体实现，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列\ > 如果是需求或者重构类的PR，需要补充详细设计文档（说明上下游组件关系、时序图、类图、DFX能力等内容） 修复 throw_on_npumalloc_oom 、 pinned_max_round_threshold_mb 和 pinned_max_cached_size_mb的用例问题。 # 【资料变更】 > 请确认是否涉及资料变更。如涉及，需要在PR中体现，并简要说明修改内容。如不涉及，需填写“不涉及” 不涉及 # 【接口变更】 > 请确认是否涉及跨代码仓或者客户面可见的接口变更。如涉及，需要详细说明接口以及对应的变更内容，同时需要在资料中体现。如不涉及，需填写“不涉及” 不涉及 # 【功能验证】 > 说明测试场景，测试方法。如果本次测试方式与常规单元测试不同，请详细说明您的测试步骤\ > 新增/变更内容是否已新增/适配UT测试用例看护，并补充测试自验证截图 通过CI验证。 # 【CheckList】 > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] - [x] 代码注释完备，正确记录错误日志 - [x] 代码实现进行了返回值、空指针等校验 - [x] PR标题正确使用类型标签，如：feat、fix、refactor、docs、test等 - [x] PR持续集成流水线（CI）执行通过，代码检查无异常 See merge request: Ascend/pytorch!41705 | 3 个月前 | |
[Fix] Fix static check errors detected by SPACES Co-authored-by: huangjingwei<huangjingwei4@huawei.com> # message auto-generated for no-merge-commit merge: !35981 merge master_lintrunner into master [Fix] Fix static check errors detected by SPACES Created-by: huangjingwei Commit-by: huangjingwei Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20260203 --> # 【合入来源】 > <font color="red">**如有社区issue，请关联issue链接**</font>\ > <font color="red">**请勿携带内部流程信息（需求链接、问题单、内部issue等）**</font> - [ ] 需求 - [ ] 问题单 - [x] issue/工单 - [ ] 重构优化 - [ ] 资料更新 # 【修改方案】 检测和删除代码中的行尾空白字符 # 【资料变更】 不涉及 # 【接口变更】 不涉及 # 【功能验证】 不涉及 # 【CheckList】 > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] - [x] 代码注释完备，正确记录错误日志 - [x] 代码实现进行了返回值、空指针等校验 - [x] PR标题正确使用类型标签，如：feat、fix、refactor、docs、test等 - [x] PR持续集成流水线（CI）执行通过，代码检查无异常 See merge request: Ascend/pytorch!35981 | 5 个月前 | |
feat: Add time_us timestamp collection to memory snapshot trace events Co-authored-by: culechan<chenshuai81@huawei.com> # message auto-generated for no-merge-commit merge: !48034 merge issue5311-time-us into master feat: Add time_us timestamp collection to memory snapshot trace events Created-by: chenqiming Commit-by: culechan Merged-by: ascend-robot Description: <!--PR描述模板更新日期：20260203 --> # 【合入来源】 > <font color="red">**如有社区issue，请关联issue链接**</font>\ > <font color="red">**请勿携带内部流程信息（需求链接、问题单、内部issue等）**</font> - [ ] 需求 - [ ] 问题单 - [x] issue/工单 → 关联 https://gitcode.com/Ascend/pytorch/issues/5311 - [ ] 重构优化 - [ ] 资料更新 # 【修改方案】 Closes #5311 本 PR 补齐 NPU memory snapshot 的 trace 事件时间戳，实现方式与 CUDA 侧保持一致（对照 c10::CachingDeviceAllocator / c10::cuda::CUDACachingAllocator），共修改五个文件并新增 UT 用例文件 test/allocator/test_memory_snapshot_time_us.py： 1. **NPUCachingAllocator.h**：TraceEntry 新增 **trace_time_ union**（记录时存 getApproximateTime() 的 tick，快照时换算为 epoch 微秒）与构造参数 time（参数位置与 c10 基类一致），并显式 include ApproximateClock.h； 2. **NPUCachingAllocator.cpp**：record_trace 记录 tick；trace() 新增 **tsc_to_us 回调**完成 tick → 微秒换算；converter 放在多设备 snapshot 处，标定一次供所有设备使用； 3. **NPUWorkspaceAllocator.cpp**：3 处 TraceEntry 构造同步传入时间戳；snapshot() 引入 **ApproximateClockToUnixTimeConverter 成员**，将 workspace 轨迹由未换算的原始 tick 换算为 epoch 微秒，converter 常驻 allocator 实例、标定一次供历次快照复用，与 c10::cuda::CUDACachingAllocator 的实现方式一致； 4. **Module.cpp**：序列化输出 **time_us** 字段；workspace 快照的换算已收敛至 allocator 内部，合并进 device_traces 前单位即已统一； 5. **memory.py**：TraceEntry TypedDict 补充 time_us 字段说明。 说明：workspace 的 trace 收集在 **BUILD_LIBTORCH** 构建下被 #ifndef 屏蔽，该构建产物中不会出现 workspace 事件，合并前的换算主要面向非 libtorch 构建路径。 # 【资料变更】 不涉及 # 【接口变更】 不涉及 # 【功能验证】 在 NPU 环境（aarch64，CANN 9.2.0，torch 2.13.0，davinci0）验证：开启 _record_memory_history(enabled="all") 后执行分配/释放/empty_cache，并覆盖 matmul、bmm、conv2d、SDPA 等 **8 类 aclnn 算子**；_snapshot() 返回的 **146 条 trace 事件全部携带 time_us**，值为 epoch 微秒、单调递增，与系统时钟偏差约 **0.7s**；_dump_snapshot 流程回归正常。 验证脚本运行后会**逐事件打屏**：脚本对 _snapshot() 返回的每一条 trace 事件，都输出 action、addr、size、**time_us 原始值**、对应可读时间与距上一事件的毫秒间隔；即使后续断言失败，事件明细也已先完整打印，确保**每个事件的 time_us 都能被用户看到**。 **UT 看护**：已随 PR 新增 test/allocator/test_memory_snapshot_time_us.py，覆盖全事件 time_us 覆盖率、单调递增、epoch 窗口、可读日期、pickle 往返五条用例，随本 PR 构建的 wheel 执行 **5/5 通过**。 ## time_us 使用方式 开启记录并执行业务后，_snapshot() 的 device_traces 中每条事件携带 **time_us**（epoch 微秒），可直接用于时间轴展示，或与 profiler 事件按时间对齐： python import torch_npu snap = torch_npu.npu.memory._snapshot() for trace in snap["device_traces"]: for e in trace: print(e["action"], hex(e["addr"]), e["size"], e["time_us"]) # time_us: epoch 微秒 ## 复现步骤 **执行环境**（本 PR 实测所用）：aarch64 NPU 服务器；在 docker 容器内执行（镜像含 Python 3.11 与构建工具链），容器挂载 CANN 9.2.0 与 NPU 设备（/dev/davinci0 等）；容器内安装 torch 2.13.0+cpu，torch_npu 为**本 PR 构建的 wheel**。 **版本配套**：CANN 9.2.0、torch 2.13.0、本 PR wheel 三者需配套。time_us 断言验证的是本 PR 的行为——装入旧版 torch_npu（无 time_us）时断言会失败，属预期结果；torch 装成其他变体（如 +cu130）会在 import 阶段报错。脚本为纯 python 实现，本身无版本敏感语法。 **步骤**： 1. 按 CheckList 构建或直接安装本 PR 构建的 torch_npu wheel； 2. 在容器内（source CANN 9.2.0 后）运行下方验证脚本（也可按核心链路自行编写：_record_memory_history → 业务分配 → _snapshot → 检查 time_us）； 3. 预期结果：**所有 trace 事件携带 time_us**，值为 epoch 微秒、按事件顺序单调递增、与系统时钟偏差在秒级以内——本环境实测 146 条事件全部通过。 验证脚本（verify_5311.py）如下： python import os import time import datetime import pickle import torch import torch_npu torch_npu.npu.set_device(0) def probe(name, fn): try: fn() torch.npu.synchronize() print("OP-OK:", name) except Exception as e: print("OP-FAIL:", name, type(e).__name__, str(e)[:100]) x = torch.randn(1024, 1024, device="npu") torch_npu.npu.memory._record_memory_history(enabled="all", context="all", stacks="python") y = torch.randn(2048, 2048, device="npu") # 覆盖多类 aclnn 算子，保证事件多样性 probe("matmul", lambda: torch.randn(4096, 4096, device="npu") @ torch.randn(4096, 4096, device="npu")) probe("bmm", lambda: torch.bmm(torch.randn(8, 64, 96, device="npu"), torch.randn(8, 96, 64, device="npu"))) probe("conv2d", lambda: torch.nn.functional.conv2d( torch.randn(8, 3, 64, 64, device="npu"), torch.randn(16, 3, 3, 3, device="npu"), padding=1)) probe("layer_norm", lambda: torch.nn.functional.layer_norm( torch.randn(128, 256, device="npu"), (256,))) probe("softmax", lambda: torch.softmax(torch.randn(256, 256, device="npu"), dim=-1)) probe("sdpa", lambda: torch.nn.functional.scaled_dot_product_attention( torch.randn(2, 8, 512, 64, device="npu"), torch.randn(2, 8, 512, 64, device="npu"), torch.randn(2, 8, 512, 64, device="npu"))) probe("gelu-bf16", lambda: torch.nn.functional.gelu( torch.randn(8192, 8192, device="npu", dtype=torch.bfloat16))) del x, y torch_npu.npu.empty_cache() snap = torch_npu.npu.memory._snapshot() traces = snap["device_traces"] entries = [e for tr in traces for e in tr] times = [e["time_us"] for e in entries if "time_us" in e] now = time.time() # ---- 逐事件明细：每条事件的 time_us 与可读时间，直接可审 ---- print("=" * 110) print(f"{'idx':>4} {'action':<20} {'addr':>14} {'size':>10} {'time_us':>16} " f"{'时间(+8时区)':<21} {'距上一事件(ms)':>12}") print("-" * 110) prev = None for i, e in enumerate(entries): t = e.get("time_us") if t is None: print(f"{i:>4} {e['action']:<20} {hex(e['addr']):>14} {e['size']:>10} {'MISSING':>16}") continue hms = datetime.datetime.fromtimestamp(t / 1e6).strftime("%m-%d %H:%M:%S.%f")[:-3] gap = "" if prev is None else f"{(t - prev) / 1000:.3f}" print(f"{i:>4} {e['action']:<20} {hex(e['addr']):>14} {e['size']:>10} {t:>16} {hms:<21} {gap:>12}") prev = t print("=" * 110) # ---- 汇总断言 ---- if times: mono = all(a <= b for a, b in zip(times, times[1:])) lo, hi = (now - 3600) * 1e6, (now + 60) * 1e6 in_window = sum(1 for t in times if lo <= t <= hi) print("device_traces:", len(traces), "total entries:", len(entries), "with time_us:", len(times)) print("monotonic(raw order):", mono) print("epoch-window hits:", in_window, "/", len(times)) print("last-vs-now delta seconds:", round(abs(times[-1] / 1e6 - now), 3)) ws = [e for e in entries if e["action"] == "workspace_snapshot"] ws_ok = sum(1 for e in ws if "time_us" in e and lo <= e["time_us"] <= hi) print("workspace entries:", len(ws), "| epoch-scale time_us:", ws_ok) print("P2-FIX-VERDICT:", "PASS" if (len(ws) == 0 or ws_ok == len(ws)) else "FAIL") else: print("NO-TIME-US-FOUND") print("VERIFY-PY-DONE") # 将已通过断言的快照原样落盘（与断言数据同源），供 memory_viz 渲染。 # 输出路径固定在挂载卷目录 /home/c30087003/memviz/：宿主机可直接取用； # 勿改为相对路径——相对路径随执行时的工作目录变化，产物可能落进容器可写层，容器删除即丢失。 out_path = "/home/c30087003/memviz/snap_verify.pickle" os.makedirs(os.path.dirname(out_path), exist_ok=True) with open(out_path, "wb") as f: pickle.dump(snap, f) print("DUMP-SAVED:", out_path) **注意**：脚本中的输出绝对路径（out_path）必须指向**已挂载到容器内且具备读写权限**的目录（如本环境的 /home/c30087003/memviz/）。使用容器内未挂载的路径时，文件会写入容器可写层、随容器删除而丢失；指向只读挂载路径则写入直接失败。 ## 对接场景复现 **场景一：pytorch.org/memory_viz 时间轴可视化** 运行「复现步骤」的验证脚本：断言通过后，脚本会将**已断言的快照原样落盘**（pickle.dump(snap, ...) → snap_verify.pickle），因此渲染的数据与断言的数据**同源**。将该 pickle 上传至 **pytorch.org/memory_viz**：各视图（Active Memory Timeline / Allocated Memory / Allocator State History / Active Cached Segment Timeline）正常加载渲染，**146 条事件全部携带 time_us**，事件详情中可见 **time_us 换算的时间戳**，调用栈正常显示。注：memory_viz 各时间轴视图的横轴为**事件序号**（每事件一步，不按真实时间缩放），time_us 体现在事件详情的时刻展示中；本轮快照在 empty_cache 之后采集，segments 视图为空属正常。 **场景二：与 profiler、trace 等带时间戳的事件流时间对齐** 补齐后，trace 事件的 time_us 为 **epoch 微秒**，与 profiler、trace 等事件流使用同一时间基准——memory snapshot 的事件可直接与这些带时间戳的事件流按时刻对齐。例如将某次分配的 time_us 与 profiler 导出的时间轴比对，即可定位该分配发生时对应算子的执行情况，无需再依赖事件顺序索引推断时序。 # 【CheckList】 - [x] 代码注释完备，正确记录错误日志 - [x] 代码实现进行了返回值、空指针等校验 - [x] PR标题正确使用类型标签，如：feat、fix、refactor、docs、test等 - [x] PR持续集成流水线（CI）执行通过，代码检查无异常（本 head 已通过，见 ci-pipeline-passed 标签） See merge request: Ascend/pytorch!48034 | 2 天前 | |
[master][bugfix]cann and pta header mixing bulid bugfix Co-authored-by: Dring<17737727613@163.com> # message auto-generated for no-merge-commit merge: !44990 merge master into master [master][bugfix]cann and pta header mixing bulid bugfix Created-by: Dring Commit-by: Dring Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20260203 --> # 【合入来源】 > <font color="red">**如有社区issue，请关联issue链接**</font>\ > <font color="red">**请勿携带内部流程信息（需求链接、问题单、内部issue等）**</font> https://gitcode.com/Ascend/pytorch/issues/3991 - [✕ ] 需求 - [ ✓] 问题单 - [ ✓] issue/工单 - [ ✓] 重构优化 - [✕ ] 资料更新 # 【修改方案】 > 请描述修改内容的具体实现，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列\ > 如果是需求或者重构类的PR，需要补充详细设计文档（说明上下游组件关系、时序图、类图、DFX能力等内容） 问题现象： PTA 26.1.0 仓库中的 third_party/acl 头文件来自 CANN 9.1.0，而编译环境安装的是 CANN 9.0.0。当同一个编译单元同时包含两套版本的 ACL 头文件时，会出现类似以下错误：aclmdlRITask 未声明、未定义或类型不匹配 aclmdlRITask 是 CANN 9.1.0 头文件所依赖的定义，但 CANN 9.0.0 对应头文件中不存在该定义或定义不兼容。 根因分析： 1 当前头文件查找路径不统一：PTA 源码中大量使用以下写法 #include "third_party/acl/inc/acl/acl_mdl.h" 因为编译命令中包含 PTA 项目根目录，这种写法会直接命中 PTA 26.1.0 仓库内由 CANN 9.1.0 导入的头文件：torch_npu/third_party/acl/inc/acl/acl_mdl.h 但该头文件内部使用的是标准 SDK 相对路径：#include "acl/acl_base.h" 编译器无法相对 acl_mdl.h 所在目录找到 acl/acl_base.h，因此转而按照全部 -I 目录依次搜索。如果 CANN 9.0.0 的 include 路径排在 PTA 内置 ACL 路径前面，就会命中：CANN-9.0.0/include/acl/acl_base.h 同一个翻译单元最终形成： acl_mdl.h -> PTA third_party 中的 CANN 9.1.0 版本 acl_base.h -> 环境 CANN 9.0.0 版本 这是一种“首层头文件由源码路径固定版本、传递头文件由 -I 顺序选择版本”的混合查找模式。 2 问题不局限于 acl_mdl.h 同样风险存在于所有能够继续 include 其他 CANN 头文件的入口，包括： acl/... aml/... profiling/... graph/... ge/... op_proto/... 因此不能只修复出现错误的某一个头文件，也不能只替换 acl_mdl.h。必须统一整个 CANN 头文件族的查找规则。 修改目标： 修改后需要满足 源码不再包含 third_party/acl/inc/... 这种仓库物理路径。 ACL、AML、profiling 等头文件全部通过统一 include root 查找。 一个编译 target 对 CANN 头文件只选择一套版本。 CANN 9.0.0 环境构建时，首层和传递头文件必须全部命中 CANN 9.0.0。 使用 PTA 内置头文件构建时，首层和传递头文件必须全部命中 PTA 内置的同一套版本。 wheel、libtorch_npu、C++ Extension 和 Inductor/AOT 使用同一目录契约 修改方案： 1、代码中使用 PTA 内置 ACL 头文件的地方，删除 third_party/acl/inc/ 物理路径前缀，统一改成从 include root 查找 2、打包或安装时，把 third_party/acl/inc 下需要公开的目录按原相对结构复制到安装产物的公共 include 根目录 # 【资料变更】 > 请确认是否涉及资料变更。如涉及，需要在PR中体现，并简要说明修改内容。如不涉及，需填写“不涉及” 不涉及 # 【接口变更】 > 请确认是否涉及跨代码仓或者客户面可见的接口变更。如涉及，需要详细说明接口以及对应的变更内容，同时需要在资料中体现。如不涉及，需填写“不涉及” 不涉及 # 【功能验证】 > 说明测试场景，测试方法。如果本次测试方式与常规单元测试不同，请详细说明您的测试步骤\ > 新增/变更内容是否已新增/适配UT测试用例看护，并补充测试自验证截图 cann 9.0.0 + pta 26.1.0的vllm-ascend安装验证成功  # 【CheckList】 > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] - [✓ ] 代码注释完备，正确记录错误日志 - [✕ ] 代码实现进行了返回值、空指针等校验 - [✓ ] PR标题正确使用类型标签，如：feat、fix、refactor、docs、test等 - [✓ ] PR持续集成流水线（CI）执行通过，代码检查无异常 See merge request: Ascend/pytorch!44990 | 1 个月前 | |
[fix] fix memory config testcase Co-authored-by: liujunzhu<liujunzhu@huawei.com> # message auto-generated for no-merge-commit merge: !41705 merge master into master [fix] fix memory config testcase Created-by: liujunzhu Commit-by: liujunzhu Merged-by: ascend-robot Description: <!-- PR描述模板更新日期：20260203 --> # 【合入来源】 > <font color="red">**如有社区issue，请关联issue链接**</font>\ > <font color="red">**请勿携带内部流程信息（需求链接、问题单、内部issue等）**</font> - [x] 需求 - [ ] 问题单 - [ ] issue/工单 - [ ] 重构优化 - [ ] 资料更新 # 【修改方案】 > 请描述修改内容的具体实现，涉及哪些组件之间进行交互，可以用1、2、3、...进行罗列\ > 如果是需求或者重构类的PR，需要补充详细设计文档（说明上下游组件关系、时序图、类图、DFX能力等内容） 修复 throw_on_npumalloc_oom 、 pinned_max_round_threshold_mb 和 pinned_max_cached_size_mb的用例问题。 # 【资料变更】 > 请确认是否涉及资料变更。如涉及，需要在PR中体现，并简要说明修改内容。如不涉及，需填写“不涉及” 不涉及 # 【接口变更】 > 请确认是否涉及跨代码仓或者客户面可见的接口变更。如涉及，需要详细说明接口以及对应的变更内容，同时需要在资料中体现。如不涉及，需填写“不涉及” 不涉及 # 【功能验证】 > 说明测试场景，测试方法。如果本次测试方式与常规单元测试不同，请详细说明您的测试步骤\ > 新增/变更内容是否已新增/适配UT测试用例看护，并补充测试自验证截图 通过CI验证。 # 【CheckList】 > PR提交人对以下CheckList自检项进行全量自检，自检通过或不涉及，均修改 [ ] 为 [x] - [x] 代码注释完备，正确记录错误日志 - [x] 代码实现进行了返回值、空指针等校验 - [x] PR标题正确使用类型标签，如：feat、fix、refactor、docs、test等 - [x] PR持续集成流水线（CI）执行通过，代码检查无异常 See merge request: Ascend/pytorch!41705 | 3 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 个月前 | ||
| 5 个月前 | ||
| 2 天前 | ||
| 1 个月前 | ||
| 3 个月前 |