Api

大模型 API 核心参数：调对了事半功倍，调错了钱打水漂 大家好，我是极客老墨。 我刚开始接大模型 API 时，最容易犯的毛病就是把所有问题都往 prompt 上推。输出不稳定，先改 prompt；JSON 解析失败，继续改 prompt；账单涨了，还想着是不是 prompt 不够精简。改到最后，prompt 越写越长，接口却还是像没装仪表盘的车，能跑，但不知道哪里在烧钱、哪里在抖。 这篇不讲玄学调参。我就按一个常见场景来讲：做一个客服工单摘要接口。 输入是一段用户和客服的对话，输出要稳定变成这样的 JSON： 1{ 2 "summary": "用户咨询退款到账时间，客服告知预计 3-5 个工作日", 3 "category": "refund", 4 "risk_level": "low", 5 "next_action": "等待退款到账" 6} 这个接口看着简单，真接到业务里会遇到四个问题： 有时输出一段自然语言，JSON 解析直接炸。 有时写到一半停了，字段缺一截。 有时同一条工单跑两次，分类不一致。 有时为了一个简单摘要开了推理模式，成本和延迟都上去了。 这些问题不全是 prompt 的锅。后来我才把 API 参数当成方向盘、油门、刹车和仪表盘来看：prompt 负责告诉模型要去哪，参数负责控制它怎么走、走多远、花多少钱、异常时怎么停下来。 本文以 DeepSeek API 为主线。DeepSeek 当前官方文档里，Chat Completions 的模型 ID 是 deepseek-v4-flash 和 deepseek-v4-pro；deepseek-chat、deepseek-reasoner 仍可兼容，但官方已说明将于 2026/07/24 弃用。下面的参数口径按本文撰写时查阅的官方文档编写，后续以官方最新文档为准。 model：我会先选一辆够用的车 客服工单摘要这类任务，第一版通常不需要最强模型。它不是奥数题，也不是复杂代码审查，核心是稳定抽取、分类、压缩信息。 DeepSeek 当前官方模型表里有两个主模型： model 适合什么 deepseek-v4-flash 延迟、成本更敏感的通用任务，比如摘要、分类、提取、普通问答 deepseek-v4-pro 更复杂的推理、规划、工具调用、代码分析 官方还保留了两个兼容别名： deepseek-chat：对应 deepseek-v4-flash 的非 thinking 模式。 deepseek-reasoner：对应 deepseek-v4-flash 的 thinking 模式。 这里我会先做一个保守判断：能用 deepseek-v4-flash 跑稳，就先不上 deepseek-v4-pro；能关 thinking 跑稳，就先不开 thinking。 ...