LLM 推理引擎怎么选——2026 年从本地单机到 PD 分离的全景选型地图

Sun, 19 Jul 2026 00:00:00 +0000

阿里云 CAP 有一篇讲推理引擎选型的文章，把候选收敛到四个：Ollama、vLLM、SGLang、Hugging Face Pipeline。这个划分在 2024 年是够用的。

但到 2026 年，它至少漏掉了半张地图——NVIDIA 的 TensorRT-LLM 完成了「PyTorch 化」转身、SGLang 因为首个开源复现 DeepSeek 大规模部署而封神、Hugging Face 自己给 TGI 挂上了「维护模式」横幅并劝你改用 vLLM，而整个 2025 年推理引擎领域真正的主线，其实是一个字：拆。

这篇文章把这张地图更新到 2026 年年中。它不替你拍板选哪个产品——它给你一套分层框架、一张决策矩阵和一棵决策树，让你自己把候选收敛到 1–2 个。

为什么 2026 年「选推理引擎」才是个真问题
#

三年前不需要纠结这个。那时候能把一个 7B 模型在 GPU 上跑起来、返回还算流畅的 token 流，就已经过关。

现在情况变了，原因有三个：

模型能力在趋同，部署形态在分化。 开源侧从 Llama、Qwen 到 DeepSeek-V3/R1、Kimi K2，能力差距在缩小；真正拉开差距的，变成了「你能不能把它高效、低成本、稳定地跑起来」。同一个 DeepSeek-R1，有人一张 4090 勉强跑起来做原型，有人用 96 张 H100 做到接近官方吞吐、成本压到官方 API 的五分之一——差的就是推理引擎和部署架构。
大规模 MoE 把推理从「单卡工程」推成了「分布式系统工程」。 DeepSeek-V3 是 671B 总参 / 37B 激活，Kimi K2 更是 1T 总参。这类模型单机放不下，必须跨节点做专家并行（EP），推理引擎的选择直接决定了你要不要碰 all-to-all 通信、专家负载均衡这些硬骨头。
同一个模型，引擎之间的吞吐/成本差异可以到数倍。 这不是「快一点点」的差别，是「同样的卡，能不能多服务几倍用户」的差别，直接写进云账单。

所以选型不再是「随便挑一个能跑的」，而是先想清楚你在地图的哪一层。

大模型为什么记不住你——Cursor / Claude Code / Codex 记忆机制全拆解

Mon, 04 May 2026 00:00:00 +0000

Cursor 有 Rules + Memories，Claude Code 有 CLAUDE.md + MEMORY.md，Codex 有 AGENTS.md + Memories——这些 Agent 工具都有各自的"记忆"系统。但没有一个真的修改了模型权重——所有"记忆"本质都是把结构化文本塞回 system prompt。这篇调研用 67+ 条一手资料交叉验证了这个结论，从架构约束到产品实现，彻底拆解 Agent 记忆系统的真相。

为什么这个问题值得花 67 条资料去研究
#

因为每个做 Agent 的人都会撞到这堵墙：

Cursor、Claude Code、Codex 都有"记忆"功能，但它们到底是怎么实现的？
为什么我让 AI 记住用户偏好，它过 10 轮就忘了？
为什么 Prompt Caching 不能替代 Memory？
Mem0、Zep、Letta、LangGraph Store——到底选哪个？

答案在 Anthropic / OpenAI / Google 的官方文档、Karpathy 的公开访谈、以及 arXiv 论文里——但分散在 67 个不同的地方。这篇调研把它们串起来了。

一句话结论
#

所谓「大模型没有记忆」不是疏忽，而是 Transformer O(n²) 注意力 + KV cache 显存 + 权重纠缠（灾难性遗忘）+ GDPR 合规 四重约束的均衡解。Cursor / Claude Code / Codex 等 Agent 工具的 “Memory” 本质都是把结构化文本塞回 system prompt，模型权重永远不动。Prompt Caching 只是性能优化，不是记忆。未来 1–3 年的主流是 「无状态 LLM 内核 + 有状态 Agent 记忆层」 混合架构。

深度调研 on 卓琪的开发笔记

LLM 推理引擎怎么选——2026 年从本地单机到 PD 分离的全景选型地图

为什么 2026 年「选推理引擎」才是个真问题 #

大模型为什么记不住你——Cursor / Claude Code / Codex 记忆机制全拆解

为什么这个问题值得花 67 条资料去研究 #

一句话结论 #

为什么 2026 年「选推理引擎」才是个真问题
#

为什么这个问题值得花 67 条资料去研究
#

一句话结论
#