1. 从“会调”到“懂原理”的分水岭到底在哪调 API 这件事门槛已经低到不能再低了。一个刚学编程不到三个月的人照着文档复制一段请求代码把密钥填进去改改提示词就能让大模型吐出看起来像模像样的回答。我见过不少团队招人时问“会不会用大模型”对方说会结果一上手遇到超时、限流、输出格式不稳定、上下文超长被截断整个人就卡住了完全不知道从哪下手排查。这就是标题里说的那个现象会调 API 的人很多懂原理的人极少。我自己带过几个项目也跟不少同行聊过发现一个很普遍的规律——大部分人把大模型当成一个“黑盒接口”在用输入一段文字输出一段文字中间发生了什么完全不清楚。平时跑跑 demo 没问题一旦要上生产、要控成本、要保证稳定性问题就全暴露出来了。这篇手记想做的事情很明确把大模型 API 调用背后那些“看不见的机制”拆开讲清楚。不是讲论文里的数学推导而是讲一个工程从业者在实际项目里必须理解的原理——为什么会有 token 这个概念、上下文窗口到底怎么算、温度参数改了之后模型内部发生了什么、流式输出和一次性输出在工程上有什么本质区别、限流和重试该怎么设计才合理。这些内容文档里往往一笔带过但恰恰是区分“会调”和“懂原理”的关键。适合谁来读如果你已经能跑通大模型 API 的基本调用但总觉得心里没底遇到问题只能靠猜和试那这篇内容就是写给你的。如果你刚开始接触大模型工程还没真正上手调过也没关系我会从最基础的概念讲起用生活化的类比把原理说透再落到具体的代码和参数上。读完你至少能做到两件事第一知道每次调用背后发生了什么第二遇到常见问题时能自己定位原因而不是盲目改参数。2. 大模型 API 调用的核心机制拆解2.1 一次 API 调用到底经历了什么很多人以为调 API 就是“把问题发给模型模型想一下把答案发回来”。这个理解在宏观上没错但在工程上太粗糙了。真实的过程要复杂得多我把它拆成几个阶段来讲。第一阶段是请求组装。你写的提示词、系统指令、历史对话全都会被拼接成一个完整的文本序列。这个序列不是随便拼的它遵循模型训练时见过的特定格式。不同厂商的模型拼接格式不一样有的用特殊标记分隔角色有的用固定模板。如果你自己手动拼很容易拼错导致模型表现异常。所以工程上一般用官方 SDK 或者封装好的消息结构让 SDK 去处理拼接。第二阶段是分词与编码。拼好的文本会被切分成 token然后转成数字 ID 序列。这一步是很多人忽略的关键环节。模型不认识文字它只认识数字。分词器决定了“一段文字对应多少个 token”而 token 数量直接决定了你的成本和能不能塞进上下文窗口。第三阶段是前向计算。数字序列进入模型经过几十层网络的计算最终输出下一个 token 的概率分布。注意模型一次只预测一个 token。你看到的整段回答是模型反复预测、每次追加一个 token、再重新计算得到的。这就是为什么流式输出能实现——因为模型本来就是一个个 token 往外吐的。第四阶段是解码与后处理。根据你设置的温度、top_p 等参数从概率分布里选出一个 token转成文字追加到已有序列后面然后重复第三阶段直到遇到结束标记或者达到最大长度。理解了这个流程很多现象就说得通了。比如为什么同样的提示词两次回答不一样——因为解码阶段有随机性。为什么长对话越来越慢、越来越贵——因为每次都要把全部历史重新算一遍。为什么有时候模型“答非所问”——可能是分词阶段把关键信息切碎了也可能是上下文太长导致前面的内容被挤掉了。2.2 Token大模型世界的“最小货币单位”Token 这个概念我觉得怎么强调都不为过。它既是计费单位又是容量单位还是性能单位。不理解 token就没法真正理解大模型工程的成本结构和限制条件。先说 token 是什么。你可以把它理解成“模型眼里的字”。对于英文一个 token 大约对应 0.75 个单词或者说 4 个字符左右。对于中文情况复杂一些一个汉字通常对应 1 到 2 个 token取决于分词器的设计。我实测过几个主流模型同样一段中文不同模型算出来的 token 数能差出百分之二三十。为什么会有这个差异因为分词器的词表不一样。有的分词器对中文优化得好常见词能合并成一个 token有的分词器中文词表小一个词被拆成好几个 token。这个差异直接影响你的成本。假设你的应用每天处理一百万次请求每次平均多出 50 个 token按某些模型的定价算下来一个月就是一笔不小的开支。再说 token 和上下文窗口的关系。上下文窗口指的是模型一次能处理的最大 token 数包括输入和输出。比如一个 8K 窗口的模型你的提示词加历史对话加模型回答总共不能超过 8192 个 token。超了怎么办要么截断要么报错。截断的话你得决定砍掉哪部分——通常是从最老的历史开始砍但这可能导致模型丢失关键信息。这里有个工程上很容易踩的坑很多人只计算了用户当前输入的长度忘了把系统提示词、历史对话、以及模型即将生成的输出预留空间算进去。结果就是请求发出去了模型回答到一半被截断返回一个不完整的答案。我的做法是在组装请求前先估算总 token 数给输出预留至少 500 到 1000 个 token 的空间如果超了就主动压缩历史对话而不是等模型报错。提示不同模型对 token 的计算方式不同不要用一个模型的 token 数去估算另一个模型。工程上建议直接用对应模型的 tokenizer 做精确计算或者调用厂商提供的 token 计数接口。2.3 上下文窗口模型的“工作记忆”及其工程约束上下文窗口这个概念我用一个类比来解释。想象你请了一位顾问来帮你分析问题但他有个特点每次只能记住有限的信息。你跟他聊得越多他越容易忘记前面说过的话。上下文窗口就是这位顾问的“记忆容量”。这个容量是硬限制不是软限制。超过就是超过模型不会“努力记一下”。所以工程上必须主动管理上下文。我见过一些项目直接把用户的所有历史对话原封不动地塞进去结果没聊几轮就超了然后开始报错或者回答质量急剧下降。管理上下文有几种常见策略。第一种是滑动窗口只保留最近 N 轮对话老的直接丢掉。简单粗暴但可能丢失重要信息。第二种是摘要压缩把老对话用模型总结成一段简短摘要替代原文。这个策略效果好但增加了一次额外的模型调用有成本和延迟。第三种是关键信息提取从历史里抽出实体、意图、约束条件等结构化信息单独维护。这个最复杂但效果最好适合对准确性要求高的场景。我自己的经验是大部分场景用滑动窗口加摘要压缩的组合就够了。具体做法是保留最近 5 到 10 轮完整对话更早的对话每隔几轮做一次摘要把摘要放在系统提示词里。这样既控制了 token 数又保留了长期记忆的骨架。还有一个容易被忽略的点上下文窗口的“有效容量”往往小于标称容量。什么意思就是虽然模型声称支持 32K 甚至 128K 的窗口但在实际使用中当输入接近上限时模型对中间部分内容的注意力会下降。业内管这个叫“迷失在中间”现象。所以重要的信息尽量放在提示词的开头或结尾中间部分放次要内容。2.4 温度与采样为什么同一个问题答案不一样温度这个参数文档里通常只说“控制随机性值越大越随机”。但到底怎么个随机法很多人说不清楚。我试着用工程视角解释一下。模型在预测下一个 token 时输出的其实是一个概率分布。比如词表里有五万个 token每个 token 都有一个概率值加起来等于一。温度的作用是调整这个分布的“陡峭程度”。温度趋近于零时分布变得极其陡峭概率最高的那个 token 几乎必然被选中输出就变得确定。温度升高时分布被“压平”低概率的 token 也有机会被选中输出就变得多样。但这里有个细节温度不是简单地“加噪声”它是在 softmax 之前对 logits 做除法。logits 是模型输出的原始分数除以温度后再做 softmax。温度小于 1 时分数差距被放大分布更陡温度大于 1 时分数差距被缩小分布更平。理解这一点你就知道为什么温度不能随便设——设得太高模型可能选出完全不相关的 token输出变得胡言乱语设得太低输出又过于死板缺乏灵活性。除了温度还有 top_p 和 top_k 两个采样参数。top_k 是只从概率最高的 K 个 token 里选top_p 是只从累积概率达到 P 的最小 token 集合里选。这两个参数和温度配合使用可以更精细地控制输出。我的经验是做事实性问答时温度设 0 到 0.3做创意写作时设 0.7 到 1.0做代码生成时设 0.2 左右比较稳。top_p 一般设 0.9 到 0.95top_k 用默认值就行不用太纠结。注意温度设为 0 并不保证完全确定性的输出。由于浮点运算的精度问题、并行计算的顺序差异以及不同硬件上的实现细节即使温度为零两次调用也可能有微小差异。如果你的业务要求严格可复现需要在应用层做缓存或去重。3. 工程实践中的关键参数与调用策略3.1 超时、重试与退避别让一次网络抖动毁掉整个请求大模型 API 调用本质上是网络请求网络请求就会失败。超时、连接重置、服务端临时不可用这些都是常态。我见过不少项目调用代码里连个 try-catch 都没有一旦网络抖动整个流程就崩了。先说超时设置。大模型推理的延迟波动很大短则几百毫秒长则几十秒。超时设太短正常请求也被掐断设太长失败请求会拖垮整个系统。我的做法是分两段设置连接超时设 5 到 10 秒读取超时根据模型和任务设 30 到 120 秒。对于流式输出读取超时可以设得更长因为 token 是陆续返回的只要还在返回数据就不算超时。再说重试。不是所有失败都值得重试。网络超时、服务端 5xx 错误这些可以重试参数错误、认证失败、配额耗尽重试也没用只会浪费时间和配额。重试次数一般设 2 到 3 次再多就说明服务本身有问题应该走降级逻辑。重试的间隔很关键。固定间隔重试容易造成“惊群效应”——大量请求同时失败同时重试再次把服务打垮。正确的做法是指数退避加随机抖动。第一次重试等 1 秒第二次等 2 秒第三次等 4 秒每次再加一个随机的小偏移。这样能把重试请求分散开给服务恢复的时间。import time import random import requests def call_with_retry(url, payload, headers, max_retries3): for attempt in range(max_retries 1): try: resp requests.post(url, jsonpayload, headersheaders, timeout(10, 60)) if resp.status_code 200: return resp.json() elif resp.status_code 500: raise Exception(fServer error: {resp.status_code}) else: raise Exception(fClient error: {resp.status_code}, no retry) except Exception as e: if attempt max_retries: raise wait (2 ** attempt) random.uniform(0, 1) time.sleep(wait)这段代码是我在多个项目里用过的简化版核心就是指数退避加抖动。实际使用时还要根据具体 SDK 调整但思路是一样的。3.2 流式输出不只是体验优化更是工程必需流式输出就是模型生成一个 token 就返回一个 token而不是等全部生成完再一次性返回。很多人觉得这只是为了用户体验——让用户看到文字一个个蹦出来感觉更快。但实际上流式输出在工程上有更重要的意义。第一它降低了首字节延迟。对于长回答一次性输出可能要等十几秒甚至几十秒用户早就失去耐心了。流式输出能让用户在几百毫秒内看到第一个字感知上的等待时间大幅缩短。第二它让超时控制更灵活。一次性输出时如果模型卡住了你只能等超时。流式输出时你可以设置“如果超过 N 秒没有新 token 返回就中断”更精细地控制。第三它支持提前终止。有时候模型开始胡言乱语或者用户已经看到了想要的答案你可以直接断开连接节省后续的 token 消耗。但流式输出也带来新的工程挑战。首先是拼接问题。流式返回的 token 可能把一个词切成两半你需要正确处理边界。其次是错误处理。流到一半连接断了你得决定是重试整个请求还是从断点继续。重试整个请求会导致重复输出从断点继续则需要模型支持大部分 API 不支持。我的做法是对于短回答用一次性输出简单可靠对于长回答用流式输出但在应用层做缓冲每积累一定长度或遇到标点符号再展示给用户避免 token 边界问题。同时记录已经输出的内容如果连接中断至少能把已生成的部分展示出来而不是全部丢弃。3.3 并发控制与限流别把配额当无限资源大模型 API 通常有速率限制按每分钟请求数或每分钟 token 数来算。很多开发者一开始不注意等到线上流量上来请求被大量拒绝才发现问题。限流策略的核心是“知道自己有多少配额然后按配额来安排请求”。我一般会在应用层做一个令牌桶或者漏桶控制请求发出的速率。令牌桶允许一定程度的突发漏桶则更平滑。对于大模型调用我倾向于用漏桶因为服务端通常不喜欢突发流量。具体实现上可以用信号量控制并发数用队列控制排队。比如设置最大并发 10超出的请求进入队列等待。队列满了就拒绝返回一个友好的提示而不是让请求无限堆积。还有一个容易被忽略的点不同模型的限流是独立的。如果你同时调用多个模型需要分别控制。另外输入 token 和输出 token 可能分别计算限流要仔细看文档。提示限流被触发时API 通常会返回 429 状态码并在响应头里带上重试等待时间。一定要读取这个头信息按它建议的时间等待而不是自己瞎猜。3.4 成本控制从 token 账单反推优化点大模型调用的成本最终都体现在 token 账单上。想控制成本就得从 token 入手。我一般从三个维度来优化。第一个维度是减少输入 token。系统提示词能精简就精简不要写一大堆废话。历史对话能摘要就摘要不要原封不动地塞。少样本示例能少放就少放放最关键的几个就行。我见过一个项目系统提示词写了三千多字里面一大半是重复的说明和客套话砍掉之后成本直接降了四成。第二个维度是控制输出 token。在提示词里明确要求模型“简洁回答”“不超过 N 个字”能有效减少输出长度。设置 max_tokens 参数作为硬限制防止模型跑偏写一大堆。但要注意max_tokens 设得太小可能导致回答被截断需要根据任务类型调整。第三个维度是选择合适的模型。不是所有任务都需要最贵的模型。简单的分类、抽取、改写任务用便宜的小模型就够了。复杂的推理、创作任务再用大模型。我通常会在应用里做一个路由层根据任务复杂度动态选择模型成本能降一半以上。下面这张表是我总结的常见优化手段和预期效果供参考。优化手段实施难度预期成本降幅注意事项精简系统提示词低10%-30%注意别删掉关键约束历史对话摘要中20%-40%摘要本身有成本设置 max_tokens低10%-20%设太小会截断回答模型路由中30%-50%需要评估小模型效果缓存相同请求中视重复率而定注意缓存过期策略批量处理高10%-20%增加延迟4. 常见问题排查与实战避坑指南4.1 输出格式不稳定从“求它”到“约束它”让模型输出 JSON结果它给你返回一段带解释的文字JSON 藏在中间。这个问题几乎每个做结构化输出的人都会遇到。早期我的做法是在提示词里反复强调“只输出 JSON不要其他内容”但效果不稳定模型有时候听有时候不听。后来我总结了一套组合拳。第一在提示词里给出明确的格式示例让模型模仿。第二使用 API 提供的结构化输出功能如果厂商支持的话直接约束输出格式。第三在应用层做解析容错用正则表达式从返回文本里提取 JSON 部分而不是假设整个返回就是 JSON。第四如果解析失败把错误信息反馈给模型让它重新生成。这套组合拳下来格式稳定性从大概七成提升到了九成五以上。剩下的百分之几用重试兜底就够了。还有一个技巧把 JSON 的 schema 写进提示词包括每个字段的类型、是否必填、取值范围。模型看到明确的约束遵守的概率会高很多。4.2 模型“胡言乱语”幻觉的成因与缓解幻觉这个词听起来很玄但成因其实很工程化。模型本质上是在做“下一个 token 预测”它没有事实核查机制。当训练数据里没有相关信息或者提示词里的信息模糊不清时模型会倾向于“编一个看起来合理的答案”而不是说“我不知道”。缓解幻觉我从几个方面入手。第一在提示词里明确允许模型说“不知道”。很多人写提示词时默认模型必须回答结果模型被逼着编。加上一句“如果信息不足请直接说明”能减少很多胡编。第二提供参考资料。把相关的文档、数据放在提示词里让模型基于给定材料回答而不是靠记忆。这就是常说的检索增强生成思路。实测下来有参考资料的情况下事实准确率能提升一大截。第三降低温度。温度越低模型越倾向于选择高概率的 token也就是更“保守”的回答幻觉相对少一些。但温度太低会导致回答死板需要平衡。第四做后验证。对于关键信息用规则或另一个模型做交叉检查。比如模型说了一个日期你用正则提取出来跟原始资料比对。不一致就标记出来人工复核。注意幻觉不可能完全消除只能缓解。对于高风险场景比如医疗、法律、金融一定要有人工审核环节不能完全信任模型输出。4.3 长对话“失忆”上下文管理的实战技巧长对话中模型忘记前面说过的内容这个问题的根源是上下文窗口有限加上“迷失在中间”效应。我的实战经验是不要指望模型自己记住要在工程上主动管理。具体做法维护一个结构化的对话状态包括用户意图、已确认的事实、待解决的问题、约束条件。每轮对话后更新这个状态。组装请求时把状态摘要放在系统提示词里把最近几轮原始对话放在后面。这样模型每次都能看到关键信息不受窗口限制。另外对于特别长的文档分析任务不要一次性塞进去。我的做法是分段处理每段生成摘要最后把摘要汇总再让模型分析。虽然多调用了几次但准确率比一次性塞进去高得多。还有一个细节把最重要的信息放在提示词的开头和结尾。开头是系统指令和关键约束结尾是当前问题和最近对话。中间部分放次要的历史信息。这样即使模型对中间部分注意力下降关键信息也不容易丢。4.4 排查速查表从现象到原因的快速定位下面这张表是我在实际项目中整理的常见问题速查表遇到问题时可以按图索骥。现象可能原因排查方向解决手段请求超时网络问题/模型负载高/输入太长检查网络、查看输入 token 数重试、缩短输入、换时段返回 429触发限流查看响应头重试时间降低并发、加队列、申请提额输出被截断max_tokens 太小/上下文超限检查 max_tokens 和总 token 数调大 max_tokens、压缩历史格式不对提示词不明确/模型不遵守检查提示词和示例加格式约束、用结构化输出回答质量差提示词模糊/温度不合适/模型选错检查提示词、温度、模型优化提示词、调温度、换模型重复输出温度太低/提示词有循环诱导检查温度和提示词调高温度、修改提示词答非所问上下文丢失/分词问题检查历史管理和输入编码优化上下文管理、换分词器成本超预期输入输出 token 过多分析 token 分布精简提示词、设 max_tokens、路由这张表我放在项目文档里新同事上手时先看这个能解决八成常见问题。剩下的两成再具体分析。4.5 几个我踩过的坑和总结的经验第一个坑以为温度为零就是确定性的。前面提过浮点运算和并行计算会导致微小差异。我早期做测试时以为温度设零就能复现结果两次结果不一样排查了半天才发现是这个原因。后来做需要复现的测试时我会在应用层做缓存相同输入直接返回缓存结果。第二个坑忽略 token 计数的差异。不同模型、不同版本的分词器算出来的 token 数不一样。我曾经用 A 模型的 token 数去估算 B 模型的成本结果偏差很大。后来学乖了每个模型都用对应的 tokenizer 单独算。第三个坑重试没有退避。早期写重试逻辑时失败后立即重试结果把服务端打得更惨触发更严格的限流。后来改成指数退避加抖动问题就解决了。第四个坑流式输出没做缓冲。直接把 token 推给前端结果一个词被切成两半前端显示得乱七八糟。后来在应用层加了一个小缓冲遇到标点或积累到一定长度再推送体验就好多了。第五个坑系统提示词写太长。一开始觉得提示词越详细越好把各种规则、示例、约束全塞进去结果 token 成本高不说模型还经常忽略后面的内容。后来精简到只保留最关键的几条效果反而更好。这些坑说到底都指向同一个道理大模型工程不是“调个接口就完事”它需要你理解背后的机制然后在工程上做针对性的设计。会调 API 的人很多但愿意花时间搞懂原理、踩坑总结的人少。希望这篇手记能帮你少走一些弯路。后续我还会继续写这个系列下一篇打算聊提示词工程的工程化实践——怎么把提示词当成代码来管理、测试和迭代。如果你在实际项目里遇到过什么奇葩问题或者有自己的一套排查方法欢迎交流。
1. 从“会调”到“懂原理”的分水岭到底在哪调 API 这件事门槛已经低到不能再低了。一个刚学编程不到三个月的人照着文档复制一段请求代码把密钥填进去改改提示词就能让大模型吐出看起来像模像样的回答。我见过不少团队招人时问“会不会用大模型”对方说会结果一上手遇到超时、限流、输出格式不稳定、上下文超长被截断整个人就卡住了完全不知道从哪下手排查。这就是标题里说的那个现象会调 API 的人很多懂原理的人极少。我自己带过几个项目也跟不少同行聊过发现一个很普遍的规律——大部分人把大模型当成一个“黑盒接口”在用输入一段文字输出一段文字中间发生了什么完全不清楚。平时跑跑 demo 没问题一旦要上生产、要控成本、要保证稳定性问题就全暴露出来了。这篇手记想做的事情很明确把大模型 API 调用背后那些“看不见的机制”拆开讲清楚。不是讲论文里的数学推导而是讲一个工程从业者在实际项目里必须理解的原理——为什么会有 token 这个概念、上下文窗口到底怎么算、温度参数改了之后模型内部发生了什么、流式输出和一次性输出在工程上有什么本质区别、限流和重试该怎么设计才合理。这些内容文档里往往一笔带过但恰恰是区分“会调”和“懂原理”的关键。适合谁来读如果你已经能跑通大模型 API 的基本调用但总觉得心里没底遇到问题只能靠猜和试那这篇内容就是写给你的。如果你刚开始接触大模型工程还没真正上手调过也没关系我会从最基础的概念讲起用生活化的类比把原理说透再落到具体的代码和参数上。读完你至少能做到两件事第一知道每次调用背后发生了什么第二遇到常见问题时能自己定位原因而不是盲目改参数。2. 大模型 API 调用的核心机制拆解2.1 一次 API 调用到底经历了什么很多人以为调 API 就是“把问题发给模型模型想一下把答案发回来”。这个理解在宏观上没错但在工程上太粗糙了。真实的过程要复杂得多我把它拆成几个阶段来讲。第一阶段是请求组装。你写的提示词、系统指令、历史对话全都会被拼接成一个完整的文本序列。这个序列不是随便拼的它遵循模型训练时见过的特定格式。不同厂商的模型拼接格式不一样有的用特殊标记分隔角色有的用固定模板。如果你自己手动拼很容易拼错导致模型表现异常。所以工程上一般用官方 SDK 或者封装好的消息结构让 SDK 去处理拼接。第二阶段是分词与编码。拼好的文本会被切分成 token然后转成数字 ID 序列。这一步是很多人忽略的关键环节。模型不认识文字它只认识数字。分词器决定了“一段文字对应多少个 token”而 token 数量直接决定了你的成本和能不能塞进上下文窗口。第三阶段是前向计算。数字序列进入模型经过几十层网络的计算最终输出下一个 token 的概率分布。注意模型一次只预测一个 token。你看到的整段回答是模型反复预测、每次追加一个 token、再重新计算得到的。这就是为什么流式输出能实现——因为模型本来就是一个个 token 往外吐的。第四阶段是解码与后处理。根据你设置的温度、top_p 等参数从概率分布里选出一个 token转成文字追加到已有序列后面然后重复第三阶段直到遇到结束标记或者达到最大长度。理解了这个流程很多现象就说得通了。比如为什么同样的提示词两次回答不一样——因为解码阶段有随机性。为什么长对话越来越慢、越来越贵——因为每次都要把全部历史重新算一遍。为什么有时候模型“答非所问”——可能是分词阶段把关键信息切碎了也可能是上下文太长导致前面的内容被挤掉了。2.2 Token大模型世界的“最小货币单位”Token 这个概念我觉得怎么强调都不为过。它既是计费单位又是容量单位还是性能单位。不理解 token就没法真正理解大模型工程的成本结构和限制条件。先说 token 是什么。你可以把它理解成“模型眼里的字”。对于英文一个 token 大约对应 0.75 个单词或者说 4 个字符左右。对于中文情况复杂一些一个汉字通常对应 1 到 2 个 token取决于分词器的设计。我实测过几个主流模型同样一段中文不同模型算出来的 token 数能差出百分之二三十。为什么会有这个差异因为分词器的词表不一样。有的分词器对中文优化得好常见词能合并成一个 token有的分词器中文词表小一个词被拆成好几个 token。这个差异直接影响你的成本。假设你的应用每天处理一百万次请求每次平均多出 50 个 token按某些模型的定价算下来一个月就是一笔不小的开支。再说 token 和上下文窗口的关系。上下文窗口指的是模型一次能处理的最大 token 数包括输入和输出。比如一个 8K 窗口的模型你的提示词加历史对话加模型回答总共不能超过 8192 个 token。超了怎么办要么截断要么报错。截断的话你得决定砍掉哪部分——通常是从最老的历史开始砍但这可能导致模型丢失关键信息。这里有个工程上很容易踩的坑很多人只计算了用户当前输入的长度忘了把系统提示词、历史对话、以及模型即将生成的输出预留空间算进去。结果就是请求发出去了模型回答到一半被截断返回一个不完整的答案。我的做法是在组装请求前先估算总 token 数给输出预留至少 500 到 1000 个 token 的空间如果超了就主动压缩历史对话而不是等模型报错。提示不同模型对 token 的计算方式不同不要用一个模型的 token 数去估算另一个模型。工程上建议直接用对应模型的 tokenizer 做精确计算或者调用厂商提供的 token 计数接口。2.3 上下文窗口模型的“工作记忆”及其工程约束上下文窗口这个概念我用一个类比来解释。想象你请了一位顾问来帮你分析问题但他有个特点每次只能记住有限的信息。你跟他聊得越多他越容易忘记前面说过的话。上下文窗口就是这位顾问的“记忆容量”。这个容量是硬限制不是软限制。超过就是超过模型不会“努力记一下”。所以工程上必须主动管理上下文。我见过一些项目直接把用户的所有历史对话原封不动地塞进去结果没聊几轮就超了然后开始报错或者回答质量急剧下降。管理上下文有几种常见策略。第一种是滑动窗口只保留最近 N 轮对话老的直接丢掉。简单粗暴但可能丢失重要信息。第二种是摘要压缩把老对话用模型总结成一段简短摘要替代原文。这个策略效果好但增加了一次额外的模型调用有成本和延迟。第三种是关键信息提取从历史里抽出实体、意图、约束条件等结构化信息单独维护。这个最复杂但效果最好适合对准确性要求高的场景。我自己的经验是大部分场景用滑动窗口加摘要压缩的组合就够了。具体做法是保留最近 5 到 10 轮完整对话更早的对话每隔几轮做一次摘要把摘要放在系统提示词里。这样既控制了 token 数又保留了长期记忆的骨架。还有一个容易被忽略的点上下文窗口的“有效容量”往往小于标称容量。什么意思就是虽然模型声称支持 32K 甚至 128K 的窗口但在实际使用中当输入接近上限时模型对中间部分内容的注意力会下降。业内管这个叫“迷失在中间”现象。所以重要的信息尽量放在提示词的开头或结尾中间部分放次要内容。2.4 温度与采样为什么同一个问题答案不一样温度这个参数文档里通常只说“控制随机性值越大越随机”。但到底怎么个随机法很多人说不清楚。我试着用工程视角解释一下。模型在预测下一个 token 时输出的其实是一个概率分布。比如词表里有五万个 token每个 token 都有一个概率值加起来等于一。温度的作用是调整这个分布的“陡峭程度”。温度趋近于零时分布变得极其陡峭概率最高的那个 token 几乎必然被选中输出就变得确定。温度升高时分布被“压平”低概率的 token 也有机会被选中输出就变得多样。但这里有个细节温度不是简单地“加噪声”它是在 softmax 之前对 logits 做除法。logits 是模型输出的原始分数除以温度后再做 softmax。温度小于 1 时分数差距被放大分布更陡温度大于 1 时分数差距被缩小分布更平。理解这一点你就知道为什么温度不能随便设——设得太高模型可能选出完全不相关的 token输出变得胡言乱语设得太低输出又过于死板缺乏灵活性。除了温度还有 top_p 和 top_k 两个采样参数。top_k 是只从概率最高的 K 个 token 里选top_p 是只从累积概率达到 P 的最小 token 集合里选。这两个参数和温度配合使用可以更精细地控制输出。我的经验是做事实性问答时温度设 0 到 0.3做创意写作时设 0.7 到 1.0做代码生成时设 0.2 左右比较稳。top_p 一般设 0.9 到 0.95top_k 用默认值就行不用太纠结。注意温度设为 0 并不保证完全确定性的输出。由于浮点运算的精度问题、并行计算的顺序差异以及不同硬件上的实现细节即使温度为零两次调用也可能有微小差异。如果你的业务要求严格可复现需要在应用层做缓存或去重。3. 工程实践中的关键参数与调用策略3.1 超时、重试与退避别让一次网络抖动毁掉整个请求大模型 API 调用本质上是网络请求网络请求就会失败。超时、连接重置、服务端临时不可用这些都是常态。我见过不少项目调用代码里连个 try-catch 都没有一旦网络抖动整个流程就崩了。先说超时设置。大模型推理的延迟波动很大短则几百毫秒长则几十秒。超时设太短正常请求也被掐断设太长失败请求会拖垮整个系统。我的做法是分两段设置连接超时设 5 到 10 秒读取超时根据模型和任务设 30 到 120 秒。对于流式输出读取超时可以设得更长因为 token 是陆续返回的只要还在返回数据就不算超时。再说重试。不是所有失败都值得重试。网络超时、服务端 5xx 错误这些可以重试参数错误、认证失败、配额耗尽重试也没用只会浪费时间和配额。重试次数一般设 2 到 3 次再多就说明服务本身有问题应该走降级逻辑。重试的间隔很关键。固定间隔重试容易造成“惊群效应”——大量请求同时失败同时重试再次把服务打垮。正确的做法是指数退避加随机抖动。第一次重试等 1 秒第二次等 2 秒第三次等 4 秒每次再加一个随机的小偏移。这样能把重试请求分散开给服务恢复的时间。import time import random import requests def call_with_retry(url, payload, headers, max_retries3): for attempt in range(max_retries 1): try: resp requests.post(url, jsonpayload, headersheaders, timeout(10, 60)) if resp.status_code 200: return resp.json() elif resp.status_code 500: raise Exception(fServer error: {resp.status_code}) else: raise Exception(fClient error: {resp.status_code}, no retry) except Exception as e: if attempt max_retries: raise wait (2 ** attempt) random.uniform(0, 1) time.sleep(wait)这段代码是我在多个项目里用过的简化版核心就是指数退避加抖动。实际使用时还要根据具体 SDK 调整但思路是一样的。3.2 流式输出不只是体验优化更是工程必需流式输出就是模型生成一个 token 就返回一个 token而不是等全部生成完再一次性返回。很多人觉得这只是为了用户体验——让用户看到文字一个个蹦出来感觉更快。但实际上流式输出在工程上有更重要的意义。第一它降低了首字节延迟。对于长回答一次性输出可能要等十几秒甚至几十秒用户早就失去耐心了。流式输出能让用户在几百毫秒内看到第一个字感知上的等待时间大幅缩短。第二它让超时控制更灵活。一次性输出时如果模型卡住了你只能等超时。流式输出时你可以设置“如果超过 N 秒没有新 token 返回就中断”更精细地控制。第三它支持提前终止。有时候模型开始胡言乱语或者用户已经看到了想要的答案你可以直接断开连接节省后续的 token 消耗。但流式输出也带来新的工程挑战。首先是拼接问题。流式返回的 token 可能把一个词切成两半你需要正确处理边界。其次是错误处理。流到一半连接断了你得决定是重试整个请求还是从断点继续。重试整个请求会导致重复输出从断点继续则需要模型支持大部分 API 不支持。我的做法是对于短回答用一次性输出简单可靠对于长回答用流式输出但在应用层做缓冲每积累一定长度或遇到标点符号再展示给用户避免 token 边界问题。同时记录已经输出的内容如果连接中断至少能把已生成的部分展示出来而不是全部丢弃。3.3 并发控制与限流别把配额当无限资源大模型 API 通常有速率限制按每分钟请求数或每分钟 token 数来算。很多开发者一开始不注意等到线上流量上来请求被大量拒绝才发现问题。限流策略的核心是“知道自己有多少配额然后按配额来安排请求”。我一般会在应用层做一个令牌桶或者漏桶控制请求发出的速率。令牌桶允许一定程度的突发漏桶则更平滑。对于大模型调用我倾向于用漏桶因为服务端通常不喜欢突发流量。具体实现上可以用信号量控制并发数用队列控制排队。比如设置最大并发 10超出的请求进入队列等待。队列满了就拒绝返回一个友好的提示而不是让请求无限堆积。还有一个容易被忽略的点不同模型的限流是独立的。如果你同时调用多个模型需要分别控制。另外输入 token 和输出 token 可能分别计算限流要仔细看文档。提示限流被触发时API 通常会返回 429 状态码并在响应头里带上重试等待时间。一定要读取这个头信息按它建议的时间等待而不是自己瞎猜。3.4 成本控制从 token 账单反推优化点大模型调用的成本最终都体现在 token 账单上。想控制成本就得从 token 入手。我一般从三个维度来优化。第一个维度是减少输入 token。系统提示词能精简就精简不要写一大堆废话。历史对话能摘要就摘要不要原封不动地塞。少样本示例能少放就少放放最关键的几个就行。我见过一个项目系统提示词写了三千多字里面一大半是重复的说明和客套话砍掉之后成本直接降了四成。第二个维度是控制输出 token。在提示词里明确要求模型“简洁回答”“不超过 N 个字”能有效减少输出长度。设置 max_tokens 参数作为硬限制防止模型跑偏写一大堆。但要注意max_tokens 设得太小可能导致回答被截断需要根据任务类型调整。第三个维度是选择合适的模型。不是所有任务都需要最贵的模型。简单的分类、抽取、改写任务用便宜的小模型就够了。复杂的推理、创作任务再用大模型。我通常会在应用里做一个路由层根据任务复杂度动态选择模型成本能降一半以上。下面这张表是我总结的常见优化手段和预期效果供参考。优化手段实施难度预期成本降幅注意事项精简系统提示词低10%-30%注意别删掉关键约束历史对话摘要中20%-40%摘要本身有成本设置 max_tokens低10%-20%设太小会截断回答模型路由中30%-50%需要评估小模型效果缓存相同请求中视重复率而定注意缓存过期策略批量处理高10%-20%增加延迟4. 常见问题排查与实战避坑指南4.1 输出格式不稳定从“求它”到“约束它”让模型输出 JSON结果它给你返回一段带解释的文字JSON 藏在中间。这个问题几乎每个做结构化输出的人都会遇到。早期我的做法是在提示词里反复强调“只输出 JSON不要其他内容”但效果不稳定模型有时候听有时候不听。后来我总结了一套组合拳。第一在提示词里给出明确的格式示例让模型模仿。第二使用 API 提供的结构化输出功能如果厂商支持的话直接约束输出格式。第三在应用层做解析容错用正则表达式从返回文本里提取 JSON 部分而不是假设整个返回就是 JSON。第四如果解析失败把错误信息反馈给模型让它重新生成。这套组合拳下来格式稳定性从大概七成提升到了九成五以上。剩下的百分之几用重试兜底就够了。还有一个技巧把 JSON 的 schema 写进提示词包括每个字段的类型、是否必填、取值范围。模型看到明确的约束遵守的概率会高很多。4.2 模型“胡言乱语”幻觉的成因与缓解幻觉这个词听起来很玄但成因其实很工程化。模型本质上是在做“下一个 token 预测”它没有事实核查机制。当训练数据里没有相关信息或者提示词里的信息模糊不清时模型会倾向于“编一个看起来合理的答案”而不是说“我不知道”。缓解幻觉我从几个方面入手。第一在提示词里明确允许模型说“不知道”。很多人写提示词时默认模型必须回答结果模型被逼着编。加上一句“如果信息不足请直接说明”能减少很多胡编。第二提供参考资料。把相关的文档、数据放在提示词里让模型基于给定材料回答而不是靠记忆。这就是常说的检索增强生成思路。实测下来有参考资料的情况下事实准确率能提升一大截。第三降低温度。温度越低模型越倾向于选择高概率的 token也就是更“保守”的回答幻觉相对少一些。但温度太低会导致回答死板需要平衡。第四做后验证。对于关键信息用规则或另一个模型做交叉检查。比如模型说了一个日期你用正则提取出来跟原始资料比对。不一致就标记出来人工复核。注意幻觉不可能完全消除只能缓解。对于高风险场景比如医疗、法律、金融一定要有人工审核环节不能完全信任模型输出。4.3 长对话“失忆”上下文管理的实战技巧长对话中模型忘记前面说过的内容这个问题的根源是上下文窗口有限加上“迷失在中间”效应。我的实战经验是不要指望模型自己记住要在工程上主动管理。具体做法维护一个结构化的对话状态包括用户意图、已确认的事实、待解决的问题、约束条件。每轮对话后更新这个状态。组装请求时把状态摘要放在系统提示词里把最近几轮原始对话放在后面。这样模型每次都能看到关键信息不受窗口限制。另外对于特别长的文档分析任务不要一次性塞进去。我的做法是分段处理每段生成摘要最后把摘要汇总再让模型分析。虽然多调用了几次但准确率比一次性塞进去高得多。还有一个细节把最重要的信息放在提示词的开头和结尾。开头是系统指令和关键约束结尾是当前问题和最近对话。中间部分放次要的历史信息。这样即使模型对中间部分注意力下降关键信息也不容易丢。4.4 排查速查表从现象到原因的快速定位下面这张表是我在实际项目中整理的常见问题速查表遇到问题时可以按图索骥。现象可能原因排查方向解决手段请求超时网络问题/模型负载高/输入太长检查网络、查看输入 token 数重试、缩短输入、换时段返回 429触发限流查看响应头重试时间降低并发、加队列、申请提额输出被截断max_tokens 太小/上下文超限检查 max_tokens 和总 token 数调大 max_tokens、压缩历史格式不对提示词不明确/模型不遵守检查提示词和示例加格式约束、用结构化输出回答质量差提示词模糊/温度不合适/模型选错检查提示词、温度、模型优化提示词、调温度、换模型重复输出温度太低/提示词有循环诱导检查温度和提示词调高温度、修改提示词答非所问上下文丢失/分词问题检查历史管理和输入编码优化上下文管理、换分词器成本超预期输入输出 token 过多分析 token 分布精简提示词、设 max_tokens、路由这张表我放在项目文档里新同事上手时先看这个能解决八成常见问题。剩下的两成再具体分析。4.5 几个我踩过的坑和总结的经验第一个坑以为温度为零就是确定性的。前面提过浮点运算和并行计算会导致微小差异。我早期做测试时以为温度设零就能复现结果两次结果不一样排查了半天才发现是这个原因。后来做需要复现的测试时我会在应用层做缓存相同输入直接返回缓存结果。第二个坑忽略 token 计数的差异。不同模型、不同版本的分词器算出来的 token 数不一样。我曾经用 A 模型的 token 数去估算 B 模型的成本结果偏差很大。后来学乖了每个模型都用对应的 tokenizer 单独算。第三个坑重试没有退避。早期写重试逻辑时失败后立即重试结果把服务端打得更惨触发更严格的限流。后来改成指数退避加抖动问题就解决了。第四个坑流式输出没做缓冲。直接把 token 推给前端结果一个词被切成两半前端显示得乱七八糟。后来在应用层加了一个小缓冲遇到标点或积累到一定长度再推送体验就好多了。第五个坑系统提示词写太长。一开始觉得提示词越详细越好把各种规则、示例、约束全塞进去结果 token 成本高不说模型还经常忽略后面的内容。后来精简到只保留最关键的几条效果反而更好。这些坑说到底都指向同一个道理大模型工程不是“调个接口就完事”它需要你理解背后的机制然后在工程上做针对性的设计。会调 API 的人很多但愿意花时间搞懂原理、踩坑总结的人少。希望这篇手记能帮你少走一些弯路。后续我还会继续写这个系列下一篇打算聊提示词工程的工程化实践——怎么把提示词当成代码来管理、测试和迭代。如果你在实际项目里遇到过什么奇葩问题或者有自己的一套排查方法欢迎交流。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
