自从 ChatGPT 问世以后，LLM 相关技术对人工智能技术领域形成了冲击性的影响，许多围绕 LLM 的技术架构的发展也一直在如火如荼的展开，比如 RAG 和 AI-Agent，以及时下比较火爆的 Model Context Protocol (MCP)[1]。在展开之前结合行业现实，笔者认为解释清楚 LLM Inference（LLM 推理）和 LLM Serving（LLM 服务）的概念是十分必要的。
事实上，由于行业的快速发展，许多概念和知识点一直在业界混淆不清，比如对于 LLM Inference 和 LLM Serving 两个概念我相信不少人都是相当不清晰的。笔者认为造成这些问题的主要原因之一是在 LLM 的工程实践过程中将其所负责的功能范畴相互交错导致的。简单来说，为了满足业务需求很多 LLM 相关的技术框架不得已将 LLM Inference 和 LLM Serving 的功能集合都实现成在一起，导致功能集合的边界模糊不清。因此，除了从 Inference 和 LLM Serving 的角度去谈 MCP 的发展，解释清楚此两者的概念范畴同样也是本文的主要目的之一。
准确来说 Service Inference 和 Model Serving 不是什么新的概念，而是在传统机器学习时代就已经形成的共识。只不过由于 LLM 的划时代创新和流行普及，行业里才出现了 LLM Inference 和 LLM Serving 这样的术语。需要说明的是虽然 LLM Inference 和 LLM Serving 是 LLM 技术中两个密切相关的术语，但是它们却在大语言模型的部署和使用上有各自的侧重点。笔者将两者的内涵和区别列举如下：
-
定义：指运行经过训练的 LLM，以根据用户给定的输入（例如，用户提示或查询）生成预测或输出（包括文本，语音，图片或视频等）的过程。 -
责任范围：专注于模型本身的执行（这里指模型的运行时状态，包括预测过程）。 -
场景示例：比如向 GPT 等 LLM 提供提示并接收响应是一项推理任务。其中 vLLM[2] 是典型的 LLM Inference 实现框架。
主要特点：
-
计算密集型，通常需要专用硬件（例如 GPU 或 TPU）。 -
优化可以采用量化或蒸馏等技术来降低延迟和计算成本。 -
直接关注模型的运行时行为。 LLM Serving 主要特点：
-
通常包含 API 接入层、负载均衡、自动扩缩容、服务监控和日志记录。 -
支持多租户、速率限制和故障转移等高级特性。 -
针对高可用性、可扩展性和用户体验等系统实现集成并进行优化。 -
定义：指支持用户或应用程序能够大规模地访问 LLM Inference 的基础设施和软件系统。 -
责任范围：主要是指支持 LLM Inference 的端到端的服务流程，包括但不限于请求接入处理、请求路由处理、流量管理和模型管理等。 -
场景示例：譬如支持 vLLM[2] 的 Kserve[3] 框架，可以便捷和高效地为多个用户或应用程序提供 LLM 推理预测服务。
从上面的对比我们可以看出来 LLM Inference 的关注点在模型的执行本身，譬如模型的内存管理和算力资源的分配，如上面列举到的 vLLM，它通过借鉴操作系统中虚拟内存和内存分页管理的理念，实现了 LLM 服务推理中内存使用的优化方案，并解决了大模型加载和运行时许多内存使用的问题。而 LLM Serving 则是更多的面向用户和客户端，通过 IT 工程实践去解决使用大语言模型的问题。以上面的 Kserve 为例，在技术层面提供了模型服务的扩缩容能力，并支持同系列模型不同版本（譬如 ChatGPT3 和 4，Llama2 和 Llama3）的服务（模型的路由服务）。Kserve 也通过提供标准化的数据平面协议和自身的 ServingRuntime 等概念来支持不同的机器学习框架训练出来的模型，以此来提供一致的服务推理体验。
笔者列举上述技术框架的原因并不是为了打广告，而是通过实际的技术案例来强调说明 LLM Inference 和 LLM Serving 的差别。同时，细心的读者应该关注到，LLM Serving 一般来说是需要集成特定 LLM Inference 的能力的。但是绝不能就此武断的说：LLM Serving 包含了 LLM Inference。也就是说，两者并不是简单的包含与被包含的关系。打个比方，不能因为一个 Web 应用开发框架集成了关系数据库的能力，就说这个开发框架包含了关系数据库。
为了说明清楚这个问题，不得不再以此说明一下 MCP 的概念，为了简单起见，笔者将 MCP 官网的定义直接放在了下面：
MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools.
通过 MCP 官网的定义看来，MCP 更像一个桥梁，用来连接 AI 模型（当然包括大语言模型）和不同的数据源与工具（读者觉得这里的 tools 可能含义很宽泛，可以包括上文提到的 AI applications，可以是 function calling，也可以是 AI-Agent，甚至可以是包含外部知识库和提示词工程的应用等等）。那么对比上面 LLM Inference 和 LLM Serving 的概念，其实是很难做出一个确定的划分的。
再来看看 MCP 的架构：
图片来源于：MCP Architecture
从上图展示的情况来看，MCP Server 承担的角色更像是 LLM Serving 的角色，而从它面向 Host（可以想象成是用户端）的 MCP Client 来看也印证了这个想法。然而，事情到这并不算结束，因为 MCP 的引入主要是为了实现 AI 模型和不同数据源和工具的标准化接入。可以考虑如下的场景（包括不仅限于）：
-
连接提示词工程优化的 function calling 或者工具，使得服务推理更加精准有效。 -
连接外部知识库，使得 LLM 能够得出更专业和有价值的反馈。 -
连接外部智能体来实现复杂的任务和工作流 -
……
从上面的场景上来看，MCP 的引入可以优化 LLM 的服务推理过程，提升 LLM 的运行时行为的准确度和针对性，同时也增强了 LLM 与外界的交互体验。而这些点又正好是 LLM Inference 所关注的地方。综上分析可以明显的看到，MCP 实际上对于 LLM Inference 和 LLM Serving 的功能范围都是有所涉及的。虽然 MCP 并不是完整的功能点覆盖，而是一个 Inference 和 Serving 的简单复合体，但是很难将其归类于 LLM Inference 和 LLM Serving 的任何一边。做出这样的分析，其目的当然是为了更好的评估和理解未来 MCP 的发展方向。
根据上一小节的分析可以知道，MCP 作为一个连接 LLM 和 AI 应用的桥梁，它是 LLM Inference 和 LLM Serving 的简单复合体，它未来是还有很多事情需要去做的。这些事情不仅仅是功能点的覆盖，比如“桥梁链接”之间的鉴权和认证策略的增强，大规模用户使用场景时的路由负载均衡，流量管理，以及基础设施服务建设等等，读者觉得更重要的是对 LLM Inference 和 LLM Serving 的功能范围的明确划分，将 LLM Inference 划分为 MCP 的 Backend Service，而将 LLM Serving 划分为 MCP 的 Frontend Service。经过这样的分离，MCP 的 Backend Service 部分可以重点关注模型自身的运行时优化，而 MCP 的 Frontend Service 则可以聚焦于工程技术的优化，以更好的实现其与用户之间的桥梁作用，两个部分分别独立的发展演进，引入前沿的技术成果且互不影响。
当然，以上分析和预测纯属于笔者自己的一些思考和感想，并不代表技术社区的既定发展方向，仅用于与读者分享看法和共同探讨。
张怀龙，曾就职于阿尔卡特朗讯、百度、IBM、英特尔等知名公司担任高级开发职位，拥有 16 年技术研发经验，专注于云原生微服务技术，并在云原生与 LLM 技术的交叉领域进行创新实践，如致力于云原生场景下的 LLM 服务推理， 曾工作在 Istio，OpenVINO、Kserve 和 OPEA（企业 AI 开放平台）等技术社区。作者也曾在 KubeCon、ServiceMeshCon、IstioCon、GOTC、GOSIM 和 InfoQ/Qcon 等会议上发表技术演讲。
参考文档：
https://modelcontextprotocol.io/introduction
https://docs.vllm.ai/en/latest/
https://kserve.github.io/website/latest/
AICon 2025 强势来袭，5 月上海站、6 月北京站，双城联动，全览 AI 技术前沿和行业落地。大会聚焦技术与应用深度融合，汇聚 AI Agent、多模态、场景应用、大模型架构创新、智能数据基建、AI 产品设计和出海策略等话题。即刻扫码购票，一同探索 AI 应用边界！！
今日荐文
微软再次裁员：18 年老员工、10 倍 TypeScript 性能提升幕后功臣也一并优化了
氛围编程成新晋顶流，腾讯也出手了！代码助手 CodeBuddy 重磅升级，网友实测：真香
3200+ Cursor 用户被恶意“劫持”！贪图“便宜API”却惨遭收割， AI 开发者们要小心了
拜拜，昂贵的谷歌搜索 API！阿里开源 RL 框架让大模型自给自足、成本直降88%，网友：游戏规则变了
Mistral 拿出杀手锏叫阵 DeepSeek！性价比卷出天际、开源模型却断供，社区粉丝失望透顶
你也「在看」吗？👇
（文：AI前线）