跨平台开源 LLM 训练 / 推理库全景考

序：一个必须先撕开的词

「基于 C++ 的 LLM 库」这句话，其实是一句歧义句。若不先拆开，后面所有讨论都是鸡同鸭讲。

试看三物：

• llama.cpp——从张量到调度器到 HTTP server，几乎全是 C/C++，Python 只用来做格式转换。
• PyTorch——C++ 写成，但你日常摸到的是 Python 那层皮；它的 C++ 前端（libtorch）完整存在，却少人问津。
• vLLM——Python 占了 84.2%，C++ 只有 3.4%，可这 3.4% 恰恰是它全部性能的来源。

三者皆可称「C++ 库」，然其义迥异。故本报告立三层分类法，一切论述皆在此框架下展开：

一条极重要的判据：「用什么语言写成」与「能否被该语言的开发者使用」，是两件独立的事。
TensorFlow 的 C++ 占 60%，却把 tensorflow/cc 明列于「不在兼容性保证之内」；XLA 更甚——无 GitHub release、compile options 得从 Python 里导出成字节数组，JAX 维护者自承 "it's not a smooth path"。
此二者用 C++ 写成，交付界面却在 Python。反之，ONNX Runtime 与 OpenVINO 之所以是真 C++ 栈，非因语言，而因它们把 C++ 当作对外交付的产品。

第一层：纯 C/C++ 实现——推理为王，训练为丐

1.1 全景表

1.2 llama.cpp：跨平台之王，靠的不是自己写后端

llama.cpp 现有 17–18 个计算后端：CUDA / Metal / Vulkan / SYCL / HIP / CANN / MUSA / OpenCL(Adreno) / BLAS / BLIS / ZenDNN / zDNN(IBM Z) / RPC / Hexagon / WebGPU / OpenVINO / ET(Esperanto)。

然其奥妙不在工程量，在治理结构。

ggml 用四层 C 函数指针 vtable 解耦硬件：ggml_backend_reg_i（注册）→ ggml_backend_device_i（能力查询）→ ggml_backend_i（执行）→ ggml_backend_buffer_i（内存）。C 无虚函数，故手工填表。调度器向每个设备问一句 supports_op，答曰不能，便沿优先级顺延，末了CPU 兜底。

于是：

• 新增后端的最小成本，从「改核心 + 过 review」降为「填四个结构体」。
• 华为（CANN）、摩尔线程（MUSA）、IBM（zDNN）、高通（Hexagon）、AMD（ZenDNN）、Esperanto（ET）自己来贴 PR。
• ggml 只维护一个 ggml_backend_i 接口。

十八个后端，是治理结构的产物，不是工程量的产物。

这条路走了约 20 个月：2023-03 首发时是单文件 ggml.c；2023-10 引入 backend 抽象；2024-11 后端拆为独立库并支持动态加载。

但真相还有另一半：真正的成本不在接口，在内存契约。GGML 只建两个静态池（权重 + 中间缓冲），无临时分配 API，且要求 buffer 可返回主机可寻址的 get_base()。FOSDEM 2025 上有人记录了为 TTNN 写后端时遭遇的四重违约（非行主序、无法映射设备内存、typed allocation、自有量化类型），最后靠「虚拟指针 0x1000 + tensor extra 存真地址」的技巧绕过。
跨平台的债，不在首次接入，在永远还不清的回归测试与算子补齐——这正是 CANN 后端至今仍标 Experimental 的原因。

1.3 训练侧：一场安静的溃败

这是本报告最令人唏嘘的一节。

llm.c（Karpathy）：~1000 行 C + CUDA 复现 GPT-2/GPT-3，多卡走 MPI + NCCL，技术上完全成立。然末次提交停在 2025-06-26，已 14 个月无更新；只支持 GPT-2/GPT-3 架构，不支持 Llama 系；作者重心已转向 nanochat（PyTorch）与 microgpt。

llama.cpp 的 finetune：老模块 2024 年被 PR #8669 直接删掉；现存的 llama-finetune 禁用 mmap、强制 F32 KV cache。维护者 2026-02 原话：

"I can promise you that the python pile will be better than the finetune experiment… only good for finetuning extremely small models."

