一个模型,三家供应商,几个月的折腾——我的大模型API选型手记
去年12月我们团队接了一个智能客服系统的活儿。不是什么大项目日活几千但领导提了个硬指标回复延迟不能超过2秒月度API成本控制在5000以内。我当时觉得问题不大——市面上大模型API那么多随便选一家不就行了呢事实证明我们太天真了。一开始想得挺简单业务场景不复杂用户发问题 → 意图识别 → 知识库检索 → 生成回复。选模型的时候脑子里就两件事效果好、价格便宜。2025年12月初开始调研。当时DeepSeek-V3.2 刚火社区一片叫好我心想这不就是我们要的第一轮拉了三家供应商做对比第一轮试跑被延迟坑了12月中旬搭好测试环境拿200条真实用户对话做压测。结果直接让我怀疑人生。首字延迟TTFT平均1.2秒看着还行。但P95延迟飙到4.7秒——每20个请求就有一个要等将近5秒才出第一个字。用户早跑了。更离谱吞吐量只有38 tokens/s大段回复时用户能明显感觉到在加载中……。最让人窝火的是高峰期经常弹429限流我们明明没超配额找了客服也说不清楚。我后来查了AI Ping的公开评测数据才明白——同样是DeepSeek-V3.2不同供应商的推理优化水平差距巨大。蓝耘元生代在Qwen3-235B上TTFT只有0.58秒排名第一而有些平台同样的模型能慢到10秒以上。这事给我上了一课同一个模型在不同供应商手里跑出来的效果差距大到可以让你怀疑是不是同一个东西。关键不在模型本身在供应商的推理基础设施。第二轮隐性成本才是大头延迟的问题让我意识到不能只看标价。1月初又加了两家供应商做第二轮这次我学聪明了直接盯三个指标有效吞吐量不是峰值是7×24平均P90/P95延迟波动系数峰值/均值越小越稳定测试期间我写了个简单的Python脚本每5分钟发一轮请求连续跑了72小时importtime,jsonfromopenaiimportOpenAIfromdatetimeimportdatetime clients{蓝耘:OpenAI(api_keysk-xxx,base_urlhttps://maas-api.lanyun.net/v1),供应商D:OpenAI(api_keysk-xxx,base_urlhttps://api.provider-d.com/v1),供应商E:OpenAI(api_keysk-xxx,base_urlhttps://api.provider-e.com/v1),}test_prompts[请解释TCP三次握手的过程,帮我写一段Python快速排序代码,什么是Kubernetes的Pod,# ... 共20条不同长度的测试prompt]results{name:{latencies:[],throughputs:[],errors:0}fornameinclients}forround_numinrange(864):# 72h × 12轮/hforname,clientinclients.items():forpromptintest_prompts:try:starttime.time()respclient.chat.completions.create(modeldeepseek-ai/DeepSeek-V3.1,messages[{role:user,content:prompt}],max_tokens512,temperature0.7)elapsedtime.time()-start tokenslen(resp.choices[0].message.content)results[name][latencies].append(elapsed)results[name][throughputs].append(tokens/elapsedifelapsed0else0)exceptExceptionase:results[name][errors]1time.sleep(300)# 5分钟间隔ifround_num%500:print(f[{datetime.now()}] 已完成{round_num}/864 轮)72小时后数据出来了指标蓝耘元生代供应商D供应商E平均吞吐量 (tokens/s)110.9278.4591.23P90延迟 (s)0.331.870.96波动系数 (峰值/均值)1.23×3.45×2.18×72h错误次数3次47次22次蓝耘的吞吐量比D高出41%延迟只有D的五分之一。更关键的是波动系数——1.23倍说明服务稳得很不会突然抽风。D那边3.45倍的波动说白了就是你永远不知道下一秒延迟会飙到哪去这种不确定性在生产环境里是要命的。所以别再只看标价了。吞吐量、延迟稳定性、波动系数——这些才是真正要命的东西。第三轮算账标价是会骗人的2月初拿72小时的数据算了笔账。按预估的日调用量约5万次三家供应商的实际月度成本项目蓝耘元生代供应商D供应商EToken消耗预估/月8200万8200万8200万标价成本¥3,280¥3,280¥3,280因延迟重试浪费的Token~120万~890万~410万因超时丢弃的请求折算Token~40万~320万~150万实际月度成本¥3,512¥4,770¥4,098隐性成本占比7%45%25%算笔账就知道了延迟高 → 用户等不及 → 刷新页面 → 重试请求 → 重复扣费。这套连锁反应吃掉的钱标价上根本看不出来。蓝耘的隐性成本只有7%因为延迟低、波动小几乎不需要重试。算下来一个月省了1200多一年就是1万5。后来我注意到蓝耘的GPU算力平台支持按秒计费——这对我们这种不是7×24跑推理的团队简直是救星。训练任务跑完自动回收不花冤枉钱。我们之前在别的平台包月租GPU利用率经常不到40%钱全打了水漂。一句话总结我的教训真正的成本 标价 延迟税 波动税 返工税。蓝耘帮我省的不是标价上的差价是那些你平时根本注意不到的窟窿。最后一根稻草迁移成本几乎为零说真的就算数据再好如果要大规模改代码我也不太想换。团队3个人工期紧哪有时间折腾。但蓝耘的API用的是OpenAI兼容格式。我直接把base_url一换、API key一改代码就跑起来了。从决定切换到完成迁移前后不到半小时。# 从供应商D切换到蓝耘只改了3行clientOpenAI(api_keysk-lanyun-xxxxx,# 改1base_urlhttps://maas-api.lanyun.net/v1# 改2)# 其他代码完全不用动这一点其实很关键。有些供应商虽然也号称兼容OpenAI但跑起来总有各种小坑——参数名不一样、返回格式有差异、流式响应的chunk结构不同。蓝耘这边我跑了两个星期真没遇到过兼容性问题。另外有个小细节蓝耘支持reasoning_content字段输出思维链对调试prompt和做意图分析特别好用。我们后来在意图识别环节用了这个能力——让模型先展示推理过程再输出分类结果准确率直接涨了将近8个点。2月15日切过去了选型折腾了两个月2月15号正式把智能客服切到了蓝耘元生代MaaS平台。上线后第一个完整月3月的情况平均响应延迟0.8秒TTFT 1.5秒生成合计2.3秒。虽然比2秒的硬指标超了一点但P90也在3秒以内领导没说什么。API花了¥3,240比预算省了35%。领导终于笑了。一个月里只有一次凌晨3点的短暂抖动持续不到两分钟。蓝耘那边的监控告警比我们自己发现得还快。中间有个小插曲。3月初业务突然来了波流量——某个内部活动引流日调用量从5万直接飙到15万。我当时慌得一批心想又要被429教做人。结果蓝耘那边自动扩容扛住了延迟几乎没变。后来看控制台才发现弹性调度在后台默默加了资源我这边完全无感。我回头看选型这事到底在选什么两个月折腾下来我最深的体会其实很简单——大模型API选型选的不是模型本身是供应商的工程能力。模型大家都能接。DeepSeek-V3.2、Qwen、Kimi谁都能当代理。但同一个模型在不同供应商手里延迟差5倍、吞吐差1.5倍、隐性成本差5倍——这些差距全在推理基础设施上。蓝耘能做到清华评测多个第一GPU利用率干到95%背后是裸金属直通、NUMA亲和性调度、动态批处理这些实打实的工程投入不是光靠压价格就能解决的。选供应商没有银弹。适合别人的不一定适合你。但有一个原则我觉得是通用的别只看标价。看延迟、看吞吐、看稳定性、看隐性成本。把72小时压测跑起来数据不会骗人。