你想用百炼跑个模型，结果卡在「开通了但不知道从哪下手」：控制台里模型一大堆、API Key 分不清用哪个、在线调试能跑通但本地代码调不通、想搭个知识库应用又不知道走哪条路。这篇按接入顺序把整条链路拆开，每步给你该看什么、该验什么，具体价格和可用模型清单去站内对应页面核对当天的数字。
百炼这类平台最容易让人卡住的不是「不会调模型」，而是开通之后不知道从哪下手：控制台里模型一排排、访问凭证分不清该用哪个、在线调试明明能跑通、复制到本地就报错，想搭个知识库应用又不知道该走可视化编排还是自己写代码。这篇按接入顺序把链路拆开，每一步告诉你该看什么、该验什么。
先说明一件事：下面凡是涉及单价、可用模型清单、额度这些会变的数字，都不在正文里写死，一律给站内路径让你自己核对当天的数据。这样你照着做的时候不会被我几天前的记忆带偏。
动手之前先把三件事定下来
很多人是开了账号就直接冲进控制台点模型，结果调到一半发现自己选的计费方式根本不适合自己的用量。先花十分钟把下面三件事定下来，后面能省掉不少返工。
- 想清楚你要的是按量调 API，还是订阅式套餐：调用量不稳定、以验证效果为主的，按量更合适；每天都有固定请求量、想锁定预算的，再看套餐。两条路的口径差别，到站内 /coding-plans/aliyun-bailian-coding-plan-pro 和 /coding-plans/aliyun-bailian-token-plan-pro 对照当时的额度说明。
- 分清账号主体和地域：企业账号、个人账号，以及不同地域能用的模型和计费口径可能对不上，别拿 A 账号的控制台截图去核 B 账号的账单。
- 先估调用量级再挑模型档位。具体单价和模型清单不要凭记忆，去站内 /official-api/providers/alibaba 看当时的数字。
拿 Key、跑通第一次调用
开通之后的第一件事是创建访问凭证。这里有个很容易被忽略的原则：按「一个应用一个 Key」分开放，测试和生产不要混用同一个。混用之后一旦触发限额，你既不知道是哪个应用打的，排查时也不敢随手停掉。
- 先在线调试在控制台的调试面板里发一条请求，确认模型名、参数格式都对。在线能跑通，说明模型本身和参数没问题。
- 再写本地代码把调试面板里的请求示例抄到本地。此时如果失败，基本只剩三类原因：凭证没带全或带错、请求体字段名写错、网络走不通。
- 按顺序排查先确认凭证是不是请求头里那个字段、有没有多余空格；再逐字比对字段名大小写；最后用最简单的 curl 试一次，排除是你代码里框架的问题。
- 量一次延迟基线在没有任何业务代码干扰的情况下测一次响应时间，方法见 /tools/speed-test。没有基线，你之后分不清是模型变慢了还是你的网络抖了。
什么情况下这套顺序不适用：如果你的请求要走内网、或者需要固定出口 IP，那得先去确认平台的网络接入方案，别等上线当天才发现连不通，那时候改架构的成本比现在高得多。
平台上这么多模型，怎么挑一个
百炼上可选的模型不止一个系列，光看名字很容易懵。挑模型不要从「哪个最强」入手，而要从「我的任务是什么类型」入手。纯文本问答、长文档处理、代码生成、带图片的多模态输入，这四类任务的候选池本来就不一样，别拿一个模型硬扛所有活。
| 你的任务特征 | 挑模型时先看什么 | 容易踩的坑 |
|---|---|---|
| 短问答、分类、抽取 | 响应稳定性和结构化输出能力 | 只看单项能力，忽略输出格式是否守规矩 |
| 长文档总结、检索问答 | 上下文长度与长文本下的稳定性 | 上下文塞满之后成本和延迟一起失控 |
| 代码补全、脚本生成 | 对特定语言和框架的熟悉程度 | 拿通用模型做代码任务，改起来像猜 |
| 图片理解、多模态 | 是否支持你要传的模态 | 把图片当纯文本算成本，预算算不准 |
另外注意模型名后面那串后缀，它指的是快照还是别名、会不会跟着平台更新，判断方法在 /model-name-version-suffix 里讲得很细。同一个名字，今天和下周指向的可能不是同一个版本，这一点在你做效果对比时特别关键。
还有一点：选型别只看榜单名次。榜单测的任务未必是你的任务，怎么读不跑偏，参考 /ai-benchmark-ranking-reading。什么情况下不适用——如果你的任务对输出格式极其严格，光换模型解决不了问题，得先把提示词和结构化输出约束做扎实。
从调接口走到搭一个小应用
调用跑通之后，下一步通常是「我能不能直接在上面搭个应用」。这里要分清两条路：一条是直接用 API 自己写业务逻辑，另一条是用平台的应用编排能力把提示词、知识库、工具串起来。后者上手快，但可迁移性差，换平台基本要从头搭；前者活多，但可控。
- 想快速验证产品形态
- 先用可视化编排把流程跑通，别一上来就写工程代码。
- 想长期维护、要接自家系统
- 直接走 API 自己写，编排工具当原型用。
- 要做知识库问答
- 重点在文档切分和召回质量，不在模型本身。
- 要复杂多轮工具调用
- 可视化编排很快会到天花板，早点评估自己写 Agent。
上线之前有三件事建议固定下来：把提示词版本化管理，别直接在控制台改了就上线；给输出加一层格式校验，模型偶尔不守格式是常态；留一条降级路径，要么能换模型，要么能换通道。检索链路怎么搭、和微调怎么选，/fine-tune-prompt-rag 里有成本账；如果决定自己写工具调用，/stacks/agent-apis 可以当清单用。
计费口径与常见坑
计费这块最容易出错的地方是「单位没搞清」。是按输入输出分别计价，还是按时长或按次；图片和长文本怎么折算成 token，这些口径直接决定你的预算对不对。别凭印象，去 /official-api/providers/alibaba 看清口径，再用 /tools/model-cost-calculator 按你的真实用量算一遍。
- 价格是会变的，别拿几个月前的截图做预算。变动记录去 /price-watch 看，比在群里问人靠谱。
- 并发一上来就报限流：先确认你的账号档位对应的并发上限，再决定是加退避重试还是提额度。
- 长上下文把成本吃穿：上下文越长单价越高，能截断的先截断，别整篇文档往里塞。
- 测试 Key 带进线上：上线前把生产环境的凭证单独换一遍，顺便检查有没有写死在代码里的旧 Key。
什么情况下不适用：小体量自用，几乎不用考虑成本优化，纠结这个只会拖慢你验证的速度。等你的月账单到了一个让你犹豫要不要续的数字，再回来做这套排查。
下一步把站内的模型资料库和价格追踪页面加进书签，每次要做预算或选型之前先去核一遍当天的数字，比记在脑子里可靠得多。→常见问题
百炼和直接调模型原厂接口有什么区别？
百炼是聚合型的平台入口，好处是一个账号一套凭证能覆盖多个模型、配套有控制台调试和应用编排能力，迁移成本相对低。代价是价格、限流和可用模型由平台口径决定，不一定和原厂完全一致。如果你只锁定某一个模型且用量很大，值得把两条路的单价和限流都拉出来比一遍再做决定。
本地代码跑不通，但从控制台能调通，先查什么？
按这个顺序：一是凭证有没有带对，包括 Key 本身和需要的额外头字段；二是请求体和控制台示例的字段名、嵌套层级是否一致，很多报错是字段名差一个下划线；三是网络，先单独测一次连通性和延迟，用站内的测速工具量出基线，再对比控制台返回耗时，基本能定位在链路的哪一段。
套餐和按量付费该选哪个？
看你有没有稳定的日调用量。每天都有固定请求量、且能大致估出月度 token 消耗的，套餐往往更省心；调用量波动大、或者还在验证阶段的，按量更灵活，不用为了用完额度硬塞请求。具体档位和额度别照着旧文章抄，去站内的套餐页看当时的数字，再拿你的真实用量折算对比。
