如果有人告诉你：纯 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。