唯一的反例是 gemma.cpp——罕见地自带 VJP 反向传播与 Adam。然官方定位写明 "for Gemma research"，生产推荐 JAX/PyTorch。作者自己划的边界，比外人划的更窄。

为何如此？答曰：收益不对称。

推理侧的「零依赖」能换来千万级设备覆盖——这是实打实的地盘。训练侧却要重写 autograd + 优化器状态 + 分布式编排 + 数据管线，去和 PyTorch/Unsloth 抢一个本来就有 GPU、本来就有 Python 的场景。而 LLM 训练的真正门槛不在 forward/backward（那部分 C++ 早就写得很好），在 DDP / FSDP / TP / PP / ZeRO 这套策略性编排——它组合爆炸、每周在变、需要用户随时插手。

机制沉底，策略上浮。中间那层，C++ 让出去了。

1.4 「单模型 .cpp」这条路的集体灭绝

chatglm.cpp、qwen.cpp（已 archived）、baichuan.cpp、ctransformers、TinyChatEngine——全部停更或归档。退场理由高度一致："in favor of llama.cpp"。

chatglm.cpp v0.4.0 的 release note 写得直白：Drop Baichuan/InternLM support in favor of llama.cpp。

GGUF 作为格式收敛点出现之后，为单一模型族维护一套 C++ 实现的边际收益归零。

幸存者偏差要反过来读：活下来的那个，是最不像框架的那个。

而 2024 年后新出现且活得好的纯 C++ 项目，全部是换维度竞争：

第二层：C++ 核心 + Python 壳——被低估的真 C++ 栈

2.1 ONNX Runtime：名字害了它

它叫「ONNX Runtime」，于是被当成格式转换工具。实则：

• C/C++ 才是它的原生 API 层，C# / Java / ObjC / JS / Rust 全绑定在 C API 之上。
• 21,684 star，Execution Provider 覆盖 CUDA / TensorRT / TensorRT-RTX / OpenVINO / oneDNN / DirectML / QNN / NNAPI / CoreML / XNNPACK / MIGraphX / Vitis-AI / WebGPU —— 覆盖面无人能及。
• 它是 Windows ML 与 Foundry Local 的底座——即每台新 Windows 机器上的一方 LLM 运行时。

这是本报告认定的「唯一一套 C++ 代码打通 Windows / Linux / macOS / Android / iOS / Web + NVIDIA / AMD / Intel / Apple / Qualcomm」的组合。

短板须诚实标注：GenAI 的 C API 仍标 "in preview and subject to change"；KV cache 不对外暴露（由 OgaGenerator 内部托管），想自定义分页/前缀共享则无从下手；continuous batching 尚在 dev 分支。

2.2 通用框架：C++ 占比高 ≠ C++ 可用性高

libtorch 的真实处境：从「部署运行时」降级为「嵌入式张量库」。

TorchScript 自 PyTorch 2.10 起弃用，官方转向 torch.export + AOTInductor / ExecuTorch。Python 定义图，C++ 只执行图——官方亲手拆掉了 C++ 的最后一层策略界面。libtorch 未来的稳定用户，是需要在 C++ 宿主进程里做张量计算的场景（游戏、机器人、仿真、交易系统），而非 LLM 训练。

2.3 编译栈：TVM、IREE 与 XLA 的三种命运

TVM vs IREE 的「路线之争」在 2026 年已不成立——两者跑向了不同赛道。TVM 用 TIRx 主动放弃「编译器自动搞定一切」的假设，官方定位是比 Triton 更低、更显式的专家 kernel DSL；IREE 则守住「确定性流水线 + 可裁剪 C runtime + bare-metal」。

真正的对立，从「搜索 vs 确定性」变成了**「帮专家写 kernel」vs「把图可靠地编出来」**。

第三层：Python 框架 + C++/CUDA 算子——「3.4% 的 C++ 是全部性能来源」

3.1 全景表

3.2 一条必须加的注脚：语言占比严重低估真实 C++ 含量

