TensorSharp 最新进展研究报告：从 DeepSeek V4 Flash 到 GLM-5.2，以及等待中的 GLM-5.3

摘要

截至 2026 年 8 月 20 日，纯 .NET 推理引擎 TensorSharp（作者 Zhongkai Fu）于 2026 年 8 月 19 日合并 PR #163「support glm model」，正式支持 GLM-5.2（GGUF 架构 id glm-dsa） (Github) 。在 3× RTX PRO 6000 Blackwell（每张约 97 GiB 显存）上，TensorSharp 与同机 llama.cpp 背靠背实测：prompt 长度约 1000 token 以上时 TensorSharp prefill 反超，pp2048 达 1145.8 tok/s 对 llama.cpp 的 763.1 tok/s（约 1.50×），pp4096 约 1.47×，decode（tg64）也快约 4% (Github) 。而 GLM-5.3 已于 8 月 14 日发布、8 月 19 日开放 API，但权重尚未开源——官方口径为"下周五"（即约 2026 年 8 月 28 日）放出 (VL 系列全新成员 4B 与 8B 模型开源上线) 。由于 GLM-5.3 沿用 GLM-5.2 的同一基座模型、提升全部来自后训练 (mfuns.net) ，TensorSharp 现有的 glm-dsa 支持大概率可以直接承接 GLM-5.3 权重——"万事俱备，只等权重"这个判断是成立的。

---

一、起点：那篇博客园文章讲了什么

2026 年 8 月 1 日发表的《把 284B 的 DeepSeek V4 Flash 装进纯 .NET》记录的是 TensorSharp 在 2026 年 7 月 31 日这一天完成的两个动作：上午合并 PR #116，把 DeepSeek V4 Flash（DSV4，284B 参数、256 专家的 MoE）接入 TensorSharp.Server，获得 OpenAI 兼容接口与 continuous batching 多并发能力；当晚作者又推上 feature/update_direct_cuda_backend_to_support_deepseek_v4 分支，为 DSV4 手写了一条完全绕开 ggml 的直接 CUDA 后端 (博客园) 。

那篇文章的核心判断有两条。其一，DSV4 是"第一个成本合理且可用的本地部署大模型"——IQ4_XS 量化后约 128 GiB，2×80GB 显卡即可运行，4×A40 也能通过层切分承载 133 GB 版本 (博客园) 。其二，.NET 推理栈"第一次从玩具变成了可用选项"：TensorSharp 为 DSV4 提供了三条并行路径（手写 CUDA kernel 的直接 CUDA 后端、ggml 原生执行器、100% 托管代码的纯 C# CPU 后端），性能基线达到 llama.cpp 的八到九成，且多并发 slot 输出与单流温度 0 的结果逐字节一致 (博客园) 。

这篇文章的价值在于确立了 TensorSharp 的工程方法论：不赌单一路线、逐字节对齐 llama.cpp 的正确性验证、以原生 sequence slot 实现并发隔离。这套方法论在三周后的 GLM-5.2 支持中被完整复用并放大。

二、最新进展：GLM-5.2（glm-dsa）正式落地

2.1 时间线与代码事实

从 GitHub 仓库记录看，TensorSharp 在 8 月保持高频提交（8 月 16–19 日每天都有多个 commit） (Github) ，并在 2026 年 8 月 19 日合并 PR #163「support glm model」——这恰好是智谱 GLM-5.3 API 上线的同一天 (Github) 。仓库 README 已将 GLM 5.x 列入"已验证模型"清单，架构卡片 glm.md / glm_zh-cn.md 同步入库 (Github) 。

GLM-5.2 的架构对推理引擎并不友好：744B 参数 MoE（256 个路由专家、top-8 路由加 1 个共享专家），注意力采用带权重吸收的 Multi-head Latent Attention（MLA），外加 DeepSeek 稀疏注意力（DSA）的 "lightning indexer"——由它决定每个 query 可以看见哪些已缓存 token（top-k 2048）；官方宣称上下文 1M token (Github) 。KV 缓存被压缩到每层每 token 仅一行 576 宽，78 层中有 21 层带 indexer (Github) 。这意味着现成的分页 KV 批处理方案根本不适用，必须逐层定制。

2.2 TensorSharp 的应对方案

