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