SGLang 把 kernel 拆成独立仓库 sgl-kernel-npu（C++ 81.9%）、sgl-kernel-xpu；KTransformers 主体重构为 kt-kernel；vLLM-Ascend 这个插件里 C++ 52% > Python 43%。

分母被切走了，分子却在隔壁仓库。

所以「vLLM 是 Python 项目」这句话，描述的不是技术事实，而是仓库拓扑的副产品。准确说法应是：vLLM 的调度编排层是 Python，而它的性能瓶颈层（PagedAttention、量化 kernel、MoE、通信）几乎全是 C++/CUDA。

用编排层的语言给整个系统命名，等于用仪表盘材质定义一辆车。

3.3 LMDeploy turbomind：一个被高估又被低估的项目

• 被高估的是「跨平台」：turbomind 只支持 NVIDIA CUDA；昇腾 / ROCm / 寒武纪 / 沐曦全部走纯 Python 的 PyTorchEngine + dlinfer。
• 被低估的是「血统纯度」：它是 FasterTransformer 的 C++/CUDA 直系分支，是目前唯一一个在国产项目中还活着的、有生产级吞吐的 C++ 服务端引擎。

端侧与边缘：C++ 唯一无可替代的战场

端侧的真瓶颈：内存带宽，不是算力

iPhone A18 约 68 GB/s，RTX 4090 约 1008 GB/s——15 倍差距。这一条直接解释了手机 4 tok/s vs 桌面 150 tok/s 的落差。

而「NPU 更快」这个叙事要打折：NPU 的价值主要在每瓦性能（功耗降 40–60%）而非峰值吞吐。骁龙 8 Gen3 上 QNN NPU 约 32 tok/s vs llama.cpp CPU 8 线程约 18 tok/s，只有 ~1.8 倍。

更要命的是 NPU 路径普遍残缺：mllm 的 QNN 后端 decode 阶段仍回落到 CPU；MNN 官方自己把 QNN 标为 B 级（支持但有 bug）；ExecuTorch 的 Qualcomm GenAI Pipeline 到 PR6 还没合完。

「NPU 跑 LLM」目前是 prefill 加速 + decode 兜底的混合态，不是全程卸载。

一条硬判据：如何筛掉一半候选

判断一个端侧库能否真跑 LLM，看三样东西：

1. 有没有 KV-cache 分配器
2. 有没有自回归 decode benchmark
3. 有没有分块量化 GEMM

ncnn 主干 2026 年才补上 kvcache allocator 与 benchncnn_llm；MNN 和 MLC 则是从设计上就为 decoder 服务。先问这一条，能筛掉一半候选。

地基层：算子、量化、后端抽象与国产芯片

6.1 后端插件化——2026 年最重要的结构性变化

四个项目在同一年做了同一件事：把硬件后端从「编译进核心」改成「运行时 / 树外装载」。

权力结构变了：接入不再需要进主干、不需要求 PR 合并，只要实现 ABI。

这对国产芯片是决定性的。反向推论是——「某芯片支持 PyTorch / ORT」这类宣称的技术门槛已大幅降低，含金量必须靠算子覆盖率和真实性能数据判断，而非「是否支持」。

6.2 算子库：护城河已上移

NVIDIA 的护城河已从「CUDA 语言」上移到「CuTe / CUTLASS 这一层抽象」。

三个信号同时出现：CUTLASS 主力转向 CuTe DSL（4.8 已在做 Rubin）、FlashAttention-4 直接用 CuTe DSL 重写、FlashInfer 用 JIT 代码生成。护城河不再是「你不会写 CUDA」，而是**「你的新指令集要能被 CuTe layout 代数描述」**。

实证：Marlin 用手写 mma，在 Hopper 上损失约 37% 峰值算力；Machete 必须用 CUTLASS 重写才能吃下 wgmma。

6.3 FP4：格式的开放 ≠ 性能的可获得

MXFP4 有 OCP 标准背书（AMD/Intel/Qualcomm 皆签名），NVFP4 是 NVIDIA 私有变体。二者元素位宽相同（E2M1），块大小与 scale 编码不同。

但真正决定性能的是有没有原生 FP4 指令：

