开源权重的大语言模型改变了工程团队对 AI 基础设施的思考方式。与提供商控制硬件、模型权重和发布计划的闭源 API 不同，开源权重模型将这些决策权交还给了你。你可以选择模型的运行位置、如何进行微调，以及何时（如果需要的话）更新到新的检查点。这种所有权是非常强大的，但也意味着集成工作将完全落在你的肩上。

如果你之前使用的是像 OpenAI 的 GPT-4 或 Anthropic 的 Claude 这样的托管 API，好消息是许多开源权重托管提供商和推理引擎现在都遵循相同的规范：HTTP POST、JSON payload 和 bearer token 身份验证。其机制看起来很熟悉，但细节变得更加重要，因为你（而不是提供商）需要负责可靠性、成本控制和行为塑造。

API 调用的基础知识

其核心是一个 POST 请求。你通过 Authorization header 中的标准 bearer token 进行身份验证。请求体是一个 JSON 对象，其中最重要的字段是 messages 数组。该数组遵循熟悉的聊天格式：交替出现 system、user 和 assistant 角色。

以下是实际应用中一个最小化请求结构的示例：

  • 将 Authorization header 设置为 Bearer <your-token>。
  • 发送包含至少一个 model 标识符和 messages 列表的 JSON payload。
  • 如果你想要确定性或创造性的控制，请包含 max_tokens 和 temperature。

响应会返回一个 choices 数组和一个 usage 对象。不要忽略 usage 块。它包含 prompt_tokens、completion_tokens 以及总计。如果你是自托管，这是判断特定用户交互是否昂贵的信号。如果你是向第三方推理提供商付费，这就是你的计费数据。无论哪种情况，从第一天起就要记录它。

流式传输及其必要性

没有人喜欢在出现第一个文本块之前盯着加载图标看三秒钟。流式传输解决了这个问题。服务器不再等待模型完成整个生成过程，而是在生成 token 时就将其发出。你的客户端接收 Server-Sent Events 或分块 HTTP 响应，并可以在单词到达时立即渲染。

通过在 JSON payload 中设置 stream: true 标志来启用流式传输。在客户端，你通常需要逐行解析流，并寻找 data: 前缀。如果连接在中途断开，请准备好重新连接或回退到非流式的重试。聊天应用的感知延迟会大幅降低，用户会觉得系统是在与他们共同思考，而不是在批量处理他们的请求。

用于现实工作流的函数调用 (Function Calling)

仅返回纯文本的模型很有用，但能够调用工具的模型要有用得多。函数调用允许你定义一个描述可用操作（例如 search_orders 或 update_profile）的 JSON schema，然后由模型决定何时使用它们。模型不会向用户提出后续问题，而是会发出一个带有从对话中提取的参数的结构化函数调用。

例如，如果用户问“我最后一笔订单是什么？”，你的 schema 可能会定义一个带有 limit 参数的 get_recent_orders 函数。模型返回一个工具调用，你的后端针对数据库执行查询，然后你将结果作为函数响应消息反馈给模型。随后，模型会合成一个自然语言回答。

要实现这一点：

  • 在 payload 中提供 tools 或 functions 数组。
  • 使用 name、description 和 parameters schema 定义每个工具。
  • 检查响应中的工具调用完成原因 (tool-calls finish reason) 或类似的信号。
  • 在后端执行函数并进行严格验证。永远不要信任未经清洗的模型原始输出直接操作你的数据库。
  • 将函数结果追加到消息历史记录中，并发送后续请求，以便模型生成最终回复。

这种模式弥合了生成式文本与确定性系统之间的鸿沟。你的 AI 可以读取日历、查询 API 或触发 webhooks，而无需你硬编码每一个分支。

生产环境加固

在生产环境中运行开源权重模型会让你面临与任何分布式系统相同的故障模式，此外还有一些独特的模式。模型推理是计算密集型的，端点可能会在负载下崩溃。以下是保持应用程序稳定的方法。

错误与重试

  • 429 Too Many Requests：这是一个速率限制信号。请实现带有抖动（jitter）的指数退避（exponential backoff）机制。从较短的延迟开始，在重复出现 429 时将延迟翻倍，并将其上限设定在几秒钟内，以免过度冲击服务器。
  • 5xx Server Errors：这些错误通常是暂时的，特别是当你将请求路由到 GPU 工作节点池时。可以重试，但要为尝试次数设置硬上限——三次是一个常见的默认值。
  • 4xx Client Errors：不要盲目重试。400 表示你的有效负载（payload）格式错误，401 表示你的 Token 错误，404 表示该端点上不存在该模型 ID。应该修复请求，而不是陷入循环。

超时与挂起的进程

当队列积压或工作节点在生成过程中崩溃时，推理可能会出现延迟。务必设置请求超时。如果你的 HTTP 客户端默认设置为无限期，请将其更改。对于标准的补全（completions），一个合理的起点是 30 到 60 秒，健康检查则应更短。如果触发了超时，请将其视为失败，进行记录，并决定是向用户显示优雅的错误提示，还是在备用模型上进行重试。

预算控制

Token 数量直接转化为金钱或 GPU 时长。请记录每次请求的 Prompt 和 Completion Token 数量。按用户、按功能和按模型版本进行追踪。开源权重模型（Open-weight models）允许你更换检查点（checkpoints），但每个检查点都有其自身的成本结构和上下文窗口大小。如果没有日志，你将无法知道产品的哪个部分正在消耗过多的计算资源。

通过系统消息塑造行为

系统消息（System message）是你的第一道控制线。利用它来设定基调、强制执行约束，并注入每个用户对话都应遵循的静态上下文。由于开源权重模型的表现会因其微调（fine-tuning）和系统提示词的不同而有所差异，请将此字段视为一个可以进行 A/B 测试的变量。模糊的系统提示词会产生模糊的回答。精确的提示词能让模型保持在轨道上——例如，告诉助手它只处理账单和退货，并应礼貌地拒绝其他所有请求。

基础设施自由与数据主权

开源权重模型最隐形的优势之一是掌控权。你的 Prompt 和 Completion 无需离开你的环境。如果你在本地或虚拟私有云（VPC）中运行模型，就可以免除第三方数据处理协议，并减少受到训练数据争议的影响。这对于医疗、金融以及任何数据泄露即构成合规事件的领域都至关重要。

即使你使用外部推理主机，开源权重也赋予了你可移植性。如果主机更改了定价或条款，你可以将相同的模型文件迁移到另一个提供商，或者将其转为内部运行。你不会被锁定在单一的 API 上，因为只有一家公司掌握着权重。

实践起步指南

如果你今天就要进行集成，请从单个模型和单个端点开始。将你的 HTTP 客户端封装在一个小的抽象层中，用于处理身份验证、重试和 Token 日志记录。接下来添加流式传输（streaming），因为用户体验的提升是立竿见影的。然后，为高价值的工作流引入一个函数调用（function call）——如状态查询、内容审核或表单填写。在扩大推广范围之前，先监控一周的延迟、错误率和 Token 消耗。

开源权重模型比全托管 API 需要更多的设置，但它们会以透明度、灵活性和控制权来回报你的努力。仔细构建集成，对一切进行监测，你将拥有一个完全符合应用程序需求的 AI 层。

Sources and further reading