阻碍落地的并非技术

把大模型接入现有系统，技术并不复杂：配置服务地址与密钥后，SDK 调用代码基本无需改动。真正阻碍落地的，往往是预算部门询问「这个月要花多少」时，技术团队拿不出可供签字的数字。

这正是企业与个人开发者的区别。个人可以「先跑起来，花多少算多少」，企业的开销结构却必须可预估、可归因且有上限。因此，第一行调用代码动笔前就要算清成本模型，后续接入才有意义。

一、把成本写成公式

大模型 API 的计费依据是 token，而非请求次数。最常见的预算错误，是根据「每天多少次调用」估算，最终与实际账单相差好几倍。正确方式是拆解每次调用：

单次成本 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价
月度成本 = 单次成本 × 日均调用量 × 30

三个变量都必须取自真实数据，不能凭感觉估计：

• 输入 token：企业场景的输入通常远大于个人场景。带上系统提示词、检索到的文档片段、多轮历史，一次「简单问答」的输入常常是几千 token。
• 输出 token：受 max_tokens 约束，是唯一可以直接限定上限的变量。
• 日均调用量：内部工具类依据「人数 × 人均日使用次数」估算，客服类则依据工单量估算。

举个内部知识库助手的例子：系统提示 500 token + 检索片段 2500 token + 历史 1000 token = 4000 输入 token，输出限制 500 token。200 人每天各用 10 次，就是一天 2000 次调用、800 万输入 token。这个量级和「200 人偶尔问几句」的直觉差得很远，但它才是应该写进预算表的数字。

二、选择按量计费还是预付额度

量级计算出来后，选择付费方式便有了依据。

按量计费适用于验证阶段：调用量尚不确定，实际用多少就扣多少，不会产生沉没成本；代价是财务难以排期，月度账单会波动，还需每月对账。

预付额度（许多平台称为资源包）针对三个企业特有问题：一次走完预算审批，无需每月重复申请；统一采购口径，以一份合同覆盖多个项目；通过额度封顶，自然限制失控风险。

判断标准可以直接量化：实际用量连续两三个月的波动保持在 30% 以内，说明已进入可预估区间，改用预付比按量更省心；若仍大幅波动，就继续按量，不要急于锁定。

三、接入时把 usage 写入日志

接入本身是最简单的一步。工程实施中必须把服务地址和密钥提取为配置，不能写死，下面以jiekou.vip为例：

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["LLM_API_KEY"],
    base_url=os.environ["https://api.highwayapi.ai/openai"],
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "你好"}],
    max_tokens=500,
)
print(resp.usage)

其中有个细节需要单独说明：resp.usage 是成本治理的起点。它会返回本次调用实际消耗的输入与输出 token。只有把这些数据写入日志，第一节的估算公式才能根据实测结果校准。很多团队接入时仅打印 content、却把 usage 丢弃，直到月底账单超支，才发现没有留下任何可用于复盘的数据。

排错时常见的几个返回码中，404 应先核对服务地址尾部是否多写或漏写了 /v1（不同 SDK 的路径拼接方式并不相同，最快的方法是确认最终请求的完整 URL）；401 通常表示密钥未携带或填写错误；429 表示触发频率限制，应降低并发后重试。

四、接入第一天就按项目拆分密钥

只知道「花了多少」并不够，还要明确「谁花的」。实现成本很低：接入时分别按项目和环境申请独立密钥，用量便会自然分开统计：

• 每条业务线使用一把，用量和成本可直接对应到部门。
• 测试与生产分别使用，防止压测流量混入生产账单。
• 某把密钥泄露或项目下线时，可单独吊销，不会影响其他线。

第一天实施几乎没有成本；等十几个服务共用一把后再拆，就必须逐个修改配置并重新发布。

小结

企业接入大模型 API，应遵循「先算账、再选付费方式、最后写代码」的顺序：通过 token 公式估算真实量级，依据用量稳定程度在按量与预付之间选择；接入时把地址和密钥提取为配置，并把 usage 写入日志，再按项目拆分密钥。技术接入只有几行代码，真正的前提是把成本转化成可预估、可归因的数字。