• Blackwell sm_120：NVFP4 原生 MMQ，prefill 涨 43~68%，decode 几乎无变化（73.7 → 73.6 t/s）
• RDNA4 gfx1201：无 fp4 WMMA 指令，只能反量化回 FP16 跑 v_wmma_f32_16x16x16_f16——FP4 只有带宽收益，没有算力收益

同一份 GGUF 文件，一边是算力提升，一边只有显存收益。

6.4 国产芯片：接入了，但只接了一半

最后一公里卡在三处：

1. 分发层：PrivateUse1 只解决算子注册，PyTorch 官方教程明示集合通信与 benchmark timer 的扩展方式尚未提供。
2. 通信层：各家自建 HCCL / ENCCL / CNCL / MCCL，无统一 ABI。
3. 最尖锐的一条：llama.cpp 里只有 MUSA 与 CANN 两家有后端——国产芯片几乎全部押注 PyTorch，一旦脱离 Python 生态（端侧、嵌入式、浏览器），它们等于不存在。

圆桌：C++ 到底是在退化，还是在扩张？

正方（架构史家）：退化不可逆

判据在于：谁能定义用户写什么语言。

• 单机 C++ 训练循环每个框架都有（libtorch 有官方 C++ MNIST 示例），但 DDP 的 C++ 前端不存在——PyTorch 分布式维护者 2025-05 原话 "there is no C++ frontend for DDP"。
• 这不是「忘了写」，是「不值得写」。机制给足了，策略不给。
• 四个框架、四家公司口径一致：TensorFlow 把 tensorflow/cc 列进「不覆盖」，XLA 无 release，Paddle 官方劝退，MindSpore 只到算子级。C++ 只保证到算子这一层，这是收敛，不是巧合。
• llama.cpp 的成功恰恰因为它放弃了训练、放弃了通用性——老 finetune 被 PR #8669 删除，作者亲口劝你别用。

正方自承弱点：算子层不可替代；端侧与嵌入式是 C++ 的稳固阵地；gemma.cpp 是我的反例（但作者自己划的边界更窄）。

收一句：C++ 从「你用它写模型」退到了「你用它写别人调用的东西」。这叫退化，不叫消亡。

反方（系统工程师）：正在换路扩张

判据在于：谁掌握「硬件到人」的最后一公里。

• 2026 年四个项目同时把后端从「编译进核心」改成「运行时装载」，接入权被民主化了。对昇腾、摩尔线程这类玩家，这是从求人进门到自己开锁。
• linguist 系统性地看不见 C++：SGLang 的 sgl-kernel-npu 是 C++ 81.9%，vLLM-Ascend 是 C++ 52% > Python 43%。vLLM 的 3.4% C++，统计的是被剥离后的残骸。
• 训练侧我认输，但训练是一次性资本支出，推理是永续运营支出。在服务化部署、端侧、嵌入式、浏览器、国产化信创这五个战场，C++ 不但活着而且是唯一选项。

反方自承弱点：训练侧 C++ 是全面溃败，不是暂时落后；llama.cpp 的 finetune 是玩具，谁拿它对标 Megatron 我第一个反对；编译地狱是真实成本，把「零依赖」说成设计优越性就是撒谎。

收一句：C++ 输掉了「怎么写模型」，却正在赢下「怎么把模型交到人手上」。

吾之拍板

正方说的是「权力」，反方说的是「地盘」。二者非但不矛盾，且互为因果。

正因为 C++ 放弃了上层的策略之争，它才有余力把下层的机制做到极致。

三条总纲，可作本报告结论：

1. 训练编排层已彻底 Python 化，且不可逆。 无 DDP C++ API、llm.c 停更 14 个月、gemma.cpp 自标 research——这不是技术不可行，是收益不对称。想在 2026 年用纯 C++ 训大模型，等于徒手爬珠峰：能爬，但没理由爬。
2. 推理部署层 C++ 不但活着，且在 2026 年通过「后端插件化」获得了新的扩张动能。 关键不是后端数量，而是接入成本从「求 PR 合并」降到「实现 ABI」——这改变了生态的权力结构。
3. 判断一个库的价值，看它的 C++ 是不是「产品界面」，而非它是不是用 C++ 写的。 有稳定 ABI、有独立发版、有不装 Python 的完整路径——ONNX Runtime、OpenVINO、IREE 之所以是真 C++ 栈，全在于此。TVM 与 XLA 用 C++ 写，交付界面却在 Python。

