1. 这场“用脚投票”到底在发生什么最近跟几个在北美做基础设施的朋友聊天话题绕来绕去总会落到同一个点上API 账单。有个做 AI 客服 SaaS 的哥们给我看了他们上个月的用量报表光是推理调用这一项就吃掉了整个毛利的三成多。他说了句挺扎心的话——“我们不是在给客户做产品是在给模型厂商打工。”这话听着夸张但放在 2024 到 2025 年这个节点上一点都不离谱。OpenAI的旗舰模型定价虽然一直在往下调可对于真正跑量、跑长上下文、跑高频 Agent 调用的团队来说Token成本依然是压在头顶的一座山。于是你能看到一个很明显的转向越来越多美国本土的工程团队开始把目光投向开源模型尤其是来自中国的DeepSeek、智谱这一批。标题里说“中国成最大赢家”我不太喜欢这种宏大叙事但如果你把视角放到开发者社区里会发现一个更朴素的事实开源模型正在吃掉原本属于闭源 API 的那部分“性价比敏感型”市场。这不是谁打败谁而是市场分层了——愿意为极致效果付溢价的继续用闭源愿意为成本和控制权折腾的转向开源。这篇文章我想聊的不是新闻而是一个工程师在面对“API 太贵”这个问题时实际会怎么想、怎么选、怎么落地。我会把选型逻辑、部署路径、Token 成本核算、常见坑都拆开讲。适合谁看适合正在被 API 账单折磨的后端、算法、独立开发者也适合想搞清楚“开源模型到底能不能用”的技术决策者。哪怕你只是刚听说 DeepSeek 和智谱看完也能知道第一步该干嘛。2. 为什么“贵”这件事逼着大家重新算账2.1 先把 Token 成本这笔账算清楚很多人对 Token 成本是没有体感的因为 API 是按量计费月底出账单才知道疼。我习惯用一个简单的模型来估算你可以直接套。假设你做一个中等规模的 AI 应用日活 5000 人每人每天平均发起 8 次请求每次请求输入 1500 Token、输出 500 Token。那么日输入 Token5000 × 8 × 1500 6000 万日输出 Token5000 × 8 × 500 2000 万按闭源旗舰模型一个比较典型的价位输入约 $2.5/百万 Token输出约 $10/百万 Token来算输入成本60 × 2.5 $150/天输出成本20 × 10 $200/天合计约 $350/天一个月就是 $10500这还只是一个中等规模应用。如果你的场景是长文档处理、代码 Agent、多轮对话输入 Token 会轻松翻好几倍。Prompt Token的膨胀是隐形的杀手尤其是那种把整个知识库塞进上下文的做法账单会教你做人。而开源模型的自托管方案成本结构完全不同你付的是 GPU 租赁或折旧、电费、运维人力边际成本随并发上升而摊薄。当日请求量跨过某个临界点后自托管的单位成本会明显低于按量付费。这个临界点在哪取决于你的模型大小和硬件价格后面我会给一个粗略的估算方法。2.2 闭源 API 的“隐性成本”比账单更烦人钱只是明面上的。真正让工程团队头疼的是闭源 API 带来的一堆约束速率限制高峰期被限流用户体验直接崩你还不能怪谁。数据出境与合规很多企业客户明确要求数据不出自己的边界闭源 API 天然做不到。版本漂移模型悄悄更新你的 Prompt 效果一夜之间变了排查起来极其痛苦。不可定制想微调想加领域知识基本没门只能靠 Prompt 硬凑。我见过一个团队因为上游模型某次静默更新导致他们的结构化输出解析大面积失败整整花了两天定位。这种“你无法控制的东西在变”的焦虑是推动大家转向开源的核心动力之一。开源模型给你的最大礼物不是免费而是确定性——权重在你手里版本你说了算。2.3 开源模型这一波到底强在哪两三年前说“开源模型能用”很多人会笑。但 DeepSeek、智谱 GLM 这一批出来之后情况变了。它们在很多任务上已经能打平甚至超过上一代闭源模型尤其在中文理解、代码生成、结构化输出这些场景。更关键的是生态成熟度上来了。以前部署一个开源模型要折腾半天现在 vLLM、SGLang 这些推理框架把吞吐和显存优化做得很好量化方案也丰富一张消费级显卡就能跑起来一个能用的模型。DeepSeek的本地部署方案在社区里被反复验证智谱也提供了灵活的 API 和自托管选项这对预算有限但又想用上强模型的团队来说是实打实的利好。3. 选型这件事别只看榜单3.1 闭源、开源 API、自托管三条路怎么选我把常见的选择整理成一张表你可以对照自己的情况方案类型典型代表成本结构数据控制运维负担适合场景闭源 APIOpenAI 旗舰按 Token 付费数据出境几乎为零快速验证、效果优先开源模型 API智谱 API、DeepSeek API按 Token 付费单价更低部分可控低成本敏感、要中文能力自托管vLLM 部署 DeepSeek硬件运维固定成本完全可控高高频调用、数据敏感我的建议是分阶段走早期用 API 快速验证产品等调用量稳定、成本曲线清晰之后再把高频、稳定的那部分流量迁到自托管。不要一上来就自建那是给自己找罪受。3.2 一个可落地的成本临界点估算自托管划不划算核心看一个数你的日 Token 消耗量。假设你租一张 A100约 $2/小时一个月约 $1440用 vLLM 部署一个 7B 到 14B 级别的模型在合理批处理下吞吐大概能做到每秒几千 Token。保守按每秒 2000 Token 算一天满负荷能处理约 1.7 亿 Token。对比闭源 API1.7 亿 Token 按混合价 $5/百万算一天就是 $850一个月 $25500。而自托管一个月硬件成本才 $1440 左右。差距是十几倍。当然这是理想情况实际要考虑利用率、并发波动、运维人力。但结论很清楚当日消耗跨过几千万 Token 这个量级自托管就开始有账可算了。低于这个量老老实实用 API。3.3 别忽略“迁移成本”这个隐形坑很多人算成本只算 Token 单价忘了迁移本身要花的功夫。从闭源 API 换到开源模型你要处理Prompt 重写不同模型对指令的敏感度不一样原来调好的 Prompt 可能要重调。输出格式适配结构化输出、函数调用的格式各家有差异。评测体系你得有一套自己的评测集否则换了模型效果掉了都不知道。我踩过的坑是直接拿闭源模型的 Prompt 去跑开源模型结果输出格式全乱。后来老老实实建了一个 200 条的小评测集每次换模型或换版本都跑一遍心里才有底。这个评测集不用大但一定要覆盖你的核心场景。4. 实操从 API 到自托管的完整路径4.1 第一步先用开源 API 试水别急着买卡。先用智谱 API或DeepSeek API把你的业务跑一遍看看效果能不能接受。这一步的目的是验证可行性成本极低。以调用一个开源模型的 API 为例结构上和闭源 API 几乎一样import requests url https://api.example.com/v1/chat/completions headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } payload { model: glm-4, messages: [ {role: system, content: 你是一个严谨的技术助手}, {role: user, content: 解释一下 Token 在推理计费中的作用} ], temperature: 0.3 } resp requests.post(url, headersheaders, jsonpayload, timeout60) print(resp.json()[choices][0][message][content])这段代码没什么玄机但有几个点要注意超时一定要设开源 API 在高峰期响应可能比闭源慢temperature 调低做结构化任务时更稳定错误处理要写全尤其是 429 限流和 5xx 服务端错误要能重试。4.2 第二步本地部署一个能用的模型验证通过后如果你决定自托管推荐从vLLM入手。它对显存和吞吐的优化做得比较成熟社区文档也全。一个典型的部署流程# 安装 vLLM pip install vllm # 启动一个 OpenAI 兼容的服务 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/deepseek-llm-7b-chat \ --served-model-name deepseek-7b \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000启动之后你的本地就有了一个 OpenAI 兼容的接口原来的代码只要改base_url就能接上from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY # 本地部署通常不校验 ) resp client.chat.completions.create( modeldeepseek-7b, messages[{role: user, content: 写一个快速排序}] ) print(resp.choices[0].message.content)这里有几个参数值得说清楚--tensor-parallel-size多卡并行时设为卡数单卡就是 1。--max-model-len最大上下文长度设太大吃显存设太小长文本会截断按业务需求来。--gpu-memory-utilization显存占用比例0.9 是常用值留一点给系统。注意max-model-len和显存是强相关的。上下文翻倍KV Cache 显存基本也翻倍。如果你发现启动就 OOM先把这个值调小。4.3 第三步把 Token 用量管起来自托管之后成本从“按 Token 付费”变成了“按硬件付费”但这不代表你可以随便浪费。Token 用量管理依然重要因为它直接决定你的并发能力和响应速度。几个实用的做法Prompt 压缩把冗余的系统提示精简能省 20% 到 40% 的输入 Token。缓存对重复的查询结果做缓存尤其是那些高频、答案固定的问题。分级路由简单问题走小模型复杂问题走大模型别用大炮打蚊子。流式输出用户体验更好也能更早释放连接资源。我实测下来光是 Prompt 压缩加结果缓存这两招就能把有效 Token 消耗砍掉三成左右。这个收益在自托管场景下体现为更高的并发在 API 场景下就是实打实的省钱。5. 那些没人告诉你、但一定会踩的坑5.1 部署和调用阶段的典型问题我把社区里高频出现的问题整理成一张速查表现象可能原因排查方向启动即 OOM上下文设太大 / 显存不够调小 max-model-len降 gpu-memory-utilization输出乱码或截断编码问题 / max_tokens 太小检查 tokenizer调大输出上限响应极慢批处理没开 / 并发过高开启 continuous batching加卡或限流结构化输出解析失败模型不遵循格式用 JSON mode 或加 few-shot 示例API 返回 401/403Key 失效或权限不足检查密钥有效期和调用权限5.2 关于 Token 失效和鉴权的那点事做自托管服务时鉴权这块经常被忽略。如果你把服务暴露给内部多个团队用一定要加一层网关做鉴权。常见的做法是用JWT做 Token 签发和校验配合刷新机制。我见过最典型的问题就是Token 续签没做好用户用着用着突然掉线。核心逻辑是access token 设短有效期比如 15 分钟refresh token 设长有效期前端在 access token 快过期时自动刷新。如果 refresh token 也失效了就引导重新登录。这套逻辑不复杂但细节没处理好用户体验会很差。提示本地部署的服务默认不校验 api_key一旦对外暴露务必加上网关鉴权否则等于把算力白送人。5.3 模型选型的几个反直觉经验第一别迷信参数量。一个经过良好指令微调的 7B 模型在你的垂直场景里可能比一个没调好的 70B 更好用。先跑评测再定规模。第二中文场景要专门测。有些开源模型英文很强中文一塌糊涂。DeepSeek 和智谱在中文上的表现是它们的强项如果你的业务以中文为主优先考虑这两家。第三量化要谨慎。4-bit 量化能省显存但效果会有损失尤其是推理和代码任务。我的经验是能用 8-bit 就别用 4-bit除非显存实在不够。第四版本要锁死。自托管的最大优势就是确定性所以部署时一定要固定模型版本别用latest这种标签否则某天重启服务模型变了效果也变了。6. 这套方案还能怎么扩展走到自托管这一步之后其实打开了很多新玩法。比如你可以基于开源模型做领域微调把公司内部的文档、话术、规范喂进去得到一个真正懂你业务的模型。这在闭源 API 时代是想都不敢想的。再比如多模型路由把简单意图识别交给小模型复杂推理交给大模型甚至可以在本地和云端之间做动态调度——本地扛日常流量云端兜底峰值。这套架构的灵活度是纯 API 方案给不了的。我自己在实际操作中的体会是转向开源不是一次性的决定而是一个渐进的过程。先用 API 验证再小流量自托管最后逐步把核心流量迁过来。每一步都留好回退的路别搞大跃进。踩过几次坑之后你会发现真正难的不是把模型跑起来而是把成本、效果、稳定性这三者平衡好。而这个平衡点只有你自己跑过一遍数据才知道在哪。