TensorSharp 是开发者傅忠恺打造的原生 .NET 10 大模型推理引擎，直接加载 GGUF，跨 Windows/macOS/Linux 运行，自带 CLI、Web 聊天界面与 Ollama/OpenAI 双兼容 API。2026-08-30 发布的 3.3.0.0 版本合入约 40 个 PR：首发 Wan 视频生成、落地 GLM-5.2 与 Muse-Glimmer、推出 DFlash2 投机解码并补齐服务端安全。社区背靠背实测显示其 prefill 吞吐较 llama.cpp 最高快 1.50×，DFlash2 让 Qwen3.8-27B 解码从 19.5 升至 31.7 tok/s。适用于想把本地推理落进 C#/.NET 技术栈、或想换引擎榨干显卡的开发者
一、模型速览
严格说，TensorSharp 不是"一个大模型"，而是一套原生 .NET 10 的本地推理引擎 （仓库 github.com/zhongkaifu/TensorSharp，BSD-3-Clause 许可）。它不用 Python、不用 C++，直接加载 GGUF 跑自回归 LLM、文本扩散与视频扩散模型；后端覆盖 GGML（Metal/CUDA/Vulkan）、直连 CUDA、Apple MLX 与纯 C# CPU；对外提供控制台、ASP.NET Core Web UI、Ollama 兼容 API 与 OpenAI 兼容 /v1/chat/completions。一句话定位：给 .NET 生态一个零原生依赖、可内嵌业务系统的本地推理底座，并在 prefill 延迟上反超 llama.cpp。 它的价值不在"又一个推理库"，而在于把推理能力下沉到 .NET 运行时------C# 程序可以像调用本地方法一样加载 GGUF、做连续批处理与投机解码，无需额外起一个 Python 进程或守护服务，部署形态和普通 NuGet 组件没有区别。
目前已注册的自回归家族包括 Gemma 3/4、Qwen 3/3.5/3.6/3.8 Flash-Next、GLM 5.x、DeepSeek V4 Flash、GPT-OSS、Nemotron-H、Mistral3、Muse-Glimmer、DiffusionGemma（文本扩散），以及多模态 Qwen-Image-Edit、Wan 2.1/2.2 视频生成与 MiniMax-H3 音视频联合生成。3.3.0.0 于 2026-08-30 发布，距上个版本 3.2.1.0 仅三周半却合入约 40 个 PR，迭代节奏凶猛；官方同时提供 10 个预编译包（CLI/Server × Linux CPU/CUDA、macOS arm64、Windows CPU/CUDA），零原生依赖即可开箱。作为本周三"推理优化工具"主题下最新鲜的候选，它把"换引擎就能白嫖性能"这件事做到了开箱即用------这也是本文选它而非又一款新模型的原因。
二、核心亮点
1. 零原生依赖 + .NET 10 源生成互操作 + 服务端安全。 3.3.0 把全部 DllImport 迁移到源生成的 LibraryImport（#162），原生字符串改按 UTF-8 编组（#144），互操作不再依赖运行时代码生成，跨平台行为一致、启动更稳。对 C# 团队而言，这意味着把它当成一个普通程序集嵌进桌面/服务端即可，无需管理 C++ 工具链。本版还集中补齐了安全：附件/图像编辑/视频路径全部收敛到上传目录内，堵死路径穿越；上传改为扩展名白名单 + 安全 content-type 并支持存储配额；API 与 404 不再泄露宿主机路径；模型热重载失败保留在服模型而非崩溃；新增 --no-webui 纯 API 模式便于嵌入网关。对外提供 HTTP 服务的用户务必升到这一版。
2. DFlash2 投机解码（#175），回滚耗时归零。 Qwen3.x 这类混合架构上，旧投机解码是负优化（18.3→15.5 tok/s），根因是 GDN 递归状态无法截断，每步被部分拒绝都要在 PCIe 上搬 151MB 状态副本。DFlash2 把状态提交全部留在设备端，回滚耗时从 3604ms 直接归零；再叠加分组动态深度卷积与候选选择器（把相邻位置的 top-K 候选通过低秩码本成对打分，将整块 token 读作格图上的一次"游走"），Qwen3.8-27B 在 RTX 3080 笔记本上从 19.5 提到 31.7 tok/s ，且输出与普通解码逐字节一致（官方实测）。同版本 llama.cpp 暂无法加载 DFlash2 草稿器------此项 TensorSharp 暂时独家。
3. vLLM 式分页 KV + 块哈希前缀共享 + 连续批处理。 引擎内核采用分页 KV 池与连续批处理，多并发下显存利用与吞吐接近生产级。配合统一 draft-verify 运行时，已集齐四种投机算法：MTP/NextN 草稿头、独立草稿 GGUF、DSpark/DFlash 块草稿、免训练 n-gram speculator，覆盖从大模型到小模型的提速需求。
4. WAN 视频生成双引擎 + GLM/Muse 家族落地。 首发阿里通义万相 Wan 2.1/2.2（文生/图生视频），同时给出 GGML 全图内核与不依赖 ggml 的 WanDirect 实现，连纯 C# CPU 后端都能出片；蒸馏版 checkpoint 从文件名自动识别并切到 4 步推理，同一 1088×832×121 帧任务在 M5 Pro 上从 3h30m 降到 17m30s。此外 GLM-5.2（744B-A40B MoE、1M 上下文）与 GLM-5.3-Flash（320B MoE）已接入，支持张量并行与 CPU MoE offload------约 92% 的 routed experts 可放进内存、显卡只留主干；Muse-Glimmer-30B 则支持图像输入、思考模式与 ATEM 工具调用。
三、部署实战
环境准备（二选一）：
bash
bash
# 方案A：装 .NET 10 SDK 后运行
dotnet --version # 需 >= 10.0
# 方案B：直接用官方 10 个预编译包（CLI/Server × Linux/macOS/Windows）
# 下载解压即可，零原生依赖模型下载（任意 GGUF，例如 HuggingFace 上的 Qwen3.8-27B / GLM-5.2 / Gemma 4 E4B）：
bash
bash
# HuggingFace
huggingface-cli download <owner>/<repo> --include "*.gguf" --local-dir ./models
# 国内可改用 ModelScope 镜像下载同名 GGUF小显存跑超大 MoE：对 GLM 这类模型加
--moe-offload把专家卸载到内存，显卡只留主干。
后端选择：默认按平台自动挑后端（Windows/Linux 走 CUDA，macOS 走 Metal，无独显走 Vulkan/CPU）；显式指定可用 --backend cuda|metal|vulkan|cpu。AMD 用户务必用 3.3.0------小 BAR 显卡上此前有约 27× 的 Vulkan 减速已在 #141 修复。
启动服务（开启 DFlash2 投机解码提速）：
bash
bash
# 控制台交互 REPL
dotnet TensorSharp.Cli.dll chat --model ./models/model.gguf --temp 0.7
# 或启动 OpenAI 兼容服务（--no-webui 纯 API，便于挂网关）
dotnet TensorSharp.Server.dll --model ./models/model.gguf \
--port 5000 --spec --no-webui推理代码（Python 客户端，复制即可跑）：
python
bash
# pip install openai
from openai import OpenAI
client = OpenAI(
base_url="http://localhost:5000/v1",
api_key="EMPTY", # TensorSharp.Server 默认无鉴权
)
resp = client.chat.completions.create(
model="local",
messages=[
{"role": "system", "content": "你是一个简洁的中文助手。"},
{"role": "user", "content": "用一句话解释什么是投机解码。"},
],
temperature=0.7,
max_tokens=256,
)
print(resp.choices[0].message.content)效果验证：服务启动后日志会打印已加载的 GGUF 架构与量化类型，也可访问 /api/models 查看在服模型；Python 客户端返回标准 OpenAI 格式 ChatCompletion 对象，resp.usage 含 prompt_tokens / completion_tokens，即代表 prefill 与 decode 链路打通。
四、性能测评
速度维度（来源：官方 GitHub 实测 / 社区背靠背测试，2026-08）。需要强调：TensorSharp 的快并非靠牺牲精度换来------DFlash2 与普通解码逐字节一致，说明提速来自计算与调度优化而非近似计算，这点对生产环境尤为关键。
| 场景 | TensorSharp 3.3.0 | 对照 | 提升 |
|---|---|---|---|
| GLM-5.2 prefill（pp2048，3×RTX PRO 6000 Blackwell，prompt≥1000） | 1145.8 tok/s | llama.cpp 763.1 tok/s | 1.50× |
| GLM-5.2 prefill（pp4096） | ~1.47× vs llama.cpp | --- | --- |
| Qwen3.8-27B 解码（RTX 3080 笔记本，贪心） | 31.7 tok/s（+DFlash2） | 普通解码 19.5 tok/s | +62.6% |
GLM-5.2 NextN 草稿（--spec） |
约 1.3×，草稿接受率 94% | --- | --- |
视频生成维度（来源：官方实测）：
| 任务 | TensorSharp 3.3.0 | 对照 | 提速 |
|---|---|---|---|
| 图生视频 1088×832×121 帧（M5 Pro，蒸馏 4 步） | 17m30s | 普通 3h30m | ~12× |
| TI2V-5B 81 帧 480p（16GB 显卡） | 8 分钟 | --- | --- |
| Wan 2.1 端到端 vs stable-diffusion.cpp | --- | --- | 6× |
显存维度：权重采用零拷贝映射 + 原生量化（Q4_KM/Q8_0/IQ 系列/MXFP4），与同文件 llama.cpp 占用基本持平；差异主要来自 KV 池与并发设置，CLI 单轮对话显存≈模型权重本身，超大 MoE 可借 --moe-offload 进一步压低显存峰值。
质量维度：DFlash2 与普通解码逐字节一致 ，属无损提速；Wan 各后端 latent 余弦相似度 ≥0.999、DiT 单步 cos 0.99999+，数值对齐 diffusers 参考实现。需说明：以上 tok/s 均为项目在指定硬件上的最佳-case 实测，落地到你的模型与显卡请以本地复测为准。想自己复测：用相同 GGUF、相同 GPU，在 TensorSharp 与 llama.cpp 上各跑一次长 prefill 与固定 decode，记录 resp.usage 与首 token 耗时即可横向对比；注意关闭其他占用显存的进程，保证两次实验显存余量一致。
五、使用建议
适用：.NET/C# 团队要把本地推理内嵌进桌面或后端服务；想换引擎专门榨 prefill 与首 token 延迟；跑 Wan 视频生成或 GLM-5.2/Muse-Glimmer 这类新家族；AMD 小 BAR 显卡用户（3.3.0 修掉了约 27× Vulkan 减速）。
不适用：需要多机 EP/PP 大规模训练式部署（生态成熟度仍不如 vLLM）；依赖 ONNX/TensorFlow 等非 GGUF 格式；需要服务端内置鉴权/TLS（当前需自建 Nginx 反向代理）；跨大版本升级请先 pin 版本、核对启动参数，避免 flag 改名导致启动失败。
调优提示 ：解码提速一律先加 --spec；超大 MoE 加 --moe-offload 把专家卸到内存；Wan 直接用蒸馏版 checkpoint 触发 4 步推理；对外服务用 --no-webui 纯 API 并加反向代理；自建服务强烈建议升到 3.3.0，安全修复集中在此版本。
选型对照（本地推理引擎横向）：
| 维度 | TensorSharp 3.3.0 | llama.cpp | Ollama | vLLM |
|---|---|---|---|---|
| 语言/依赖 | C#/.NET10，零原生依赖 | C++，无依赖 | Go+C，需守护进程 | Python，偏重 |
| 多并发 | 连续批处理 + 分页 KV | 有限 | 有限 | 工业级 |
| 投机解码 | 4 种，含独家 DFlash2 | DSpark/MTP | 依赖底层 | 支持 |
| 视频生成 | Wan / MiniMax-H3 | 部分 | 否 | 实验性 |
| 最适场景 | .NET 内嵌 / 桌面 / 视频 | 通用本地 | 快速上手 | 服务端大规模 |
一句话结论：要"嵌进 C# 程序"或"顺手出视频"，TensorSharp 现在是最省心的那条路；要扛千级并发的生产流量，vLLM 仍是默认答案。