TensorSharp 为 GLM-5.2 提供了两套实现，均以 llama.cpp 的 src/models/glm-dsa.cpp 为复现基准 (Github) ：

实现路径	技术形态	特点
GGML 后端（ggml_cuda / ggml_vulkan / ggml_cpu / ggml_metal）	原生整模型执行器（ggml_ops_glm_dsa.cpp）	自行加载分片 GGUF、按层切分到多卡、设备上持有 MLA 与 indexer 缓存，每个 ubatch 只提交一张图并配 LRU 图缓存，稳态 decode 只是重放已捕获的 CUDA 图 (Github)
--backend cpu（100% 托管）与 --backend cuda	逐算子路径（TensorSharp.Models/Models/GlmDsa/*）	建立在共享托管/量化算子之上，同时充当原生执行器的参考实现，可用 TS_GLM_NATIVE=0 做 A/B 对比 (Github)

多卡策略上有一个值得注意的实测结论：默认的按层切分（layer split）在这台机器上赢了张量并行（--tp 3）——pp2048 为 896.8 对 502.8 tok/s，tg64 为 43.9 对 16.2 tok/s。原因是三张卡为 PCIe 直连、无 NVLink，每层两次 all-reduce 的总线开销超过了切分省下的算力；文档明确指出换到 NVLink/NVSwitch 主机上结论会反转 (Github) 。此外 --n-cpu-moe N 可把占 checkpoint 92% 的路由专家留在系统内存，让显存不足的机器也能跑（代价是速度大跌：pp2048 从 915.9 掉到 94.7 tok/s） (Github) 。

并发服务方面，GLM 与 DeepSeek V4 共用同一套原生 per-sequence slot 契约；由于 MLA 每 token 只存一行压缩表示，"没有分页 KV 布局可批"，TensorSharp 刻意不实现分页路径，改为批量融合 decode（TS_BATCHED_FUSED_DECODE=1）：N 个序列各一个 token 共享一张图，所有投影、路由器、专家与 LM head 在整批上只跑一次。实测 4 路并发 200 token 补全合计 75.2 tok/s，为单流 41.6 tok/s 的 1.81× (Github) 。

三、性能与正确性：和 llama.cpp 的正面对比

3.1 性能数据

测试条件：3× RTX PRO 6000 Blackwell（每张约 97 GiB），GLM-5.2-UD-IQ2_XXS（226 GiB 权重），按层切分，两侧同一轮背靠背测量（llama.cpp 用 llama-bench，TensorSharp 用校验工具的 --bench，各取两次重复中的最好值，重复测量波动约 4%） (Github) ：

测试	llama.cpp	TensorSharp（默认 ubatch 1024）	TensorSharp（ubatch 2048）	最优加速比
pp128	276.5 t/s	254.8 t/s	264.4 t/s	0.96×（llama.cpp 胜）
pp512	695.4 t/s	666.9 t/s	659.6 t/s	0.96×（llama.cpp 胜）
pp2048	763.1 t/s	918.9 t/s	1145.8 t/s	1.50×
pp4096	715.8 t/s	864.7 t/s	1048.7 t/s	1.47×
tg64（decode）	42.2 t/s	43.7 t/s	43.9 t/s	1.04×

交叉点在约 1000 个 prompt token：256 专家 top-8 路由下，512 token 的分块平均只给每个专家约 16 行，专家 GEMM 的 tile 大部分是填充，因此加大 micro-batch 是长 prompt 上最划算的改动——这正是"长上下文下比 llama.cpp 快"的机制解释。短 prompt 时 llama.cpp 领先几个百分点，差在每次调用的固定开销（托管层跳转、输入上传、154880 宽的 logits 回传）。decode 受显存带宽限制，两边接近，TensorSharp 略快 (Github) 。仓库 README 的口径更保守：pp2048 1.20×、pp4096 1.21×、decode 1.04×（按默认 ubatch 1024 计） (Github) 。权重加载速度也值得一提：热页缓存下 218 GiB 约 37 秒（5.9 GiB/s，16 读线程跨 6 分片并行） (Github) 。

需要客观指出的边界：这组数字来自 TensorSharp 作者自己的文档，属于单方自报基准；测试用的是 2-bit 动态量化（UD-IQ2_XXS）这一最低质量档；且"更快"集中在长 prompt prefill，短 prompt 和 decode 只是持平或略胜。把它放进行业坐标看：GLM-5.2 自托管的主流路径此前是 vLLM / SGLang（FP8/BF16，8×H200 级硬件）或 llama.cpp + Unsloth GGUF（量化路线） (阿里云开发者社区) ，TensorSharp 是第三个能把这个 744B 模型完整跑起来并对外服务的引擎，也是其中唯一的纯 .NET 实现 (Github) 。

3.2 正确性：比速度更硬的部分

TensorSharp 延续了 DSV4 时期的"逐字节对齐"验收标准。用记录下来的 prompt token id 做前向对比（隔离分词差异），GLM-5.2-UD-IQ2_XXS 对 llama.cpp b200-9731ad3：ggml_cuda 三卡 6/6 逐 token 一致（含 1 个走稀疏路径的 2741 token prompt）、ggml_cpu 3/3、纯托管 cpu 1/1 (Github) 。

文档还披露了两个能体现工程严谨度的细节。其一，Hadamard 旋转被刻意复现：它在精确算术下是抵消的正交对合变换，但 indexer 的 key 缓存是 F16，先旋转再舍入才能把误差均匀摊到 128 维——去掉它就会改变 2741 token prompt 上的 top-k 选择，破坏与 llama.cpp 的逐 token 一致 (Github) 。其二，"同后端"这个限定是必要的：llama.cpp 自己的 CPU 与 CUDA 构建在该 prompt 上第 5 个生成 token 就已分叉，TensorSharp 的策略是精确复现当前所跑后端的那一个 (Github) 。批量 decode 默认关闭的原因同样诚实：2-bit 权重下 75 层 256 选 8 的 top-k 路由会把 GEMM 形状变化带来的末位差异放大成肉眼可见的另一段续写 (Github) 。

3.3 上下文长度：1M 是上限，不是承诺

GGUF 宣称 1,048,576 token，但 78 层每 token 的 576 宽 MLA 行加 indexer 行约 93 KiB——1M 上下文就是约 93 GiB 的 KV 缓存，相当于在权重之外再多占一整张卡 (Github) 。TensorSharp 的处理是把宣称值当作上限：加载器用权重落盘后设备上真实剩余的显存来定上下文。在三张 RTX PRO 6000 上，默认层切分选出 342,272 token，--n-cpu-moe 30 可抬到 646,400；--tp 3 因每个 rank 持完整缓存副本，只能选出 91,136 (Github) 。这个"诚实定上下文"的策略，比静默截断或 OOM 崩溃要工程化得多。

四、硬件背景：为什么是 RTX PRO 6000

RTX PRO 6000 Blackwell 是 NVIDIA 2025 年 GTC 发布的工作站/服务器专业卡：GB202 满血核心、24,064 个 CUDA 核心、第五代 Tensor Core、96 GB GDDR7 ECC 显存，工作站版显存带宽约 1,792 GB/s，PCIe 5.0 x16 接口，工作站版 600 W TDP，售价约 8,500 美元 (Nvidia) 。三张卡合计约 288 GB 显存、约 5.4 TB/s 聚合带宽——这正好把 226 GiB 的 2-bit GLM-5.2 权重按层切分放下，还剩约 60 GiB 给 KV 缓存与计算图 (Github) 。

这个配置的意义在于部署门槛的坐标移动。作为对照：BF16 全精度 GLM-5.2 需要约 1.5 TB（8×H100/16 卡级），FP8 约 750 GB（8×H200），Q4_K_M GGUF 约 376–476 GB，而 2-bit UD-IQ2_XXS 把门槛压到约 241 GB——此前这一档的现实载体是 256 GB 统一内存的 Mac Studio（3–9 tok/s）或"单卡 + 大内存 offload"的低速方案 (阿里云开发者社区) 。3× RTX PRO 6000 是一台塔式/机架工作站就能承载的配置（整机卡成本约 2.5 万美元量级），却能把 prefill 跑到 1000+ tok/s、decode 跑到 44 tok/s (Github) ——这是"前沿开源模型私有化部署"第一次进入工作站预算区间还能保持可用速度。需要注意的是这三张卡为 PCIe 直连、无 NVLink，这也是 TP 模式在该机上不划算的直接原因 (Github) 。

五、GLM-5.3：万事俱备，只等权重

5.1 GLM-5.3 的发布状态

智谱（Z.ai）于 2026 年 8 月 14 日正式发布 GLM-5.3，主打编程与网络安全防御能力；8 月 19 日 API 正式上线，定价与 GLM-5.2 持平，已接入 ZCode 并纳入 GLM Coding Plan (mfuns.net) 。在 Artificial Analysis 综合智能指数上取得 60 分，与 Claude Fable 5、GPT-5.6 Sol 等闭源旗舰处于同一区间，与 Kimi K3 并列开源模型第一；同时是前沿旗舰中单任务成本最低的模型 (VL 系列全新成员 4B 与 8B 模型开源上线) 。官方披露的基准跃升主要来自后训练：Terminal-Bench 3.0 从 4.6 升至 28.3，DeepSWE v1.1 从 46.2 升至 66.9，内部编程体感评测称较 GLM-5.2 提升 50% (mfuns.net) 。

权重尚未开源。 8 月 14 日发布时的口径是"两周内开源、先完成安全评估与模型加固" (mfuns.net) ；8 月 19 日 API 上线时官方确认"下周五正式开源" (sohu.com) 。以 8 月 19 日（周三）计，"下周五"即 2026 年 8 月 28 日前后（部分媒体写作 8 月 25 日，以官方最终公告为准） (腾讯新闻) 。也就是说，您"只等 GLM 5.3 权重开源"的判断在今天是准确的。

5.2 为什么 TensorSharp 大概率"即插即用"

关键事实：GLM-5.3 与 GLM-5.2 沿用同一基础模型（约 743B/744B 基座），全部性能提升来自后训练阶段的 Scaling（IndexShare、SAO 与 Slime 框架），未重训基座、未改底层架构 (mfuns.net) 。对推理引擎而言，决定适配工作量的是架构（层结构、注意力形态、tokenizer、GGUF arch id）而非权重数值——只要 GLM-5.3 的 GGUF 仍以 glm-dsa 架构发布，TensorSharp 现有的两套执行器、层切分加载、slot 并发与校验工具链理论上可以直接承接，最多需要处理聊天模板或新增能力（如有）的边角差异。一个小不确定项：有资料称 GLM-5.3 增加了多模态视觉能力 (百度百科) ，而 TensorSharp 目前的 GLM 卡片标注为纯文本 (Github) ；若 5.3 权重确含视觉塔，文本路径不受影响，但视觉输入需要另行适配。GLM-5.3 权重开源后的第一周，社区量化（Unsloth GGUF 等）跟进速度和 TensorSharp 的实际兼容性验证，是最值得盯的两个信号 (thundercompute.com) 。

六、生态意义与展望

从 7 月 31 日的 DSV4（284B）到 8 月 19 日的 GLM-5.2（744B），TensorSharp 在三周内把纯 .NET 推理栈的承载上限抬高了 2.6 倍，且保持了对 llama.cpp 的逐 token 对齐传统 (博客园) 。放到更大的图景里：.NET 生态在 AI 应用层（Semantic Kernel、Microsoft Agent Framework 等）进展很快，但推理层长期依赖跨进程调用"别人的引擎"；TensorSharp 把推理引擎变成了 .NET 进程内的一等公民——100% 托管 CPU 路径零原生依赖、可审计，对金融、政企等合规敏感场景是实打实的差异化 (博客园) 。

对整个本地推理领域，这条线的启示是：前沿开源模型的私有化部署正在从"数据中心工程"变成"工作站工程"。GLM-5.2 以 MIT 许可开源、2-bit 量化压到 226 GiB、3 张工作站卡即可承载并获得千 token/s 级 prefill (Github) ；而 GLM-5.3 同基座 + 后训练的迭代方式意味着，一旦 8 月 28 日前后权重落地，包括 TensorSharp、llama.cpp 在内的整条已有工具链可以几乎零成本完成切换 (mfuns.net) 。届时值得验证的三件事：GLM-5.3 的 GGUF 是否沿用 glm-dsa 架构 id；TensorSharp 能否延续"同后端 6/6 逐 token 一致"的对齐纪录；以及在同样三张 RTX PRO 6000 上，1M 上下文宣称值与实际可用 KV 容量之间的落差是否改善。