推理服务（Inference）

约 1643 字大约 5 分钟

2026-05-12

训练决定模型学到了什么，推理决定模型在真实产品里如何响应用户。对 builder 来说，Inference 不是一个云服务按钮，而是延迟、成本、上下文、稳定性和部署边界的综合选择。

为什么要学这个

很多 AI 应用的第一个 demo 都是直接调用模型 API。但产品一旦进入真实用户、真实流量和真实任务，问题会立刻变具体：响应太慢怎么办，成本怎么控制，模型换了会不会破坏输出，隐私数据能不能送到第三方 API，本地模型够不够用，服务崩了怎么降级。

Inference 这一层决定了模型能力如何被产品消费。它连接上游的模型、prompt、RAG、Agent，也连接下游的接口、队列、缓存、监控和用户体验。

模型能力只有被稳定、可控、可观测地调用，才算进入了产品系统。

推理服务的核心不是“跑出答案”，而是在约束条件下交付可用答案。

同一个模型，在 API、GPU 服务、本地量化模型和边缘设备上的表现会完全不同。你选择的不是单一模型，而是一套延迟、成本、质量、隐私和运维复杂度之间的平衡。

难度：初级。 先理解托管模型 API 的调用方式、参数、限制和成本结构。

API Model 指通过云端服务调用模型，例如把输入发送给模型提供方，再接收文本、结构化输出、工具调用结果或多模态结果。它的优势是上手快、模型更新快、基础设施负担低。

但 API 不等于“没有工程问题”。你仍然要处理速率限制、超时、重试、日志脱敏、账单控制、版本变更和输出回归。尤其是 Agent 场景，一次用户请求可能触发多轮模型调用，成本和延迟会被放大。

难度：中级。 你需要理解本地运行模型为什么更可控，也为什么更吃硬件、部署和调参能力。

Local Model 是在自己的设备、服务器或私有环境中运行模型。它适合隐私要求高、成本敏感、需要离线运行或需要深度定制的场景。

本地模型的限制也很直接：模型权重、显存、上下文窗口、并发能力、量化方式、推理框架都会影响效果。对很多团队来说，本地模型不是替代所有 API，而是承担特定任务：分类、抽取、代码补全、轻量 Agent、隐私数据处理或 fallback。

难度：中级。 量化要在模型体积、推理速度和输出质量之间做取舍，不能只看“能不能跑起来”。

Quantization 是把模型权重或计算精度降低，例如从 FP16 降到 INT8、INT4，用更少显存和计算资源运行模型。它让个人电脑、小 GPU 或边缘设备运行大模型成为可能。

问题在于，量化可能降低输出质量，尤其是长推理、代码生成、多语言、数学和工具调用场景。判断量化模型是否可用，不应该只靠主观聊天体验，而要用你自己的任务样本测试。

难度：高级。 Serving 关注的是把模型变成稳定服务：并发、队列、流式输出、缓存、监控、失败处理和版本管理。

Serving 是把模型部署成可被应用调用的服务。它通常涉及模型加载、请求队列、批处理、GPU 利用率、token streaming、日志、指标、健康检查和扩缩容。

一个成熟的推理服务至少要回答：

Serving 做不好，模型越强，线上问题越难排查。

AI x Web3 项目经常需要把链上数据、用户意图、合约接口和风险提示送进模型。Inference 这一层会直接影响用户能否安全地等待结果、是否愿意支付成本、以及 Agent 是否能在合理时间内完成链上前置判断。

如果模型要参与交易解释、合约分析、策略建议或 Agent 执行，推理服务必须留下可审计记录：用了哪个模型、输入来自哪里、输出是什么、是否触发工具、失败时如何处理。链上动作不可逆，推理层就不能像普通聊天一样随意。

做一个最小推理对比：

重点不是证明哪个模型最好，而是学会把模型选择放进真实约束里。