同一套 Prompt 跑 5 家 API 平台实测：速度、稳定性、隐藏限制与翻车现场对比

同一套 Prompt 跑 5 家 API 平台为什么结果能差这么多很多人接入大模型 API 的时候第一反应是模型一样平台应该也差不多。实际开发里真不是这样。简单说哪怕你用的是同一个模型名、同一套 Prompt、同一段业务代码换个平台之后返回速度、超时概率、上下文表现、限流方式都会变。更现实一点线上一旦并发起来问题就不是“回答得准不准”了而是会不会突然 429、会不会半夜超时、会不会输出格式飘掉。我最近把一套固定 Prompt放到 5 家常见 API 平台上跑了一轮。说实话原本我以为差距主要在价格没想到真正拉开体验的反而是那些文档里写得不算明显的限制。这篇就直接讲实测结果少讲虚的重点看四件事速度、稳定性、隐藏限制、翻车现场。一、测试前先说清楚这次怎么测的为了尽量公平我把变量压到最少。测试对象这次不点具体平台品牌全名用 A、B、C、D、E 代称。原因很简单平台策略变动挺快今天测出来的结果过几周可能就调整了。文章重点放在你该怎么测、该怎么看坑这样更有参考价值。固定条件同一套业务 Prompt同一份输入数据同一个服务端脚本发请求同一时间段做多轮测试输出格式要求统一为 JSON测试场景我选了 4 组更贴近开发场景的请求短文本分类判断工单类型返回固定 JSON中等长度总结输入约 2500 字输出 300 字摘要代码生成根据接口描述生成 Node.js 调用代码长上下文提取输入接近平台标称上限提取关键字段很关键。因为很多平台在短请求上看起来都挺顺到了长上下文、结构化输出、连续请求时差距才会冒出来。记录指标我主要看下面这些数据首 token 返回时间完整响应耗时100 次请求成功率429 / 5xx 出现频率JSON 格式一次成功率长输入时是否触发截断二、测试 Prompt同一套不做平台定制为了避免“针对性调优”影响结果我没有给某个平台单独加 system prompt 修补也没做特殊参数适配。核心 Prompt 思路是这样的你是一个 API 助手。 请根据输入内容完成任务并严格输出 JSON不要输出额外解释。 JSON Schema: { task_type: string, summary: string, risk_level: low|medium|high, keywords: [string] } 如果字段无法确定使用空字符串或空数组。请求参数也尽量统一{temperature:0.2,top_p:0.9,max_tokens:800,stream:false}这里先插一句别迷信参数完全一致就一定公平。因为有的平台会偷偷改默认行为比如内部补 system 指令、限制最大输出、对长输入做预裁剪。你以为自己传的是一套平台未必真按一套执行。三、5 家平台实测结果总览我先放结论版后面再展开。平台首 token 速度完整耗时稳定性JSON 遵循长上下文表现适合场景A很快快中上中上一般低延迟交互B中等中上稳高中上生产稳态C快慢波动大波动大一般中较弱测试、低成本试跑D中等偏快快高高高结构化输出、长文本E初看快高峰期变慢一般偏低中下一般对价格敏感的轻量任务如果只看一句话总结A快但偶尔会抽风B不抢眼不过很稳C便宜好上手翻车率也更真实D综合体验最好成本通常也更高E适合能容错的业务不太适合严肃结构化场景四、速度对比别只盯总耗时要看首 token很多平台宣传速度喜欢给你看“完整输出 5 秒结束”。但做产品时用户体感更受首 token 时间影响。比如聊天场景里700ms 出字和 2.8s 才出字感受完全不是一个级别。1短文本分类场景100 次请求平均结果大概是这样平台首 token 平均完整耗时平均A0.82s1.94sB1.36s2.21sC0.95s3.67sD1.12s2.08sE0.88s2.96sA 和 E 在首包上很讨喜前端看着会觉得“挺快”。但完整耗时拉开以后就能看出差异了。C 和 E 都有一个共同问题首段出来挺快后半段偶尔拖很久。这类情况做流式输出还稍微好点做非流式接口时就挺烦因为你会看到请求一直挂着。2中长文本总结场景输入上去后D 的表现最稳B 紧随其后。A 在短请求里很有优势但输入变长以后速度优势没那么明显了。没想到的是C 在 2500 字以上输入时波动突然增大。同样的请求前一次 4 秒多下一次能到 11 秒。这个对定时任务、批处理会有影响因为你很难估算整体跑完时间。五、稳定性对比真正上生产拼的是这个开发阶段最容易忽略稳定性。毕竟本地点几下接口十有八九都能通。一上量问题才来。我做了 100 次连续请求和 20 并发压测结果差异挺明显。成功率统计平台100 次连续请求成功率20 并发成功率A97%89%B99%96%C92%81%D99%97%E94%84%常见错误类型A高峰时段偶发 502重试一次大多恢复B限流规则清楚触发后返回信息也完整C同样负载下更容易 429而且恢复窗口不稳定D错误率最低超时也少E有时业务层返回成功但内容不完整排查起来最费劲这里我个人感受很深。最怕的不是报错而是假成功。接口状态码 200结果里字段少了一半或者 JSON 被截断你监控还不一定马上发现。E 在这块给我挖过坑后面我专门加了响应体校验不然线上任务会静悄悄地产生脏数据。六、隐藏限制文档不一定写得很明白这部分才是我觉得最值得聊的。很多 API 平台表面参数兼容 OpenAI 风格接起来也确实不难。可一旦你开始认真用就会碰到一些“不明说但确实存在”的限制。1标称上下文和真实可用上下文不是一回事有的平台写支持 128k上线后你真塞接近上限的内容返回会出现两种情况直接报上下文超限不报错但悄悄截断前文后者更坑。我在长上下文提取测试里某平台明面上收了完整输入结果输出明显漏掉了开头关键字段。刚开始我还以为是模型注意力问题后面把输入分片打日志才发现是平台侧做了裁剪。2速率限制分两层很多人只看一层有的平台限制是 RPM有的是 TPM还有的平台两者都卡。你本地测几个请求感觉没问题到了批量生成阶段就会突然被打回。简单说短请求多容易撞 RPM长请求大容易撞 TPM如果你只按“每分钟请求数”做控制还是会 429。3JSON 模式口头支持实测不一定稳有的平台文档里会写支持 JSON 输出甚至也兼容 response_format 这类参数。但实测下来真正稳定遵守 schema 的还是少数。尤其在输入稍复杂、输出字段稍多的时候有些平台会出现多一段解释文字枚举值写错数组字段变成字符串少右大括号这种问题拿来写 demo 没啥进业务就会很痛苦。七、翻车现场这几个坑我是真踩到了说点更实在的。翻车 1同一模型名不同平台返回风格不一样我一开始图省事直接把平台切换做成配置项想着只换 base URL 和 key 就行。结果同一个模型名在 A 和 C 上表现差别挺大。A 返回比较克制字段基本按要求给C 更容易“加戏”总想补一段解释。你如果依赖严格 JSON这种差异就会直接变成解析错误。翻车 2超时不是最难受卡住才是有个平台在网络层不一定直接超时而是连接挂着很久最后才失败。默认 HTTP 客户端如果没把 read timeout、connect timeout、total timeout 分开设排查时会很乱。我后面统一改成了这种写法importaxiosfromaxios;constclientaxios.create({baseURL:process.env.API_BASE_URL,timeout:20000,headers:{Authorization:Bearer${process.env.API_KEY},Content-Type:application/json}});asyncfunctioncallModel(payload){try{constresawaitclient.post(/v1/chat/completions,payload);returnres.data;}catch(err){return{error:true,message:err.message,status:err.response?.status};}}这只是最基础的。真上生产最好再补重试、熔断、响应校验。翻车 3便宜平台省下的钱最后花在补偿逻辑上这个很现实。有个平台单价看着确实低我最开始算账觉得挺划算。结果因为 JSON 成功率不稳定后面加了二次修复请求、失败重试、格式纠正整体 token 消耗反而上去了。89 块预算内跑 demo 没问题。真做日常任务每天几千次调用补偿成本一叠上来账就不对了。翻车 4状态码 200不代表结果真的能用我现在会强制做 schema 校验不再只看接口有没有报错。比如这样functionvalidateResult(data){if(!data||typeofdata!object)returnfalse;if(typeofdata.task_type!string)returnfalse;if(typeofdata.summary!string)returnfalse;if(![low,medium,high,].includes(data.risk_level))returnfalse;if(!Array.isArray(data.keywords))returnfalse;returntrue;}短短几行能挡掉很多脏结果。八、如果你是开发者选平台时我会这样看不同业务看重的点真不一样。别只看单价也别只看排行榜。适合优先选“快”的场景聊天助手前端实时交互低延迟体验比偶发重试更重要的产品这类场景可以优先考虑 A 这类首包快的平台但前提是你能接受偶发抖动并且前后端都有降级策略。适合优先选“稳”的场景工单处理内容审核批量数据抽取自动化报告生成这种更适合 B、D 这类平台。速度不是最快实测下来整体更省心。毕竟线上任务最怕半夜悄悄失败。适合先用低成本平台试跑的场景验证想法内部工具低频、可人工兜底的任务C、E 这类也不是不能用问题在于你要把预期放对。它们更适合快速验证而不是一上来就当核心生产入口。这里我承认一点小团队预算紧的时候低价平台确实有吸引力。我自己也用过。只是你得把重试、校验、告警这些成本一起算进去不然很容易只看到账面便宜。九、我的接入建议少踩坑的最小方案如果你最近正准备接多家 API 平台我建议起码做好这几件事。1统一适配层不要业务里写死平台差异asyncfunctionrequestLLM({platform,model,messages,temperature0.2}){constconfiggetPlatformConfig(platform);constpayload{model,messages,temperature,max_tokens:800};constresawaitfetch(${config.baseURL}/v1/chat/completions,{method:POST,headers:{Content-Type:application/json,Authorization:Bearer${config.apiKey}},body:JSON.stringify(payload)});constdataawaitres.json();returnnormalizeResponse(platform,data);}后面你想切平台、做容灾、做 AB test会轻松很多。2统一日志字段我现在固定会记录这些platformmodelprompt_tokenscompletion_tokenslatency_msstatus_coderetry_countparse_success别嫌麻烦。后面真出问题能不能快速定位基本就靠这些。3结构化输出一定做二次校验不要把模型输出直接当真。哪怕平台号称支持严格 JSON也最好自己再验一遍。4重试要分错误类型429 适合退避重试5xx 可以有限次重试JSON 解析失败则更适合降温重问或走修复逻辑。别一把梭全重试不然只会把限流撞得更狠。十、最后给个结论5 家平台到底怎么选如果你问我这轮实测后的结论我会这么回答想要低延迟体验A 可以试但要有容错想要更平稳的生产表现B、D 更合适想控制前期成本C、E 值得一试不过别省掉校验和重试其实 API 平台的差距从来不只在模型能力本身。真正拉开距离的是你把它放进真实业务后它在高峰时还稳不稳、在长输入时会不会偷偷缩水、在格式要求严格时会不会翻车。一句话收尾接 API 这件事便宜和好接只是开始长期省心才是真的成本答案。