# 芯元一科技 · 全站正文 --- > 芯元一 FX 系列全闪 NVMe-oF 存储加速平台：480B 大模型实测推理吞吐 +29–40%、首 token 延迟 −26–32%，每个数字都对应可申请查证的测试报告。 --- 本文件由站点内容自动生成，是 https://vuke.top 全部页面的 Markdown 正文。数字后的 R 编号链接到对应的测试报告页面。 --- ## 芯元一科技｜AI 推理存储加速 · KV Cache 分层 · FX 全闪阵列 > 芯元一 FX 系列全闪 NVMe-oF 存储加速平台：480B 大模型实测推理吞吐 +29–40%、首 token 延迟 −26–32%，每个数字都对应可申请查证的测试报告。 网页地址: https://vuke.top · 更新于 2026 年 11 月 12 日 FX 系列全闪 NVMe-oF 阵列接住溢出显存的 KV Cache。在 480B 大模型的生产部署形态下，推理吞吐 +29–40%，首 token 延迟 −26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。每个数字都对应一份可以申请查证的测试报告。 ### 数字都有出处 每一项都写明对照基线和报告编号。不同平台的结果分开列出，不做合并。 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | 推理吞吐提升 | +29–40% | 对比本地 NVMe 单盘 | Qwen3-Coder-480B-FP8、TP=8 生产部署形态，长上下文冷恢复负载：并发 8 时 +29%，并发 16（实测中提升幅度最大的一档）时 +40%；TP4×2 双实例全机口径为 +35–36%。 | 实测 · [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | | 首 token 延迟（TTFT）降低 | −26–32% | 对比本地 NVMe 单盘 | 同一 480B·TP8 负载的三档并发下，TTFT p50 从 10.17–35.73 s 降到 7.53–26.35 s。 | 实测 · [R2](https://vuke.top/evidence/R2) | | 相对无外存重算的加速 | 8.6–20× | 对比无外存、整段重算 | 并发 16：整段重算的 TTFT p50 为 149.5 s，接入 FX100 后为 11.85 s；吞吐 4.1 tok/s 对 74.9 tok/s。 | 实测 · [R2](https://vuke.top/evidence/R2) | | LMCache 并行读补丁的 TTFT 改善 | 4.1× | 对比打补丁之前 | 单卡、并发 16、冷读盘（Qwen2.5-32B）：TTFT 37.97 s → 9.30 s；读带宽 0.98 → 5.23 GB/s，约 5.3×。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 模型服务加载提速 | 6.2–9.3× | 对比 NFS，昇腾 910B 平台 | 华为 Atlas 910B 平台：DeepSeek-32B 服务加载 691 s → 112 s（6.2×），DeepSeek-70B 1399 s → 150 s（9.3×）。 | 实测 · [R9](https://vuke.top/evidence/R9) | | 训练 Checkpoint 保存提速 | 1.9× | 对比 R1 报告中的对照基线 | 8 卡 32B LoRA，每份整模型快照 65.6 GB：178 s → 94 s；持续写带宽 3.26 → 6.40 GB/s（+96%）。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 模型切换场景的算力有效利用率 | 46.7% → 62.8% | 每小时切换 20 次的档位 | 按实测加载时间建模：每小时切换 20 次模型时，算力有效利用率从 46.7% 提高到 62.8%。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 8 卡并发加载模型 | 16% / 30% | 对比 R1 报告中的对照基线 | 8 张卡同时冷读模型：整体墙钟时间快 16%，单个模型加载快 30%。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 两轮独立测量的偏差 | ≤5% | 同一档位重复测量 | 同一档位做两轮独立测量，偏差不超过 5%；fs:// 共享池的跨实例热共享同时验证通过。 | 实测 · [R3](https://vuke.top/evidence/R3) | | 外置 KV 层可替代的显存驻留量级 | 128 GB | 沐曦 N260 单卡，14B 模型七组对照 | 14B 模型七组对照的结论：外置 KV 层可以替代 128 GB 级别的显存驻留。该轮平台是沐曦 N260 单卡，方法论可跨平台使用，数字不与 MI308X 混用。 | 实测 · [R5](https://vuke.top/evidence/R5) | | ComfyUI + LTX-Video 2.3 模型实跑通过 | 7 / 7 | AMD MI308X，ROCm 7.2 | 交付的 7 个模型（3 个 VAE、fp8 文本编码器、文本投影、2 个 LoRA）在 MI308X / ROCm 7.2 上全部实跑通过，没有出现 dtype、算子或内核错误。 | 实测 · [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7) | | 阵列与推理节点的配比 | 1 : 8 | 生产配比口径 | 每台 FX100 服务 8 个推理节点：100 GbE 能支撑 8 节点 KV 回读是实测锚点。联测口径下，存储投入约占 GPU 预算的一成以内。 | 估算 · [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | ### 显存放不下的，交给全闪层 长上下文会话会不断把 KV Cache 挤出显存。没有外置层时，被挤出的会话只能整段重算；有了 FX，它们被直接读回。 - L1 显存（HBM）: 当前活跃的会话 (由 vLLM 管理) - L2 主机内存: 近期用过的会话 (由 LMCache 管理) - L3 FX 全闪阵列: 全部历史会话，跨实例共享 (NVMe-oF · RoCEv2) [了解工作原理](https://vuke.top/tech) ### 同一负载，三档并发 R2 报告的原始读数。FX100 与本地 NVMe 单盘在并发 8、16、32 下逐档对照。 | 并发 | FX100 TTFT p50 (s) | 本地 NVMe 单盘 TTFT p50 (s) | 整段重算 TTFT p50 (s) | FX100 tok/s | 本地 NVMe 单盘 tok/s | 整段重算 tok/s | | --- | --- | --- | --- | --- | --- | --- | | 8 | 7.53 | 10.17 | — | 56.6 | 43.9 | — | | 16 | 11.85 | 17.31 | 149.48 | 74.9 | 53.6 | 4.1 | | 32 | 26.35 | 35.73 | — | 71.6 | 53.9 | — | Qwen3-Coder-480B-FP8 · TP=8 · 8 × MI308X · 长上下文冷恢复负载。TTFT 为 p50，单位秒；吞吐单位 tok/s；整段重算只测了并发 16 一档。 出处: [R2](https://vuke.top/evidence/R2) ### FX 系列全闪存储平台 四款机型，单接口速率从 100 Gb 到 400 Gb。规格为厂商口径；FX100 有完整的实测报告。 | 机型 | 接口代际 | 单接口速率 | IOPS | 闪存形态 | 状态 | 实测报告 | | --- | --- | --- | --- | --- | --- | --- | | [FX100](https://vuke.top/products/fx100) | PCIe 3.0 | 100 Gb | 1,600 万 | U.2 | 量产在售 | [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) [R4](https://vuke.top/evidence/R4) [R5](https://vuke.top/evidence/R5) [R9](https://vuke.top/evidence/R9) | | [FX200](https://vuke.top/products/fx200) | PCIe 4.0 | 200 Gb | 3,200 万 | U.2 | 量产在售 | — | | [FX300](https://vuke.top/products/fx300) | PCIe 5.0 | 400 Gb | 6,000 万 | U.2 | 量产在售 | — | | [FX400](https://vuke.top/products/fx400) | PCIe 6.0 | 400 Gb | 1.4 亿 | E1.S | 测试机阶段，计划 2026 年底量产 | — | ### 围绕这层存储，我们还做这些 - [存储加速：KV Cache 分层](https://vuke.top/solutions/storage-acceleration): 存储加速 - [国产与非 N 卡算力适配](https://vuke.top/solutions/domestic-compute): 国产算力适配 - [算力中心效能优化](https://vuke.top/solutions/efficiency-optimization): 效能优化 - [算力中心建设](https://vuke.top/solutions/datacenter-construction): 算力中心建设 - [推理栈软件开发](https://vuke.top/solutions/software-development): 软件开发 ### 先联测，后决策 合作从一次约 10 周的门禁化联测开始。四道门禁逐级放行，任何一道不达标就在那里停下，不必为没有被证实的收益买单。 - **G1 · 第 2 周 · 到货验收**: 物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - **G2 · 第 4 周 · 单机基线**: 复现单节点 8 卡推理基线，与 R1 口径的偏差在 ±10% 以内；单阵列本地压测达到实测锚点 83% 的线效。 - **G3 · 第 7 周 · 联测主门禁**: KV 分层加速须同时满足：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - **G4 · 第 10 周 · 稳定性与验收**: 72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 ### 常见问题 #### 芯元一是做什么的？ 芯元一（天津）半导体设备有限公司做大模型推理的存储加速。产品是 FX 系列全闪 NVMe-oF 阵列，用来承接溢出显存的 KV Cache，让被挤出的会话可以直接读回而不是重新计算。围绕这款产品，我们还提供国产与非 N 卡算力适配、算力中心效能优化、算力中心建设和推理栈软件开发服务。 #### FX 系列存储加速平台是什么？ FX 系列是在广东绿算 GP 系列硬件上开发的软硬件一体存储加速系统，配套 vLLM + LMCache 的 KV Cache 分层软件栈，其中包含芯元一自研的并行读补丁。FX100、FX200、FX300 已量产在售，FX400 计划 2026 年底量产。FX100 单接口 100 Gb、1,600 万 IOPS；FX300 为 PCIe 5.0 平台，单接口 400 Gb、6,000 万 IOPS（均为厂商规格）。 #### KV Cache 分层存储加速能把推理性能提升多少？ 在 Qwen3-Coder-480B-FP8、8 × AMD MI308X、TP=8 的生产部署形态下，长上下文冷恢复负载的实测结果是：相对本地 NVMe 单盘，推理吞吐提升 29–40%，TTFT p50 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)；相对无外存整段重算，加速 8.6–20× [R2](https://vuke.top/evidence/R2)。这是应用层的吞吐和首 token 延迟，不是存储设备本身的微秒级时延。 #### 哪些场景收益大，哪些场景收益有限？ 收益来自缓存命中。长上下文、多轮对话、高并发的会话恢复（Agent、代码助手、客服）命中率高，收益最大。短对话、低并发的场景命中率低，收益有限。所以我们建议先联测、后采购：用你自己的会话长度分布和并发量测一遍，再决定买不买。 #### 这些数字怎么验证？能复现吗？ 每个关键数字都标了报告编号（R1–R9），报告可以向我们申请查阅。其中 R4 是第三方检测机构出具的正式报告。R8 是测试代码导出包和原始数据，包含 LMCache 并行读补丁、负载客户端、编排脚本和探针取证脚本，第三方可以在自己的集群上重跑。同一档位两轮独立测量的偏差不超过 5% [R3](https://vuke.top/evidence/R3)。 #### 接入 FX 需要改造推理引擎吗？ 不需要重写推理引擎。接入点是开源的 vLLM + LMCache 组合：LMCache 负责把显存放不下的 KV Cache 下沉到主机内存和外置存储，FX 阵列作为外置的那一层。我们在 ROCm 平台上做了源码级适配，并行读补丁随 R8 一并交付 [R1](https://vuke.top/evidence/R1) [R8](https://vuke.top/evidence/R8)。 ### 联系我们 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## FX 系列全闪 NVMe-oF 存储平台：FX100 / FX200 / FX300 / FX400 > FX 系列四款机型的规格对比：PCIe 3.0 到 6.0，单接口 100–400 Gb，1,600 万到 1.4 亿 IOPS。FX100 满配参考价 ¥371,200，并有完整实测报告。 网页地址: https://vuke.top/products · 更新于 2026 年 11 月 12 日 FX 系列是为大模型推理的 KV Cache 第三层设计的全闪 NVMe-oF 阵列，在广东绿算 GP 系列硬件上开发，与 vLLM + LMCache 软件栈一起交付。下表规格均为厂商口径；有实测报告的机型单独标注。 | 机型 | 接口代际 | 单接口速率 | IOPS | 闪存形态 | 状态 | 实测报告 | | --- | --- | --- | --- | --- | --- | --- | | [FX100](https://vuke.top/products/fx100) | PCIe 3.0 | 100 Gb | 1,600 万 | U.2 | 量产在售 | [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) [R4](https://vuke.top/evidence/R4) [R5](https://vuke.top/evidence/R5) [R9](https://vuke.top/evidence/R9) | | [FX200](https://vuke.top/products/fx200) | PCIe 4.0 | 200 Gb | 3,200 万 | U.2 | 量产在售 | — | | [FX300](https://vuke.top/products/fx300) | PCIe 5.0 | 400 Gb | 6,000 万 | U.2 | 量产在售 | — | | [FX400](https://vuke.top/products/fx400) | PCIe 6.0 | 400 Gb | 1.4 亿 | E1.S | 测试机阶段，计划 2026 年底量产 | — | ### FX100: 实测数据最完整的主力机型 FX100 是 FX 系列里实测数据最完整的一款：R1–R5 与 R9 都以它为被测设备，覆盖 AMD MI308X、沐曦 N260、华为昇腾 910B 三个平台。单接口 100 Gb、1,600 万 IOPS，生产配比为每台服务 8 个推理节点。 ### FX200: 单口带宽与 IOPS 翻倍的 PCIe 4.0 机型 FX200 把单接口速率提高到 200 Gb、IOPS 提高到 3,200 万，均为 FX100 的两倍。6 个 PCIe 扩展槽支持 ASIC、FPGA、DPU 异构板卡混插，适合需要更高单口带宽或自带加速卡的集群。 ### FX300: PCIe 5.0 性能档，含 6 块 DPU FX300 是 PCIe 5.0 平台的性能档：单接口 400 Gb、6,000 万 IOPS，配 6 块 DPU 和 Gen5 企业级 NVMe SSD，面向高并发 KV 回读与大模型权重的快速分发。 ### FX400: 下一代旗舰，PCIe 6.0 + E1.S FX400 是下一代旗舰：PCIe 6.0 平台、E1.S 闪存形态，厂商规格为设备聚合带宽 4.8 Tb/s、1.4 亿 IOPS。测试机排期为 2026 年 8 月，量产计划在 2026 年底；规格以测试机实测回填，量产定价待发布。 ### FX100 参考价怎么算出来的 满配整机参考价 = 平台 ¥160,000 + 24 × ¥8,800 = ¥371,200，裸容量 184.3 TB，约合 ¥2,014/TB。SSD 按参考市场价计、随行就市，正式价格以采购合同为准。 ### 关于产品名称 关于名称：FX100 在早期测试报告的文件名里写作 AISSD5000，更早也叫过 WS5000 / GP5000，报告原文有时署「铭信」。它们指的是同一款产品。本站统一使用 FX 命名（FX100 / FX200 / FX300 / FX400），报告条目保留原始标题，方便对照查证。 --- ## FX100 全闪 NVMe-oF 阵列：规格、适用场景与实测 > FX100 是 FX 系列里实测数据最完整的一款：R1–R5 与 R9 都以它为被测设备，覆盖 AMD MI308X、沐曦 N260、华为昇腾 910B 三个平台。单接口 100 Gb、1,600 万 IOPS，生产配比为每台服务 8 个推理节点。 网页地址: https://vuke.top/products/fx100 · 更新于 2026 年 11 月 12 日 FX100 是 FX 系列里实测数据最完整的一款：R1–R5 与 R9 都以它为被测设备，覆盖 AMD MI308X、沐曦 N260、华为昇腾 910B 三个平台。单接口 100 Gb、1,600 万 IOPS，生产配比为每台服务 8 个推理节点。 ### 规格 | 规格 | 数值 | | --- | --- | | 接口代际 | PCIe 3.0 | | 单接口速率 | 100 Gb | | IOPS | 1,600 万 | | 闪存形态 | U.2 | | 主控与扩展 | 双主控，2×3 接口（ASIC） | | 盘位配置 | 24 × 7.68 TB Gen4 企业级 U.2 NVMe SSD | | 状态 | 量产在售 | | 参考价 | ¥371,200 | ### FX100 参考价怎么算出来的 满配整机参考价 = 平台 ¥160,000 + 24 × ¥8,800 = ¥371,200，裸容量 184.3 TB，约合 ¥2,014/TB。SSD 按参考市场价计、随行就市，正式价格以采购合同为准。 ### 适合谁 - 想先用联测验证 KV Cache 分层收益，再决定是否扩容的团队 - 已有 100 GbE RoCEv2 网络的 MI308X 或昇腾 910B 推理集群 - 受 NFS 拖累、模型加载与切换耗时过长的存量集群 ### 相关实测报告 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | 推理吞吐提升 | +29–40% | 对比本地 NVMe 单盘 | Qwen3-Coder-480B-FP8、TP=8 生产部署形态，长上下文冷恢复负载：并发 8 时 +29%，并发 16（实测中提升幅度最大的一档）时 +40%；TP4×2 双实例全机口径为 +35–36%。 | 实测 · [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | | 首 token 延迟（TTFT）降低 | −26–32% | 对比本地 NVMe 单盘 | 同一 480B·TP8 负载的三档并发下，TTFT p50 从 10.17–35.73 s 降到 7.53–26.35 s。 | 实测 · [R2](https://vuke.top/evidence/R2) | | 相对无外存重算的加速 | 8.6–20× | 对比无外存、整段重算 | 并发 16：整段重算的 TTFT p50 为 149.5 s，接入 FX100 后为 11.85 s；吞吐 4.1 tok/s 对 74.9 tok/s。 | 实测 · [R2](https://vuke.top/evidence/R2) | | LMCache 并行读补丁的 TTFT 改善 | 4.1× | 对比打补丁之前 | 单卡、并发 16、冷读盘（Qwen2.5-32B）：TTFT 37.97 s → 9.30 s；读带宽 0.98 → 5.23 GB/s，约 5.3×。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 模型服务加载提速 | 6.2–9.3× | 对比 NFS，昇腾 910B 平台 | 华为 Atlas 910B 平台：DeepSeek-32B 服务加载 691 s → 112 s（6.2×），DeepSeek-70B 1399 s → 150 s（9.3×）。 | 实测 · [R9](https://vuke.top/evidence/R9) | | 训练 Checkpoint 保存提速 | 1.9× | 对比 R1 报告中的对照基线 | 8 卡 32B LoRA，每份整模型快照 65.6 GB：178 s → 94 s；持续写带宽 3.26 → 6.40 GB/s（+96%）。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 模型切换场景的算力有效利用率 | 46.7% → 62.8% | 每小时切换 20 次的档位 | 按实测加载时间建模：每小时切换 20 次模型时，算力有效利用率从 46.7% 提高到 62.8%。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 8 卡并发加载模型 | 16% / 30% | 对比 R1 报告中的对照基线 | 8 张卡同时冷读模型：整体墙钟时间快 16%，单个模型加载快 30%。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 两轮独立测量的偏差 | ≤5% | 同一档位重复测量 | 同一档位做两轮独立测量，偏差不超过 5%；fs:// 共享池的跨实例热共享同时验证通过。 | 实测 · [R3](https://vuke.top/evidence/R3) | | 外置 KV 层可替代的显存驻留量级 | 128 GB | 沐曦 N260 单卡，14B 模型七组对照 | 14B 模型七组对照的结论：外置 KV 层可以替代 128 GB 级别的显存驻留。该轮平台是沐曦 N260 单卡，方法论可跨平台使用，数字不与 MI308X 混用。 | 实测 · [R5](https://vuke.top/evidence/R5) | | 阵列与推理节点的配比 | 1 : 8 | 生产配比口径 | 每台 FX100 服务 8 个推理节点：100 GbE 能支撑 8 节点 KV 回读是实测锚点。联测口径下，存储投入约占 GPU 预算的一成以内。 | 估算 · [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R4](https://vuke.top/evidence/R4) · FX100 KV Cache 性能测试报告（480B · 多实例形态 · 编号 -006） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R5](https://vuke.top/evidence/R5) · FX100 KV Cache 性能测试报告（14B · 显存效益） (沐曦 N260 单卡) - [R9](https://vuke.top/evidence/R9) · FX100 与华为昇腾 910B 模型推理与训练性能测试（对照 NFS 基线） (华为 Atlas 910B × 8（Kunpeng-920）) --- ## FX200 全闪 NVMe-oF 阵列：规格、适用场景与实测 > FX200 把单接口速率提高到 200 Gb、IOPS 提高到 3,200 万，均为 FX100 的两倍。6 个 PCIe 扩展槽支持 ASIC、FPGA、DPU 异构板卡混插，适合需要更高单口带宽或自带加速卡的集群。 网页地址: https://vuke.top/products/fx200 · 更新于 2026 年 11 月 12 日 FX200 把单接口速率提高到 200 Gb、IOPS 提高到 3,200 万，均为 FX100 的两倍。6 个 PCIe 扩展槽支持 ASIC、FPGA、DPU 异构板卡混插，适合需要更高单口带宽或自带加速卡的集群。 ### 规格 | 规格 | 数值 | | --- | --- | | 接口代际 | PCIe 4.0 | | 单接口速率 | 200 Gb | | IOPS | 3,200 万 | | 闪存形态 | U.2 | | 主控与扩展 | 6 个 PCIe 扩展槽，可混插 ASIC / FPGA / DPU 板卡 | | 盘位配置 | 24 × 7.68 TB Gen4 企业级 U.2 NVMe SSD | | 状态 | 量产在售 | | 参考价 | 按配置询价 | ### 适合谁 - 单口 100 Gb 已成为瓶颈的高并发 KV 回读场景 - 需要在存储侧插入 FPGA 或 DPU 做自定义处理的团队 ### 相关实测报告 该机型规格为厂商口径，暂无公开的实测报告。 --- ## FX300 全闪 NVMe-oF 阵列：规格、适用场景与实测 > FX300 是 PCIe 5.0 平台的性能档：单接口 400 Gb、6,000 万 IOPS，配 6 块 DPU 和 Gen5 企业级 NVMe SSD，面向高并发 KV 回读与大模型权重的快速分发。 网页地址: https://vuke.top/products/fx300 · 更新于 2026 年 11 月 12 日 FX300 是 PCIe 5.0 平台的性能档：单接口 400 Gb、6,000 万 IOPS，配 6 块 DPU 和 Gen5 企业级 NVMe SSD，面向高并发 KV 回读与大模型权重的快速分发。 ### 规格 | 规格 | 数值 | | --- | --- | | 接口代际 | PCIe 5.0 | | 单接口速率 | 400 Gb | | IOPS | 6,000 万 | | 闪存形态 | U.2 | | 主控与扩展 | 2×3 PCIe 扩展槽，支持 ASIC / FPGA / DPU 异构板卡 | | 盘位配置 | 24 × 7.68 TB Gen5 企业级 NVMe SSD | | 状态 | 量产在售 | | 参考价 | 按配置询价 | ### 适合谁 - 已经部署 400 Gb 网络的新建算力中心 - 多实例共享同一缓存池、回读并发很高的推理平台 ### 相关实测报告 该机型规格为厂商口径，暂无公开的实测报告。 --- ## FX400 全闪 NVMe-oF 阵列：规格、适用场景与实测 > FX400 是下一代旗舰：PCIe 6.0 平台、E1.S 闪存形态，厂商规格为设备聚合带宽 4.8 Tb/s、1.4 亿 IOPS。测试机排期为 2026 年 8 月，量产计划在 2026 年底；规格以测试机实测回填，量产定价待发布。 网页地址: https://vuke.top/products/fx400 · 更新于 2026 年 11 月 12 日 FX400 是下一代旗舰：PCIe 6.0 平台、E1.S 闪存形态，厂商规格为设备聚合带宽 4.8 Tb/s、1.4 亿 IOPS。测试机排期为 2026 年 8 月，量产计划在 2026 年底；规格以测试机实测回填，量产定价待发布。 ### 规格 | 规格 | 数值 | | --- | --- | | 接口代际 | PCIe 6.0 | | 单接口速率 | 400 Gb | | IOPS | 1.4 亿 | | 设备聚合带宽 | 4.8 Tb/s | | 闪存形态 | E1.S | | 主控与扩展 | 2×3 PCIe 扩展槽，支持 ASIC / FPGA / DPU 异构板卡 | | 盘位配置 | E1.S 形态闪存 | | 状态 | 测试机阶段，计划 2026 年底量产 | | 参考价 | 量产定价待发布 | ### 适合谁 - 正在为下一代平台做规划的大规模算力中心 - 愿意参与测试机联测、提前拿到实测数据的团队 ### 相关实测报告 该机型规格为厂商口径，暂无公开的实测报告。 --- ## 解决方案：存储加速、国产算力适配、算力中心建设与效能优化 > 芯元一的五条能力线：KV Cache 分层存储加速、国产与非 N 卡算力适配、算力中心效能优化、算力中心建设、推理栈软件开发，每条都附实测报告编号。 网页地址: https://vuke.top/solutions · 更新于 2026 年 11 月 12 日 从一层存储出发，向上是推理栈软件，向下是算力中心的规划与建设。每条能力线都指向具体的报告编号。 ### [存储加速：KV Cache 分层](https://vuke.top/solutions/storage-acceleration) 在显存和主机内存之外加一层 FX 全闪 NVMe-oF 存储，用 vLLM + LMCache 把溢出的 KV Cache 写进去，命中时直接读回。480B 大模型生产部署形态下，相对本地 NVMe 单盘吞吐提升 29–40%、TTFT 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。 出处: [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) [R4](https://vuke.top/evidence/R4) [R9](https://vuke.top/evidence/R9) ### [国产与非 N 卡算力适配](https://vuke.top/solutions/domestic-compute) 我们在推理栈的源码层面做适配，并且每个平台单独出实测报告：AMD MI308X × 8 [R1](https://vuke.top/evidence/R1)、华为昇腾 910B × 8 [R9](https://vuke.top/evidence/R9)、沐曦 N260 [R5](https://vuke.top/evidence/R5)。不同平台的数字分开标注，不合并成一个头条。 出处: [R1](https://vuke.top/evidence/R1) [R5](https://vuke.top/evidence/R5) [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7) [R8](https://vuke.top/evidence/R8) [R9](https://vuke.top/evidence/R9) ### [算力中心效能优化](https://vuke.top/solutions/efficiency-optimization) 先把等待时间压下去，再谈扩卡。在每小时切换 20 次模型的档位下，算力有效利用率从 46.7% 提高到 62.8% [R1](https://vuke.top/evidence/R1)。 出处: [R1](https://vuke.top/evidence/R1) [R5](https://vuke.top/evidence/R5) ### [算力中心建设](https://vuke.top/solutions/datacenter-construction) 从 128 卡联测到千卡级算力中心，我们交付的是可以重算的方案：网络 BOM、三级存储与 KV 分层、供电与 PUE、TCO，全部用 Python 建模，你可以改参数重跑。 出处: [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) ### [推理栈软件开发](https://vuke.top/solutions/software-development) 我们直接改推理栈的源码，并把改动原样交付给你：补丁、编排脚本和原始数据都在 R8 复现包里 [R8](https://vuke.top/evidence/R8)。 出处: [R1](https://vuke.top/evidence/R1) [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7) [R8](https://vuke.top/evidence/R8) --- ## 存储加速：KV Cache 分层 > 在显存和主机内存之外加一层 FX 全闪 NVMe-oF 存储，用 vLLM + LMCache 把溢出的 KV Cache 写进去，命中时直接读回。480B 大模型生产部署形态下，相对本地 NVMe 单盘吞吐提升 29–40%、TTFT 降低 26–32%。 网页地址: https://vuke.top/solutions/storage-acceleration · 更新于 2026 年 11 月 12 日 存储加速 ### 要解决的问题 长上下文、多轮对话和 Agent 负载会不断把 KV Cache 挤出显存。被挤出的会话再次到来时，GPU 只能把整段上下文重新算一遍，首 token 延迟可能长达上百秒，吞吐也随之下滑。 ### 我们的做法 在显存和主机内存之外加一层 FX 全闪 NVMe-oF 存储，用 vLLM + LMCache 把溢出的 KV Cache 写进去，命中时直接读回。480B 大模型生产部署形态下，相对本地 NVMe 单盘吞吐提升 29–40%、TTFT 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。 ### 要点与出处 - 不加卡先多出一截产能：联测口径下存储投入约占 GPU 预算的一成以内，换来 29–40% 的吞吐提升 [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) - 会话恢复风暴不再拖垮服务：相对无外存整段重算，加速 8.6–20× [R2](https://vuke.top/evidence/R2) - 多个实例共用一份缓存：fs:// 共享池的跨实例热共享已验证，两轮独立测量偏差 ≤5% [R3](https://vuke.top/evidence/R3) - 存量集群同样受益：在 NFS 成为瓶颈的昇腾 910B 平台上，模型加载提速 6.2–9.3× [R9](https://vuke.top/evidence/R9) ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） - [R4](https://vuke.top/evidence/R4) · FX100 KV Cache 性能测试报告（480B · 多实例形态 · 编号 -006） - [R9](https://vuke.top/evidence/R9) · FX100 与华为昇腾 910B 模型推理与训练性能测试（对照 NFS 基线） ### 相关产品 - [FX100](https://vuke.top/products/fx100): 实测数据最完整的主力机型 - [FX200](https://vuke.top/products/fx200): 单口带宽与 IOPS 翻倍的 PCIe 4.0 机型 - [FX300](https://vuke.top/products/fx300): PCIe 5.0 性能档，含 6 块 DPU ### 先联测，后决策 合作从一次约 10 周的门禁化联测开始。四道门禁逐级放行，任何一道不达标就在那里停下，不必为没有被证实的收益买单。 - **G1 · 第 2 周 · 到货验收**: 物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - **G2 · 第 4 周 · 单机基线**: 复现单节点 8 卡推理基线，与 R1 口径的偏差在 ±10% 以内；单阵列本地压测达到实测锚点 83% 的线效。 - **G3 · 第 7 周 · 联测主门禁**: KV 分层加速须同时满足：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - **G4 · 第 10 周 · 稳定性与验收**: 72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 --- ## 国产与非 N 卡算力适配 > 我们在推理栈的源码层面做适配，并且每个平台单独出实测报告：AMD MI308X × 8、华为昇腾 910B × 8、沐曦 N260。不同平台的数字分开标注，不合并成一个头条。 网页地址: https://vuke.top/solutions/domestic-compute · 更新于 2026 年 11 月 12 日 国产算力适配 ### 要解决的问题 国产卡和非 N 卡买回来只是第一步。推理框架要重新编译，缓存库的读路径要重写，多模态模型的算子要逐个验证——这些工作没人做，卡就只是放在机房里的硬件。 ### 我们的做法 我们在推理栈的源码层面做适配，并且每个平台单独出实测报告：AMD MI308X × 8 [R1](https://vuke.top/evidence/R1)、华为昇腾 910B × 8 [R9](https://vuke.top/evidence/R9)、沐曦 N260 [R5](https://vuke.top/evidence/R5)。不同平台的数字分开标注，不合并成一个头条。 ### 要点与出处 - vLLM / LMCache 在 ROCm 上的源码级编译与补丁：并行读补丁让 TTFT 改善 4.1× [R1](https://vuke.top/evidence/R1) - 多平台实测覆盖：MI308X 上的 R1–R4，昇腾 910B 上的 R9，沐曦 N260 上的 R5 - 多模态同样跑通：ComfyUI + LTX-Video 2.3 的 7 个模型在 MI308X / ROCm 7.2 全部实跑通过，无算子或内核错误 [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7) - 交付到代码一级：git patch、负载客户端、编排与取证脚本、原始数据完整导出 [R8](https://vuke.top/evidence/R8) ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） - [R5](https://vuke.top/evidence/R5) · FX100 KV Cache 性能测试报告（14B · 显存效益） - [R6](https://vuke.top/evidence/R6) · ComfyUI + LTX-Video 2.3 全模型部署、适配与使用报告（V2） - [R7](https://vuke.top/evidence/R7) · ComfyUI + LTX-Video 2.3 模型适配报告（AMD MI308X） - [R8](https://vuke.top/evidence/R8) · FX100 KV Cache 测试代码导出包与原始测试数据 - [R9](https://vuke.top/evidence/R9) · FX100 与华为昇腾 910B 模型推理与训练性能测试（对照 NFS 基线） ### 相关产品 - [FX100](https://vuke.top/products/fx100): 实测数据最完整的主力机型 ### 先联测，后决策 合作从一次约 10 周的门禁化联测开始。四道门禁逐级放行，任何一道不达标就在那里停下，不必为没有被证实的收益买单。 - **G1 · 第 2 周 · 到货验收**: 物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - **G2 · 第 4 周 · 单机基线**: 复现单节点 8 卡推理基线，与 R1 口径的偏差在 ±10% 以内；单阵列本地压测达到实测锚点 83% 的线效。 - **G3 · 第 7 周 · 联测主门禁**: KV 分层加速须同时满足：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - **G4 · 第 10 周 · 稳定性与验收**: 72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 --- ## 算力中心效能优化 > 先把等待时间压下去，再谈扩卡。在每小时切换 20 次模型的档位下，算力有效利用率从 46.7% 提高到 62.8%。 网页地址: https://vuke.top/solutions/efficiency-optimization · 更新于 2026 年 11 月 12 日 效能优化 ### 要解决的问题 很多集群的问题不是卡不够，而是卡在等：等模型加载，等模型切换，等 Checkpoint 写完。这些等待时间里 GPU 在耗电，却没有产出。 ### 我们的做法 先把等待时间压下去，再谈扩卡。在每小时切换 20 次模型的档位下，算力有效利用率从 46.7% 提高到 62.8% [R1](https://vuke.top/evidence/R1)。 ### 要点与出处 - 模型切换：按实测加载时间建模，每小时切换 20 次时有效利用率 46.7% → 62.8% [R1](https://vuke.top/evidence/R1) - 并发加载：8 张卡同时冷读，墙钟时间快 16%，单模型加载快 30% [R1](https://vuke.top/evidence/R1) - 训练 Checkpoint：并发写快 1.9×，缩短训练中的空转气泡 [R1](https://vuke.top/evidence/R1) - 显存等效：外置 KV 层可以替代 128 GB 级别的显存驻留（14B 模型七组对照，沐曦 N260 平台） [R5](https://vuke.top/evidence/R5) ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） - [R5](https://vuke.top/evidence/R5) · FX100 KV Cache 性能测试报告（14B · 显存效益） ### 相关产品 - [FX100](https://vuke.top/products/fx100): 实测数据最完整的主力机型 ### 先联测，后决策 合作从一次约 10 周的门禁化联测开始。四道门禁逐级放行，任何一道不达标就在那里停下，不必为没有被证实的收益买单。 - **G1 · 第 2 周 · 到货验收**: 物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - **G2 · 第 4 周 · 单机基线**: 复现单节点 8 卡推理基线，与 R1 口径的偏差在 ±10% 以内；单阵列本地压测达到实测锚点 83% 的线效。 - **G3 · 第 7 周 · 联测主门禁**: KV 分层加速须同时满足：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - **G4 · 第 10 周 · 稳定性与验收**: 72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 --- ## 算力中心建设 > 从 128 卡联测到千卡级算力中心，我们交付的是可以重算的方案：网络 BOM、三级存储与 KV 分层、供电与 PUE、TCO，全部用 Python 建模，你可以改参数重跑。 网页地址: https://vuke.top/solutions/datacenter-construction · 更新于 2026 年 11 月 12 日 算力中心建设 ### 要解决的问题 算力中心的方案书常常只有结论，没有推导：网络怎么配、存储配多少、多久回本，都要你相信一张表格。 ### 我们的做法 从 128 卡联测到千卡级算力中心，我们交付的是可以重算的方案：网络 BOM、三级存储与 KV 分层、供电与 PUE、TCO，全部用 Python 建模，你可以改参数重跑。 ### 要点与出处 - 千卡方案（128 节点 × 8 张 MI308X）带完整 TCO 模型：网络、存储、供电、折旧逐项建模，并做 1 万次 Monte Carlo 敏感性分析 - 门禁化联测：G1 到货验收 → G2 单机基线 → G3 联测主门禁（TTFT 降幅 ≥25%，吞吐落在 +29–40% 实测区间 [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)）→ G4 72 小时稳定性，不达标即止损 - 存储按生产口径配比：每台 FX100 服务 8 个节点，依据是 100 GbE 支撑 8 节点 KV 回读的实测锚点 [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) - 网络与关键部件的价格锚点均注明公开来源，可逐项核对 ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） ### 相关产品 - [FX100](https://vuke.top/products/fx100): 实测数据最完整的主力机型 - [FX300](https://vuke.top/products/fx300): PCIe 5.0 性能档，含 6 块 DPU - [FX400](https://vuke.top/products/fx400): 下一代旗舰，PCIe 6.0 + E1.S ### 先联测，后决策 合作从一次约 10 周的门禁化联测开始。四道门禁逐级放行，任何一道不达标就在那里停下，不必为没有被证实的收益买单。 - **G1 · 第 2 周 · 到货验收**: 物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - **G2 · 第 4 周 · 单机基线**: 复现单节点 8 卡推理基线，与 R1 口径的偏差在 ±10% 以内；单阵列本地压测达到实测锚点 83% 的线效。 - **G3 · 第 7 周 · 联测主门禁**: KV 分层加速须同时满足：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - **G4 · 第 10 周 · 稳定性与验收**: 72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 --- ## 推理栈软件开发 > 我们直接改推理栈的源码，并把改动原样交付给你：补丁、编排脚本和原始数据都在 R8 复现包里。 网页地址: https://vuke.top/solutions/software-development · 更新于 2026 年 11 月 12 日 软件开发 ### 要解决的问题 硬件到位之后，真正卡住进度的往往是软件：上游框架不支持你的卡，缓存库在你的负载下有缺陷，新的模型类型没人适配。 ### 我们的做法 我们直接改推理栈的源码，并把改动原样交付给你：补丁、编排脚本和原始数据都在 R8 复现包里 [R8](https://vuke.top/evidence/R8)。 ### 要点与出处 - 已经验证过的上游级工程能力：vLLM / LMCache 的 ROCm 编译、并行读补丁、GDS 适配层、fs:// 缺陷定位 [R1](https://vuke.top/evidence/R1) [R8](https://vuke.top/evidence/R8) - 新需求的快速验证：AI 视频生成产线（ComfyUI / LTX-Video 已跑通） [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7)、私有化推理一体机等 - 开发者资源：约 10,000 名成熟软件开发者（公司口径，接受尽调核验，不作为论证数据） - 高校协同：与北京信息科技大学开展校企合作，万名量级的在校开发者可通过课程共建与开源实训参与 ROCm 生态（校方口径） ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） - [R6](https://vuke.top/evidence/R6) · ComfyUI + LTX-Video 2.3 全模型部署、适配与使用报告（V2） - [R7](https://vuke.top/evidence/R7) · ComfyUI + LTX-Video 2.3 模型适配报告（AMD MI308X） - [R8](https://vuke.top/evidence/R8) · FX100 KV Cache 测试代码导出包与原始测试数据 ### 先联测，后决策 合作从一次约 10 周的门禁化联测开始。四道门禁逐级放行，任何一道不达标就在那里停下，不必为没有被证实的收益买单。 - **G1 · 第 2 周 · 到货验收**: 物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - **G2 · 第 4 周 · 单机基线**: 复现单节点 8 卡推理基线，与 R1 口径的偏差在 ±10% 以内；单阵列本地压测达到实测锚点 83% 的线效。 - **G3 · 第 7 周 · 联测主门禁**: KV 分层加速须同时满足：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - **G4 · 第 10 周 · 稳定性与验收**: 72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 --- ## 实测证据库：R1–R9 测试报告索引 > 本站全部关键数字的出处：九份测试报告的范围、平台与关键结论，覆盖 AMD MI308X、华为昇腾 910B、沐曦 N260，含第三方正式报告与可复现代码包。 网页地址: https://vuke.top/evidence · 更新于 2026 年 11 月 12 日 本站的每个关键数字后面都有一个编号，对应这里的一份报告。这里公开每份报告测了什么、在什么平台上测、得出了什么结论；报告原件可以向我们申请查阅。 ### 测试报告 | ID | 日期 | 类型 | 测试平台 | 标题 | | --- | --- | --- | --- | --- | | [R1](https://vuke.top/evidence/R1) | 2026-07-03 | 性能测试报告 | AMD Instinct MI308X × 8 · ROCm 7.2 | FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） | | [R2](https://vuke.top/evidence/R2) | 2026-07-05 | 性能测试报告（正式版） | AMD Instinct MI308X × 8 · ROCm 7.2 | FX100 KV Cache 性能测试报告（480B · TP8 长上下文） | | [R3](https://vuke.top/evidence/R3) | 2026-07-06 | 性能测试汇总报告（正式版） | AMD Instinct MI308X × 8 · ROCm 7.2 | FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） | | [R4](https://vuke.top/evidence/R4) | 2026-07-06 | 第三方检测机构正式报告 | AMD Instinct MI308X × 8 · ROCm 7.2 | FX100 KV Cache 性能测试报告（480B · 多实例形态 · 编号 -006） | | [R5](https://vuke.top/evidence/R5) | 2026-07-03 | 性能测试报告（正式版，编号 -004） | 沐曦 N260 单卡 | FX100 KV Cache 性能测试报告（14B · 显存效益） | | [R6](https://vuke.top/evidence/R6) | 2026-07-07 | 部署与适配报告 | AMD Instinct MI308X · ROCm 7.2 | ComfyUI + LTX-Video 2.3 全模型部署、适配与使用报告（V2） | | [R7](https://vuke.top/evidence/R7) | 2026-07-07 | 模型适配报告 | AMD Instinct MI308X | ComfyUI + LTX-Video 2.3 模型适配报告（AMD MI308X） | | [R8](https://vuke.top/evidence/R8) | 2026-07 | 代码导出包与原始数据 | AMD Instinct MI308X · ROCm 7.2 | FX100 KV Cache 测试代码导出包与原始测试数据 | | [R9](https://vuke.top/evidence/R9) | 2026-05-30 | 性能测试报告 | 华为 Atlas 910B × 8（Kunpeng-920） | FX100 与华为昇腾 910B 模型推理与训练性能测试（对照 NFS 基线） | ### 关键数字与出处 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | 推理吞吐提升 | +29–40% | 对比本地 NVMe 单盘 | Qwen3-Coder-480B-FP8、TP=8 生产部署形态，长上下文冷恢复负载：并发 8 时 +29%，并发 16（实测中提升幅度最大的一档）时 +40%；TP4×2 双实例全机口径为 +35–36%。 | 实测 · [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | | 首 token 延迟（TTFT）降低 | −26–32% | 对比本地 NVMe 单盘 | 同一 480B·TP8 负载的三档并发下，TTFT p50 从 10.17–35.73 s 降到 7.53–26.35 s。 | 实测 · [R2](https://vuke.top/evidence/R2) | | 相对无外存重算的加速 | 8.6–20× | 对比无外存、整段重算 | 并发 16：整段重算的 TTFT p50 为 149.5 s，接入 FX100 后为 11.85 s；吞吐 4.1 tok/s 对 74.9 tok/s。 | 实测 · [R2](https://vuke.top/evidence/R2) | | LMCache 并行读补丁的 TTFT 改善 | 4.1× | 对比打补丁之前 | 单卡、并发 16、冷读盘（Qwen2.5-32B）：TTFT 37.97 s → 9.30 s；读带宽 0.98 → 5.23 GB/s，约 5.3×。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 模型服务加载提速 | 6.2–9.3× | 对比 NFS，昇腾 910B 平台 | 华为 Atlas 910B 平台：DeepSeek-32B 服务加载 691 s → 112 s（6.2×），DeepSeek-70B 1399 s → 150 s（9.3×）。 | 实测 · [R9](https://vuke.top/evidence/R9) | | 训练 Checkpoint 保存提速 | 1.9× | 对比 R1 报告中的对照基线 | 8 卡 32B LoRA，每份整模型快照 65.6 GB：178 s → 94 s；持续写带宽 3.26 → 6.40 GB/s（+96%）。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 模型切换场景的算力有效利用率 | 46.7% → 62.8% | 每小时切换 20 次的档位 | 按实测加载时间建模：每小时切换 20 次模型时，算力有效利用率从 46.7% 提高到 62.8%。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 8 卡并发加载模型 | 16% / 30% | 对比 R1 报告中的对照基线 | 8 张卡同时冷读模型：整体墙钟时间快 16%，单个模型加载快 30%。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 两轮独立测量的偏差 | ≤5% | 同一档位重复测量 | 同一档位做两轮独立测量，偏差不超过 5%；fs:// 共享池的跨实例热共享同时验证通过。 | 实测 · [R3](https://vuke.top/evidence/R3) | | 外置 KV 层可替代的显存驻留量级 | 128 GB | 沐曦 N260 单卡，14B 模型七组对照 | 14B 模型七组对照的结论：外置 KV 层可以替代 128 GB 级别的显存驻留。该轮平台是沐曦 N260 单卡，方法论可跨平台使用，数字不与 MI308X 混用。 | 实测 · [R5](https://vuke.top/evidence/R5) | | ComfyUI + LTX-Video 2.3 模型实跑通过 | 7 / 7 | AMD MI308X，ROCm 7.2 | 交付的 7 个模型（3 个 VAE、fp8 文本编码器、文本投影、2 个 LoRA）在 MI308X / ROCm 7.2 上全部实跑通过，没有出现 dtype、算子或内核错误。 | 实测 · [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7) | | 阵列与推理节点的配比 | 1 : 8 | 生产配比口径 | 每台 FX100 服务 8 个推理节点：100 GbE 能支撑 8 节点 KV 回读是实测锚点。联测口径下，存储投入约占 GPU 预算的一成以内。 | 估算 · [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | ### 480B · TP8 原始读数 | 并发 | FX100 TTFT p50 (s) | 本地 NVMe 单盘 TTFT p50 (s) | 整段重算 TTFT p50 (s) | FX100 tok/s | 本地 NVMe 单盘 tok/s | 整段重算 tok/s | | --- | --- | --- | --- | --- | --- | --- | | 8 | 7.53 | 10.17 | — | 56.6 | 43.9 | — | | 16 | 11.85 | 17.31 | 149.48 | 74.9 | 53.6 | 4.1 | | 32 | 26.35 | 35.73 | — | 71.6 | 53.9 | — | Qwen3-Coder-480B-FP8 · TP=8 · 8 × MI308X · 长上下文冷恢复负载。TTFT 为 p50，单位秒；吞吐单位 tok/s；整段重算只测了并发 16 一档。 出处: [R2](https://vuke.top/evidence/R2) ### 测试平台 (R1, R2, R3, R4) - 加速卡: 8 × AMD Instinct MI308X（每卡 192 GB HBM，gfx942） - 主机: 2 × AMD EPYC 9654（384 线程），内存约 1.5 TB - 软件栈: ROCm 7.2 · vLLM 0.20.1+rocm721 · LMCache（上游主线 2026-06-29 源码编译） - 被测设备: FX100 全闪 NVMe-oF 阵列：4 盘 RAID0（14 TB，XFS），RoCEv2，单口 100 GbE - 对照基线: 本地 NVMe 单盘（PCIe Gen4，2 TB）；无外存、整段重算 - 480B 模型: Qwen3-Coder-480B-FP8（MoE，权重约 450 GB） ### 四种数据口径 - **实测**: 出自签字级或正式版测试报告，带报告编号。 - **厂商**: 产品标称规格与列表参考价。 - **公开**: 来自可公开查阅的第三方资料，附来源链接。 - **估算**: 由实测锚点推算，测算模型可用 Python 复现。 ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) 关于名称：FX100 在早期测试报告的文件名里写作 AISSD5000，更早也叫过 WS5000 / GP5000，报告原文有时署「铭信」。它们指的是同一款产品。本站统一使用 FX 命名（FX100 / FX200 / FX300 / FX400），报告条目保留原始标题，方便对照查证。 --- ## R1：FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） > 一份报告回答五个问题：LMCache 并行读补丁有多大作用、KV 分层在多卡下能否扩展、8 卡并发加载模型快多少、频繁切换模型时算力有效利用率如何变化、训练 Checkpoint 并发写能快多少。测试模型为 Qwen2.5-32B 与 7B。 网页地址: https://vuke.top/evidence/R1 · 更新于 2026 年 11 月 12 日 一份报告回答五个问题：LMCache 并行读补丁有多大作用、KV 分层在多卡下能否扩展、8 卡并发加载模型快多少、频繁切换模型时算力有效利用率如何变化、训练 Checkpoint 并发写能快多少。测试模型为 Qwen2.5-32B 与 7B。 - 报告: R1 - 日期: 2026-07-03 - 类型: 性能测试报告 - 测试平台: AMD Instinct MI308X × 8 · ROCm 7.2 ### 关键结论 - LMCache 并行读补丁：单卡并发 16 冷读盘，TTFT 37.97 s → 9.30 s（4.1×），读带宽 0.98 → 5.23 GB/s - 训练 Checkpoint：每份 65.6 GB 的整模型快照，保存耗时 178 s → 94 s（1.9×），持续写带宽 3.26 → 6.40 GB/s - 模型并发加载：8 张卡同时冷读，墙钟时间快 16%，单模型加载快 30% - 模型切换：每小时切换 20 次时，算力有效利用率 46.7% → 62.8% ### 这份报告支撑的数字 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | LMCache 并行读补丁的 TTFT 改善 | 4.1× | 对比打补丁之前 | 单卡、并发 16、冷读盘（Qwen2.5-32B）：TTFT 37.97 s → 9.30 s；读带宽 0.98 → 5.23 GB/s，约 5.3×。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 训练 Checkpoint 保存提速 | 1.9× | 对比 R1 报告中的对照基线 | 8 卡 32B LoRA，每份整模型快照 65.6 GB：178 s → 94 s；持续写带宽 3.26 → 6.40 GB/s（+96%）。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 模型切换场景的算力有效利用率 | 46.7% → 62.8% | 每小时切换 20 次的档位 | 按实测加载时间建模：每小时切换 20 次模型时，算力有效利用率从 46.7% 提高到 62.8%。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 8 卡并发加载模型 | 16% / 30% | 对比 R1 报告中的对照基线 | 8 张卡同时冷读模型：整体墙钟时间快 16%，单个模型加载快 30%。 | 实测 · [R1](https://vuke.top/evidence/R1) | | 阵列与推理节点的配比 | 1 : 8 | 生产配比口径 | 每台 FX100 服务 8 个推理节点：100 GbE 能支撑 8 节点 KV 回读是实测锚点。联测口径下，存储投入约占 GPU 预算的一成以内。 | 估算 · [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | ### 测试平台 - 加速卡: 8 × AMD Instinct MI308X（每卡 192 GB HBM，gfx942） - 主机: 2 × AMD EPYC 9654（384 线程），内存约 1.5 TB - 软件栈: ROCm 7.2 · vLLM 0.20.1+rocm721 · LMCache（上游主线 2026-06-29 源码编译） - 被测设备: FX100 全闪 NVMe-oF 阵列：4 盘 RAID0（14 TB，XFS），RoCEv2，单口 100 GbE - 对照基线: 本地 NVMe 单盘（PCIe Gen4，2 TB）；无外存、整段重算 - 480B 模型: Qwen3-Coder-480B-FP8（MoE，权重约 450 GB） ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## R2：FX100 KV Cache 性能测试报告（480B · TP8 长上下文） > Qwen3-Coder-480B-FP8 以八卡单实例（TP=8）的标准生产形态部署，在长上下文冷恢复负载下做三方对照：FX100、本地 NVMe 单盘、无外存整段重算，并按并发 8 / 16 / 32 做梯度。本站引用最多的吞吐与 TTFT 数字出自这份报告。 网页地址: https://vuke.top/evidence/R2 · 更新于 2026 年 11 月 12 日 Qwen3-Coder-480B-FP8 以八卡单实例（TP=8）的标准生产形态部署，在长上下文冷恢复负载下做三方对照：FX100、本地 NVMe 单盘、无外存整段重算，并按并发 8 / 16 / 32 做梯度。本站引用最多的吞吐与 TTFT 数字出自这份报告。 - 报告: R2 - 日期: 2026-07-05 - 类型: 性能测试报告（正式版） - 测试平台: AMD Instinct MI308X × 8 · ROCm 7.2 ### 关键结论 - 吞吐：并发 8 时 56.6 对 43.9 tok/s（+29%），并发 16 时 74.9 对 53.6 tok/s（+40%） - TTFT p50：三档并发分别为 7.53 / 11.85 / 26.35 s，本地 NVMe 单盘为 10.17 / 17.31 / 35.73 s，降幅 26–32% - 对比无外存整段重算（并发 16）：TTFT p50 149.48 s → 11.85 s，吞吐 4.1 → 74.9 tok/s ### 原始读数 | 并发 | FX100 TTFT p50 (s) | 本地 NVMe 单盘 TTFT p50 (s) | 整段重算 TTFT p50 (s) | FX100 tok/s | 本地 NVMe 单盘 tok/s | 整段重算 tok/s | | --- | --- | --- | --- | --- | --- | --- | | 8 | 7.53 | 10.17 | — | 56.6 | 43.9 | — | | 16 | 11.85 | 17.31 | 149.48 | 74.9 | 53.6 | 4.1 | | 32 | 26.35 | 35.73 | — | 71.6 | 53.9 | — | Qwen3-Coder-480B-FP8 · TP=8 · 8 × MI308X · 长上下文冷恢复负载。TTFT 为 p50，单位秒；吞吐单位 tok/s；整段重算只测了并发 16 一档。 出处: [R2](https://vuke.top/evidence/R2) ### 这份报告支撑的数字 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | 推理吞吐提升 | +29–40% | 对比本地 NVMe 单盘 | Qwen3-Coder-480B-FP8、TP=8 生产部署形态，长上下文冷恢复负载：并发 8 时 +29%，并发 16（实测中提升幅度最大的一档）时 +40%；TP4×2 双实例全机口径为 +35–36%。 | 实测 · [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | | 首 token 延迟（TTFT）降低 | −26–32% | 对比本地 NVMe 单盘 | 同一 480B·TP8 负载的三档并发下，TTFT p50 从 10.17–35.73 s 降到 7.53–26.35 s。 | 实测 · [R2](https://vuke.top/evidence/R2) | | 相对无外存重算的加速 | 8.6–20× | 对比无外存、整段重算 | 并发 16：整段重算的 TTFT p50 为 149.5 s，接入 FX100 后为 11.85 s；吞吐 4.1 tok/s 对 74.9 tok/s。 | 实测 · [R2](https://vuke.top/evidence/R2) | | 阵列与推理节点的配比 | 1 : 8 | 生产配比口径 | 每台 FX100 服务 8 个推理节点：100 GbE 能支撑 8 节点 KV 回读是实测锚点。联测口径下，存储投入约占 GPU 预算的一成以内。 | 估算 · [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | ### 测试平台 - 加速卡: 8 × AMD Instinct MI308X（每卡 192 GB HBM，gfx942） - 主机: 2 × AMD EPYC 9654（384 线程），内存约 1.5 TB - 软件栈: ROCm 7.2 · vLLM 0.20.1+rocm721 · LMCache（上游主线 2026-06-29 源码编译） - 被测设备: FX100 全闪 NVMe-oF 阵列：4 盘 RAID0（14 TB，XFS），RoCEv2，单口 100 GbE - 对照基线: 本地 NVMe 单盘（PCIe Gen4，2 TB）；无外存、整段重算 - 480B 模型: Qwen3-Coder-480B-FP8（MoE，权重约 450 GB） ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## R3：FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） > 同一台 8 卡服务器改为四卡双实例（TP4×2）部署，九档负载记录全部指标：TTFT 的 p50 / p90 / p99、TPOT、吞吐与盘带宽。这份报告还验证了两件事：fs:// 共享池能让两个实例热共享同一份缓存；同一档位做两轮独立测量，偏差不超过 5%。 网页地址: https://vuke.top/evidence/R3 · 更新于 2026 年 11 月 12 日 同一台 8 卡服务器改为四卡双实例（TP4×2）部署，九档负载记录全部指标：TTFT 的 p50 / p90 / p99、TPOT、吞吐与盘带宽。这份报告还验证了两件事：fs:// 共享池能让两个实例热共享同一份缓存；同一档位做两轮独立测量，偏差不超过 5%。 - 报告: R3 - 日期: 2026-07-06 - 类型: 性能测试汇总报告（正式版） - 测试平台: AMD Instinct MI308X × 8 · ROCm 7.2 ### 关键结论 - TP4×2 全机口径吞吐提升 +35–36% - fs:// 共享池跨实例热共享验证通过 - 两轮独立测量偏差 ≤5% > 说明: 签字原件沿用早期产品称谓（AISSD5000）。对外提供的是品牌统一版：产品名统一为 FX100，重排版式并补充了图表与数值校验附录，九档实测值与签字原件逐格一致。签字原件可应要求提供，用于核对同一性。 ### 这份报告支撑的数字 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | 推理吞吐提升 | +29–40% | 对比本地 NVMe 单盘 | Qwen3-Coder-480B-FP8、TP=8 生产部署形态，长上下文冷恢复负载：并发 8 时 +29%，并发 16（实测中提升幅度最大的一档）时 +40%；TP4×2 双实例全机口径为 +35–36%。 | 实测 · [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | | 两轮独立测量的偏差 | ≤5% | 同一档位重复测量 | 同一档位做两轮独立测量，偏差不超过 5%；fs:// 共享池的跨实例热共享同时验证通过。 | 实测 · [R3](https://vuke.top/evidence/R3) | | 阵列与推理节点的配比 | 1 : 8 | 生产配比口径 | 每台 FX100 服务 8 个推理节点：100 GbE 能支撑 8 节点 KV 回读是实测锚点。联测口径下，存储投入约占 GPU 预算的一成以内。 | 估算 · [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) | ### 测试平台 - 加速卡: 8 × AMD Instinct MI308X（每卡 192 GB HBM，gfx942） - 主机: 2 × AMD EPYC 9654（384 线程），内存约 1.5 TB - 软件栈: ROCm 7.2 · vLLM 0.20.1+rocm721 · LMCache（上游主线 2026-06-29 源码编译） - 被测设备: FX100 全闪 NVMe-oF 阵列：4 盘 RAID0（14 TB，XFS），RoCEv2，单口 100 GbE - 对照基线: 本地 NVMe 单盘（PCIe Gen4，2 TB）；无外存、整段重算 - 480B 模型: Qwen3-Coder-480B-FP8（MoE，权重约 450 GB） ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## R4：FX100 KV Cache 性能测试报告（480B · 多实例形态 · 编号 -006） > R2 与 R3 的正式汇编版，由第三方检测机构出具，报告编号 -006。如果你的采购或合规流程需要一份出自第三方机构的文件，引用这一份。 网页地址: https://vuke.top/evidence/R4 · 更新于 2026 年 11 月 12 日 R2 与 R3 的正式汇编版，由第三方检测机构出具，报告编号 -006。如果你的采购或合规流程需要一份出自第三方机构的文件，引用这一份。 - 报告: R4 - 日期: 2026-07-06 - 类型: 第三方检测机构正式报告 - 测试平台: AMD Instinct MI308X × 8 · ROCm 7.2 ### 关键结论 - 汇编 R2（TP8）与 R3（TP4×2）两种部署形态的全部实测结论 - 由第三方检测机构出具，报告编号 -006 ### 测试平台 - 加速卡: 8 × AMD Instinct MI308X（每卡 192 GB HBM，gfx942） - 主机: 2 × AMD EPYC 9654（384 线程），内存约 1.5 TB - 软件栈: ROCm 7.2 · vLLM 0.20.1+rocm721 · LMCache（上游主线 2026-06-29 源码编译） - 被测设备: FX100 全闪 NVMe-oF 阵列：4 盘 RAID0（14 TB，XFS），RoCEv2，单口 100 GbE - 对照基线: 本地 NVMe 单盘（PCIe Gen4，2 TB）；无外存、整段重算 - 480B 模型: Qwen3-Coder-480B-FP8（MoE，权重约 450 GB） ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## R5：FX100 KV Cache 性能测试报告（14B · 显存效益） > 这份报告回答「外置 KV 层能不能当显存用」。14B 模型上做七组对照（GDS 直读、两档显存下的重算、低显存直读），用三步论证得出显存等效替代的结论。测试平台是沐曦 N260 单卡，方法论可以跨平台使用，但数字不与 MI308X 的结果混用。 网页地址: https://vuke.top/evidence/R5 · 更新于 2026 年 11 月 12 日 这份报告回答「外置 KV 层能不能当显存用」。14B 模型上做七组对照（GDS 直读、两档显存下的重算、低显存直读），用三步论证得出显存等效替代的结论。测试平台是沐曦 N260 单卡，方法论可以跨平台使用，但数字不与 MI308X 的结果混用。 - 报告: R5 - 日期: 2026-07-03 - 类型: 性能测试报告（正式版，编号 -004） - 测试平台: 沐曦 N260 单卡 ### 关键结论 - 外置 KV 层可以替代 128 GB 级别的显存驻留 - 七组对照覆盖 GDS 直读、两档显存重算与低显存直读 ### 这份报告支撑的数字 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | 外置 KV 层可替代的显存驻留量级 | 128 GB | 沐曦 N260 单卡，14B 模型七组对照 | 14B 模型七组对照的结论：外置 KV 层可以替代 128 GB 级别的显存驻留。该轮平台是沐曦 N260 单卡，方法论可跨平台使用，数字不与 MI308X 混用。 | 实测 · [R5](https://vuke.top/evidence/R5) | ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## R6：ComfyUI + LTX-Video 2.3 全模型部署、适配与使用报告（V2） > 视频生成方向的适配证明：交付的 7 个模型（3 个 VAE、fp8 文本编码器、文本投影、2 个 LoRA）在 MI308X / ROCm 7.2 上全部实跑通过，没有出现 dtype、算子或内核错误。 网页地址: https://vuke.top/evidence/R6 · 更新于 2026 年 11 月 12 日 视频生成方向的适配证明：交付的 7 个模型（3 个 VAE、fp8 文本编码器、文本投影、2 个 LoRA）在 MI308X / ROCm 7.2 上全部实跑通过，没有出现 dtype、算子或内核错误。 - 报告: R6 - 日期: 2026-07-07 - 类型: 部署与适配报告 - 测试平台: AMD Instinct MI308X · ROCm 7.2 ### 关键结论 - 7 个交付模型全部实跑通过 - 未出现 dtype、算子或内核错误 ### 这份报告支撑的数字 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | ComfyUI + LTX-Video 2.3 模型实跑通过 | 7 / 7 | AMD MI308X，ROCm 7.2 | 交付的 7 个模型（3 个 VAE、fp8 文本编码器、文本投影、2 个 LoRA）在 MI308X / ROCm 7.2 上全部实跑通过，没有出现 dtype、算子或内核错误。 | 实测 · [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7) | ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## R7：ComfyUI + LTX-Video 2.3 模型适配报告（AMD MI308X） > R6 的分模型细目：3 个 VAE 与 Singularity LoRA 逐个实跑的记录，以及在 MI308X 上需要注意的适配要点。 网页地址: https://vuke.top/evidence/R7 · 更新于 2026 年 11 月 12 日 R6 的分模型细目：3 个 VAE 与 Singularity LoRA 逐个实跑的记录，以及在 MI308X 上需要注意的适配要点。 - 报告: R7 - 日期: 2026-07-07 - 类型: 模型适配报告 - 测试平台: AMD Instinct MI308X ### 关键结论 - 3 个 VAE 与 Singularity LoRA 的逐模型实跑记录 - MI308X 上的适配要点 ### 这份报告支撑的数字 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | ComfyUI + LTX-Video 2.3 模型实跑通过 | 7 / 7 | AMD MI308X，ROCm 7.2 | 交付的 7 个模型（3 个 VAE、fp8 文本编码器、文本投影、2 个 LoRA）在 MI308X / ROCm 7.2 上全部实跑通过，没有出现 dtype、算子或内核错误。 | 实测 · [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7) | ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## R8：FX100 KV Cache 测试代码导出包与原始测试数据 > 让第三方能自己重跑一遍的全部材料：LMCache 并行读补丁（git patch 与修改前后全文）、负载客户端、编排脚本、探针取证脚本，以及原始测试数据。 网页地址: https://vuke.top/evidence/R8 · 更新于 2026 年 11 月 12 日 让第三方能自己重跑一遍的全部材料：LMCache 并行读补丁（git patch 与修改前后全文）、负载客户端、编排脚本、探针取证脚本，以及原始测试数据。 - 报告: R8 - 日期: 2026-07 - 类型: 代码导出包与原始数据 - 测试平台: AMD Instinct MI308X · ROCm 7.2 ### 关键结论 - LMCache 并行读补丁：git patch 与修改前后全文 - 负载客户端、编排脚本、探针取证脚本 - KV Cache 测试的原始结果数据 ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## R9：FX100 与华为昇腾 910B 模型推理与训练性能测试（对照 NFS 基线） > 在华为 Atlas 910B × 8 的昇腾平台上，以 NFS 为基线做三组对照：模型推理加载（DeepSeek-32B / 70B）、训练权重与 Checkpoint 存取（Qwen-7B）、训练数据加速（YOLOv8 / COCO）。平台是昇腾 910B 而不是 MI308X，本站引用时都会注明。 网页地址: https://vuke.top/evidence/R9 · 更新于 2026 年 11 月 12 日 在华为 Atlas 910B × 8 的昇腾平台上，以 NFS 为基线做三组对照：模型推理加载（DeepSeek-32B / 70B）、训练权重与 Checkpoint 存取（Qwen-7B）、训练数据加速（YOLOv8 / COCO）。平台是昇腾 910B 而不是 MI308X，本站引用时都会注明。 - 报告: R9 - 日期: 2026-05-30 - 类型: 性能测试报告 - 测试平台: 华为 Atlas 910B × 8（Kunpeng-920） ### 关键结论 - DeepSeek-32B 服务加载 691 s → 112 s（6.2×） - DeepSeek-70B 服务加载 1399 s → 150 s（9.3×） - 另含训练权重 / Checkpoint 存取与训练数据加速两组对照 ### 这份报告支撑的数字 | 指标 | 数值 | 对照基线 | 说明 | 出处 | | --- | --- | --- | --- | --- | | 模型服务加载提速 | 6.2–9.3× | 对比 NFS，昇腾 910B 平台 | 华为 Atlas 910B 平台：DeepSeek-32B 服务加载 691 s → 112 s（6.2×），DeepSeek-70B 1399 s → 150 s（9.3×）。 | 实测 · [R9](https://vuke.top/evidence/R9) | ### 申请报告原件 告诉我们你需要的报告编号和用途，我们会回复获取方式。R8 的代码导出包与原始数据同样按申请提供。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) --- ## KV Cache 分层的工作原理：显存、内存与外置全闪 > KV Cache 被挤出显存后，是整段重算还是从外置全闪读回？按一次请求的路径说明 KV Cache 分层为什么能降低 TTFT，以及它在哪些场景没用。 网页地址: https://vuke.top/tech · 更新于 2026 年 11 月 12 日 一句话：把溢出显存的 KV Cache 存下来，下次直接读，不再重算。下面沿着一次请求的路径，说明它为什么有效、在哪里有效、在哪里没用。 ### 问题：显存装不下所有会话 大模型每处理一个 token，都会在各注意力层留下一份 Key / Value 张量，这就是 KV Cache。有了它，生成下一个 token 时不必重新计算前面的上下文。上下文越长，这份缓存越大。 显存是有限的。本站测试平台的每张 AMD MI308X 有 192 GB HBM，除了放模型权重，还要放所有活跃会话的 KV Cache。会话一多，较早的缓存就被逐出。 被逐出的会话再发来请求时，模型只能把整段上下文重新预填充一遍。在 480B 模型、并发 16 的实测里，这样一次整段重算的首 token 延迟 p50 是 149.5 s [R2](https://vuke.top/evidence/R2)。 ### 三层存放：显存、主机内存、外置全闪 KV Cache 分层按访问热度把缓存放在三种介质上。前两层由推理框架管理，第三层需要单独的存储设备，FX 系列做的就是这一层。 - 第一层，显存：放当前活跃的会话，三层里访问延迟最低，容量也最小。 - 第二层，主机内存：放近期用过的会话，由 LMCache 管理。 - 第三层，外置全闪：放全部历史会话，并让多个推理实例共享同一份缓存。 ### 一次请求怎么走 命中一次外置缓存，就省掉一次完整的预填充。这是首 token 延迟下降的全部原因。 - 请求到达，LMCache 按输入 token 的前缀查找已有的 KV Cache。 - 显存里有，直接使用。 - 显存里没有，依次查主机内存和外置全闪；命中后把 KV Cache 读回显存，跳过这部分预填充。 - 各层都没有，才由 GPU 计算，并把新生成的 KV Cache 写入各层，供以后使用。 ### 实测：读回比重算快多少 测试对象是 Qwen3-Coder-480B-FP8，以八卡单实例（TP=8）的生产形态部署在 8 × AMD MI308X 上，负载是长上下文冷恢复。有两个对照基线，分母不同，不能混在一句话里说。 对比无外存、整段重算：加速 8.6–20× [R2](https://vuke.top/evidence/R2)。并发 16 时，TTFT p50 从 149.5 s 降到 11.85 s。 对比本地 NVMe 单盘：吞吐提升 29–40%，TTFT p50 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。也就是说，同样是把 KV Cache 存下来再读，放在 FX100 上比放在服务器本地的一块 NVMe 盘上更快。 ### 为什么网络上的阵列比本地盘还快 直觉上，本地盘离 GPU 更近，应该更快。但决定首 token 延迟的不是协议多出来的那一点时延，而是并发回读时能不能把数据足够快地送回显存。 实测形态下，对照的是一块本地 NVMe 盘（PCIe Gen4，2 TB），FX100 是 4 盘 RAID0 的全闪池，通过 RoCEv2 走单口 100 GbE [R2](https://vuke.top/evidence/R2)。软件上，LMCache 并行读补丁把单卡冷读带宽从 0.98 GB/s 提高到 5.23 GB/s [R1](https://vuke.top/evidence/R1)。 外置池还有一件本地盘做不到的事：多个推理实例共享同一份缓存。fs:// 共享池的跨实例热共享已经验证通过 [R3](https://vuke.top/evidence/R3)。 ### 边界：什么时候没用 收益来自缓存命中。短对话、低并发的场景里，会话很少被逐出，也很少回来，命中率低，这层存储的收益就有限。 长上下文、多轮对话、Agent 和代码助手这类负载，会话恢复频繁，收益最明显。你的负载属于哪一种，要用自己的会话长度分布和并发量测过才知道。这也是我们坚持先联测、后采购的原因。 ### 软件栈与复现材料 接入不需要重写推理引擎，用的是开源的 vLLM + LMCache 组合。实测使用的版本是 ROCm 7.2、vLLM 0.20.1+rocm721，LMCache 由上游主线 2026-06-29 的源码编译 [R2](https://vuke.top/evidence/R2)。 我们写的 LMCache 并行读补丁，连同负载客户端、编排脚本、探针取证脚本和原始数据，一起打包为 R8，第三方可以在自己的集群上重跑 [R8](https://vuke.top/evidence/R8)。 ### 原始读数 | 并发 | FX100 TTFT p50 (s) | 本地 NVMe 单盘 TTFT p50 (s) | 整段重算 TTFT p50 (s) | FX100 tok/s | 本地 NVMe 单盘 tok/s | 整段重算 tok/s | | --- | --- | --- | --- | --- | --- | --- | | 8 | 7.53 | 10.17 | — | 56.6 | 43.9 | — | | 16 | 11.85 | 17.31 | 149.48 | 74.9 | 53.6 | 4.1 | | 32 | 26.35 | 35.73 | — | 71.6 | 53.9 | — | Qwen3-Coder-480B-FP8 · TP=8 · 8 × MI308X · 长上下文冷恢复负载。TTFT 为 p50，单位秒；吞吐单位 tok/s；整段重算只测了并发 16 一档。 出处: [R2](https://vuke.top/evidence/R2) ### 外部参考资料 - [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/abs/2309.06180) · arXiv (SOSP '23). vLLM 的 PagedAttention 显存管理与 KV Cache 分页的设计动机 - [Mooncake: A KVCache-centric Disaggregated Architecture for LLM Serving](https://arxiv.org/abs/2407.00079) · arXiv. 以 KV Cache 为中心的存算分离架构，以及跨节点复用 KV Cache 的设计取舍 - [LMCache (GitHub repository)](https://github.com/LMCache/LMCache) · LMCache Project. LMCache 的源码、架构与存储后端说明 - [vLLM Documentation](https://docs.vllm.ai/) · vLLM Project. vLLM 的部署方式、前缀缓存与张量并行等配置的官方说明 - [NVM Express Specifications](https://nvmexpress.org/specifications/) · NVM Express, Inc.. NVMe 与 NVMe over Fabrics 的官方规范 - [RFC 5040: A Remote Direct Memory Access Protocol Specification](https://datatracker.ietf.org/doc/html/rfc5040) · IETF. RDMA 协议的规范定义 --- ## 洞察：用实测数据回答 AI 推理存储的常见问题 > 关于 KV Cache 分层、TTFT 优化、LMCache、NVMe-oF、国产算力适配与推理存储验收的文章。每篇先给结论，再给实测数据和报告出处。 网页地址: https://vuke.top/insights · 更新于 2026 年 11 月 12 日 买方真正会问的问题，一篇回答一个。每篇先给结论，再给数据和出处。 - [频繁切换模型时 GPU 利用率低，怎么办？](https://vuke.top/insights/gpu-utilization-model-switching) (2026-11-12): 每次切换模型，GPU 都在等权重从存储读进显存。实测显示，每小时切换 20 次时，缩短加载时间可把算力有效利用率从 46.7% 提高到 62.8%。 - [厂商给的推理性能数据，怎么核实真假？](https://vuke.top/insights/how-to-verify-vendor-benchmarks) (2026-11-12): 核实厂商推理性能数据的五个检查项：对照基线、测试平台与部署形态、重复测量偏差、第三方报告、复现材料。附常见的数字陷阱和提问清单。 - [推理存储加速项目怎么验收？四道门禁的做法](https://vuke.top/insights/inference-storage-acceptance-gates) (2026-11-12): 把推理存储加速的验收拆成四道按周推进的门禁：到货验收、单机基线、联测主门禁、稳定性验收。每道都有可测量的通过条件，不达标就停。 - [NFS 加载大模型太慢？昇腾 910B 平台实测对比](https://vuke.top/insights/model-loading-nfs-bottleneck) (2026-11-12): 在华为昇腾 910B × 8 的平台上，把模型存储从 NFS 换成 FX100 全闪阵列后，DeepSeek-32B 与 70B 的服务加载时间实测对比，以及这组数字的适用范围。 - [KV Cache 放本地 NVMe 还是外置 NVMe-oF 阵列？](https://vuke.top/insights/nvme-of-vs-local-nvme-for-kv-cache) (2026-11-12): 两种做法都能避免整段重算。480B 模型三档并发的实测里，外置 FX100 阵列相对本地 NVMe 单盘吞吐更高、首 token 延迟更低；本文同时说明对照条件的局限。 - [KV Cache 被逐出后重算还是读回？480B 模型实测](https://vuke.top/insights/recompute-vs-read-back-480b) (2026-11-12): 480B 模型、并发 16 的长上下文冷恢复负载下，整段重算与从 FX100 读回 KV Cache 的首 token 延迟和吞吐对比，附测试条件、两个对照基线和复现方式。 - [不加 GPU，怎么降低大模型推理的首 token 延迟？](https://vuke.top/insights/reduce-ttft-without-adding-gpus) (2026-11-12): 长上下文场景里，首 token 延迟高往往是因为被逐出显存的会话在整段重算。本文给出三个不加卡的办法，以及 480B 模型在三档并发下的实测降幅。 - [KV Cache 分层是什么？原理、收益与适用边界](https://vuke.top/insights/what-is-kv-cache-tiering) (2026-11-12): KV Cache 分层把溢出显存的 KV Cache 存到主机内存和外置全闪存储，会话回来时直接读回而不重算。本文说明三层结构、实测收益和不适用的场景。 - [KV Cache 分层在什么场景下没用？](https://vuke.top/insights/when-kv-cache-tiering-does-not-help) (2026-11-12): KV Cache 分层的收益来自缓存命中。短对话、低并发、上下文从不重复、瓶颈在输出阶段，这四类负载收益有限。本文说明原因和自查方法。 --- ## 频繁切换模型时 GPU 利用率低，怎么办？ > 每次切换模型，GPU 都在等权重从存储读进显存。实测显示，每小时切换 20 次时，缩短加载时间可把算力有效利用率从 46.7% 提高到 62.8%。 网页地址: https://vuke.top/insights/gpu-utilization-model-switching · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: 推理集群需要频繁切换模型，GPU 有效利用率很低，怎么提高？ **结论**: 先缩短模型加载时间。每次切换模型，GPU 都要等权重从存储读进显存，这段时间不产出任何 token。按实测加载时间建模，在每小时切换 20 次的档位下，接入 FX100 后算力有效利用率从 46.7% 提高到 62.8% [R1](https://vuke.top/evidence/R1)。 ### 利用率丢在哪里 多模型共用一批卡的平台，模型会按需换入换出。换入一个模型要把几十到几百 GB 的权重读进显存，这段时间里卡是通电的，却没有在服务请求。 切换越频繁，这部分等待在一小时里占的比例越高。监控里看到的「GPU 占用」可能不低，但真正用于推理的时间被加载吃掉了。 ### 实测数据 以下数据来自 8 × AMD MI308X 平台上的综合测试，测试模型为 Qwen2.5-32B 与 7B。 - 模型切换：每小时切换 20 次时，算力有效利用率 46.7% → 62.8% [R1](https://vuke.top/evidence/R1)。 - 并发加载：8 张卡同时冷读模型，整体墙钟时间快 16%，单个模型加载快 30% [R1](https://vuke.top/evidence/R1)。 - 训练 Checkpoint：每份 65.6 GB 的整模型快照，保存耗时 178 s → 94 s，持续写带宽 3.26 → 6.40 GB/s [R1](https://vuke.top/evidence/R1)。 ### 这个利用率数字是怎么来的 62.8% 不是在生产流量下直接测出来的利用率，而是用实测的加载时间建模得到的：给定每小时切换次数和每次加载耗时，算出一小时里有多少时间真正可用于推理 [R1](https://vuke.top/evidence/R1)。 这意味着你可以代入自己的数字重算。切换次数比 20 次少，收益会小；模型更大、加载更久，收益会大。 ### 怎么判断值不值得做 先数两个数：每张卡每小时切换多少次模型，每次切换从发起到能服务要多久。两者相乘就是每小时损失的时间。 如果你的模型是常驻的，几乎不切换，那么这项优化对你没有意义，应该把注意力放在 KV Cache 和首 token 延迟上。 ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） (AMD Instinct MI308X × 8 · ROCm 7.2) ### 外部参考资料 - [vLLM Documentation](https://docs.vllm.ai/) · vLLM Project. vLLM 的部署方式、前缀缓存与张量并行等配置的官方说明 - [AMD ROCm Documentation](https://rocm.docs.amd.com/) · AMD. ROCm 软件栈的组成与受支持硬件 --- ## 厂商给的推理性能数据，怎么核实真假？ > 核实厂商推理性能数据的五个检查项：对照基线、测试平台与部署形态、重复测量偏差、第三方报告、复现材料。附常见的数字陷阱和提问清单。 网页地址: https://vuke.top/insights/how-to-verify-vendor-benchmarks · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: 供应商提供的大模型推理性能数据，买方应该怎么核实？ **结论**: 看五件事：有没有写明对照基线，有没有写明测试平台和部署形态，有没有给出重复测量的偏差，有没有第三方机构出具的报告，以及能不能拿到复现材料自己重跑。缺任何一项，这个数字都只能当作参考，不能当作采购依据。 ### 五个检查项 下面每一项都用我们自己的报告举例，说明一份可以核实的数据应该长什么样。 - 对照基线：同一套设备，相对无外存整段重算是 8.6–20×，相对本地 NVMe 单盘是吞吐 +29–40% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。不写基线的「提升多少」没有意义。 - 平台与部署形态：AMD MI308X、华为昇腾 910B、沐曦 N260 上的结果分别成文，不合并 [R2](https://vuke.top/evidence/R2) [R9](https://vuke.top/evidence/R9) [R5](https://vuke.top/evidence/R5)。换一种卡、换一种并行方式，数字都会变。 - 重复测量偏差：同一档位做两轮独立测量，偏差不超过 5% [R3](https://vuke.top/evidence/R3)。只测一次的数字，无从判断是不是偶然。 - 第三方报告：两种部署形态的结论由第三方检测机构汇编出具了正式报告 [R4](https://vuke.top/evidence/R4)。 - 复现材料：补丁、负载客户端、编排脚本和原始数据打包交付，买方可以自己重跑 [R8](https://vuke.top/evidence/R8)。 ### 三个常见的数字陷阱 即使数字本身是真的，也有几种常见的呈现方式会误导判断。 - 混用分母：把相对「什么都不做」的大倍数，说成相对现有方案的提升。 - 只报最有利的一档：完整的做法是报出梯度。以 480B 模型为例，吞吐提升在并发 8 时是 +29%，并发 16 时是 +40%，并发 32 时是 +33% [R2](https://vuke.top/evidence/R2)。 - 把建模结果说成实测结果：由实测数据推算出来的数字应当明确标注为估算，并交出推算用的模型。 ### 可以直接拿去问厂商的问题 核实不需要很深的技术背景，把下面的问题发过去，看对方能不能逐条给出书面回答。 - 这个提升是跟什么方案比出来的？对照组的硬件配置是什么？ - 测试用的是什么模型、几张卡、哪种部署形态、什么负载？ - 同样的测试重复过几次？每次的读数差多少？ - 有没有第三方机构出具的报告？报告编号是什么？ - 测试脚本和原始数据能不能给我们，让我们在自己的集群上重跑？ ### 核实之后还要做什么 核实只能说明厂商的数字在厂商的条件下成立。你的模型、上下文长度和并发量不同，结果也会不同。所以最后一步始终是在自己的负载上测一遍，并把通过条件提前写下来。 ### 相关实测报告 - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R4](https://vuke.top/evidence/R4) · FX100 KV Cache 性能测试报告（480B · 多实例形态 · 编号 -006） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R5](https://vuke.top/evidence/R5) · FX100 KV Cache 性能测试报告（14B · 显存效益） (沐曦 N260 单卡) - [R8](https://vuke.top/evidence/R8) · FX100 KV Cache 测试代码导出包与原始测试数据 (AMD Instinct MI308X · ROCm 7.2) - [R9](https://vuke.top/evidence/R9) · FX100 与华为昇腾 910B 模型推理与训练性能测试（对照 NFS 基线） (华为 Atlas 910B × 8（Kunpeng-920）) ### 外部参考资料 - [MLPerf Inference: Datacenter](https://mlcommons.org/benchmarks/inference-datacenter/) · MLCommons. 推理性能公开基准的测试口径，讨论「可比、可复现」时的中立参照 --- ## 推理存储加速项目怎么验收？四道门禁的做法 > 把推理存储加速的验收拆成四道按周推进的门禁：到货验收、单机基线、联测主门禁、稳定性验收。每道都有可测量的通过条件，不达标就停。 网页地址: https://vuke.top/insights/inference-storage-acceptance-gates · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: 推理存储加速项目应该怎么验收，才不会为没有兑现的性能买单？ **结论**: 把验收拆成四道按周推进的门禁，每一道都有可以测量的通过条件，任何一道不达标就停在那里：G1 到货验收（第 2 周）、G2 单机基线（第 4 周）、G3 联测主门禁（第 7 周）、G4 稳定性与验收（第 10 周）。 ### 为什么要分门禁 性能类项目最常见的纠纷是：设备到了、钱付了，上线后的数字和方案书对不上，而双方对「怎么算达标」各有说法。 门禁化的做法是把这个争议提前。合作开始之前就写清楚每个阶段测什么、测到多少算过；过了才进下一阶段，没过就止损。买方承担的风险被限制在当前这一道门禁以内。 ### 四道门禁的通过条件 下面是我们在联测中使用的四道门禁，全程约 10 周。 - G1 到货验收（第 2 周）：物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - G2 单机基线（第 4 周）：复现单节点 8 卡推理基线，与 R1 报告口径的偏差在 ±10% 以内 [R1](https://vuke.top/evidence/R1)；单阵列本地压测达到实测锚点 83% 的线效。 - G3 联测主门禁（第 7 周）：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内 [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - G4 稳定性与验收（第 10 周）：72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 ### 门禁上的数字从哪里来 门禁阈值不是谈判出来的，而是从已有的实测报告里取的。G3 要求的吞吐区间就是 480B 模型两种部署形态下测得的 +29–40% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。 这样设计的好处是双向约束：厂商不能事后降低标准，买方也不会被要求接受一个从未被测出来过的指标。 ### 买方应该额外要求什么 除了门禁本身，有三样东西值得写进合作条款。 - 签字版报告：每道门禁的结果落在纸面上，而不是停留在演示里。 - 复现材料：补丁、负载客户端、编排脚本和原始数据，让你自己的团队能重跑 [R8](https://vuke.top/evidence/R8)。 - 可重算的测算模型：投入产出的测算用源码交付，你可以换成自己的参数重新计算。 ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R8](https://vuke.top/evidence/R8) · FX100 KV Cache 测试代码导出包与原始测试数据 (AMD Instinct MI308X · ROCm 7.2) ### 外部参考资料 - [MLPerf Inference: Datacenter](https://mlcommons.org/benchmarks/inference-datacenter/) · MLCommons. 推理性能公开基准的测试口径，讨论「可比、可复现」时的中立参照 --- ## NFS 加载大模型太慢？昇腾 910B 平台实测对比 > 在华为昇腾 910B × 8 的平台上，把模型存储从 NFS 换成 FX100 全闪阵列后，DeepSeek-32B 与 70B 的服务加载时间实测对比，以及这组数字的适用范围。 网页地址: https://vuke.top/insights/model-loading-nfs-bottleneck · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: 大模型放在 NFS 上加载很慢，换成全闪存储能快多少？ **结论**: 在华为昇腾 910B × 8 的平台上，把模型存储从 NFS 换成 FX100 后，DeepSeek-32B 的服务加载时间从 691 s 降到 112 s（6.2×），DeepSeek-70B 从 1399 s 降到 150 s（9.3×） [R9](https://vuke.top/evidence/R9)。 ### 为什么 NFS 会成为瓶颈 加载一个大模型，本质上是把几十到几百 GB 的权重文件顺序读进内存和显存。读得多快，取决于存储能给多少吞吐。 很多存量集群用 NFS 存放模型，优点是部署简单、所有节点都能访问。但它的吞吐受限于文件服务器和网络路径，多个节点同时加载时还会相互争抢。卡越多、模型越大，这个瓶颈越明显。 ### 昇腾 910B 平台的实测结果 测试平台是华为 Atlas 910B × 8（Kunpeng-920），对照基线是 NFS，被测设备是 FX100。 - DeepSeek-32B 服务加载：昇腾 910B 平台上 691 s → 112 s，6.2× [R9](https://vuke.top/evidence/R9)。 - DeepSeek-70B 服务加载：昇腾 910B 平台上 1399 s → 150 s，9.3× [R9](https://vuke.top/evidence/R9)。 ### 和 AMD MI308X 上的数据是什么关系 没有换算关系。上面的数字出自昇腾 910B 平台、对照的是 NFS；MI308X 平台上的加载测试对照的是另一个基线，结论是 8 张卡同时冷读模型时整体墙钟时间快 16%、单个模型加载快 30% [R1](https://vuke.top/evidence/R1)。 两组数字的平台和对照基线都不同，不能相加，也不能用一组去推算另一组。能确定的只有方向：模型加载是吃存储吞吐的操作，换更快的存储就会更快。 ### 加载快了有什么用 最直接的是模型切换。多模型共用一批卡时，每次切换都要等加载；MI308X 平台按实测加载时间建模的结果是，每小时切换 20 次时算力有效利用率从 46.7% 提高到 62.8% [R1](https://vuke.top/evidence/R1)。 其次是恢复时间。服务重启、节点故障切换、弹性扩容，都要先把模型加载完才能接流量。加载从十几、二十几分钟缩到两三分钟，对可用性的影响是实在的。 ### 相关问题 #### 这组数字适用于其他国产算力卡吗？ 不能直接套用。R9 只在昇腾 910B 平台上测过 [R9](https://vuke.top/evidence/R9)。其他平台需要单独实测，我们也会单独出报告，不同平台的数字不混用。 ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R9](https://vuke.top/evidence/R9) · FX100 与华为昇腾 910B 模型推理与训练性能测试（对照 NFS 基线） (华为 Atlas 910B × 8（Kunpeng-920）) ### 外部参考资料 - [NVM Express Specifications](https://nvmexpress.org/specifications/) · NVM Express, Inc.. NVMe 与 NVMe over Fabrics 的官方规范 - [RFC 5040: A Remote Direct Memory Access Protocol Specification](https://datatracker.ietf.org/doc/html/rfc5040) · IETF. RDMA 协议的规范定义 --- ## KV Cache 放本地 NVMe 还是外置 NVMe-oF 阵列？ > 两种做法都能避免整段重算。480B 模型三档并发的实测里，外置 FX100 阵列相对本地 NVMe 单盘吞吐更高、首 token 延迟更低；本文同时说明对照条件的局限。 网页地址: https://vuke.top/insights/nvme-of-vs-local-nvme-for-kv-cache · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: KV Cache 应该存在服务器本地的 NVMe 盘上，还是存在外置的 NVMe-oF 全闪阵列上？ **结论**: 两者都能避免整段重算，但在高并发回读下外置阵列更快：480B 模型、TP=8 的实测里，FX100 相对本地 NVMe 单盘吞吐高 29–40%、TTFT p50 低 26–32% [R2](https://vuke.top/evidence/R2)。外置阵列还能让多个推理实例共享同一份缓存 [R3](https://vuke.top/evidence/R3)。 ### 对照是怎么设的 本地方案是一块 NVMe 盘（PCIe Gen4，2 TB）。外置方案是 FX100 全闪 NVMe-oF 阵列：4 盘 RAID0（14 TB，XFS），通过 RoCEv2 走单口 100 GbE [R2](https://vuke.top/evidence/R2)。 需要说明的是，这不是同等盘数的对比，对照组是单盘。如果你的服务器本地已经配了多盘阵列，差距会和这里不同，需要用自己的配置实测。 ### 三档并发的逐档读数 模型是 Qwen3-Coder-480B-FP8，部署在 8 × AMD MI308X 上，负载为长上下文冷恢复。箭头左边是本地 NVMe 单盘，右边是 FX100。 - 并发 8：TTFT p50 10.17 s → 7.53 s，吞吐 43.9 → 56.6 tok/s（+29%） [R2](https://vuke.top/evidence/R2)。 - 并发 16：TTFT p50 17.31 s → 11.85 s，吞吐 53.6 → 74.9 tok/s（+40%） [R2](https://vuke.top/evidence/R2)。 - 并发 32：TTFT p50 35.73 s → 26.35 s，吞吐 53.9 → 71.6 tok/s（+33%） [R2](https://vuke.top/evidence/R2)。 ### 为什么走网络反而更快 直觉上本地盘离 GPU 更近。但决定首 token 延迟的不是协议多出来的那一点时延，而是并发回读时能不能把数据足够快地送回显存。多盘全闪池加上 RDMA 网络，能提供的并发读带宽高于单块本地盘。 软件也有份：LMCache 并行读补丁把单卡冷读带宽从 0.98 GB/s 提高到 5.23 GB/s [R1](https://vuke.top/evidence/R1)。没有这个补丁，再快的盘也会被串行读路径卡住。 ### 外置阵列多出来的两件事 一是共享。本地盘上的缓存只有这台服务器能用；外置池里的缓存，被调度到任何一个实例的会话都能读到。fs:// 共享池的跨实例热共享已经验证通过 [R3](https://vuke.top/evidence/R3)。 二是配比。生产口径是每台 FX100 服务 8 个推理节点，依据是 100 GbE 支撑 8 节点 KV 回读的实测锚点 [R1](https://vuke.top/evidence/R1) [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。 ### 什么时候本地盘就够了 单台服务器、并发不高、会话不需要跨实例迁移的场景，本地 NVMe 盘已经能拿到「不重算」这个最大的收益。外置阵列的优势出现在并发回读压力大、或者多个实例需要共享缓存的时候。 ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） (AMD Instinct MI308X × 8 · ROCm 7.2) ### 外部参考资料 - [NVM Express Specifications](https://nvmexpress.org/specifications/) · NVM Express, Inc.. NVMe 与 NVMe over Fabrics 的官方规范 - [RFC 5040: A Remote Direct Memory Access Protocol Specification](https://datatracker.ietf.org/doc/html/rfc5040) · IETF. RDMA 协议的规范定义 - [LMCache (GitHub repository)](https://github.com/LMCache/LMCache) · LMCache Project. LMCache 的源码、架构与存储后端说明 --- ## KV Cache 被逐出后重算还是读回？480B 模型实测 > 480B 模型、并发 16 的长上下文冷恢复负载下，整段重算与从 FX100 读回 KV Cache 的首 token 延迟和吞吐对比，附测试条件、两个对照基线和复现方式。 网页地址: https://vuke.top/insights/recompute-vs-read-back-480b · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: KV Cache 被逐出显存后，是整段重算快，还是从外置存储读回快？ **结论**: 读回快得多。Qwen3-Coder-480B-FP8 在并发 16 的长上下文冷恢复负载下，无外存整段重算的 TTFT p50 是 149.48 s、吞吐 4.1 tok/s；把 KV Cache 存在 FX100 上再读回，TTFT p50 是 11.85 s、吞吐 74.9 tok/s [R2](https://vuke.top/evidence/R2)。 ### 测试是怎么做的 模型是 Qwen3-Coder-480B-FP8，以八卡单实例（TP=8）的生产形态部署在 8 × AMD MI308X 上。负载是长上下文冷恢复：会话的 KV Cache 已经不在显存里，请求到来时要么重算，要么读回。 同一负载下做三方对照：FX100 全闪阵列、本地 NVMe 单盘、无外存整段重算。FX100 与本地盘按并发 8、16、32 三档测量，整段重算只测了并发 16 一档 [R2](https://vuke.top/evidence/R2)。 ### 并发 16 的三组读数 三种做法在同一并发下的 TTFT p50 与吞吐如下。 - 无外存、整段重算：TTFT p50 149.48 s，吞吐 4.1 tok/s [R2](https://vuke.top/evidence/R2)。 - 本地 NVMe 单盘：TTFT p50 17.31 s，吞吐 53.6 tok/s [R2](https://vuke.top/evidence/R2)。 - FX100 全闪阵列：TTFT p50 11.85 s，吞吐 74.9 tok/s [R2](https://vuke.top/evidence/R2)。 ### 两个基线不能混着说 「快了多少」取决于跟谁比。这组测试里有两个分母。 对比无外存整段重算，加速是 8.6–20× [R2](https://vuke.top/evidence/R2)。这个数字回答的是「要不要把 KV Cache 存下来」。 对比本地 NVMe 单盘，吞吐提升 29–40%，TTFT p50 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。这个数字回答的是「存在哪里更好」。把两组数字合成一句话，就会让人误以为外置阵列比本地盘快一个量级，这不是事实。 ### 这些数字能不能复现 同一档位做两轮独立测量，偏差不超过 5% [R3](https://vuke.top/evidence/R3)。两种部署形态的结论由第三方检测机构汇编出具了正式报告 [R4](https://vuke.top/evidence/R4)。 LMCache 并行读补丁、负载客户端、编排脚本和原始数据打包为 R8，可以在自己的集群上重跑 [R8](https://vuke.top/evidence/R8)。你的模型、上下文长度和并发量不同，读数也会不同；这份数据说明的是量级和方向。 ### 相关实测报告 - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R4](https://vuke.top/evidence/R4) · FX100 KV Cache 性能测试报告（480B · 多实例形态 · 编号 -006） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R8](https://vuke.top/evidence/R8) · FX100 KV Cache 测试代码导出包与原始测试数据 (AMD Instinct MI308X · ROCm 7.2) ### 外部参考资料 - [LMCache (GitHub repository)](https://github.com/LMCache/LMCache) · LMCache Project. LMCache 的源码、架构与存储后端说明 - [vLLM Documentation](https://docs.vllm.ai/) · vLLM Project. vLLM 的部署方式、前缀缓存与张量并行等配置的官方说明 --- ## 不加 GPU，怎么降低大模型推理的首 token 延迟？ > 长上下文场景里，首 token 延迟高往往是因为被逐出显存的会话在整段重算。本文给出三个不加卡的办法，以及 480B 模型在三档并发下的实测降幅。 网页地址: https://vuke.top/insights/reduce-ttft-without-adding-gpus · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: 不增加 GPU，怎么降低大模型推理的首 token 延迟（TTFT）？ **结论**: 长上下文场景里，首 token 延迟高的主要原因往往是被逐出显存的会话在整段重算，而不是算力不够。给推理集群加一层外置全闪存储保存 KV Cache，会话回来时直接读回：480B 模型实测，相对本地 NVMe 单盘，TTFT p50 降低 26–32% [R2](https://vuke.top/evidence/R2)。 ### 先确认延迟花在哪里 首 token 延迟主要由预填充阶段决定：模型要先处理完全部输入，才能输出第一个 token。输入越长，预填充越久。 如果一个会话的 KV Cache 还在显存里，新一轮请求只需要处理新增的那部分输入。如果它已经被逐出，整段历史上下文都要重新算。在 480B 模型、并发 16 的实测里，这样一次整段重算的 TTFT p50 是 149.5 s [R2](https://vuke.top/evidence/R2)。 所以第一步是看监控：延迟高的请求，是不是集中在隔了一段时间才回来的长会话上。 ### 三个不加卡的办法 这三件事都是在存储和软件上做文章，不需要新增算力卡。 - 把被逐出的 KV Cache 存下来：用 vLLM + LMCache 把它写到外置全闪存储，命中时读回，跳过这部分预填充。 - 让读回足够快：LMCache 并行读补丁把单卡、并发 16 冷读盘的 TTFT 从 37.97 s 降到 9.30 s，读带宽从 0.98 GB/s 提高到 5.23 GB/s [R1](https://vuke.top/evidence/R1)。 - 让多个实例共用一份缓存：fs:// 共享池的跨实例热共享已经验证通过，会话被调度到另一个实例时不必重算 [R3](https://vuke.top/evidence/R3)。 ### 实测能降多少 下面是 Qwen3-Coder-480B-FP8、TP=8、8 × AMD MI308X 的读数，对照基线是本地 NVMe 单盘。 - 并发 8：TTFT p50 从 10.17 s 降到 7.53 s [R2](https://vuke.top/evidence/R2)。 - 并发 16：TTFT p50 从 17.31 s 降到 11.85 s [R2](https://vuke.top/evidence/R2)。 - 并发 32：TTFT p50 从 35.73 s 降到 26.35 s [R2](https://vuke.top/evidence/R2)。 ### 什么情况下还是得加卡 外置缓存省掉的是重复的预填充。如果请求的上下文从来没有出现过，没有缓存可读，这一层帮不上忙。 如果瓶颈在输出阶段，也就是每个 token 的生成速度不够，那是算力问题，需要的是更多或更快的卡。先分清延迟属于哪一种，再决定钱花在哪里。 ### 相关实测报告 - [R1](https://vuke.top/evidence/R1) · FX100 大模型推理与训练综合性能测试报告（AMD MI308X × 8） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） (AMD Instinct MI308X × 8 · ROCm 7.2) ### 外部参考资料 - [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/abs/2309.06180) · arXiv (SOSP '23). vLLM 的 PagedAttention 显存管理与 KV Cache 分页的设计动机 - [LMCache (GitHub repository)](https://github.com/LMCache/LMCache) · LMCache Project. LMCache 的源码、架构与存储后端说明 --- ## KV Cache 分层是什么？原理、收益与适用边界 > KV Cache 分层把溢出显存的 KV Cache 存到主机内存和外置全闪存储，会话回来时直接读回而不重算。本文说明三层结构、实测收益和不适用的场景。 网页地址: https://vuke.top/insights/what-is-kv-cache-tiering · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: KV Cache 分层是什么？ **结论**: KV Cache 分层是把大模型推理时溢出显存的 KV Cache 依次存到主机内存和外置全闪存储，会话再次到来时直接读回，而不是让 GPU 把整段上下文重新计算。在 480B 模型的实测中，相对无外存整段重算，首 token 延迟 p50 从 149.5 s 降到 11.85 s [R2](https://vuke.top/evidence/R2)。 ### 为什么需要分层 大模型每处理一个 token，都会在各注意力层留下一份 Key / Value 张量，也就是 KV Cache。有了它，生成下一个 token 时不必重新计算前面的上下文。上下文越长，这份缓存越大。 显存要同时放模型权重和所有活跃会话的 KV Cache。会话一多，较早的缓存就被逐出。被逐出的会话再发来请求时，模型只能把整段上下文重新预填充一遍，首 token 延迟随之飙升。 分层的思路很直接：被逐出的 KV Cache 不丢弃，而是换个地方存着。 ### 三层各放什么 缓存按访问热度放在三种介质上。前两层由推理框架管理，第三层需要单独的存储设备。 - 显存：当前活跃的会话，由 vLLM 管理。 - 主机内存：近期用过的会话，由 LMCache 管理。 - 外置全闪存储：全部历史会话，并且可以让多个推理实例共享同一份缓存。 ### 实测收益有多大 测试对象是 Qwen3-Coder-480B-FP8，以 TP=8 的生产形态部署在 8 × AMD MI308X 上，负载为长上下文冷恢复。有两个对照基线，要分开看。 对比无外存、整段重算：加速 8.6–20× [R2](https://vuke.top/evidence/R2)。 对比本地 NVMe 单盘：吞吐提升 29–40%，TTFT p50 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。也就是说，同样是把 KV Cache 存下来再读，放在外置全闪阵列上比放在服务器本地的一块盘上更快。 ### 什么时候不适用 收益来自缓存命中。短对话、低并发的场景里，会话很少被逐出，也很少回来，这一层就没有多少内容可读。长上下文、多轮对话、Agent 和代码助手这类会话恢复频繁的负载，收益才明显。 所以在决定采购之前，应该先用自己的会话长度分布和并发量测一遍。 ### 相关问题 #### 做 KV Cache 分层需要改造推理引擎吗？ 不需要重写。实测使用的是开源的 vLLM + LMCache 组合，外加一个 LMCache 并行读补丁；补丁、编排脚本和原始数据都打包在 R8 里，可以在自己的集群上重跑 [R8](https://vuke.top/evidence/R8)。 #### KV Cache 分层和前缀缓存是什么关系？ 前缀缓存决定哪些 KV Cache 可以被后续请求复用，分层决定这些 KV Cache 存在哪里。两者配合使用：前缀命中之后，分层保证被命中的缓存即使已经离开显存，也能从内存或外置存储读回。 ### 相关实测报告 - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R3](https://vuke.top/evidence/R3) · FX100 KV Cache 性能测试汇总报告（480B · TP4×2 · 全指标） (AMD Instinct MI308X × 8 · ROCm 7.2) - [R8](https://vuke.top/evidence/R8) · FX100 KV Cache 测试代码导出包与原始测试数据 (AMD Instinct MI308X · ROCm 7.2) ### 外部参考资料 - [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/abs/2309.06180) · arXiv (SOSP '23). vLLM 的 PagedAttention 显存管理与 KV Cache 分页的设计动机 - [LMCache (GitHub repository)](https://github.com/LMCache/LMCache) · LMCache Project. LMCache 的源码、架构与存储后端说明 - [vLLM Documentation](https://docs.vllm.ai/) · vLLM Project. vLLM 的部署方式、前缀缓存与张量并行等配置的官方说明 --- ## KV Cache 分层在什么场景下没用？ > KV Cache 分层的收益来自缓存命中。短对话、低并发、上下文从不重复、瓶颈在输出阶段，这四类负载收益有限。本文说明原因和自查方法。 网页地址: https://vuke.top/insights/when-kv-cache-tiering-does-not-help · 更新于 2026 年 11 月 12 日 发布于: 2026-11-12 **问题**: KV Cache 分层存储加速在哪些场景下没有效果？ **结论**: 缓存很少被命中的时候。短对话、低并发、每次请求的上下文都不重复的负载里，会话很少被逐出显存，逐出后也很少再回来，外置的 KV Cache 层没有多少内容可以读回，收益有限。瓶颈在输出阶段的负载同样受益不大。 ### 收益是从哪里来的 KV Cache 分层只做一件事：会话的 KV Cache 被逐出显存之后，下次请求到来时把它读回来，省掉重新预填充。每命中一次，省一次预填充；没有命中，就什么也没省。 我们报告里的大幅收益，是在长上下文冷恢复负载下测得的：480B 模型、并发 16 时，整段重算的 TTFT p50 是 149.5 s [R2](https://vuke.top/evidence/R2)。这类负载恰好是命中价值最高的情形，不代表所有负载。 ### 四类收益有限的负载 如果你的业务主要是下面这几种，在采购之前要格外谨慎。 - 短对话：上下文很短，预填充本身只要很少时间，读回省不下多少。 - 低并发：显存放得下所有活跃会话，几乎没有逐出，也就没有需要读回的缓存。 - 上下文从不重复：例如批量处理各不相同的文档，每个请求都是新的输入，没有可以复用的前缀。 - 瓶颈在输出阶段：输出很长、首 token 延迟只占总耗时一小部分的任务，决定体验的是每个 token 的生成速度，那取决于算力。 ### 怎么判断自己属于哪一种 不需要猜，从线上日志里可以数出来。 - 会话的上下文长度分布：长上下文占多大比例。 - 会话的返回间隔：用户隔多久发下一轮，这段时间里它的缓存还在不在显存。 - 显存里 KV Cache 的逐出频率：逐出越频繁，潜在的命中越多。 - 首 token 延迟在总耗时里的占比：占比越高，优化它越有价值。 ### 我们的建议 如果上面几项指标显示你的负载以长会话、多轮、高并发为主，这一层很可能值得做；如果不是，把预算花在别处更合适。 拿不准的时候，先用自己的负载做一次小规模联测，并把通过条件提前写下来。测出来没用，就在那里停下。这比任何一方的推测都可靠。 ### 相关问题 #### Agent 和代码助手这类负载属于哪一种？ 通常属于收益明显的一类。它们的上下文长、轮次多，会话被逐出后再回来的情况很常见，正是缓存命中价值高的场景。具体能提升多少，仍然要用自己的会话分布实测。 ### 相关实测报告 - [R2](https://vuke.top/evidence/R2) · FX100 KV Cache 性能测试报告（480B · TP8 长上下文） (AMD Instinct MI308X × 8 · ROCm 7.2) ### 外部参考资料 - [Efficient Memory Management for Large Language Model Serving with PagedAttention](https://arxiv.org/abs/2309.06180) · arXiv (SOSP '23). vLLM 的 PagedAttention 显存管理与 KV Cache 分页的设计动机 - [SGLang: Efficient Execution of Structured Language Model Programs](https://arxiv.org/abs/2312.07104) · arXiv (NeurIPS '24). 多轮对话与共享前缀场景下，前缀复用为什么有效 --- ## 常见问题：FX 存储加速、实测数据、价格与合作方式 > 关于芯元一 FX 系列的常见问题：KV Cache 分层能提升多少、数据怎么验证、FX100 多少钱、支持哪些算力卡、怎么开始联测。 网页地址: https://vuke.top/faq · 更新于 2026 年 11 月 12 日 回答里的数字都标了报告编号，点击编号可以看到那份报告测了什么。 ### 芯元一是做什么的？ 芯元一（天津）半导体设备有限公司做大模型推理的存储加速。产品是 FX 系列全闪 NVMe-oF 阵列，用来承接溢出显存的 KV Cache，让被挤出的会话可以直接读回而不是重新计算。围绕这款产品，我们还提供国产与非 N 卡算力适配、算力中心效能优化、算力中心建设和推理栈软件开发服务。 ### FX 系列存储加速平台是什么？ FX 系列是在广东绿算 GP 系列硬件上开发的软硬件一体存储加速系统，配套 vLLM + LMCache 的 KV Cache 分层软件栈，其中包含芯元一自研的并行读补丁。FX100、FX200、FX300 已量产在售，FX400 计划 2026 年底量产。FX100 单接口 100 Gb、1,600 万 IOPS；FX300 为 PCIe 5.0 平台，单接口 400 Gb、6,000 万 IOPS（均为厂商规格）。 ### KV Cache 分层存储加速能把推理性能提升多少？ 在 Qwen3-Coder-480B-FP8、8 × AMD MI308X、TP=8 的生产部署形态下，长上下文冷恢复负载的实测结果是：相对本地 NVMe 单盘，推理吞吐提升 29–40%，TTFT p50 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)；相对无外存整段重算，加速 8.6–20× [R2](https://vuke.top/evidence/R2)。这是应用层的吞吐和首 token 延迟，不是存储设备本身的微秒级时延。 ### 哪些场景收益大，哪些场景收益有限？ 收益来自缓存命中。长上下文、多轮对话、高并发的会话恢复（Agent、代码助手、客服）命中率高，收益最大。短对话、低并发的场景命中率低，收益有限。所以我们建议先联测、后采购：用你自己的会话长度分布和并发量测一遍，再决定买不买。 ### 这些数字怎么验证？能复现吗？ 每个关键数字都标了报告编号（R1–R9），报告可以向我们申请查阅。其中 R4 是第三方检测机构出具的正式报告。R8 是测试代码导出包和原始数据，包含 LMCache 并行读补丁、负载客户端、编排脚本和探针取证脚本，第三方可以在自己的集群上重跑。同一档位两轮独立测量的偏差不超过 5% [R3](https://vuke.top/evidence/R3)。 ### 接入 FX 需要改造推理引擎吗？ 不需要重写推理引擎。接入点是开源的 vLLM + LMCache 组合：LMCache 负责把显存放不下的 KV Cache 下沉到主机内存和外置存储，FX 阵列作为外置的那一层。我们在 ROCm 平台上做了源码级适配，并行读补丁随 R8 一并交付 [R1](https://vuke.top/evidence/R1) [R8](https://vuke.top/evidence/R8)。 ### FX100 满配整机多少钱？ FX100 满配整机的参考价约为 ¥371,200：平台 ¥160,000，加 24 块 7.68 TB 企业级 NVMe SSD（参考价每块 ¥8,800），裸容量 184.3 TB，约合 ¥2,014/TB。SSD 价格随行就市，正式价格以采购合同为准。FX200、FX300 按配置询价，FX400 的量产定价尚未发布。 ### 已有 GPU 集群不想扩卡，存储加速有用吗？ 有用，这正是「先提效、再扩卡」的思路。在华为昇腾 910B 平台对照 NFS 的实测中，DeepSeek-32B 的服务加载时间从 691 s 降到 112 s（6.2×），DeepSeek-70B 从 1399 s 降到 150 s（9.3×） [R9](https://vuke.top/evidence/R9)。在 MI308X 平台上，训练 Checkpoint 保存快 1.9×，每小时切换 20 次模型时算力有效利用率从 46.7% 提高到 62.8% [R1](https://vuke.top/evidence/R1)。 ### 支持哪些国产或非 NVIDIA 算力卡？ 已有实测报告的平台是 AMD Instinct MI308X（ROCm 7.2，R1–R4）、华为昇腾 910B [R9](https://vuke.top/evidence/R9) 和沐曦 N260 [R5](https://vuke.top/evidence/R5)。三个平台分别出报告、分别标注，数字不混用。多模态方面，ComfyUI + LTX-Video 2.3 的 7 个模型已在 MI308X 上全部实跑通过 [R6](https://vuke.top/evidence/R6) [R7](https://vuke.top/evidence/R7)。 ### 一台 FX100 可以服务多少个推理节点？ 生产配比口径是每台 FX100 服务 8 个推理节点，依据是 100 GbE 能支撑 8 节点 KV 回读这一实测锚点。按这个配比，联测口径下存储投入约占 GPU 预算的一成以内。你的实际配比取决于会话长度和并发量，联测的 G3 门禁会验证「8 节点共享单台阵列」这一条。 ### 怎么开始合作？ 从一次约 10 周的门禁化联测开始，共四道门禁：G1 到货验收、G2 单机基线、G3 联测主门禁（TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内 [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)）、G4 72 小时稳定性验收。任何一道不达标就止损，全部通过再谈规模合作。完整测算模型在签署 NDA 后以 Python 源码提供。通过联系页面的电话或邮箱即可预约排期。 ### 怎么拿到测试报告原件？ 通过联系页面的邮箱或电话说明你需要的报告编号即可申请。本站每份报告的详情页都公开了测试范围、平台和关键结论，方便你先判断哪一份与你的场景相关。R8（代码导出包与原始数据）和 R9（昇腾 910B 平台报告）同样按申请提供。 ### AISSD5000、WS5000 和 FX100 是什么关系？ 它们是同一款产品在不同时期的名称。早期测试报告的文件名里写作 AISSD5000，更早也叫过 WS5000 / GP5000，报告原文有时署「铭信」。本站统一使用 FX 命名（FX100 / FX200 / FX300 / FX400），报告条目保留原始标题以便查证。 --- ## 术语表：KV Cache、TTFT、LMCache、NVMe-oF 等推理存储术语 > 大模型推理与存储加速的常用术语解释：KV Cache、KV Cache 分层、TTFT、TPOT、Prefill、冷恢复、前缀缓存、LMCache、vLLM、NVMe-oF、RoCEv2、HBM 等。 网页地址: https://vuke.top/glossary · 更新于 2026 年 11 月 12 日 读懂推理存储需要的十几个词。每个词条先给定义，再说明它在实测里对应什么。 ### [KV Cache](https://vuke.top/glossary/kv-cache) KV Cache 是大模型推理时保存下来的中间结果：每个已处理的 token 在各注意力层算出的 Key 和 Value 张量。有了它，模型生成下一个 token 时不必把前面的上下文重新算一遍。上下文越长，KV Cache 占用的显存越多。 ### [KV Cache 分层](https://vuke.top/glossary/kv-cache-tiering) KV Cache 分层是把 KV Cache 按访问热度放在不同介质上：显存放当前活跃的会话，主机内存放近期会话，外置全闪存储放全部历史会话并供多个实例共享。前两层由推理框架管理，第三层需要单独的存储设备。 ### [TTFT（首 token 延迟）](https://vuke.top/glossary/ttft) TTFT（Time To First Token）是从请求发出到模型返回第一个 token 的时间，决定了用户感受到的「响应快不快」。它主要由预填充（prefill）阶段决定：模型要先处理完全部输入，才能开始输出。 ### [TPOT（单 token 输出时间）](https://vuke.top/glossary/tpot) TPOT（Time Per Output Token）是模型开始输出之后，平均每生成一个 token 所用的时间。TTFT 衡量「多久开始说话」，TPOT 衡量「说得有多快」，两者合起来描述一次请求的完整时延。 ### [Prefill（预填充）](https://vuke.top/glossary/prefill) Prefill（预填充）是推理的第一个阶段：模型一次性处理全部输入 token，并为它们生成 KV Cache。输入越长，prefill 越耗时，这也是长上下文请求首 token 延迟高的直接原因。之后逐个生成输出 token 的阶段称为 decode。 ### [冷恢复](https://vuke.top/glossary/cold-recovery) 冷恢复指一个会话的 KV Cache 已经不在显存里，请求再次到来时必须先把上下文状态恢复出来。恢复有两条路：从外置存储读回 KV Cache，或者让 GPU 把整段上下文重新计算。大量会话同时恢复的情形常被称为「会话恢复风暴」。 ### [前缀缓存（Prefix Caching）](https://vuke.top/glossary/prefix-caching) 前缀缓存是推理引擎复用相同输入前缀的 KV Cache 的机制：两个请求开头相同（例如同一段系统提示词或同一份文档），第二个请求可以跳过这部分的计算。vLLM 内置的前缀缓存只在显存内生效。 ### [LMCache](https://vuke.top/glossary/lmcache) LMCache 是一个对接 vLLM 的开源 KV Cache 库，负责把显存放不下的 KV Cache 下沉到主机内存和外置存储，并在命中时读回。它是 KV Cache 分层的主流开源实现。 ### [vLLM](https://vuke.top/glossary/vllm) vLLM 是一个开源的大模型推理与服务引擎，以 PagedAttention 的显存管理方式和高吞吐著称，是生产环境里部署开源大模型的常见选择。 ### [NVMe-oF](https://vuke.top/glossary/nvme-of) NVMe-oF（NVMe over Fabrics）把 NVMe 协议从服务器内部的 PCIe 总线延伸到网络上，让多台服务器通过以太网、InfiniBand 等网络共享远端的 NVMe 存储，同时保留接近本地盘的性能。 ### [RoCEv2](https://vuke.top/glossary/rocev2) RoCEv2（RDMA over Converged Ethernet v2）是在以太网上实现 RDMA 的协议，报文封装在 UDP/IP 里，因此可以跨三层网络路由。RDMA 让数据绕过操作系统内核直接在两台机器的内存之间传输，时延低、CPU 占用少。 ### [HBM（高带宽内存）](https://vuke.top/glossary/hbm) HBM（High Bandwidth Memory）是 AI 加速卡上使用的堆叠式高带宽内存，也就是通常所说的显存。它速度极快但容量有限、价格昂贵，模型权重和 KV Cache 都要争用这部分空间。 ### [TP（张量并行）](https://vuke.top/glossary/tensor-parallelism) 张量并行（Tensor Parallelism，TP）把一个模型的每一层拆到多张卡上共同计算。TP=8 表示一个模型实例横跨 8 张卡，是单卡装不下的超大模型的常见部署方式；TP4×2 则是把 8 张卡分成两个各占 4 卡的实例。 ### [MoE（混合专家模型）](https://vuke.top/glossary/moe) MoE（Mixture of Experts，混合专家）是一种模型结构：每一层包含多个「专家」子网络，每个 token 只激活其中少数几个。它让模型可以做得很大而单次计算量不随之等比增长，但权重体积庞大。 ### [ROCm](https://vuke.top/glossary/rocm) ROCm 是 AMD 为其 GPU 提供的开源计算软件栈，包含驱动、编译器、数学库和深度学习框架支持，在 AMD Instinct 加速卡上的角色相当于 NVIDIA 平台上的 CUDA。 ### [Checkpoint（训练检查点）](https://vuke.top/glossary/checkpoint) Checkpoint 是训练过程中定期保存到存储上的模型状态快照，用于故障恢复和结果留存。保存期间训练通常要暂停，写得越慢，GPU 空转的时间越长。 --- ## 什么是 KV Cache？ > KV Cache 是大模型推理时保存下来的中间结果：每个已处理的 token 在各注意力层算出的 Key 和 Value 张量。有了它，模型生成下一个 token 时不必把前面的上下文重新算一遍。上下文越长，KV Cache 占用的显存越多。 网页地址: https://vuke.top/glossary/kv-cache · 更新于 2026 年 11 月 12 日 KV Cache 是大模型推理时保存下来的中间结果：每个已处理的 token 在各注意力层算出的 Key 和 Value 张量。有了它，模型生成下一个 token 时不必把前面的上下文重新算一遍。上下文越长，KV Cache 占用的显存越多。 ### 在实测里 显存放不下时，KV Cache 会被逐出。被逐出的会话再次到来，要么整段重算，要么从外置存储读回。在 480B 模型的实测中，读回比重算快 8.6–20× [R2](https://vuke.top/evidence/R2)。 出处: [R2](https://vuke.top/evidence/R2) --- ## 什么是 KV Cache 分层？ > KV Cache 分层是把 KV Cache 按访问热度放在不同介质上：显存放当前活跃的会话，主机内存放近期会话，外置全闪存储放全部历史会话并供多个实例共享。前两层由推理框架管理，第三层需要单独的存储设备。 网页地址: https://vuke.top/glossary/kv-cache-tiering · 更新于 2026 年 11 月 12 日 KV Cache 分层是把 KV Cache 按访问热度放在不同介质上：显存放当前活跃的会话，主机内存放近期会话，外置全闪存储放全部历史会话并供多个实例共享。前两层由推理框架管理，第三层需要单独的存储设备。 ### 在实测里 FX 系列承担的是第三层。在 480B 模型生产部署形态下，加上这一层后吞吐提升 29–40%、TTFT 降低 26–32% [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。 出处: [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) --- ## 什么是 TTFT（首 token 延迟）？ > TTFT（Time To First Token）是从请求发出到模型返回第一个 token 的时间，决定了用户感受到的「响应快不快」。它主要由预填充（prefill）阶段决定：模型要先处理完全部输入，才能开始输出。 网页地址: https://vuke.top/glossary/ttft · 更新于 2026 年 11 月 12 日 TTFT（Time To First Token）是从请求发出到模型返回第一个 token 的时间，决定了用户感受到的「响应快不快」。它主要由预填充（prefill）阶段决定：模型要先处理完全部输入，才能开始输出。 ### 在实测里 长上下文会话的 KV Cache 被逐出后，TTFT 会急剧变长。实测中，整段重算的 TTFT p50 为 149.5 s，从 FX100 读回则为 11.85 s（480B 模型，并发 16） [R2](https://vuke.top/evidence/R2)。 出处: [R2](https://vuke.top/evidence/R2) --- ## 什么是 TPOT（单 token 输出时间）？ > TPOT（Time Per Output Token）是模型开始输出之后，平均每生成一个 token 所用的时间。TTFT 衡量「多久开始说话」，TPOT 衡量「说得有多快」，两者合起来描述一次请求的完整时延。 网页地址: https://vuke.top/glossary/tpot · 更新于 2026 年 11 月 12 日 TPOT（Time Per Output Token）是模型开始输出之后，平均每生成一个 token 所用的时间。TTFT 衡量「多久开始说话」，TPOT 衡量「说得有多快」，两者合起来描述一次请求的完整时延。 ### 在实测里 R3 报告在九档负载下同时记录了 TTFT 的 p50 / p90 / p99、TPOT、吞吐和盘带宽 [R3](https://vuke.top/evidence/R3)。 出处: [R3](https://vuke.top/evidence/R3) --- ## 什么是 Prefill（预填充）？ > Prefill（预填充）是推理的第一个阶段：模型一次性处理全部输入 token，并为它们生成 KV Cache。输入越长，prefill 越耗时，这也是长上下文请求首 token 延迟高的直接原因。之后逐个生成输出 token 的阶段称为 decode。 网页地址: https://vuke.top/glossary/prefill · 更新于 2026 年 11 月 12 日 Prefill（预填充）是推理的第一个阶段：模型一次性处理全部输入 token，并为它们生成 KV Cache。输入越长，prefill 越耗时，这也是长上下文请求首 token 延迟高的直接原因。之后逐个生成输出 token 的阶段称为 decode。 ### 在实测里 命中一次外置 KV Cache，就省掉一次完整的 prefill。这是 KV Cache 分层能降低 TTFT 的根本原因。 --- ## 什么是 冷恢复？ > 冷恢复指一个会话的 KV Cache 已经不在显存里，请求再次到来时必须先把上下文状态恢复出来。恢复有两条路：从外置存储读回 KV Cache，或者让 GPU 把整段上下文重新计算。大量会话同时恢复的情形常被称为「会话恢复风暴」。 网页地址: https://vuke.top/glossary/cold-recovery · 更新于 2026 年 11 月 12 日 冷恢复指一个会话的 KV Cache 已经不在显存里，请求再次到来时必须先把上下文状态恢复出来。恢复有两条路：从外置存储读回 KV Cache，或者让 GPU 把整段上下文重新计算。大量会话同时恢复的情形常被称为「会话恢复风暴」。 ### 在实测里 本站引用的 480B 测试用的就是长上下文冷恢复负载，这是 Agent 和代码助手场景的典型压力 [R2](https://vuke.top/evidence/R2)。 出处: [R2](https://vuke.top/evidence/R2) --- ## 什么是 前缀缓存（Prefix Caching）？ > 前缀缓存是推理引擎复用相同输入前缀的 KV Cache 的机制：两个请求开头相同（例如同一段系统提示词或同一份文档），第二个请求可以跳过这部分的计算。vLLM 内置的前缀缓存只在显存内生效。 网页地址: https://vuke.top/glossary/prefix-caching · 更新于 2026 年 11 月 12 日 前缀缓存是推理引擎复用相同输入前缀的 KV Cache 的机制：两个请求开头相同（例如同一段系统提示词或同一份文档），第二个请求可以跳过这部分的计算。vLLM 内置的前缀缓存只在显存内生效。 ### 在实测里 外置 KV Cache 把这个机制延伸到显存之外：被逐出的前缀仍然可以命中，而且能在多个实例之间共享 [R3](https://vuke.top/evidence/R3)。 出处: [R3](https://vuke.top/evidence/R3) --- ## 什么是 LMCache？ > LMCache 是一个对接 vLLM 的开源 KV Cache 库，负责把显存放不下的 KV Cache 下沉到主机内存和外置存储，并在命中时读回。它是 KV Cache 分层的主流开源实现。 网页地址: https://vuke.top/glossary/lmcache · 更新于 2026 年 11 月 12 日 LMCache 是一个对接 vLLM 的开源 KV Cache 库，负责把显存放不下的 KV Cache 下沉到主机内存和外置存储，并在命中时读回。它是 KV Cache 分层的主流开源实现。 ### 在实测里 芯元一为 LMCache 编写了并行读补丁：单卡并发 16 冷读盘时，TTFT 从 37.97 s 降到 9.30 s（4.1×） [R1](https://vuke.top/evidence/R1)。补丁随 R8 代码导出包交付 [R8](https://vuke.top/evidence/R8)。 出处: [R1](https://vuke.top/evidence/R1) [R8](https://vuke.top/evidence/R8) --- ## 什么是 vLLM？ > vLLM 是一个开源的大模型推理与服务引擎，以 PagedAttention 的显存管理方式和高吞吐著称，是生产环境里部署开源大模型的常见选择。 网页地址: https://vuke.top/glossary/vllm · 更新于 2026 年 11 月 12 日 vLLM 是一个开源的大模型推理与服务引擎，以 PagedAttention 的显存管理方式和高吞吐著称，是生产环境里部署开源大模型的常见选择。 ### 在实测里 本站的 MI308X 实测使用 vLLM 0.20.1+rocm721，与 LMCache 组合构成 KV Cache 分层软件栈 [R2](https://vuke.top/evidence/R2)。 出处: [R2](https://vuke.top/evidence/R2) --- ## 什么是 NVMe-oF？ > NVMe-oF（NVMe over Fabrics）把 NVMe 协议从服务器内部的 PCIe 总线延伸到网络上，让多台服务器通过以太网、InfiniBand 等网络共享远端的 NVMe 存储，同时保留接近本地盘的性能。 网页地址: https://vuke.top/glossary/nvme-of · 更新于 2026 年 11 月 12 日 NVMe-oF（NVMe over Fabrics）把 NVMe 协议从服务器内部的 PCIe 总线延伸到网络上，让多台服务器通过以太网、InfiniBand 等网络共享远端的 NVMe 存储，同时保留接近本地盘的性能。 ### 在实测里 FX 系列是 NVMe-oF 全闪阵列。实测形态为 4 盘 RAID0、RoCEv2、单口 100 GbE，在应用层 TTFT 上优于本地 NVMe 单盘 [R2](https://vuke.top/evidence/R2)。 出处: [R2](https://vuke.top/evidence/R2) --- ## 什么是 RoCEv2？ > RoCEv2（RDMA over Converged Ethernet v2）是在以太网上实现 RDMA 的协议，报文封装在 UDP/IP 里，因此可以跨三层网络路由。RDMA 让数据绕过操作系统内核直接在两台机器的内存之间传输，时延低、CPU 占用少。 网页地址: https://vuke.top/glossary/rocev2 · 更新于 2026 年 11 月 12 日 RoCEv2（RDMA over Converged Ethernet v2）是在以太网上实现 RDMA 的协议，报文封装在 UDP/IP 里，因此可以跨三层网络路由。RDMA 让数据绕过操作系统内核直接在两台机器的内存之间传输，时延低、CPU 占用少。 ### 在实测里 本站实测中，FX100 通过 RoCEv2 承载 NVMe-oF 流量 [R2](https://vuke.top/evidence/R2)。 出处: [R2](https://vuke.top/evidence/R2) --- ## 什么是 HBM（高带宽内存）？ > HBM（High Bandwidth Memory）是 AI 加速卡上使用的堆叠式高带宽内存，也就是通常所说的显存。它速度极快但容量有限、价格昂贵，模型权重和 KV Cache 都要争用这部分空间。 网页地址: https://vuke.top/glossary/hbm · 更新于 2026 年 11 月 12 日 HBM（High Bandwidth Memory）是 AI 加速卡上使用的堆叠式高带宽内存，也就是通常所说的显存。它速度极快但容量有限、价格昂贵，模型权重和 KV Cache 都要争用这部分空间。 ### 在实测里 本站 MI308X 测试平台每张卡有 192 GB HBM。R5 报告论证了外置 KV 层可以替代 128 GB 级别的显存驻留（沐曦 N260 平台） [R5](https://vuke.top/evidence/R5)。 出处: [R5](https://vuke.top/evidence/R5) --- ## 什么是 TP（张量并行）？ > 张量并行（Tensor Parallelism，TP）把一个模型的每一层拆到多张卡上共同计算。TP=8 表示一个模型实例横跨 8 张卡，是单卡装不下的超大模型的常见部署方式；TP4×2 则是把 8 张卡分成两个各占 4 卡的实例。 网页地址: https://vuke.top/glossary/tensor-parallelism · 更新于 2026 年 11 月 12 日 张量并行（Tensor Parallelism，TP）把一个模型的每一层拆到多张卡上共同计算。TP=8 表示一个模型实例横跨 8 张卡，是单卡装不下的超大模型的常见部署方式；TP4×2 则是把 8 张卡分成两个各占 4 卡的实例。 ### 在实测里 R2 用的是 TP=8 单实例，R3 用的是 TP4×2 双实例，两种形态下 KV 分层都有效 [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3)。 出处: [R2](https://vuke.top/evidence/R2) [R3](https://vuke.top/evidence/R3) --- ## 什么是 MoE（混合专家模型）？ > MoE（Mixture of Experts，混合专家）是一种模型结构：每一层包含多个「专家」子网络，每个 token 只激活其中少数几个。它让模型可以做得很大而单次计算量不随之等比增长，但权重体积庞大。 网页地址: https://vuke.top/glossary/moe · 更新于 2026 年 11 月 12 日 MoE（Mixture of Experts，混合专家）是一种模型结构：每一层包含多个「专家」子网络，每个 token 只激活其中少数几个。它让模型可以做得很大而单次计算量不随之等比增长，但权重体积庞大。 ### 在实测里 本站 480B 测试所用的 Qwen3-Coder-480B-FP8 就是 MoE 模型，权重约 450 GB [R2](https://vuke.top/evidence/R2)。 出处: [R2](https://vuke.top/evidence/R2) --- ## 什么是 ROCm？ > ROCm 是 AMD 为其 GPU 提供的开源计算软件栈，包含驱动、编译器、数学库和深度学习框架支持，在 AMD Instinct 加速卡上的角色相当于 NVIDIA 平台上的 CUDA。 网页地址: https://vuke.top/glossary/rocm · 更新于 2026 年 11 月 12 日 ROCm 是 AMD 为其 GPU 提供的开源计算软件栈，包含驱动、编译器、数学库和深度学习框架支持，在 AMD Instinct 加速卡上的角色相当于 NVIDIA 平台上的 CUDA。 ### 在实测里 本站 MI308X 平台的全部实测都基于 ROCm 7.2，vLLM 与 LMCache 由源码编译 [R1](https://vuke.top/evidence/R1)。 出处: [R1](https://vuke.top/evidence/R1) --- ## 什么是 Checkpoint（训练检查点）？ > Checkpoint 是训练过程中定期保存到存储上的模型状态快照，用于故障恢复和结果留存。保存期间训练通常要暂停，写得越慢，GPU 空转的时间越长。 网页地址: https://vuke.top/glossary/checkpoint · 更新于 2026 年 11 月 12 日 Checkpoint 是训练过程中定期保存到存储上的模型状态快照，用于故障恢复和结果留存。保存期间训练通常要暂停，写得越慢，GPU 空转的时间越长。 ### 在实测里 实测中，每份 65.6 GB 的整模型快照保存耗时从 178 s 降到 94 s（1.9×） [R1](https://vuke.top/evidence/R1)。 出处: [R1](https://vuke.top/evidence/R1) --- ## 关于芯元一：以实测立信的 AI 推理存储加速公司 > 芯元一（天津）半导体设备有限公司专注大模型推理的存储加速，产品为 FX 系列全闪 NVMe-oF 阵列。了解我们做什么、怎么做，以及为什么只讲测过的数字。 网页地址: https://vuke.top/about · 更新于 2026 年 11 月 12 日 芯元一（天津）半导体设备有限公司专注一件事：让已经买回来的算力卡产出更多 token。我们的做法是在显存和主机内存之外补上一层外置全闪存储，把推理过程中溢出的 KV Cache 接住，需要时直接读回，而不是让 GPU 重新计算一遍。 产品是 FX 系列全闪 NVMe-oF 阵列，在广东绿算 GP 系列硬件平台上开发，配合 vLLM + LMCache 的 KV Cache 分层软件栈交付，其中包含我们自研的 LMCache 并行读补丁。 我们对外只讲测过的数字。R1–R9 九份报告覆盖 AMD Instinct MI308X、华为昇腾 910B、沐曦 N260 三个平台，不同平台的数字分开标注、互不混用；测试补丁、编排脚本与原始数据打包为 R8，第三方可以独立复现。 ### 我们怎么对待数据 - **数字必须有出处**: 本站的关键数字都标注报告编号。标不出编号的数字，我们不写。 - **不同平台分开说**: MI308X、昇腾 910B、沐曦 N260 的结果各自成文、各自标注，不合并成一个更好看的头条。 - **说清对照基线**: 「快了多少」必须说明是跟谁比。对比本地 NVMe 单盘和对比整段重算是两个分母，我们不混用。 - **交出复现材料**: 补丁、脚本和原始数据打包为 R8，第三方可以自己重跑，不必只相信我们的图表。 - **说明适用边界**: 短对话、低并发的场景收益有限。这一点我们会在你立项之前说清楚。 ### 先联测，后决策 合作从一次约 10 周的门禁化联测开始。四道门禁逐级放行，任何一道不达标就在那里停下，不必为没有被证实的收益买单。 - **G1 · 第 2 周 · 到货验收**: 物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - **G2 · 第 4 周 · 单机基线**: 复现单节点 8 卡推理基线，与 R1 口径的偏差在 ±10% 以内；单阵列本地压测达到实测锚点 83% 的线效。 - **G3 · 第 7 周 · 联测主门禁**: KV 分层加速须同时满足：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - **G4 · 第 10 周 · 稳定性与验收**: 72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 完整测算模型在签署 NDA 后以 Python 源码提供，你可以换成自己的参数重新计算。 ### 公司信息 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) 关于名称：FX100 在早期测试报告的文件名里写作 AISSD5000，更早也叫过 WS5000 / GP5000，报告原文有时署「铭信」。它们指的是同一款产品。本站统一使用 FX 命名（FX100 / FX200 / FX300 / FX400），报告条目保留原始标题，方便对照查证。 --- ## 联系我们：预约联测、申请测试报告 > 联系芯元一预约 KV Cache 分层联测排期、申请 R1–R9 测试报告原件，或咨询 FX 系列配置与报价。电话与邮箱均可，邮箱 7×24 小时在线。 网页地址: https://vuke.top/contact · 更新于 2026 年 11 月 12 日 预约联测排期、申请报告原件、咨询配置与报价，都可以直接找我们。 - 公司: 芯元一（天津）半导体设备有限公司 - 联系人: 王利民 - 电话: 13161818898 - 邮箱: mingxin@agentmail.to (邮箱由 AI 自动接收与分拣，7×24 小时在线) ### 为了更快给你答复，可以先告诉我们 - 你用的加速卡型号和数量 - 推理框架与主要模型 - 典型的上下文长度和并发量 - 想查阅的报告编号（R1–R9） ### 先联测，后决策 合作从一次约 10 周的门禁化联测开始。四道门禁逐级放行，任何一道不达标就在那里停下，不必为没有被证实的收益买单。 - **G1 · 第 2 周 · 到货验收**: 物料全部到货并点验合格；每台阵列上电自检通过，24 块盘全部识别。 - **G2 · 第 4 周 · 单机基线**: 复现单节点 8 卡推理基线，与 R1 口径的偏差在 ±10% 以内；单阵列本地压测达到实测锚点 83% 的线效。 - **G3 · 第 7 周 · 联测主门禁**: KV 分层加速须同时满足：TTFT 降幅 ≥25%，吞吐提升落在 +29–40% 的实测区间内；8 个节点共享一台阵列时，回读带宽逼近网卡上限。 - **G4 · 第 10 周 · 稳定性与验收**: 72 小时连续压测不中断；注入单盘、单链路故障时业务无感；出具签字版联测报告。 --- ## 隐私说明 > 芯元一官网的隐私说明：本站不设注册与表单，不使用广告追踪；你通过电话或邮件主动提供的信息仅用于回复你的咨询。 网页地址: https://vuke.top/privacy · 更新于 2026 年 11 月 12 日 这是一个只读的信息展示网站。下面说明我们会接触到哪些信息，以及怎么使用。 ### 本站收集什么 本站没有注册、登录和在线表单，不要求你提供任何个人信息，也不使用广告追踪或跨站追踪技术。 和所有网站一样，托管本站的服务器会产生访问日志（例如访问时间、请求的页面、IP 地址、浏览器标识），用于保障网站运行与安全。 ### 你主动联系我们时 你通过电话或邮件联系我们时提供的信息（姓名、单位、联系方式、项目情况），只用于回复你的咨询和后续的商务沟通。本站公布的邮箱由 AI 自动接收与分拣。 我们不会出售你的信息。你可以随时通过联系页面的邮箱要求查询、更正或删除你提供过的信息。