纯 C# 追平 llama.cpp?.NET 本地推理三国杀
当前位置:点晴教程→知识管理交流
→『 技术文档交流 』
如果有人告诉你:纯 C# 写的大模型推理引擎,性能已经追平了手工调优的 C++——你会信吗? 这确实发生了。2026 年,.NET 生态里同时出现了三个"本地跑大模型"的方案,而且它们代表了三种完全不同的技术信仰:
我把三个仓库全部拉下来,从代码量、提交记录、官方基准到许可证逐项拆了一遍。结论有点出人意料。 一、先看家底:这不是一个量级的比赛
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 全有现成后端包, 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×)也如实列着。它的赢法不是内核更快,而是调度层更聪明:连续批处理 + 前缀共享。 一句话总结水位:
四、许可证:可能一票否决的那一行三个项目恰好占了三个档位:
对很多公司来说,这一项就直接决定了 dotLLM 能不能进选型名单——和技术好坏无关。 五、怎么选?一张表说清
求稳选 LLamaSharp,求纯选 dotLLM,求全选 TensorSharp。 六、写在最后LLamaSharp 用三年时间证明:.NET 可以"借"llama.cpp 的力站稳本地推理。 dotLLM 和 TensorSharp 在 2026 年同时出现,则说明这个社区开始提出更高的要求——部署自由度和平台化能力,这恰恰是绑定路线给不了的。 三家并存,比任何一家独大都更能说明问题:C# 在本地大模型推理这件事上,已经不缺答案了。 数据说明:本文所有数据来自 2026-08-02 当日拉取的三仓库源码与官方文档;性能数字均为各项目自报基准,实际表现因硬件与负载而异,选型前请自行复测。 阅读原文:点击这里 该文章在 2026/8/3 11:50:20 编辑过 |
关键字查询
相关文章
正在查询... |