工程应用视角：从云端 API 到本地部署

这一篇从工程的角度看 Transformer/大模型：如果你是前端/全栈/平台同学，如何把它们接进系统里，从云端 API 到本地推理，再到监控和治理。

大多数人在项目里用大模型，最开始都是通过云端 API：

  • HTTP / WebSocket 调用：传 prompt，收结果；
  • 计费按 token / 时长 / QPS 限制；
  • 平台负责模型训练、部署、扩缩容和监控。

这种方式的特点是：

  • 非常适合作为“快速验证 + 先跑起来”的方案；
  • 对前后端都是“黑盒调用”，只关注协议和上下游数据结构；
  • 不方便做强定制（特殊安全策略、本地敏感数据、极端低延迟等）。

从工程实践上说，云端 API 接入时比较重要的是：

  • 做好重试与幂等：网络抖动、限流时不要直接把错误抛给用户；
  • 限制单请求长度：避免一次把海量上下文全塞进去，成本和延迟都很夸张；
  • 在业务侧加超时和降级路径：模型慢/挂了时系统还能给出一个“保底结果”。

混合架构：在线 API + 离线 / 预计算

很多系统会把“大部分逻辑”留在传统服务里，把大模型用于：

  • 生成建议方案/候选结果；
  • 做排序/打分（re-rank）；
  • 处理用户自由输入的复杂请求。

惯用的架构模式包括：

  • 检索 + 大模型：

    • 先用向量检索/全文检索找一批候选文档；
    • 再把候选 + 用户问题交给大模型摘要/回答。

  • 预计算 + 在线调用：

    • 离线用大模型为大量对象生成 embedding、标签、描述等；
    • 在线只在必要时做一次补充生成或问答。

这类架构的好处是：

  • 把“重的部分”尽量前置或离线化，降低在线调用频次；
  • 让系统更容易控成本和稳定性。

考虑自建/本地部署时，通常会有几个动机：

  • 数据安全：不希望数据出公司网络/内网；
  • 延迟要求极高：例如在端侧/边缘设备上做即时响应；
  • 成本可控：高并发、大流量时，自建可能比按调用计费更划算。

本地推理的常见技术路径有：

  • 使用 ONNX / TensorRT / MLC 等推理引擎，把模型转换成适合各平台的格式；
  • 使用像 ggml / llama.cpp 这类支持 CPU / GPU / 移动端的轻量推理库；
  • 对模型做剪枝、量化，减小内存占用和算力需求。

挑战在于：

  • 环境配置和依赖管理比直接调云端 API 复杂得多；
  • 需要自己关注模型更新、AB 实验、回滚策略等。

对于前端/客户端工程师来说，接触 Transformer 的方式有几种：

  • 直接调用后端的模型 API，前端只负责 prompt 设计和结果渲染；
  • 使用浏览器端/移动端推理库，在本地跑小模型（例如文档摘要、简单分类）；
  • 在桌面应用/插件里嵌入本地推理引擎（如 VS Code 插件里的补全模型）。

需要特别注意的是：

  • 前端环境的算力和内存普遍有限，模型大小要非常克制；
  • 交互设计上要把“模型延迟”当成一等公民，给用户足够的反馈（加载动画、分阶段结果等）；
  • 对隐私敏感数据的处理要明确边界，不要“顺手就发云端”。

一旦模型被接入真实业务，必须有一套可观测性和评估机制：

  • 基础指标：QPS、平均/尾延迟、错误率、超时数；
  • 业务指标：转化率、点击率、任务完成率、工单处理效率等；
  • 质量评估：定期抽样人工审核，或用辅助模型/规则做自动筛查。

对于生成类结果，还需要考虑：

  • 结果可控性：是否遵守业务规则、是否会生成敏感/违规内容；
  • 版本回滚：新模型/新 prompt 表现不佳时能否快速切回旧版本；
  • 日志与追踪：出问题时能够复现请求和模型的内部状态（在合规前提下）。

在工程视角下，大模型只是一个强大的组件，它依然需要被：

  • 放在合理的权限边界内（只能访问必要的数据和接口）；
  • 通过策略和规则限制其“能做什么、不能做什么”；
  • 和传统的认证/鉴权/风控系统一起协同工作。

一个常见的做法是：

  • 把模型封装在一个“受控的服务”里，对外只暴露有限的 API；
  • 所有请求都先经过网关/风控层，再转到模型服务；
  • 对模型输出再做一次规则/策略过滤，避免直接把原始结果暴露给用户。

从这个角度看，Transformer 大模型更像是一个“可编程的智能模块”，需要和现有的系统架构一起设计，而不是简单地“把结果贴上去”。