场景化选型：十个真实场景的裁决

逐场景的坑

1 · PC 本地（RTX 4060 8GB / Mac M）：8GB 是硬边界。7–8B Q4 可全量上 GPU，14B 以上必须分层卸载，吞吐会数量级下降。llama.cpp 已迁至 ggml-org，旧路径与旧文档大面积失效。

2 · Windows 桌面内嵌：ORT 是唯一「大厂维护 + C/C++ DLL + DirectML 覆盖 N 卡/A 卡/I 卡」的组合。坑：模型得先转 ONNX，新架构（MLA、新 RoPE 变体）算子支持滞后于 llama.cpp，转不通就退备选。另 ORT 1.23 已移除 ROCm EP——不影响 Windows，但说明「EP 生命周期不稳定」。

3 · macOS 原生：llama.cpp 静态链接成 framework，无 Python、无 JIT 下载代码，审核路径最短。坑：内存峰值触发 jetsam，必须 mmap 加载 + 上下文上限控制。ExecuTorch 的 MPS 后端 2026-08 已删除，若你的选型理由是「Apple GPU 加速」，此路已断。

4 · Android：「一次编译、全机型 NPU 加速」不存在。现实打法是 CPU NEON 兜底 + 按 SoC 接厂商 SDK。坑：NPU 驱动与系统版本强耦合，Android 大版本升级经常直接断，务必留 CPU 回退路径。

5 · iOS：CoreML 的价值在 ≤3B 或 embedding/分类模型；大模型走 CoreML 会被 KV cache 动态 shape 与大权重分段折磨。坑：热节流严重，长时间生成必须限流。

6 · 浏览器：WebLLM 需要预编译的模型库，不是丢个 GGUF 就能跑。坑：首屏 shader 编译卡顿 + 浏览器 buffer 上限；iOS Safari 的 WebGPU 支持度波动，需真机回归。

7 · 集群高吞吐：continuous batching、prefix cache、PD 分离、结构化输出是 vLLM/SGLang 的核心价值，自研必输。坑：vLLM 迭代极快，跨版本 API/行为会变，锁定版本并自建回归集。

8 · 消费卡 MoE：MoE 的 expert 卸载换来的可用性与吞吐不成正比，磁盘卸载基本只用于「能跑起来」而非「能用」。坑：Q2_K/Q3_K 级量化质量损失显著，需自建业务评测集定阈值。

9 · 信创：优先级顺序是合规白名单 > 厂商 SLA > 性能 > 生态通用性。坑：CANN/驱动与框架版本是强绑定矩阵，装机即锁版本，升级需整机回归；Windows 支持普遍薄弱。

10 · 边缘/裸机：内存是唯一硬指标，4GB 设备现实上限是 1–3B Q4。坑：交叉编译 toolchain 与 -march 决定成败，无 NEON/RVV 的目标不建议立项。

什么时候不该用 C++ 栈

1. 服务端在线推理——调度、批处理、观测、扩缩容生态全在 Python 侧，C++ 省下的冷启动时间远抵不上丢掉的生态。
2. 研究与实验期——模型结构周周变，Python 改一行 vs C++ 改 kernel，迭代速度就是胜负本身。
3. 模型转换 / 量化 / 评测 / 数据管线——工具链几乎全在 Python。
4. 需要紧跟新模型架构——C++ 库支持新架构通常滞后数周至数月。
5. 团队无 C++ 工程能力——没有 ASan/TSan、没有交叉编译 CI，内存与构建成本会吃掉全部收益。

一句话判据：C++ 的收益来自部署形态（无运行时、进程内嵌、冷启动、内存可控），不来自推理速度。 速度由 kernel 与硬件决定，生态在 Python。

尽职调查清单：十项，逐项打勾

墓志铭：一张退场表

这是全景图里信息量最大的一页——它证明了「C++ 原生 DL 框架」作为一个物种，在 LLM 时代完整灭绝。

