MemCache是针对AI推理场景设计的高性能分布式KVCache缓存,针对昇腾超节点、服务器的实现了精细化性能调优,提供较好的High Availability能力, 同时对接到vllm-ascend、sglang等开源推理框架
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[doc]新增版本说明书;将资料移至 docs/zh 目录下,并同步更新受影响文档 Co-authored-by: whytao<weitao46@h-partners.com> # message auto-generated for no-merge-commit merge: !531 merge develop into develop [doc]新增版本说明书;将资料移至 docs/zh 目录下,并同步更新受影响文档 Created-by: whytao Commit-by: whytao Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue fixed: [#275](https://atomgit.com/Ascend/memcache/issues/275) # 问题/功能描述 # 修改方案描述 新增版本说明书;将资料移至 docs/zh 目录下,并同步更新受影响文档。 # 是否涉及UT/ST - [ ] 是 - [ ] 否(说明理由) # 开发自检 - [ ] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [ ] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [ ] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [ ] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [ ] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [ ] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!531 | 22 天前 | |
【ci】修复devcontainer校验脚本的容器残留、SIGPIPE中止与NPU选卡问题 Co-authored-by: littleyellowbicycle<liguo29@h-partners.com> # message auto-generated for no-merge-commit merge: !482 merge fix_ci into develop 【ci】修复devcontainer校验脚本的容器残留、SIGPIPE中止与NPU选卡问题 Created-by: littleyellowbicycle Commit-by: littleyellowbicycle Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [ √] issue # 问题/功能描述 1. 特殊情况会残留容器 2. 执行用例前没有校验使用的卡是否空闲 # 修改方案描述 1. 退出时增强清理残留容器的流程 2. 在 NPU 探测之后, 选一张空闲卡并让子进程继承。各段原有的 NPU_IDLE -lt 1 整段 skip 逻辑保留——0 张空闲仍整段跳过,这只在 ≥1 张空闲时选卡 # 是否涉及UT/ST - [ √] 是 - [ ] 否(说明理由) # 开发自检 - [ √] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ √] 规范:已关联issue或里程碑 - [ √] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [ √] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [ √] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [ √] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [ √] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!482 | 1 个月前 | |
pre-commit检查改为增量检查 Co-authored-by: monkeyLoveding<2801406898@qq.com> # message auto-generated for no-merge-commit merge: !608 merge master into master pre-commit检查改为增量检查 Created-by: wangqi0808 Commit-by: monkeyLoveding Merged-by: yrewzjsx Description: 将 pre-commit 检查从全量检查(--all-files)改为增量检查,仅对变更文件进行检查,提升 PR 门禁效率。 See merge request: Ascend/memcache!608 | 7 天前 | |
refactor: memcache通过运行时C ABI解耦memfabric Co-authored-by: zhangjialee<z3262749952@163.com> # message auto-generated for no-merge-commit merge: !536 merge fix/memfabric-decouple into develop refactor: memcache通过运行时C ABI解耦memfabric Created-by: zhangjialee Commit-by: zhangjialee Merged-by: chenyz6 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue 关联 issue:[Ascend/memcache #281](https://gitcode.com/Ascend/memcache/issues/281) # 问题/功能描述 Issue #281:MemCache 将 MemFabric 作为三方库参与编译并直接使用其 C++ 类型。编译期 MF 与运行时 libmf_smem.so 的小版本或 C++ ABI 不一致时,同名 C++/STL 符号可能发生进程级抢占,MetaService 在 AccCommonServerOptions::operator=、std::string::assign 等位置 coredump。普通 dlopen 仍不足以隔离两套 C++ ABI。 # 修改方案描述 修改点: - 删除 MemCache 对 3rdparty/memfabric_hybrid 的编译、链接、头文件及 Python 包依赖,运行时固定加载 libmf_smem.so,不新增环境变量。 - ACC、ConfigStore、BM 分模块定义 def/API 封装,通过 dlopen/dlsym 调用 MF 纯 C ABI,并保持原有 C++ 驼峰调用接口。 - ConfigStore 适配类使用 ock::mmc_smem 实际命名空间,通过 ock::smem 别名保持调用侧不变,避免与 MF 原生 ock::smem C++ 符号冲突。 - dlopen 使用 RTLD_NOW | RTLD_LOCAL | RTLD_DEEPBIND,隔离 ABI0/ABI1 的 libstdc++ 弱模板符号。 - 兼容性匹配规则: - 版本来源:MMC 和 MF 均使用各自根目录的 VERSION。 - 版本编码:高 16 位为 major,低 16 位为 minor。 - 匹配条件:MMC 与运行时 MF 的 major.minor 必须完全一致,patch 不参与匹配。 - 当前分支:develop 为 1.3.x,仅匹配 MF 1.3.x;1.1.x、1.2.x 等其他版本线均拒绝加载。 - 必需接口:MF 必须导出 smem_get_abi_version,以及 MMC 实际使用的 ACC、ConfigStore、BM 模块全部必需 C ABI 符号。 - 失败行为:任一必需符号缺失或版本不匹配,均记录期望/实际版本或缺失符号并快速退出,避免 coredump。 - 结构长度:当前没有独立的结构长度字段校验,C ABI 结构布局兼容性由相同 major.minor 约束。 - Python 绑定的复制方向默认值显式转换为 int32_t,避免未注册枚举导致模块导入失败。 # 测试结果: 验证结果: - 构建与单元测试:develop DEBUG 构建成功,release/1.2 完整构建 221/221 成功;test_mf_smem_api 2/2 PASSED。 - C++ ABI 组合启动:同一 MMC 产物分别加载采用 libstdc++ ABI0、ABI1 构建的兼容版本 MF,MetaService 均启动成功,/health 返回 HTTP 200。 - 异常依赖启动:缺少 libmf_smem.so、缺少 smem_get_abi_version、缺少模块必需符号或 major.minor 不匹配时,均输出明确错误并快速退出,无 core。 - ELF 解耦检查:libmf_memcache.so 不包含对 libmf_smem.so、libacc_tcp_net.so 的 DT_NEEDED,也不存在未解析 ock::smem C++ 符号。 - CPU/host_shm benchmark:MF ABI0、ABI1 组合均完成写读,读取返回 0,逐轮写读校验和一致。 - NPU 基础初始化:acl.init 及两张 NPU 卡的 acl.rt.set_device 均返回 0,MetaService 健康检查通过。 - 双卡 device_sdma benchmark:每卡写读 256 MiB;卡 1 写/读 1.616/1.463 GB/s,写读校验和均为 1070032372;卡 2 写/读 1.571/1.481 GB/s,写读校验和均为 1069712602;读取返回 0,无 core。 - 四卡端到端推理验证: - 软件组合:vLLM 0.23.0、Qwen3-32B-W8A8、TP=4;模型列表接口返回 HTTP 200,聊天冒烟请求成功生成 64 tokens,各 TP worker 加载约 9.994 GiB 权重。 - 并发 1:8/8 请求成功、0 失败;耗时 19.58 s,请求吞吐 0.41 req/s,输出吞吐 52.31 tok/s,总吞吐 470.77 tok/s;平均 TTFT 155.15 ms,P99 TTFT 172.99 ms,平均 TPOT 18.04 ms,P99 TPOT 18.08 ms。 - 并发 16:32/32 请求成功、0 失败;耗时 6.07 s,请求吞吐 5.27 req/s,输出吞吐 674.48 tok/s,峰值输出吞吐 768 tok/s,总吞吐 6070.29 tok/s;平均 TTFT 335.07 ms,P99 TTFT 364.77 ms,平均 TPOT 21.24 ms,P99 TPOT 22.30 ms。 # 是否涉及UT/ST - [x] 是:已执行,结果见“测试结果”章节 - [ ] 否(说明理由): # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [x] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!536 | 15 天前 | |
[feature] 配置文件解析增加 ock.mmc 前缀过滤及加载清单打印 Co-authored-by: gcw_qYJeyWK4<jiangbo97@huawei.com> # message auto-generated for no-merge-commit merge: !389 merge feature/config-prefix-filter into develop [feature] 配置文件解析增加 ock.mmc 前缀过滤及加载清单打印 Created-by: gcw_qYJeyWK4 Commit-by: gcw_qYJeyWK4 Merged-by: yrewzjsx Description: # 合入来源 - [x] 需求 - [ ] 问题单 - [ ] issue # 问题/功能描述 # 修改方案描述 新增 ock.mmc. 前缀过滤:在 mmc_kv_parser.cpp 的 KVParser::ParseLine 中,对 key 不以 "ock.mmc." 开头的行直接返回 MMC_OK,跳过后续的 SetItem 设置,仅加载目标前缀下的配置项。 新增配置加载清单打印:在 mmc_configuration.cpp 的 Configuration::LoadFromFile 中,解析完成后遍历所有配置项,通过 MMC_LOG_INFO 逐个输出 key = value,方便确认实际生效的配置。 新增 StartsWith 工具函数:在 mmc_functions.h 中添加 StartsWith 内联函数,用于判断字符串是否以指定前缀开头,作为前缀过滤判断的基础能力。 # 是否涉及UT/ST - [x] 是 - [ ] 否(说明理由) # 开发自检 - [ ] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [ ] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [ ] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [ ] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [ ] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [ ] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!389 | 2 个月前 | |
feat: 支持UBSIO文件语义元数据分离 Co-authored-by: zhangjialee<z3262749952@163.com> # message auto-generated for no-merge-commit merge: !606 merge feat/ubsio-filesystem-metadata-separation into master feat: 支持UBSIO文件语义元数据分离 Created-by: zhangjialee Commit-by: zhangjialee Merged-by: yangchangjie12138 Description: # 合入来源 - [x] 需求 - [ ] 问题单 - [ ] issue # 问题/功能描述 - UBSIO 对接文件语义后,SSD key 与 value size 由 UBSIO 管理,MetaService 仅查询 DRAM 元数据时无法发现 SSD-only key。 - 文件语义的 Get、BatchGet、Query、BatchQuery 和预取需要先取得真实 value size、申请 DRAM Blob,再从共享文件系统回温;缺失该链路会降低外部命中并影响 Layerwise 返回 GVA。 - 新增能力需要与现有 KV/块设备聚合元数据模式兼容,且不能改变 DRAM 命中、异步淘汰和已有 Layerwise 语义。 # 修改方案描述 - 增加统一存储配置,LocalService 初始化时获取 SSD 元数据模式;分离模式由 UBSIO 管理 SSD key,聚合模式继续使用 MetaService 中的 SSD Blob。 - 增加 BatchStorageStat RPC,在文件语义 SSD-only miss、Query/BatchQuery 和预取路径获取真实 value size,并按 allocator 分配结果将 key 按 rank 聚合后执行 BatchGet 回温。 - Exist/BatchExist、Get/BatchGet、Query/BatchQuery 与 Layerwise 共用一致的文件语义发现和回温规则,回温后的 DRAM Blob 继续使用已有状态机、租约和命中统计。 - 分离模式刷盘完成后不向 MetaService 持久化 SSD Blob,异步刷盘、临时文件提交和 SSD 生命周期由 UBSIO 管理;聚合模式行为保持不变。 - 补齐 UBSIO BatchStat 动态加载、RPC/接口 trace、配置说明及协议序列化测试,并保留 master 的 Blob 解锁释放和 BatchPromote 逻辑。  详细设计:[Memcache ubsio 文件语义与固态盘元数据分离设计](https://gitcode.com/zhangjialee/memcache/wiki/Memcache%20ubsio%20%E6%96%87%E4%BB%B6%E8%AF%AD%E4%B9%89%E4%B8%8E%E5%9B%BA%E6%80%81%E7%9B%98%E5%85%83%E6%95%B0%E6%8D%AE%E5%88%86%E7%A6%BB%E8%AE%BE%E8%AE%A1) # 测试结果: - C++ UT/ST:覆盖存储模式配置、初始化配置消息、BatchStorageStat 消息、LocalService UBSIO 调用、MetaService SSD-only 分类与批量回温、KV 聚合模式兼容及 UBSIO proxy;代码已包含测试。本机定向 UT 因 Windows Bash 服务 E_ACCESSDENIED 未启动,远端功能与性能验证结果如下。 - MemCache benchmark:覆盖异步刷盘、SSD-only key 发现、Get/BatchGet 回温、回温后 DRAM 命中、混合命中逐项结果,以及不同长度和复用间隔的连续多轮执行;执行至第 9 轮后结束并清理测试文件。 - 预取与 Layerwise:验证 Exist/BatchExist 预取、Query/BatchQuery 同步回温并返回 GVA,以及 Qwen3 Layerwise 下 vLLM、MemCache、UBSIO 三层 key 形态。 - MiniMax-M2.5 TP8 128K:40 请求、并发 1、输出 512 时,文件语义与 KV 输入吞吐分别为 3616.92/2176.88 tok/s,命中率均为 78.08%,请求全部成功;96 请求、95% 命中时分别为 3954.19/2347.80 tok/s,KV 组出现 Eagle3 acceptance 异常;192 请求、并发 4、输出 1、95% 命中时分别为 32654.32/25216.30 tok/s,请求全部成功。  **DeepSeek-V4-Flash TP8 128K 九轮长稳结果(40 请求/轮、并发 4、输出 1)** | 轮次 | 成功/失败 | 时长(s) | tok/s | Mean TTFT(ms) | P99 TTFT(ms) | 外部命中率 | | --- | --- | ---: | ---: | ---: | ---: | ---: | | 1 | 40/0 | 74.17 | 69,033.39 | 7,189.33 | 9,466.59 | 89.60% | | 2 | 40/0 | 70.71 | 72,409.59 | 6,857.10 | 9,462.37 | 89.60% | | 3 | 40/0 | 75.91 | 67,444.47 | 7,357.57 | 9,407.89 | 89.60% | | 4 | 40/0 | 75.99 | 67,378.60 | 7,357.01 | 9,706.51 | 89.60% | | 5 | 40/0 | 73.74 | 69,435.91 | 7,137.52 | 9,296.72 | 89.60% | | 6 | 40/0 | 78.80 | 64,972.31 | 7,629.17 | 9,776.00 | 89.60% | | 7 | 40/0 | 75.72 | 67,618.25 | 7,346.03 | 9,732.46 | 89.60% | | 8 | 40/0 | 77.79 | 65,818.52 | 7,545.00 | 9,693.00 | 89.60% | | 9 | 40/0 | 77.20 | 66,319.10 | 7,480.51 | 9,592.78 | 89.60% | | 平均 | 360/0 | 75.56 | 67,825.57 | 7,322.14 | 9,570.48 | 89.60% | - DeepSeek-V4-Flash TP8 128K:相同 900 MB/worker DRAM、40 请求、并发 4、输出 1 和同一 ABCCBA 数据集下,纯 DRAM、本地块设备、NFS 文件系统命中率分别为 55.68%/89.60%/87.36%,Token 吞吐分别为 25498/71073/41777 tok/s,Mean TTFT 分别为 19.89/7.02/12.07 s。 - 分层时延:NFS BatchExist 入口到出口平均 19.780 ms,NFS BatchGet 平均 681.202 ms;NFS UnderFS 单对象 Get 平均 536.082 ms,其中 pread 337.432 ms。上层 BatchPut 在三组均约 1.5 ms,说明异步刷盘未阻塞主写路径;NFS 后台 UnderFS Put 平均 489.163 ms。 - NFS 远端共享文件系统链路请求可完成,但历史回归轮次出现 431 次 SSD 回温失败:NFS READ 平均执行 262.54 ms,叠加排队与长尾超过 300 ms pending wait,失败请求由 recompute 完成。该项记录为已知未通过条件,不作为 SSD 回温零失败结论。 # 是否涉及UT/ST - [x] 是:已执行,结果见“测试结果”章节 - [ ] 否(说明理由): # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!606 | 3 天前 | |
feat: 支持UBSIO文件语义元数据分离 Co-authored-by: zhangjialee<z3262749952@163.com> # message auto-generated for no-merge-commit merge: !606 merge feat/ubsio-filesystem-metadata-separation into master feat: 支持UBSIO文件语义元数据分离 Created-by: zhangjialee Commit-by: zhangjialee Merged-by: yangchangjie12138 Description: # 合入来源 - [x] 需求 - [ ] 问题单 - [ ] issue # 问题/功能描述 - UBSIO 对接文件语义后,SSD key 与 value size 由 UBSIO 管理,MetaService 仅查询 DRAM 元数据时无法发现 SSD-only key。 - 文件语义的 Get、BatchGet、Query、BatchQuery 和预取需要先取得真实 value size、申请 DRAM Blob,再从共享文件系统回温;缺失该链路会降低外部命中并影响 Layerwise 返回 GVA。 - 新增能力需要与现有 KV/块设备聚合元数据模式兼容,且不能改变 DRAM 命中、异步淘汰和已有 Layerwise 语义。 # 修改方案描述 - 增加统一存储配置,LocalService 初始化时获取 SSD 元数据模式;分离模式由 UBSIO 管理 SSD key,聚合模式继续使用 MetaService 中的 SSD Blob。 - 增加 BatchStorageStat RPC,在文件语义 SSD-only miss、Query/BatchQuery 和预取路径获取真实 value size,并按 allocator 分配结果将 key 按 rank 聚合后执行 BatchGet 回温。 - Exist/BatchExist、Get/BatchGet、Query/BatchQuery 与 Layerwise 共用一致的文件语义发现和回温规则,回温后的 DRAM Blob 继续使用已有状态机、租约和命中统计。 - 分离模式刷盘完成后不向 MetaService 持久化 SSD Blob,异步刷盘、临时文件提交和 SSD 生命周期由 UBSIO 管理;聚合模式行为保持不变。 - 补齐 UBSIO BatchStat 动态加载、RPC/接口 trace、配置说明及协议序列化测试,并保留 master 的 Blob 解锁释放和 BatchPromote 逻辑。  详细设计:[Memcache ubsio 文件语义与固态盘元数据分离设计](https://gitcode.com/zhangjialee/memcache/wiki/Memcache%20ubsio%20%E6%96%87%E4%BB%B6%E8%AF%AD%E4%B9%89%E4%B8%8E%E5%9B%BA%E6%80%81%E7%9B%98%E5%85%83%E6%95%B0%E6%8D%AE%E5%88%86%E7%A6%BB%E8%AE%BE%E8%AE%A1) # 测试结果: - C++ UT/ST:覆盖存储模式配置、初始化配置消息、BatchStorageStat 消息、LocalService UBSIO 调用、MetaService SSD-only 分类与批量回温、KV 聚合模式兼容及 UBSIO proxy;代码已包含测试。本机定向 UT 因 Windows Bash 服务 E_ACCESSDENIED 未启动,远端功能与性能验证结果如下。 - MemCache benchmark:覆盖异步刷盘、SSD-only key 发现、Get/BatchGet 回温、回温后 DRAM 命中、混合命中逐项结果,以及不同长度和复用间隔的连续多轮执行;执行至第 9 轮后结束并清理测试文件。 - 预取与 Layerwise:验证 Exist/BatchExist 预取、Query/BatchQuery 同步回温并返回 GVA,以及 Qwen3 Layerwise 下 vLLM、MemCache、UBSIO 三层 key 形态。 - MiniMax-M2.5 TP8 128K:40 请求、并发 1、输出 512 时,文件语义与 KV 输入吞吐分别为 3616.92/2176.88 tok/s,命中率均为 78.08%,请求全部成功;96 请求、95% 命中时分别为 3954.19/2347.80 tok/s,KV 组出现 Eagle3 acceptance 异常;192 请求、并发 4、输出 1、95% 命中时分别为 32654.32/25216.30 tok/s,请求全部成功。  **DeepSeek-V4-Flash TP8 128K 九轮长稳结果(40 请求/轮、并发 4、输出 1)** | 轮次 | 成功/失败 | 时长(s) | tok/s | Mean TTFT(ms) | P99 TTFT(ms) | 外部命中率 | | --- | --- | ---: | ---: | ---: | ---: | ---: | | 1 | 40/0 | 74.17 | 69,033.39 | 7,189.33 | 9,466.59 | 89.60% | | 2 | 40/0 | 70.71 | 72,409.59 | 6,857.10 | 9,462.37 | 89.60% | | 3 | 40/0 | 75.91 | 67,444.47 | 7,357.57 | 9,407.89 | 89.60% | | 4 | 40/0 | 75.99 | 67,378.60 | 7,357.01 | 9,706.51 | 89.60% | | 5 | 40/0 | 73.74 | 69,435.91 | 7,137.52 | 9,296.72 | 89.60% | | 6 | 40/0 | 78.80 | 64,972.31 | 7,629.17 | 9,776.00 | 89.60% | | 7 | 40/0 | 75.72 | 67,618.25 | 7,346.03 | 9,732.46 | 89.60% | | 8 | 40/0 | 77.79 | 65,818.52 | 7,545.00 | 9,693.00 | 89.60% | | 9 | 40/0 | 77.20 | 66,319.10 | 7,480.51 | 9,592.78 | 89.60% | | 平均 | 360/0 | 75.56 | 67,825.57 | 7,322.14 | 9,570.48 | 89.60% | - DeepSeek-V4-Flash TP8 128K:相同 900 MB/worker DRAM、40 请求、并发 4、输出 1 和同一 ABCCBA 数据集下,纯 DRAM、本地块设备、NFS 文件系统命中率分别为 55.68%/89.60%/87.36%,Token 吞吐分别为 25498/71073/41777 tok/s,Mean TTFT 分别为 19.89/7.02/12.07 s。 - 分层时延:NFS BatchExist 入口到出口平均 19.780 ms,NFS BatchGet 平均 681.202 ms;NFS UnderFS 单对象 Get 平均 536.082 ms,其中 pread 337.432 ms。上层 BatchPut 在三组均约 1.5 ms,说明异步刷盘未阻塞主写路径;NFS 后台 UnderFS Put 平均 489.163 ms。 - NFS 远端共享文件系统链路请求可完成,但历史回归轮次出现 431 次 SSD 回温失败:NFS READ 平均执行 262.54 ms,叠加排队与长尾超过 300 ms pending wait,失败请求由 recompute 完成。该项记录为已知未通过条件,不作为 SSD 回温零失败结论。 # 是否涉及UT/ST - [x] 是:已执行,结果见“测试结果”章节 - [ ] 否(说明理由): # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!606 | 3 天前 | |
feat: LRU 分片降低高并发锁竞争 Co-authored-by: lirui7717<lirui7717@163.com> # message auto-generated for no-merge-commit merge: !607 merge feat/sharded-lru-global-eviction-methodology into master feat: LRU 分片降低高并发锁竞争 Created-by: lirui7717 Commit-by: lirui7717 Merged-by: yangchangjie12138 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue 本pr 来源自https://gitcode.com/Ascend/memcache/pull/401 # 问题/功能描述 - 当前所有 Put、Get 等请求共享同一条 LRU 链及其锁。高并发场景下,不同 key 的操作也会互相等待,LRU 锁竞争成为性能瓶颈。 - 由于分shard 导致benchmark 太快,发现backup还没完成client就注销了, backup 线程和注销线程形成死锁。 # 修改方案描述 将单条全局 LRU 链拆分为 16 个 shard。 每个 shard 维护独立的 LRU 链和锁,key 按 hash 分配到对应 shard。不同 shard 的请求可以并发执行,减少锁竞争;同一 key 始终落在固定 shard,原有 LRU 语义保持不变。 其中改动最大的是MultiLevelElimination 也就是基于shard 全局淘汰。其思想是这样的: 1. 先轻量级收集每个shard的最后一个节点的每个访问序号,用最小堆选出全局淘汰的边界。 2. 确定全局淘汰边界后,再把边界以内的真实 key 候选收集出来。 3. 正常候选不够目标数,说明两个阶段之间发生了较严重的并发变化, 重新收集candidate,重新计算边界 4. 最后在锁的保护下实现真正的驱逐 默认为shard_lru ock.mmc.meta_service.lru_shard_count = 16 死锁解决方案为:直接不让注销线程和backup线程并行,已经启动backup的就继续backup,还没backup的就取消,之后注销线程等backup结束后再注销。 执行 bash script/build_and_pack_run.sh --build_mode RELEASE --build_cpp_example ON RUN_ARGS='-p 4 -t 4 -n 20000 -k 20000 -w 4000 -s 65536 -c 64 -r 30 -b 16,32' ./build/example/meta_service_bench/bench_meta_service $RUN_ARGS | 指标 | 非 Shard | Shard | Shard + 淘汰优化| | ------- | ---------: | ---------: |-------------: | | Get Avg | 300 us | 145 us | **171 us** | | Get P95 | 1024 us | 256 us | **512 us** | | Get P99 | 1024 us | 512 us | **512 us** | | Put Avg | 11.3 ms | 16.2 ms | **8.57 ms** | | 吞吐 | 4400 ops/s | 3187 ops/s | **5911 ops/s** | # 是否涉及UT/ST - [x] 是 新增/更新 UT,覆盖: - key 能稳定分配到对应 shard; - 各 shard 的插入、查询、淘汰行为正确; - 并发访问不同 shard 时功能正常。 - [ ] 否(说明理由) # 开发自检 - [ ] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!607 | 3 天前 | |
[反合][docs]根据doc tools扫描结果优化资料 Co-authored-by: whytao<weitao46@h-partners.com> # message auto-generated for no-merge-commit merge: !418 merge develop into develop [反合][docs]根据doc tools扫描结果优化资料 Created-by: whytao Commit-by: whytao Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue fixes [#190](https://gitcode.com/Ascend/memcache/issues/190) # 问题/功能描述 # 修改方案描述 # 是否涉及UT/ST - [ ] 是 - [x ] 否(说明理由) # 开发自检 - [ ] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [ ] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [ ] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [ ] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [ ] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [ ] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!418 | 1 个月前 | |
feat: LRU 分片降低高并发锁竞争 Co-authored-by: lirui7717<lirui7717@163.com> # message auto-generated for no-merge-commit merge: !607 merge feat/sharded-lru-global-eviction-methodology into master feat: LRU 分片降低高并发锁竞争 Created-by: lirui7717 Commit-by: lirui7717 Merged-by: yangchangjie12138 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue 本pr 来源自https://gitcode.com/Ascend/memcache/pull/401 # 问题/功能描述 - 当前所有 Put、Get 等请求共享同一条 LRU 链及其锁。高并发场景下,不同 key 的操作也会互相等待,LRU 锁竞争成为性能瓶颈。 - 由于分shard 导致benchmark 太快,发现backup还没完成client就注销了, backup 线程和注销线程形成死锁。 # 修改方案描述 将单条全局 LRU 链拆分为 16 个 shard。 每个 shard 维护独立的 LRU 链和锁,key 按 hash 分配到对应 shard。不同 shard 的请求可以并发执行,减少锁竞争;同一 key 始终落在固定 shard,原有 LRU 语义保持不变。 其中改动最大的是MultiLevelElimination 也就是基于shard 全局淘汰。其思想是这样的: 1. 先轻量级收集每个shard的最后一个节点的每个访问序号,用最小堆选出全局淘汰的边界。 2. 确定全局淘汰边界后,再把边界以内的真实 key 候选收集出来。 3. 正常候选不够目标数,说明两个阶段之间发生了较严重的并发变化, 重新收集candidate,重新计算边界 4. 最后在锁的保护下实现真正的驱逐 默认为shard_lru ock.mmc.meta_service.lru_shard_count = 16 死锁解决方案为:直接不让注销线程和backup线程并行,已经启动backup的就继续backup,还没backup的就取消,之后注销线程等backup结束后再注销。 执行 bash script/build_and_pack_run.sh --build_mode RELEASE --build_cpp_example ON RUN_ARGS='-p 4 -t 4 -n 20000 -k 20000 -w 4000 -s 65536 -c 64 -r 30 -b 16,32' ./build/example/meta_service_bench/bench_meta_service $RUN_ARGS | 指标 | 非 Shard | Shard | Shard + 淘汰优化| | ------- | ---------: | ---------: |-------------: | | Get Avg | 300 us | 145 us | **171 us** | | Get P95 | 1024 us | 256 us | **512 us** | | Get P99 | 1024 us | 512 us | **512 us** | | Put Avg | 11.3 ms | 16.2 ms | **8.57 ms** | | 吞吐 | 4400 ops/s | 3187 ops/s | **5911 ops/s** | # 是否涉及UT/ST - [x] 是 新增/更新 UT,覆盖: - key 能稳定分配到对应 shard; - 各 shard 的插入、查询、淘汰行为正确; - 并发访问不同 shard 时功能正常。 - [ ] 否(说明理由) # 开发自检 - [ ] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!607 | 3 天前 | |
feat: 支持UBSIO文件语义元数据分离 Co-authored-by: zhangjialee<z3262749952@163.com> # message auto-generated for no-merge-commit merge: !606 merge feat/ubsio-filesystem-metadata-separation into master feat: 支持UBSIO文件语义元数据分离 Created-by: zhangjialee Commit-by: zhangjialee Merged-by: yangchangjie12138 Description: # 合入来源 - [x] 需求 - [ ] 问题单 - [ ] issue # 问题/功能描述 - UBSIO 对接文件语义后,SSD key 与 value size 由 UBSIO 管理,MetaService 仅查询 DRAM 元数据时无法发现 SSD-only key。 - 文件语义的 Get、BatchGet、Query、BatchQuery 和预取需要先取得真实 value size、申请 DRAM Blob,再从共享文件系统回温;缺失该链路会降低外部命中并影响 Layerwise 返回 GVA。 - 新增能力需要与现有 KV/块设备聚合元数据模式兼容,且不能改变 DRAM 命中、异步淘汰和已有 Layerwise 语义。 # 修改方案描述 - 增加统一存储配置,LocalService 初始化时获取 SSD 元数据模式;分离模式由 UBSIO 管理 SSD key,聚合模式继续使用 MetaService 中的 SSD Blob。 - 增加 BatchStorageStat RPC,在文件语义 SSD-only miss、Query/BatchQuery 和预取路径获取真实 value size,并按 allocator 分配结果将 key 按 rank 聚合后执行 BatchGet 回温。 - Exist/BatchExist、Get/BatchGet、Query/BatchQuery 与 Layerwise 共用一致的文件语义发现和回温规则,回温后的 DRAM Blob 继续使用已有状态机、租约和命中统计。 - 分离模式刷盘完成后不向 MetaService 持久化 SSD Blob,异步刷盘、临时文件提交和 SSD 生命周期由 UBSIO 管理;聚合模式行为保持不变。 - 补齐 UBSIO BatchStat 动态加载、RPC/接口 trace、配置说明及协议序列化测试,并保留 master 的 Blob 解锁释放和 BatchPromote 逻辑。  详细设计:[Memcache ubsio 文件语义与固态盘元数据分离设计](https://gitcode.com/zhangjialee/memcache/wiki/Memcache%20ubsio%20%E6%96%87%E4%BB%B6%E8%AF%AD%E4%B9%89%E4%B8%8E%E5%9B%BA%E6%80%81%E7%9B%98%E5%85%83%E6%95%B0%E6%8D%AE%E5%88%86%E7%A6%BB%E8%AE%BE%E8%AE%A1) # 测试结果: - C++ UT/ST:覆盖存储模式配置、初始化配置消息、BatchStorageStat 消息、LocalService UBSIO 调用、MetaService SSD-only 分类与批量回温、KV 聚合模式兼容及 UBSIO proxy;代码已包含测试。本机定向 UT 因 Windows Bash 服务 E_ACCESSDENIED 未启动,远端功能与性能验证结果如下。 - MemCache benchmark:覆盖异步刷盘、SSD-only key 发现、Get/BatchGet 回温、回温后 DRAM 命中、混合命中逐项结果,以及不同长度和复用间隔的连续多轮执行;执行至第 9 轮后结束并清理测试文件。 - 预取与 Layerwise:验证 Exist/BatchExist 预取、Query/BatchQuery 同步回温并返回 GVA,以及 Qwen3 Layerwise 下 vLLM、MemCache、UBSIO 三层 key 形态。 - MiniMax-M2.5 TP8 128K:40 请求、并发 1、输出 512 时,文件语义与 KV 输入吞吐分别为 3616.92/2176.88 tok/s,命中率均为 78.08%,请求全部成功;96 请求、95% 命中时分别为 3954.19/2347.80 tok/s,KV 组出现 Eagle3 acceptance 异常;192 请求、并发 4、输出 1、95% 命中时分别为 32654.32/25216.30 tok/s,请求全部成功。  **DeepSeek-V4-Flash TP8 128K 九轮长稳结果(40 请求/轮、并发 4、输出 1)** | 轮次 | 成功/失败 | 时长(s) | tok/s | Mean TTFT(ms) | P99 TTFT(ms) | 外部命中率 | | --- | --- | ---: | ---: | ---: | ---: | ---: | | 1 | 40/0 | 74.17 | 69,033.39 | 7,189.33 | 9,466.59 | 89.60% | | 2 | 40/0 | 70.71 | 72,409.59 | 6,857.10 | 9,462.37 | 89.60% | | 3 | 40/0 | 75.91 | 67,444.47 | 7,357.57 | 9,407.89 | 89.60% | | 4 | 40/0 | 75.99 | 67,378.60 | 7,357.01 | 9,706.51 | 89.60% | | 5 | 40/0 | 73.74 | 69,435.91 | 7,137.52 | 9,296.72 | 89.60% | | 6 | 40/0 | 78.80 | 64,972.31 | 7,629.17 | 9,776.00 | 89.60% | | 7 | 40/0 | 75.72 | 67,618.25 | 7,346.03 | 9,732.46 | 89.60% | | 8 | 40/0 | 77.79 | 65,818.52 | 7,545.00 | 9,693.00 | 89.60% | | 9 | 40/0 | 77.20 | 66,319.10 | 7,480.51 | 9,592.78 | 89.60% | | 平均 | 360/0 | 75.56 | 67,825.57 | 7,322.14 | 9,570.48 | 89.60% | - DeepSeek-V4-Flash TP8 128K:相同 900 MB/worker DRAM、40 请求、并发 4、输出 1 和同一 ABCCBA 数据集下,纯 DRAM、本地块设备、NFS 文件系统命中率分别为 55.68%/89.60%/87.36%,Token 吞吐分别为 25498/71073/41777 tok/s,Mean TTFT 分别为 19.89/7.02/12.07 s。 - 分层时延:NFS BatchExist 入口到出口平均 19.780 ms,NFS BatchGet 平均 681.202 ms;NFS UnderFS 单对象 Get 平均 536.082 ms,其中 pread 337.432 ms。上层 BatchPut 在三组均约 1.5 ms,说明异步刷盘未阻塞主写路径;NFS 后台 UnderFS Put 平均 489.163 ms。 - NFS 远端共享文件系统链路请求可完成,但历史回归轮次出现 431 次 SSD 回温失败:NFS READ 平均执行 262.54 ms,叠加排队与长尾超过 300 ms pending wait,失败请求由 recompute 完成。该项记录为已知未通过条件,不作为 SSD 回温零失败结论。 # 是否涉及UT/ST - [x] 是:已执行,结果见“测试结果”章节 - [ ] 否(说明理由): # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!606 | 3 天前 | |
feat: 支持UBSIO文件语义元数据分离 Co-authored-by: zhangjialee<z3262749952@163.com> # message auto-generated for no-merge-commit merge: !606 merge feat/ubsio-filesystem-metadata-separation into master feat: 支持UBSIO文件语义元数据分离 Created-by: zhangjialee Commit-by: zhangjialee Merged-by: yangchangjie12138 Description: # 合入来源 - [x] 需求 - [ ] 问题单 - [ ] issue # 问题/功能描述 - UBSIO 对接文件语义后,SSD key 与 value size 由 UBSIO 管理,MetaService 仅查询 DRAM 元数据时无法发现 SSD-only key。 - 文件语义的 Get、BatchGet、Query、BatchQuery 和预取需要先取得真实 value size、申请 DRAM Blob,再从共享文件系统回温;缺失该链路会降低外部命中并影响 Layerwise 返回 GVA。 - 新增能力需要与现有 KV/块设备聚合元数据模式兼容,且不能改变 DRAM 命中、异步淘汰和已有 Layerwise 语义。 # 修改方案描述 - 增加统一存储配置,LocalService 初始化时获取 SSD 元数据模式;分离模式由 UBSIO 管理 SSD key,聚合模式继续使用 MetaService 中的 SSD Blob。 - 增加 BatchStorageStat RPC,在文件语义 SSD-only miss、Query/BatchQuery 和预取路径获取真实 value size,并按 allocator 分配结果将 key 按 rank 聚合后执行 BatchGet 回温。 - Exist/BatchExist、Get/BatchGet、Query/BatchQuery 与 Layerwise 共用一致的文件语义发现和回温规则,回温后的 DRAM Blob 继续使用已有状态机、租约和命中统计。 - 分离模式刷盘完成后不向 MetaService 持久化 SSD Blob,异步刷盘、临时文件提交和 SSD 生命周期由 UBSIO 管理;聚合模式行为保持不变。 - 补齐 UBSIO BatchStat 动态加载、RPC/接口 trace、配置说明及协议序列化测试,并保留 master 的 Blob 解锁释放和 BatchPromote 逻辑。  详细设计:[Memcache ubsio 文件语义与固态盘元数据分离设计](https://gitcode.com/zhangjialee/memcache/wiki/Memcache%20ubsio%20%E6%96%87%E4%BB%B6%E8%AF%AD%E4%B9%89%E4%B8%8E%E5%9B%BA%E6%80%81%E7%9B%98%E5%85%83%E6%95%B0%E6%8D%AE%E5%88%86%E7%A6%BB%E8%AE%BE%E8%AE%A1) # 测试结果: - C++ UT/ST:覆盖存储模式配置、初始化配置消息、BatchStorageStat 消息、LocalService UBSIO 调用、MetaService SSD-only 分类与批量回温、KV 聚合模式兼容及 UBSIO proxy;代码已包含测试。本机定向 UT 因 Windows Bash 服务 E_ACCESSDENIED 未启动,远端功能与性能验证结果如下。 - MemCache benchmark:覆盖异步刷盘、SSD-only key 发现、Get/BatchGet 回温、回温后 DRAM 命中、混合命中逐项结果,以及不同长度和复用间隔的连续多轮执行;执行至第 9 轮后结束并清理测试文件。 - 预取与 Layerwise:验证 Exist/BatchExist 预取、Query/BatchQuery 同步回温并返回 GVA,以及 Qwen3 Layerwise 下 vLLM、MemCache、UBSIO 三层 key 形态。 - MiniMax-M2.5 TP8 128K:40 请求、并发 1、输出 512 时,文件语义与 KV 输入吞吐分别为 3616.92/2176.88 tok/s,命中率均为 78.08%,请求全部成功;96 请求、95% 命中时分别为 3954.19/2347.80 tok/s,KV 组出现 Eagle3 acceptance 异常;192 请求、并发 4、输出 1、95% 命中时分别为 32654.32/25216.30 tok/s,请求全部成功。  **DeepSeek-V4-Flash TP8 128K 九轮长稳结果(40 请求/轮、并发 4、输出 1)** | 轮次 | 成功/失败 | 时长(s) | tok/s | Mean TTFT(ms) | P99 TTFT(ms) | 外部命中率 | | --- | --- | ---: | ---: | ---: | ---: | ---: | | 1 | 40/0 | 74.17 | 69,033.39 | 7,189.33 | 9,466.59 | 89.60% | | 2 | 40/0 | 70.71 | 72,409.59 | 6,857.10 | 9,462.37 | 89.60% | | 3 | 40/0 | 75.91 | 67,444.47 | 7,357.57 | 9,407.89 | 89.60% | | 4 | 40/0 | 75.99 | 67,378.60 | 7,357.01 | 9,706.51 | 89.60% | | 5 | 40/0 | 73.74 | 69,435.91 | 7,137.52 | 9,296.72 | 89.60% | | 6 | 40/0 | 78.80 | 64,972.31 | 7,629.17 | 9,776.00 | 89.60% | | 7 | 40/0 | 75.72 | 67,618.25 | 7,346.03 | 9,732.46 | 89.60% | | 8 | 40/0 | 77.79 | 65,818.52 | 7,545.00 | 9,693.00 | 89.60% | | 9 | 40/0 | 77.20 | 66,319.10 | 7,480.51 | 9,592.78 | 89.60% | | 平均 | 360/0 | 75.56 | 67,825.57 | 7,322.14 | 9,570.48 | 89.60% | - DeepSeek-V4-Flash TP8 128K:相同 900 MB/worker DRAM、40 请求、并发 4、输出 1 和同一 ABCCBA 数据集下,纯 DRAM、本地块设备、NFS 文件系统命中率分别为 55.68%/89.60%/87.36%,Token 吞吐分别为 25498/71073/41777 tok/s,Mean TTFT 分别为 19.89/7.02/12.07 s。 - 分层时延:NFS BatchExist 入口到出口平均 19.780 ms,NFS BatchGet 平均 681.202 ms;NFS UnderFS 单对象 Get 平均 536.082 ms,其中 pread 337.432 ms。上层 BatchPut 在三组均约 1.5 ms,说明异步刷盘未阻塞主写路径;NFS 后台 UnderFS Put 平均 489.163 ms。 - NFS 远端共享文件系统链路请求可完成,但历史回归轮次出现 431 次 SSD 回温失败:NFS READ 平均执行 262.54 ms,叠加排队与长尾超过 300 ms pending wait,失败请求由 recompute 完成。该项记录为已知未通过条件,不作为 SSD 回温零失败结论。 # 是否涉及UT/ST - [x] 是:已执行,结果见“测试结果”章节 - [ ] 否(说明理由): # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!606 | 3 天前 | |
[ci] style: 引入 pre-commit 并应用全代码库格式化 Co-authored-by: shilinlee<836160610@qq.com> # message auto-generated for no-merge-commit merge: !347 merge worktree-precommit-format into develop [ci] style: 引入 pre-commit 并应用全代码库格式化 Created-by: shilinlee_com Commit-by: shilinlee Merged-by: yrewzjsx Description: ## 合入来源 - [ ] 需求 - [x] 问题单 - [ ] issue ## 问题/功能描述 引入 pre-commit CI 格式化检查机制,并对全代码库应用自动格式化修正。 ## 修改方案描述 1. 新增/更新 pre-commit 基础设施: .clang-format、.pre-commit-config.yaml、script/ci-pre-commit-pr.sh CI 脚本 2. 对全代码库执行 pre-commit 自动格式化:clang-format、文件末尾补换行、去除尾随空格等 ## 是否涉及UT/ST - [ ] 是 - [x] 否(说明理由:纯格式化调整,不涉及功能逻辑改动) ## 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [x] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!347 | 2 个月前 | |
[ci] style: 引入 pre-commit 并应用全代码库格式化 Co-authored-by: shilinlee<836160610@qq.com> # message auto-generated for no-merge-commit merge: !347 merge worktree-precommit-format into develop [ci] style: 引入 pre-commit 并应用全代码库格式化 Created-by: shilinlee_com Commit-by: shilinlee Merged-by: yrewzjsx Description: ## 合入来源 - [ ] 需求 - [x] 问题单 - [ ] issue ## 问题/功能描述 引入 pre-commit CI 格式化检查机制,并对全代码库应用自动格式化修正。 ## 修改方案描述 1. 新增/更新 pre-commit 基础设施: .clang-format、.pre-commit-config.yaml、script/ci-pre-commit-pr.sh CI 脚本 2. 对全代码库执行 pre-commit 自动格式化:clang-format、文件末尾补换行、去除尾随空格等 ## 是否涉及UT/ST - [ ] 是 - [x] 否(说明理由:纯格式化调整,不涉及功能逻辑改动) ## 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [x] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!347 | 2 个月前 | |
key 预取,踢除 Co-authored-by: gcw_qYJeyWK4<jiangbo97@huawei.com> Co-authored-by: Zixi Qu<quzixi@huawei.com> # message auto-generated for no-merge-commit merge: !405 merge feature/key-evict-prefetch into develop [feature] key 预取,踢除 Created-by: huawei_zixiqu Commit-by: ZixiQu;Zixi Qu;gcw_qYJeyWK4 Merged-by: yrewzjsx Description: # 合入来源 - [x] 需求 - [ ] 问题单 - [ ] issue # 问题/功能描述 详情移步issue 185 # 修改方案描述 meta manager 独立EvictKeys()接口,并提供http API。 # 是否涉及UT/ST - [x] 是 - [ ] 否(说明理由) # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [x] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 ### 开发自验: 解释: 1. 调用http /query_key 确定key_20在DRAM上 2. 调用http /memory/evict (带上"locations": ["LocalCPUBackend"]) 3. 调用http /query_key确定下放到SSD上 4. 调用http /memory/prefetch 5. 调用http /query_key确定拉回到DRAM上 (SSD的copy留存,符合设计预期,未达水线不做清理)  See merge request: Ascend/memcache!405 | 1 个月前 | |
refactor: memcache通过运行时C ABI解耦memfabric Co-authored-by: zhangjialee<z3262749952@163.com> # message auto-generated for no-merge-commit merge: !536 merge fix/memfabric-decouple into develop refactor: memcache通过运行时C ABI解耦memfabric Created-by: zhangjialee Commit-by: zhangjialee Merged-by: chenyz6 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue 关联 issue:[Ascend/memcache #281](https://gitcode.com/Ascend/memcache/issues/281) # 问题/功能描述 Issue #281:MemCache 将 MemFabric 作为三方库参与编译并直接使用其 C++ 类型。编译期 MF 与运行时 libmf_smem.so 的小版本或 C++ ABI 不一致时,同名 C++/STL 符号可能发生进程级抢占,MetaService 在 AccCommonServerOptions::operator=、std::string::assign 等位置 coredump。普通 dlopen 仍不足以隔离两套 C++ ABI。 # 修改方案描述 修改点: - 删除 MemCache 对 3rdparty/memfabric_hybrid 的编译、链接、头文件及 Python 包依赖,运行时固定加载 libmf_smem.so,不新增环境变量。 - ACC、ConfigStore、BM 分模块定义 def/API 封装,通过 dlopen/dlsym 调用 MF 纯 C ABI,并保持原有 C++ 驼峰调用接口。 - ConfigStore 适配类使用 ock::mmc_smem 实际命名空间,通过 ock::smem 别名保持调用侧不变,避免与 MF 原生 ock::smem C++ 符号冲突。 - dlopen 使用 RTLD_NOW | RTLD_LOCAL | RTLD_DEEPBIND,隔离 ABI0/ABI1 的 libstdc++ 弱模板符号。 - 兼容性匹配规则: - 版本来源:MMC 和 MF 均使用各自根目录的 VERSION。 - 版本编码:高 16 位为 major,低 16 位为 minor。 - 匹配条件:MMC 与运行时 MF 的 major.minor 必须完全一致,patch 不参与匹配。 - 当前分支:develop 为 1.3.x,仅匹配 MF 1.3.x;1.1.x、1.2.x 等其他版本线均拒绝加载。 - 必需接口:MF 必须导出 smem_get_abi_version,以及 MMC 实际使用的 ACC、ConfigStore、BM 模块全部必需 C ABI 符号。 - 失败行为:任一必需符号缺失或版本不匹配,均记录期望/实际版本或缺失符号并快速退出,避免 coredump。 - 结构长度:当前没有独立的结构长度字段校验,C ABI 结构布局兼容性由相同 major.minor 约束。 - Python 绑定的复制方向默认值显式转换为 int32_t,避免未注册枚举导致模块导入失败。 # 测试结果: 验证结果: - 构建与单元测试:develop DEBUG 构建成功,release/1.2 完整构建 221/221 成功;test_mf_smem_api 2/2 PASSED。 - C++ ABI 组合启动:同一 MMC 产物分别加载采用 libstdc++ ABI0、ABI1 构建的兼容版本 MF,MetaService 均启动成功,/health 返回 HTTP 200。 - 异常依赖启动:缺少 libmf_smem.so、缺少 smem_get_abi_version、缺少模块必需符号或 major.minor 不匹配时,均输出明确错误并快速退出,无 core。 - ELF 解耦检查:libmf_memcache.so 不包含对 libmf_smem.so、libacc_tcp_net.so 的 DT_NEEDED,也不存在未解析 ock::smem C++ 符号。 - CPU/host_shm benchmark:MF ABI0、ABI1 组合均完成写读,读取返回 0,逐轮写读校验和一致。 - NPU 基础初始化:acl.init 及两张 NPU 卡的 acl.rt.set_device 均返回 0,MetaService 健康检查通过。 - 双卡 device_sdma benchmark:每卡写读 256 MiB;卡 1 写/读 1.616/1.463 GB/s,写读校验和均为 1070032372;卡 2 写/读 1.571/1.481 GB/s,写读校验和均为 1069712602;读取返回 0,无 core。 - 四卡端到端推理验证: - 软件组合:vLLM 0.23.0、Qwen3-32B-W8A8、TP=4;模型列表接口返回 HTTP 200,聊天冒烟请求成功生成 64 tokens,各 TP worker 加载约 9.994 GiB 权重。 - 并发 1:8/8 请求成功、0 失败;耗时 19.58 s,请求吞吐 0.41 req/s,输出吞吐 52.31 tok/s,总吞吐 470.77 tok/s;平均 TTFT 155.15 ms,P99 TTFT 172.99 ms,平均 TPOT 18.04 ms,P99 TPOT 18.08 ms。 - 并发 16:32/32 请求成功、0 失败;耗时 6.07 s,请求吞吐 5.27 req/s,输出吞吐 674.48 tok/s,峰值输出吞吐 768 tok/s,总吞吐 6070.29 tok/s;平均 TTFT 335.07 ms,P99 TTFT 364.77 ms,平均 TPOT 21.24 ms,P99 TPOT 22.30 ms。 # 是否涉及UT/ST - [x] 是:已执行,结果见“测试结果”章节 - [ ] 否(说明理由): # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [x] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!536 | 15 天前 | |
[usage] 流水线测试脚本新增gva直接读写相关接口 Co-authored-by: Oranbean258<tanghongcheng1@h-partners.com> # message auto-generated for no-merge-commit merge: !391 merge 0715fix into develop [usage] 流水线测试脚本新增gva直接读写相关接口 Created-by: thc72549 Commit-by: t30062639;Oranbean258 Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue # 问题/功能描述 # 修改方案描述 测试脚本中增加gva直接读写相关接口 # 是否涉及UT/ST - [ ] 是 - [x] 否(说明理由)不涉及源代码修改 # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [x] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!391 | 2 个月前 | |
[doc]新增版本说明书;将资料移至 docs/zh 目录下,并同步更新受影响文档 Co-authored-by: whytao<weitao46@h-partners.com> # message auto-generated for no-merge-commit merge: !531 merge develop into develop [doc]新增版本说明书;将资料移至 docs/zh 目录下,并同步更新受影响文档 Created-by: whytao Commit-by: whytao Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue fixed: [#275](https://atomgit.com/Ascend/memcache/issues/275) # 问题/功能描述 # 修改方案描述 新增版本说明书;将资料移至 docs/zh 目录下,并同步更新受影响文档。 # 是否涉及UT/ST - [ ] 是 - [ ] 否(说明理由) # 开发自检 - [ ] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [ ] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [ ] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [ ] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [ ] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [ ] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!531 | 22 天前 | |
feat: LRU 分片降低高并发锁竞争 Co-authored-by: lirui7717<lirui7717@163.com> # message auto-generated for no-merge-commit merge: !607 merge feat/sharded-lru-global-eviction-methodology into master feat: LRU 分片降低高并发锁竞争 Created-by: lirui7717 Commit-by: lirui7717 Merged-by: yangchangjie12138 Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue 本pr 来源自https://gitcode.com/Ascend/memcache/pull/401 # 问题/功能描述 - 当前所有 Put、Get 等请求共享同一条 LRU 链及其锁。高并发场景下,不同 key 的操作也会互相等待,LRU 锁竞争成为性能瓶颈。 - 由于分shard 导致benchmark 太快,发现backup还没完成client就注销了, backup 线程和注销线程形成死锁。 # 修改方案描述 将单条全局 LRU 链拆分为 16 个 shard。 每个 shard 维护独立的 LRU 链和锁,key 按 hash 分配到对应 shard。不同 shard 的请求可以并发执行,减少锁竞争;同一 key 始终落在固定 shard,原有 LRU 语义保持不变。 其中改动最大的是MultiLevelElimination 也就是基于shard 全局淘汰。其思想是这样的: 1. 先轻量级收集每个shard的最后一个节点的每个访问序号,用最小堆选出全局淘汰的边界。 2. 确定全局淘汰边界后,再把边界以内的真实 key 候选收集出来。 3. 正常候选不够目标数,说明两个阶段之间发生了较严重的并发变化, 重新收集candidate,重新计算边界 4. 最后在锁的保护下实现真正的驱逐 默认为shard_lru ock.mmc.meta_service.lru_shard_count = 16 死锁解决方案为:直接不让注销线程和backup线程并行,已经启动backup的就继续backup,还没backup的就取消,之后注销线程等backup结束后再注销。 执行 bash script/build_and_pack_run.sh --build_mode RELEASE --build_cpp_example ON RUN_ARGS='-p 4 -t 4 -n 20000 -k 20000 -w 4000 -s 65536 -c 64 -r 30 -b 16,32' ./build/example/meta_service_bench/bench_meta_service $RUN_ARGS | 指标 | 非 Shard | Shard | Shard + 淘汰优化| | ------- | ---------: | ---------: |-------------: | | Get Avg | 300 us | 145 us | **171 us** | | Get P95 | 1024 us | 256 us | **512 us** | | Get P99 | 1024 us | 512 us | **512 us** | | Put Avg | 11.3 ms | 16.2 ms | **8.57 ms** | | 吞吐 | 4400 ops/s | 3187 ops/s | **5911 ops/s** | # 是否涉及UT/ST - [x] 是 新增/更新 UT,覆盖: - key 能稳定分配到对应 shard; - 各 shard 的插入、查询、淘汰行为正确; - 并发访问不同 shard 时功能正常。 - [ ] 否(说明理由) # 开发自检 - [ ] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [ ] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!607 | 3 天前 | |
[ci] style: 引入 pre-commit 并应用全代码库格式化 Co-authored-by: shilinlee<836160610@qq.com> # message auto-generated for no-merge-commit merge: !347 merge worktree-precommit-format into develop [ci] style: 引入 pre-commit 并应用全代码库格式化 Created-by: shilinlee_com Commit-by: shilinlee Merged-by: yrewzjsx Description: ## 合入来源 - [ ] 需求 - [x] 问题单 - [ ] issue ## 问题/功能描述 引入 pre-commit CI 格式化检查机制,并对全代码库应用自动格式化修正。 ## 修改方案描述 1. 新增/更新 pre-commit 基础设施: .clang-format、.pre-commit-config.yaml、script/ci-pre-commit-pr.sh CI 脚本 2. 对全代码库执行 pre-commit 自动格式化:clang-format、文件末尾补换行、去除尾随空格等 ## 是否涉及UT/ST - [ ] 是 - [x] 否(说明理由:纯格式化调整,不涉及功能逻辑改动) ## 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [x] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!347 | 2 个月前 | |
[docs] 更新文档,引导用户最佳配置,并增加代码概览 Co-authored-by: ZixiQu<quzixi@huawei.com> # message auto-generated for no-merge-commit merge: !589 merge update_docs into master [docs] 更新文档,引导用户最佳配置,并增加代码概览 Created-by: huawei_zixiqu Commit-by: ZixiQu Merged-by: yrewzjsx Description: # 合入来源 - [X] 需求 - [ ] 问题单 - [ ] issue # 问题/功能描述 更新README # 修改方案描述 # 是否涉及UT/ST - [ ] 是 - [X] 否(说明理由): 更新README # 开发自检 - [X] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [X] 规范:已关联issue或里程碑 - [X] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [X] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [X] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [X] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!589 | 5 天前 | |
feat:可靠性2.0 Co-authored-by: liuao<royliu.chengdu@gmail.com> # message auto-generated for no-merge-commit merge: !409 merge store_refactor_pr into develop feat:可靠性2.0 Created-by: gcw_M5Xrk6cX Commit-by: royliu;liuao Merged-by: yrewzjsx Description: # 合入来源 - [ ] 需求 - [ ] 问题单 - [x] issue # 问题/功能描述 # 修改方案描述 # 是否涉及UT/ST - [ ] 是 - [x] 否(说明理由) # 开发自检 - [x] 规范:未超过1k;超过1k已完成备案;反合入需要标题注明【反合】 - [x] 规范:已关联issue或里程碑 - [x] 规范:不需要UT/ST且已说明理由;需要且已包含UT/ST - [x] 安全:涉及对外接口/参数/环境变量改动,并同步修改资料 - [x] 安全:未引入三方开源软件;引入三方开源软件并经过安全评审 - [x] 安全:未新增对外接口/参数;新增对外接口/参数有校验 - [x] 规范:未涉及资料改动;涉及资料改动并已完成修改 See merge request: Ascend/memcache!409 | 1 个月前 |
![]()
🔄Latest News
-
[2026/06] MemCache使能推理PrefixCache加速案例实践,请关注wiki主页案例库获取最新案例
-
[2025/12] MemCache已作为vllm-ascend backend使能大模型推理加速,详情查看vllm-ascend开源社区,使用示例
-
[2025/11] MemCache项目于2025年11月开源,开源社区地址为:https://gitcode.com/Ascend/memcache
🔜 Roadmap&发布策略
MemCache roadmap详见:Roadmap MemCache 分支发布策略:分支发布策略
🎉概述
MemCache是针对LLM推理、GR推理场景设计的高性能分布式KVCache存储引擎,其主要特性包括:
- 基于对象操作的API:支持批量和非批量的put/get/exist/remove操作,支持多层结构的KV Block读写接口。
- 多层缓存池:支持HBM,DDR,SSD组成多级缓存池,多级之间通过淘汰和预取进行数据冷热交换。
- 高带宽低时延:使用 MemFabric 作为多级内存和异构网络传输的底座,在Ascend硬件上,基于device_rdma(A2)、device_sdma(A3)、host_rdma(A2/A3)、device_urma(A5)、device_uboe(A5) 等路径提供OneCopy跨机跨介质数据直接访问能力,满足高带宽,低时延的读写性能诉求。在鲲鹏硬件上,支持host_urma(K5)。支持host_shm实现同节点共享内存通信。
- 支持扩缩容:支持LocalService动态加入和移除
- HA能力:在K8S集群中,MetaService支持多活能力,支持元数据恢复,提供尽力而为的HA能力。
🧩核心组件
MemCache包含LocalService和MetaService两大核心组件:
-
MetaService:
- 负责管理整个集群中内存池空间的分配和管理,处理LocalService的加入与退出。
- MetaService作为独立进程运行,提供两种启动方式:python API启动;二进制启动,详见 whl安装使用 和 run安装使用
- MetaService支持两种部署形态: 1、单点模式:MetaService由单个进程组成,部署方式简单,但存在单点故障的问题。如果MetaService进程崩溃或无法访问,系统将无法继续提供服务,直至重新恢复为止。 2、HA模式:该模式基于K8S的ClusterIP Service和Lease资源构建,部署较为复杂,该模式会部署多个MetaService进程实例,实现多活高可用。部署详见怎么部署一个MemCache的HA集群
-
LocalService:负责承担如下功能:
- 客户端:作为客户端,以whl/so形式作为共享库被应用进程加载调用API
- 内存提供者:负责提供一段连续的内存区域作为内存池空间的一部分,其内存可以被其他LocalService实例基于地址直接访问。
📁项目结构导览
MemCache 核心代码按模块化设计原则组织,核心实现位于 src/memcache/csrc 下。
src/memcache/csrc/ # C++ 核心实现
├── meta_service/ # MetaService:集群元数据管理、空间分配、淘汰
│ ├── mmc_meta_service.cpp # MetaService 主服务逻辑
│ ├── mmc_meta_manager.cpp # 元数据管理器(key→blob 全局映射)
│ ├── mmc_blob_allocator.cpp # 内存池空间分配器
│ ├── mmc_meta_container_lru.cpp # LRU 元数据容器(冷热追踪/淘汰)
│ └── mmc_meta_net_server.cpp # RPC 网络服务端
├── client/ # 本地客户端:被推理进程以 whl/so 形式加载
│ ├── mmc_client_default.cpp # 客户端核心实现(batch put/get/copy)
│ ├── mmc_meta_net_client.cpp # RPC 网络客户端
├── local_service/ # LocalService:内存提供者
│ ├── mmc_local_service_default.cpp # LocalService 主实现
│ └── mmc_bm_proxy.cpp # MemFabric BM 语义代理
└── under_api/ # 底座接入层(MemFabric / UBSIO)
├── mf_smem/ # MemFabric 动态库接入(HBM / DRAM 层)
│ └── smem_bm_api.cpp # 批量内存拷贝 API
└── ubs_io/ # UBSIO 动态库接入(SSD 层)
├── mmc_ubs_io_proxy.cpp # UBSIO 代理封装
└── dl_ubsio_api.cpp # UBSIO 动态加载
🔥性能表现
MemCache核心能力是提供大容量内存池和高性能的H2D、D2H、D2RH、RH2D数据访问能力,由于MemCache以 MemFabric 作为池化底座,所以支持RH2D、D2RH等OneCopy跨机跨介质数据直接访问能力,下图为RH2D对比其他中转路径的对比示意图。
基于OneCopy跨机跨介质数据直接访问的能力,MemCache在A2/A3做了相关性能测试如下: 模拟构造DeepSeek-R1模型KV大小的block,单个block size为:61x128K + 61x16K = 8784KB ≈ 8.57MB,共122个离散地址。
- 使用2个昇腾A2节点(每节点8张卡)组成双机内存池进行读写测试性能如下:
- 使用2个昇腾A3节点(每节点8张卡16Die)组成双机内存池进行读写测试性能如下:
🚀快速入门
请访问以下文档获取简易教程:
- 安装使用:whl安装和使用(适用于Python用户),run编译、安装和使用(适用于C++用户)
- 配置文件:涉及MetaService、LocalService公共配置
- 样例执行:介绍如何端到端执行样例代码,包括C++和Python样例
- DevContainer 远端开发:VS Code Remote-SSH + DevContainer 一站式开发环境搭建与全量示例运行指南
📑学习教程
📦软件硬件配套说明
- MemCache软件依赖 MemFabric,相关配套与MemFabric相同。 详见:完整软件硬件配套文档,涵盖支持的操作系统、Ascend/鲲鹏硬件型号、CANN版本、MemFabric底座版本、内存大页规格等完整配套信息。
📌FAQ
常见问题请参考:FAQ
📝相关信息
说明
此开源项目非华为产品,仅提供有限支持。