如果有人告诉你:纯 C# 写的大模型推理引擎,性能已经追平了手工调优的 C++------你会信吗?
这确实发生了。2026 年,.NET 生态里同时出现了三个"本地跑大模型"的方案,而且它们代表了三种完全不同的技术信仰:
- LLamaSharp:老老实实给 llama.cpp 当"翻译官"
- dotLLM:不信邪,从张量到 CUDA 内核全部用 C# 重写
- TensorSharp:小孩子才做选择,纯托管和原生内核我全都要
我把三个仓库全部拉下来,从代码量、提交记录、官方基准到许可证逐项拆了一遍。结论有点出人意料。
一、先看家底:这不是一个量级的比赛
| LLamaSharp | dotLLM | TensorSharp | |
|---|---|---|---|
| 诞生时间 | 2023 年 5 月 | 2026 年 2 月 | 2026 年 4 月 |
| Stars | 3759 | 483 | 281 |
| 贡献者 | 约 100 人 | 基本 1 人 | 基本 1 人 |
| 许可证 | MIT | GPL-3.0 ⚠️ | BSD-3 |
| C# 代码量 | 2.9 万行 | 6.6 万行 | 21 万行 |
| 定位 | 进程内推理库 | 库 + 单机服务器 | 完整推理平台 |
LLamaSharp 是这里唯一"久经考验"的选手:三年迭代到 v0.28.0,百人社区,还有微软 Semantic Kernel 和 Kernel Memory(RAG)的官方集成包。
而 dotLLM 和 TensorSharp 都是 2026 年的新生儿,核心开发者都只有一个人。
单人项目是这两个新引擎最大的共同风险------功能再强,选型时也要把"作者哪天不更新了怎么办"算进去。
二、三条路线,三种信仰
LLamaSharp:借力派。 它的 C# 层只有 2.9 万行代码,一行内核都不写,全部张量计算通过 P/Invoke 交给 llama.cpp 原生库。好处显而易见:性能 = llama.cpp 本身,CUDA/Metal/Vulkan 全有现成后端包,Install-Package 就能跑。代价是能力天花板 = 上游能力 − 封装损耗,新模型支持永远慢 llama.cpp 一步(README 里那张版本映射表就是证据)。
dotLLM:自立派。 作者是《Pro .NET Memory Management》的作者、.NET MVP Konrad Kokosa。这个项目的自我定位带着一点挑衅:"not a wrapper around llama.cpp"------分词、采样、量化矩阵乘全部纯 C#,连 GPU 加速都是通过 CUDA Driver API 直接加载 PTX 内核,零原生共享库依赖。这意味着它是三者中唯一能做 Native AOT 单文件分发(启动约 50ms)的引擎。
TensorSharp:合流派。 作者 Zhongkai Fu 的思路很务实:自研内核还嫩?那就把 GGML 源码直接纳入构建体系,Metal/CUDA/Vulkan 的成熟内核照用,但在此之上加 llama.cpp 默认没有的东西------vLLM 式连续批处理、张量并行、跨机 TCP 集群、多模态(图/视/音频)、甚至文本扩散和图像编辑。21 万行 C# + 16 万行 PTX,体量是 dotLLM 的五倍。
三、性能:三家到底谁快?
这里有个陷阱:三家的官方基准各测各的,直接比数字会失真。但交叉解读后,画面其实很清晰:
CPU 解码(最常用场景) :dotLLM 官方对比 llama.cpp------135M 模型 0.74×、1B 模型 0.95×、3B 模型 1.01×,已经持平。纯托管代码在内存带宽主导的解码路径上,确实追上了手工调优的 C++。
CPU 预填充(长提示词场景):dotLLM 仍是 0.32×--0.57×,差距约 2-3 倍。作者很诚实,直接写在文档里并给了追赶路线。
GPU 吞吐 :TensorSharp 和 llama.cpp 在同一块 RTX 3080、同一 GGML 后端上硬碰硬------Gemma 4 预填充 1.28× 、首 token 延迟 1.27× ,多轮对话最高 1.49× 。落后的格子(Vulkan MoE 0.87×)也如实列着。它的赢法不是内核更快,而是调度层更聪明:连续批处理 + 前缀共享。
一句话总结水位:
开箱即得的绝对性能,LLamaSharp ≈ TensorSharp(都在跑 ggml 系内核,后者高并发场景还能反超);dotLLM 在 CPU 解码追平了绑定派,其余场景仍在追赶------但它换来了另外两家给不了的东西:零原生依赖。
四、许可证:可能一票否决的那一行
三个项目恰好占了三个档位:
- ✅ LLamaSharp:MIT------随便用
- ✅ TensorSharp:BSD-3------随便用
- ⚠️ dotLLM:GPL-3.0------通过 NuGet 引用嵌进闭源商业产品,有 copyleft 合规障碍;以独立进程部署、走 HTTP API 调用则通常没问题
对很多公司来说,这一项就直接决定了 dotLLM 能不能进选型名单------和技术好坏无关。
五、怎么选?一张表说清
| 你的情况 | 选谁 |
|---|---|
| 生产环境求稳,要有人能问 | LLamaSharp |
| 已经用了 Semantic Kernel / Kernel Memory | LLamaSharp(唯一官方集成) |
| 闭源商用内嵌 | LLamaSharp 或 TensorSharp |
| 纯 CPU、零原生依赖、边缘部署、AOT 单文件 | dotLLM(唯一选项) |
| GPU 高并发服务(多用户同时请求) | TensorSharp(连续批处理默认开启) |
| AMD/Intel 显卡、macOS Metal | LLamaSharp 或 TensorSharp(dotLLM 没这后端) |
| 多模态、超大 MoE(284B)、多卡多机 | TensorSharp |
| 可解释性研究(logit lens、激活捕获) | dotLLM |
| 想学"怎么从零写一个推理引擎" | 中文读者选 TensorSharp(有配套书),性能工程爱好者选 dotLLM |
求稳选 LLamaSharp,求纯选 dotLLM,求全选 TensorSharp。
六、写在最后
LLamaSharp 用三年时间证明:.NET 可以"借"llama.cpp 的力站稳本地推理。
dotLLM 和 TensorSharp 在 2026 年同时出现,则说明这个社区开始提出更高的要求------部署自由度和平台化能力,这恰恰是绑定路线给不了的。
三家并存,比任何一家独大都更能说明问题:C# 在本地大模型推理这件事上,已经不缺答案了。
数据说明:本文所有数据来自 2026-08-02 当日拉取的三仓库源码与官方文档;性能数字均为各项目自报基准,实际表现因硬件与负载而异,选型前请自行复测。
觉得有用,转给正在做 .NET AI 技术选型的同事------可能正好帮到 TA。