框架的生死由算力生态位决定，不由代码质量决定。

OneFlow 的分布式设计公认领先、C++ 占 57%，团队却在 2023 年被收购拆散；MindSpore 靠昇腾活着（代价是从通用框架收缩为昇腾专用栈）；Paddle 靠文心 + 9 家国产芯片 + 完整 Inference 产品线活着。纯技术优秀但无绑定的，全死了。

若从零起：2026 年做跨平台 C++ LLM 项目的正确底座

• 标准：C++17（保守）或 C++20；不上 C++23。
• 张量层：直接用 ggml（MIT）或 MNN 的算子库。绝对不要自研算子库——这是最大的坑。
• 权重格式：以 GGUF 为默认，SafeTensors / ONNX 只作导入格式。
• 后端分层：
  • CPU（NEON / AVX2 / AVX-512，走 ggml 的 SIMD 抽象）+ Vulkan —— 两条通用主线
  • Metal（Apple 必需，优于 MoltenVK 转译）与 CUDA（服务器必需）—— 平台特化插件
  • QNN / CANN 等厂商 SDK —— 一律做成可选插件，不做主路径
• 构建：CMake + vendored 子模块，全静态链接，运行时不得动态查找 Python；对外只暴露纯 C ABI，Swift/Kotlin/Rust 自行绑定。
• 不要自己做：量化算法、tokenizer、batching 调度器——这三件复用生态。
• 形态：先做库，server 能力做成可选组件；进程与并发策略交给上层语言。
• 合规前置：依赖许可证清单与国产环境白名单，在写第一行代码前定稿。

附录：未核实清单（不敢臆造，如实标注）

以下条目未找到可靠一手来源，读者若欲引用，请自行复核：

1. PowerInfer-2 未见开源仓库（只有论文 arXiv:2406.06282 与项目站）。
2. SGLang 与 vLLM 合并的传闻——官方无任何合并声明，属社区传闻。
3. SiliconLLM、FastServe、MindIE 的仓库与语言构成。
4. TACO-LLM（腾讯）无公开 GitHub 仓库，系腾讯云商业产品，应归入闭源商业引擎。
5. TensorRT-LLM 的许可证细节（GitHub API 返回 NOASSERTION 而非常见的 Apache-2.0）。
6. Marlin 与 Machete 的当前活跃仓库地址与 Star 数（Machete 仅以 vLLM csrc/quantization/machete 子目录形式存在）。
7. bitsandbytes 各后端（ROCm / Intel XPU / CPU）的成熟度分级——官方未给出统一矩阵。
8. 壁仞、天数智芯、燧原的开源仓库地址。
9. 部分中文资料称「昇腾 Triton/PyTorch 接口 100% 兼容、600+ Triton 算子全适配」「MUSA SDK 5.1.0 兼容 CUDA 12.8、3194 个 PyTorch 算子全支持」——均来自厂商大会转述的二手博客，无一手仓库或官方文档可交叉验证。
10. 「WebLLM 达到原生 GPU 80% 性能」——二手测评，未找到官方一手 benchmark。
11. MNN 官方自测「prefill 比 llama.cpp 快 8.6×、decode 快 2.3×」——厂商自测，且大概率是 CPU 路径对比，需独立复现。
12. InfiniLM / InfiniCore 的 Star 数（第一路与第三路报告数字不一致，未取得一致值）。

凡厂商自测的加速倍数，皆应视为营销数据，需独立复现。

数据说明

• 全部 Star 数、提交日期、归档状态取自 GitHub REST API 实时返回，查询日期 2026-08-31。不同探马在不同时点抓取，故个别数字存在微小出入（如 llama.cpp 记为 121,695 ~ 126,470），已在正文中以「~」标注。
• 语言占比按 GitHub languages 接口的字节数统计，非行数。
• 凡引用他人论断（如 PyTorch 维护者关于 DDP 的答复、llama.cpp 维护者关于 finetune 的表态），皆注明来源与日期。
• 本报告不做任何性能实测，所有性能数字均标注来源；无一手来源者一概列入「未核实」。

报告终。共六路侦察、三方圆桌、十场景裁决。