不少开发者刚接触大模型SDK时，最先遇到的就是generate方式。不管你在哪个平台接大模型，官方文档里几乎都会给出类似这样的示例代码：构建一个请求，塞进去一段提示词，然后调generate方法，拿到返回的文本。很多教程也就止步于此，示例能跑通就算完事，但一上生产环境就露馅：输出经常被截断、偶尔返回空内容、JSON格式时好时坏、并发一高就开始超时。这篇文章我就围绕generate方式本身，把它的生成原理、参数设计、调用形态、流式解析和常见故障从头到尾拆一遍，把我自己在实际项目中踩过的坑和总结出来的经验一并写出来，给正在接大模型接口或者准备做LLM应用的开发者做参考。1. generate方式的核心形态与适用场景1.1 从自回归原理看generate的本质大模型的文本生成本质上是自回归过程：模型根据已有的全部token序列，预测下一个token的概率分布，然后从中采样出一个token，把它拼接到输入序列末尾，再继续预测下一个token，如此循环直到遇到结束符或达到最大长度限制。generate方式就是把这个循环过程封装成一个对外接口，你喂进去一段文本，它给你吐出一段文本。这个原理听起来简单，但直接影响着你在使用generate时的一系列判断。比如为什么同样的提示词，两次调用结果不一样？因为采样过程带有随机性，temperature和top_p这些参数就是在控制这个随机性的形状。再比如为什么输出长度明明设了很大，结果却提前停了？因为模型自己生成了结束符EOS，自回归循环终止了。理解自回归还有个重要推论：generate的输出质量和输入序列的质量强相关。模型不是“理解”你的要求后再专门去写一段回答，而是在你的提示词所构成的上下文里，顺着统计规律把最可能的后续文本续写出来。所以prompt在generate方式里是绝对的核心，这比在chat类接口里更重要——chat接口里模型会天然地把你的输入当作对话轮次，而generate方式下它把所有输入都当作同一个文本序列来续写。1.2 generate与chat方式的差异对照很多新人在不同SDK里看到generate和chat两种方法时容易混淆。chat方式通常传入的是消息数组，比如system、user、assistant各角色的内容，模型按对话格式处理，返回的也是带角色标记的消息结构。generate方式则是纯粹一点的文本补全，请求体通常就是一个prompt字段加上生成参数。两者底层调用的大模型可能相同，但请求格式、返回结构、适用场景都有明显区别。我整理了一个对照表：对比项generate方式chat方式输入格式单段prompt文本或token序列结构化消息列表，含角色字段请求字段prompt、max_tokens、temperature等messages、model、temperature等返回内容纯文本补全结果带角色和内容的消息对象上下文管理需要自己在prompt中拼接历史由消息列表天然维护典型场景文本续写、代码生成、单个任务多轮对话、客服、聊天机器人可用工具几乎都支持部分平台仅对话接口支持函数调用对prompt的敏感度极敏感，格式直接影响结果较敏感，但消息结构有约束我用一个实际场景来说明：你要写一个“根据文章标题生成摘要”的功能。如果走generate方式，你需要把标题拼到一个模板里，比如“请为以下文章标题生成一段简洁摘要：标题：XXX 摘要：”，然后作为prompt传给接口。如果走chat方式，你会传一个system消息说明任务规则，再传一个user消息放标题。两者的结果可能都很接近，但维护成本不同：chat方式改提示词更方便，因为system和user分开；generate方式则要求你精心维护模板。1.3 哪些场景适合用补全式生成在实践中，我总结generate方式真正好用的场景是三类。第一类是文本续写和补全类任务，比如代码补全、文档续写、翻译后处理。这类任务天然就是“给前面，接后面”，和generate的形态完全一致。实测下来，代码补全的任务用generate方式往往比chat方式更稳定，因为模型在代码数据上的续写能力被训练得很强。第二类是单轮、无状态的工具型调用。比如实体抽取、关键词提取、文本分类、格式转换。这类任务不需要记忆任何对话历史，每次都是独立请求，generate方式的轻量结构让请求体积更小，延迟也更低。第三类是需要在prompt中精细控制输出格式的任务。generate方式让你直接用纯文本模板控制模型行为，你可以精确到换行符、分隔符、JSON字段顺序，这在结构化输出场景里非常有用。只要你把示例放到位，模型在补全任务中遵循格式的概率相当高。反过来，多轮对话、需要长记忆、需要权限判断的交互类场景，不建议用generate。你要手动维护拼接历史文本，还要处理对话轮次的角色标记，很容易搞乱，chat接口是更省事的方案。2. 生成接口关键参数拆解与调参经验2.1 输出长度到底该怎么设max_tokens（有的平台叫max_length或max_new_tokens）是generate方式里最容易被随手填错的参数。很多人习惯性填一个很大的数字，比如2048或4096，想着“给多一点反正用不完”。这个思路在成本上没问题，但在行为上会引入一连串麻烦。生成过程在达到max_tokens上限时会强制截断。如果你的输出是一段JSON或结构化文本，正好在字符串中间被切断，解析环节直接报错。很多初学同学排查半天发现是长度不够，但真正的坑在于，max_tokens设太大还会改变模型的生成行为——有些平台对过长的生成序列会有更长的推理时间，尤其是使用非流式调用时，整个请求的耗时直线上升。我的建议是，先根据任务类型估算输出长度。比如做短标题生成，50到100个token就够；写一段产品描述，300到500；完整文章生成，才需要考虑1000以上。先在测试环境用一个小值试跑，看返回的实际usage中的completion_tokens，再根据真实消耗微调。对于结构化输出，比如JSON，建议在此基础上加20%到30%的余量，给模型留出解释性文字和格式符号的空间。2.2 温度与采样策略的组合逻辑temperature、top_p这两个参数控制的是生成文本的随机性。很多文档把它们分开解释：temperature越高越随机，top_p在累积概率阈值内采样。但实际上在多数平台的实现里，这两个参数是配合使用的，有的平台在请求中只允许同时使用其中一个。temperature的原理是，模型在预测下一个token时，会先对词表里所有token的logits做softmax得到概率分布。temperature大于1时对概率分布做“平滑”，让低概率token也有机会被选中；小于1时做“锐化”，让高概率token更容易胜出；等于0时基本变成贪心解码，每次都选最高概率的token。top_p的含义是，从概率最高token开始向下累计，直到累计概率超过top_p阈值，然后只在这个候选池内重新归一化采样。这个参数的好处是动态调整候选集大小：在概率分布很尖的时候，候选集很小；在分布很平的时候，候选集变大。我自己的调参经验是，不要同时折腾这两个参数。先固定top_p=1，只调temperature，因为temperature的直觉更直接。生成型文案任务比如营销文案、故事续写，temperature设在0.7到0.9，输出会比较有创造性；信息抽取、分类、翻译、代码生成这类要精准的任务，temperature设在0.1到0.3。如果你需要完全确定性的输出，比如测试用例的期望结果，直接设temperature=0。还有一个隐藏经验：如果你发现模型总是输出同一句话或者重复绕圈，不一定是参数问题，可能是prompt里的示范太少。这种时候调高temperature效果有限，应该增加prompt中的few-shot示例来引导多样性。2.3 Stop序列与结构化输出的技巧stop参数经常被忽略，但它是控制生成终结行为的最强工具之一。它接收一个字符串列表，当模型生成的内容中出现任何一个stop字符串时，生成立即终止，且该字符串不会包含在输出中。这个特性在结构化输出里特别有用。比如你要让模型只输出一个JSON对象，可以在stop里传入“\n\n”或者“}”之后你可能想要的其他结束标记。更常见的用法是：prompt里定义了输出格式，末尾用一个特殊标记（比如“### END”）表示生成结束，然后把“### END”放进stop列表。但stop有一个很容易踩的坑：stop是“出现即终止”，不比对自己是不是在合法内容里。比如你让模型生成一段代码，stop列表里放了“#”号，那所有含注释的代码都会被切断。更隐蔽的情况是，stop字符串是“end”，结果模型在回答里写了一句“the end user should...”也被误伤。所以在设计stop序列时，一定要选那些不太可能高频出现在正常输出中的标记，最好是一个独特的组合字符串，而不是通用英文单词。在需要JSON输出的场景里，我还有一个更可靠的替代方案：不依赖stop，而是让模型输出一个markdown代码块，然后用正则取出代码块内容再解析。这样即使模型在代码块外面写了废话，你也能精确提取出JSON主体。两者结合更稳妥：一是在prompt里强制“只输出代码块，不要其他任何说明”，二是从代码块中提取后再解析。这个方法在我做过的多个数据抽取项目里都是最稳的。3. 完整实现：请求、调用与流式解析3.1 请求结构规范与通用封装不同平台的generate方式请求结构大同小异，核心字段基本一致。以典型的补全类接口为例，一个请求通常包括：字段类型说明promptstring输入提示词max_tokensinteger最大生成token数temperaturefloat采样温度，默认通常为1.0top_pfloat核采样参数stoparray停止序列列表streamboolean是否流式返回stream_optionsobject流式的附加选项，部分平台支持封装SDK时，不要搞一大堆针对不同平台的硬编码分支。我的做法是定义一个统一的生成请求对象，内部负责把参数映射到具体平台的字段名。这样切换平台时，业务代码基本不用改，只需要换适配层。对于大型项目，这个抽象层还可以顺便做日志记录、耗时统计、错误码归一化，对小团队来说性价比很高。3.2 非流式调用与超时处理非流式调用是最直观的形态：请求发出，等待模型把全部token生成完，然后一次性返回完整结果。它的好处是逻辑简单、响应体结构固定，适合输出较短、对实时性要求不高的场景。伪代码形式的调用流程大致是这样的：request = GenerationRequest( prompt="请总结以下文章的核心观点：……", max_tokens=300, temperature=0.3, stop=["###"] ) response = client.generate(request) print(response.completion)非流式调用最大的痛点在于耗时。一次生成长文可能需要几十秒甚至更久，客户端库的默认超时时间往往不够用。我有一个真实项目就遇到过这种情况：一个生成报表总结的接口，模型要输出1500字左右的文本，本地测试用了一分钟左右，但生产环境偶尔会跑到两分钟，而客户端的默认超时只有60秒，导致一部分请求被客户端主动取消，而服务端还在生成。解决方案是两层：一是把客户端超时拉长，比如设到180秒甚至300秒，衡量标准是“接口可以慢，但绝不能断”；二是在业务层面做异步化，调用generation接口后立刻返回一个任务ID，后台轮询获取生成结果。第二种方案适合生成内容较重的场景，但工程复杂度更高。如果只是做个个人项目或小型工具，拉长超时再加个重试策略就够了。3.3 流式输出的增量解析与实时展示流式输出是generate方式里最实用也最需要理解的一个形态。它的原理是把自回归生成的每个token（或每几个token）作为独立的响应事件推送给客户端，客户端持续监听直到流结束。这样用户感受到的是“字在蹦出来”，而不是白屏等待。流式的请求参数只需要加一个stream=true。实际开发中，不同平台的流式事件格式有细微差别，但通常都符合SSE规范。每一个数据块大致长这样：{"id":"xxx","choices":[{"delta":{"content":"你好"},"index":0}]}收到流式响应的常规处理流程是：建立HTTP流连接；逐行读取数据，从data:字段中解析JSON；从delta或text字段中取出增量文本并追加到完整缓冲区；当收到标志流结束的事件（如[DONE]）或连接关闭时，结束读取。我在做流式输出时踩过的最大一个坑是：把“增量”当成了“全量”。很多平台的流式接口，第一个数据块的值是增量，后续的也是增量，但有个别平台会用全量替换模式。如果不事先确认这一点，会出现两种情况：一是重复渲染重复文本，页面越来越长；二是用了全量模式却按增量去追加，内容错乱得像乱码。另一个常见问题是断线重连。流式连接是长连接，用户的网络稍有不稳定就可能中断。这时候不能直接丢掉已生成的内容，也不能盲目从头再请求——最好是记录已消费的token数量或消息位置，在重连时从断点位置请求剩余部分，但这需要平台支持位置续传，不是所有平台都有。作为折中方案，流式内容在本地落一份完整副本，连接中断时至少能展示已生成的全部内容，同时提示用户是否重新生成。4. 高频异常排查与踩坑实录4.1 上下文长度与截断问题generate请求遇到的最常见错误就是上下文长度超限。模型对输入输出总长度有上限，有的模型是2048，有的是4096，更大的模型到32K甚至更长。如果你的prompt本身比较长，再加上max_tokens，加在一起超过模型上限，接口会直接报错或截掉你的尾部输入。这个问题的隐蔽性在于：报错还好排查，最麻烦的是不报错只是截断。我在实际项目中遇到过，prompt里的内容因为太长被平台悄悄截断，模型压根没看到完整的输入，结果生成的答案完全不对题。排查时看日志才发现，发送的prompt被截掉了一大段。应对方法就一条：在发送前对token数做估算。中文字符大约占1到2个token，你可以用平台提供的tokenizer先计数，再决定是缩短prompt还是减少max_tokens。一个比较稳妥的公式是：prompt_tokens + max_tokens <= 模型上限 * 0.9，留出10%的安全余量。这个余量是因为平台可能在prompt前后自动加一些格式token，实际占用的输入长度比你预期多一点。4.2 内容格式错乱的常见来源生成结果格式不对，是generate用户最常抱怨的事。明明prompt里写清楚了“输出JSON”，模型却给你回了一段解释文字再跟一个JSON代码块。这种情况的根源，往往不是模型的“理解力”问题，而是你在prompt里根本没有把格式约束传达清楚。格式错乱的第一个来源是模板太随意。打个比方，你在prompt里写“请输出JSON”，但你自己给的示例里JSON是缩进的、带引号的，模型会照着你示例的风格来，如果你示例里JSON前面有引号或外壳，它也会带着外壳输出。要让输出格式稳定，prompt模板里的示例必须严格等于期望输出的样子，不多不少。第二个来源是few-shot示例太少。纯靠文字描述“你要输出一个包含name和age字段的JSON对象”，不如直接给两个输入输出配对的例子。模型通过模式匹配学习，示例比描述管用得多。第三个来源是输出结束符处理混乱。模型生成完JSON后，可能继续生成“这是一段解释”之类的尾部文本。处理办法是在prompt末尾用特殊标记封口，或者用stop序列拦截止住，或者干脆用提取逻辑只取JSON主体。三种方式可以根据平台能力组合使用。4.3 性能与并发注意点generate方式的调用会占用模型推理资源，并发越高，单请求延迟越大。这里有一个很多新手不知道的事情：即便你用同一个模型服务，并发数不同，单次生成的延迟差异可以很大。一次生成200个token，低并发时可能几秒返回，高并发时可能翻两三倍。这是GPU推理的排队特性决定的，不是接口坏了。我在一个自动化批量处理任务里踩过这个坑：一次性往队列里塞了50个生成任务，结果所有任务都在排队，整体吞吐量不升反降，还频繁触发限流错误。后来加了限流器和队列长度控制，把并发压到10以内，单个请求的延迟稳定了，整体吞吐也上来了。另一个容易被忽视的点是临时失败重试的设计。生成任务失败以后，直接重试原prompt并不总是安全的。如果上一次请求实际已经生成了一部分内容，只是网络中断导致你没收到，重试时模型重新生成的完整文本，很可能和之前那次不完全一样。如果业务上要求内容完全一致，就需要引入幂等逻辑，比如把生成结果缓存起来，或者用temperature=0保证稳定输出。我在做自动化测试数据生成时就遇到过，明明同一个prompt提交了两次，结果两个测试用例的数据差异很大，最后用temperature=0解决了。要说generate方式的使用心得，我最大的体会是：它是一个需要“尊重机制”的接口。你越是理解它背后自回归采样的逻辑、理解每个参数的真实含义，就越能用好它；反之，把它当成魔法黑盒来用，问题就会层出不穷。文本续写、结构补全、单轮抽取这类任务，generate方式天然合适；复杂多轮对话，交给chat系接口更省心。每一步参数的设定，都应该从你实际的任务需求和模型的生成机制倒推回来，而不是照抄文档默认值。最后再分享一个小技巧：每次调完参数，把请求参数和对应的输出结果一起记录下来，积累到几十组数据后再看，你会明显发现自己对generate方式的手感不一样了。
不少开发者刚接触大模型SDK时，最先遇到的就是generate方式。不管你在哪个平台接大模型，官方文档里几乎都会给出类似这样的示例代码：构建一个请求，塞进去一段提示词，然后调generate方法，拿到返回的文本。很多教程也就止步于此，示例能跑通就算完事，但一上生产环境就露馅：输出经常被截断、偶尔返回空内容、JSON格式时好时坏、并发一高就开始超时。这篇文章我就围绕generate方式本身，把它的生成原理、参数设计、调用形态、流式解析和常见故障从头到尾拆一遍，把我自己在实际项目中踩过的坑和总结出来的经验一并写出来，给正在接大模型接口或者准备做LLM应用的开发者做参考。1. generate方式的核心形态与适用场景1.1 从自回归原理看generate的本质大模型的文本生成本质上是自回归过程：模型根据已有的全部token序列，预测下一个token的概率分布，然后从中采样出一个token，把它拼接到输入序列末尾，再继续预测下一个token，如此循环直到遇到结束符或达到最大长度限制。generate方式就是把这个循环过程封装成一个对外接口，你喂进去一段文本，它给你吐出一段文本。这个原理听起来简单，但直接影响着你在使用generate时的一系列判断。比如为什么同样的提示词，两次调用结果不一样？因为采样过程带有随机性，temperature和top_p这些参数就是在控制这个随机性的形状。再比如为什么输出长度明明设了很大，结果却提前停了？因为模型自己生成了结束符EOS，自回归循环终止了。理解自回归还有个重要推论：generate的输出质量和输入序列的质量强相关。模型不是“理解”你的要求后再专门去写一段回答，而是在你的提示词所构成的上下文里，顺着统计规律把最可能的后续文本续写出来。所以prompt在generate方式里是绝对的核心，这比在chat类接口里更重要——chat接口里模型会天然地把你的输入当作对话轮次，而generate方式下它把所有输入都当作同一个文本序列来续写。1.2 generate与chat方式的差异对照很多新人在不同SDK里看到generate和chat两种方法时容易混淆。chat方式通常传入的是消息数组，比如system、user、assistant各角色的内容，模型按对话格式处理，返回的也是带角色标记的消息结构。generate方式则是纯粹一点的文本补全，请求体通常就是一个prompt字段加上生成参数。两者底层调用的大模型可能相同，但请求格式、返回结构、适用场景都有明显区别。我整理了一个对照表：对比项generate方式chat方式输入格式单段prompt文本或token序列结构化消息列表，含角色字段请求字段prompt、max_tokens、temperature等messages、model、temperature等返回内容纯文本补全结果带角色和内容的消息对象上下文管理需要自己在prompt中拼接历史由消息列表天然维护典型场景文本续写、代码生成、单个任务多轮对话、客服、聊天机器人可用工具几乎都支持部分平台仅对话接口支持函数调用对prompt的敏感度极敏感，格式直接影响结果较敏感，但消息结构有约束我用一个实际场景来说明：你要写一个“根据文章标题生成摘要”的功能。如果走generate方式，你需要把标题拼到一个模板里，比如“请为以下文章标题生成一段简洁摘要：标题：XXX 摘要：”，然后作为prompt传给接口。如果走chat方式，你会传一个system消息说明任务规则，再传一个user消息放标题。两者的结果可能都很接近，但维护成本不同：chat方式改提示词更方便，因为system和user分开；generate方式则要求你精心维护模板。1.3 哪些场景适合用补全式生成在实践中，我总结generate方式真正好用的场景是三类。第一类是文本续写和补全类任务，比如代码补全、文档续写、翻译后处理。这类任务天然就是“给前面，接后面”，和generate的形态完全一致。实测下来，代码补全的任务用generate方式往往比chat方式更稳定，因为模型在代码数据上的续写能力被训练得很强。第二类是单轮、无状态的工具型调用。比如实体抽取、关键词提取、文本分类、格式转换。这类任务不需要记忆任何对话历史，每次都是独立请求，generate方式的轻量结构让请求体积更小，延迟也更低。第三类是需要在prompt中精细控制输出格式的任务。generate方式让你直接用纯文本模板控制模型行为，你可以精确到换行符、分隔符、JSON字段顺序，这在结构化输出场景里非常有用。只要你把示例放到位，模型在补全任务中遵循格式的概率相当高。反过来，多轮对话、需要长记忆、需要权限判断的交互类场景，不建议用generate。你要手动维护拼接历史文本，还要处理对话轮次的角色标记，很容易搞乱，chat接口是更省事的方案。2. 生成接口关键参数拆解与调参经验2.1 输出长度到底该怎么设max_tokens（有的平台叫max_length或max_new_tokens）是generate方式里最容易被随手填错的参数。很多人习惯性填一个很大的数字，比如2048或4096，想着“给多一点反正用不完”。这个思路在成本上没问题，但在行为上会引入一连串麻烦。生成过程在达到max_tokens上限时会强制截断。如果你的输出是一段JSON或结构化文本，正好在字符串中间被切断，解析环节直接报错。很多初学同学排查半天发现是长度不够，但真正的坑在于，max_tokens设太大还会改变模型的生成行为——有些平台对过长的生成序列会有更长的推理时间，尤其是使用非流式调用时，整个请求的耗时直线上升。我的建议是，先根据任务类型估算输出长度。比如做短标题生成，50到100个token就够；写一段产品描述，300到500；完整文章生成，才需要考虑1000以上。先在测试环境用一个小值试跑，看返回的实际usage中的completion_tokens，再根据真实消耗微调。对于结构化输出，比如JSON，建议在此基础上加20%到30%的余量，给模型留出解释性文字和格式符号的空间。2.2 温度与采样策略的组合逻辑temperature、top_p这两个参数控制的是生成文本的随机性。很多文档把它们分开解释：temperature越高越随机，top_p在累积概率阈值内采样。但实际上在多数平台的实现里，这两个参数是配合使用的，有的平台在请求中只允许同时使用其中一个。temperature的原理是，模型在预测下一个token时，会先对词表里所有token的logits做softmax得到概率分布。temperature大于1时对概率分布做“平滑”，让低概率token也有机会被选中；小于1时做“锐化”，让高概率token更容易胜出；等于0时基本变成贪心解码，每次都选最高概率的token。top_p的含义是，从概率最高token开始向下累计，直到累计概率超过top_p阈值，然后只在这个候选池内重新归一化采样。这个参数的好处是动态调整候选集大小：在概率分布很尖的时候，候选集很小；在分布很平的时候，候选集变大。我自己的调参经验是，不要同时折腾这两个参数。先固定top_p=1，只调temperature，因为temperature的直觉更直接。生成型文案任务比如营销文案、故事续写，temperature设在0.7到0.9，输出会比较有创造性；信息抽取、分类、翻译、代码生成这类要精准的任务，temperature设在0.1到0.3。如果你需要完全确定性的输出，比如测试用例的期望结果，直接设temperature=0。还有一个隐藏经验：如果你发现模型总是输出同一句话或者重复绕圈，不一定是参数问题，可能是prompt里的示范太少。这种时候调高temperature效果有限，应该增加prompt中的few-shot示例来引导多样性。2.3 Stop序列与结构化输出的技巧stop参数经常被忽略，但它是控制生成终结行为的最强工具之一。它接收一个字符串列表，当模型生成的内容中出现任何一个stop字符串时，生成立即终止，且该字符串不会包含在输出中。这个特性在结构化输出里特别有用。比如你要让模型只输出一个JSON对象，可以在stop里传入“\n\n”或者“}”之后你可能想要的其他结束标记。更常见的用法是：prompt里定义了输出格式，末尾用一个特殊标记（比如“### END”）表示生成结束，然后把“### END”放进stop列表。但stop有一个很容易踩的坑：stop是“出现即终止”，不比对自己是不是在合法内容里。比如你让模型生成一段代码，stop列表里放了“#”号，那所有含注释的代码都会被切断。更隐蔽的情况是，stop字符串是“end”，结果模型在回答里写了一句“the end user should...”也被误伤。所以在设计stop序列时，一定要选那些不太可能高频出现在正常输出中的标记，最好是一个独特的组合字符串，而不是通用英文单词。在需要JSON输出的场景里，我还有一个更可靠的替代方案：不依赖stop，而是让模型输出一个markdown代码块，然后用正则取出代码块内容再解析。这样即使模型在代码块外面写了废话，你也能精确提取出JSON主体。两者结合更稳妥：一是在prompt里强制“只输出代码块，不要其他任何说明”，二是从代码块中提取后再解析。这个方法在我做过的多个数据抽取项目里都是最稳的。3. 完整实现：请求、调用与流式解析3.1 请求结构规范与通用封装不同平台的generate方式请求结构大同小异，核心字段基本一致。以典型的补全类接口为例，一个请求通常包括：字段类型说明promptstring输入提示词max_tokensinteger最大生成token数temperaturefloat采样温度，默认通常为1.0top_pfloat核采样参数stoparray停止序列列表streamboolean是否流式返回stream_optionsobject流式的附加选项，部分平台支持封装SDK时，不要搞一大堆针对不同平台的硬编码分支。我的做法是定义一个统一的生成请求对象，内部负责把参数映射到具体平台的字段名。这样切换平台时，业务代码基本不用改，只需要换适配层。对于大型项目，这个抽象层还可以顺便做日志记录、耗时统计、错误码归一化，对小团队来说性价比很高。3.2 非流式调用与超时处理非流式调用是最直观的形态：请求发出，等待模型把全部token生成完，然后一次性返回完整结果。它的好处是逻辑简单、响应体结构固定，适合输出较短、对实时性要求不高的场景。伪代码形式的调用流程大致是这样的：request = GenerationRequest( prompt="请总结以下文章的核心观点：……", max_tokens=300, temperature=0.3, stop=["###"] ) response = client.generate(request) print(response.completion)非流式调用最大的痛点在于耗时。一次生成长文可能需要几十秒甚至更久，客户端库的默认超时时间往往不够用。我有一个真实项目就遇到过这种情况：一个生成报表总结的接口，模型要输出1500字左右的文本，本地测试用了一分钟左右，但生产环境偶尔会跑到两分钟，而客户端的默认超时只有60秒，导致一部分请求被客户端主动取消，而服务端还在生成。解决方案是两层：一是把客户端超时拉长，比如设到180秒甚至300秒，衡量标准是“接口可以慢，但绝不能断”；二是在业务层面做异步化，调用generation接口后立刻返回一个任务ID，后台轮询获取生成结果。第二种方案适合生成内容较重的场景，但工程复杂度更高。如果只是做个个人项目或小型工具，拉长超时再加个重试策略就够了。3.3 流式输出的增量解析与实时展示流式输出是generate方式里最实用也最需要理解的一个形态。它的原理是把自回归生成的每个token（或每几个token）作为独立的响应事件推送给客户端，客户端持续监听直到流结束。这样用户感受到的是“字在蹦出来”，而不是白屏等待。流式的请求参数只需要加一个stream=true。实际开发中，不同平台的流式事件格式有细微差别，但通常都符合SSE规范。每一个数据块大致长这样：{"id":"xxx","choices":[{"delta":{"content":"你好"},"index":0}]}收到流式响应的常规处理流程是：建立HTTP流连接；逐行读取数据，从data:字段中解析JSON；从delta或text字段中取出增量文本并追加到完整缓冲区；当收到标志流结束的事件（如[DONE]）或连接关闭时，结束读取。我在做流式输出时踩过的最大一个坑是：把“增量”当成了“全量”。很多平台的流式接口，第一个数据块的值是增量，后续的也是增量，但有个别平台会用全量替换模式。如果不事先确认这一点，会出现两种情况：一是重复渲染重复文本，页面越来越长；二是用了全量模式却按增量去追加，内容错乱得像乱码。另一个常见问题是断线重连。流式连接是长连接，用户的网络稍有不稳定就可能中断。这时候不能直接丢掉已生成的内容，也不能盲目从头再请求——最好是记录已消费的token数量或消息位置，在重连时从断点位置请求剩余部分，但这需要平台支持位置续传，不是所有平台都有。作为折中方案，流式内容在本地落一份完整副本，连接中断时至少能展示已生成的全部内容，同时提示用户是否重新生成。4. 高频异常排查与踩坑实录4.1 上下文长度与截断问题generate请求遇到的最常见错误就是上下文长度超限。模型对输入输出总长度有上限，有的模型是2048，有的是4096，更大的模型到32K甚至更长。如果你的prompt本身比较长，再加上max_tokens，加在一起超过模型上限，接口会直接报错或截掉你的尾部输入。这个问题的隐蔽性在于：报错还好排查，最麻烦的是不报错只是截断。我在实际项目中遇到过，prompt里的内容因为太长被平台悄悄截断，模型压根没看到完整的输入，结果生成的答案完全不对题。排查时看日志才发现，发送的prompt被截掉了一大段。应对方法就一条：在发送前对token数做估算。中文字符大约占1到2个token，你可以用平台提供的tokenizer先计数，再决定是缩短prompt还是减少max_tokens。一个比较稳妥的公式是：prompt_tokens + max_tokens <= 模型上限 * 0.9，留出10%的安全余量。这个余量是因为平台可能在prompt前后自动加一些格式token，实际占用的输入长度比你预期多一点。4.2 内容格式错乱的常见来源生成结果格式不对，是generate用户最常抱怨的事。明明prompt里写清楚了“输出JSON”，模型却给你回了一段解释文字再跟一个JSON代码块。这种情况的根源，往往不是模型的“理解力”问题，而是你在prompt里根本没有把格式约束传达清楚。格式错乱的第一个来源是模板太随意。打个比方，你在prompt里写“请输出JSON”，但你自己给的示例里JSON是缩进的、带引号的，模型会照着你示例的风格来，如果你示例里JSON前面有引号或外壳，它也会带着外壳输出。要让输出格式稳定，prompt模板里的示例必须严格等于期望输出的样子，不多不少。第二个来源是few-shot示例太少。纯靠文字描述“你要输出一个包含name和age字段的JSON对象”，不如直接给两个输入输出配对的例子。模型通过模式匹配学习，示例比描述管用得多。第三个来源是输出结束符处理混乱。模型生成完JSON后，可能继续生成“这是一段解释”之类的尾部文本。处理办法是在prompt末尾用特殊标记封口，或者用stop序列拦截止住，或者干脆用提取逻辑只取JSON主体。三种方式可以根据平台能力组合使用。4.3 性能与并发注意点generate方式的调用会占用模型推理资源，并发越高，单请求延迟越大。这里有一个很多新手不知道的事情：即便你用同一个模型服务，并发数不同，单次生成的延迟差异可以很大。一次生成200个token，低并发时可能几秒返回，高并发时可能翻两三倍。这是GPU推理的排队特性决定的，不是接口坏了。我在一个自动化批量处理任务里踩过这个坑：一次性往队列里塞了50个生成任务，结果所有任务都在排队，整体吞吐量不升反降，还频繁触发限流错误。后来加了限流器和队列长度控制，把并发压到10以内，单个请求的延迟稳定了，整体吞吐也上来了。另一个容易被忽视的点是临时失败重试的设计。生成任务失败以后，直接重试原prompt并不总是安全的。如果上一次请求实际已经生成了一部分内容，只是网络中断导致你没收到，重试时模型重新生成的完整文本，很可能和之前那次不完全一样。如果业务上要求内容完全一致，就需要引入幂等逻辑，比如把生成结果缓存起来，或者用temperature=0保证稳定输出。我在做自动化测试数据生成时就遇到过，明明同一个prompt提交了两次，结果两个测试用例的数据差异很大，最后用temperature=0解决了。要说generate方式的使用心得，我最大的体会是：它是一个需要“尊重机制”的接口。你越是理解它背后自回归采样的逻辑、理解每个参数的真实含义，就越能用好它；反之，把它当成魔法黑盒来用，问题就会层出不穷。文本续写、结构补全、单轮抽取这类任务，generate方式天然合适；复杂多轮对话，交给chat系接口更省心。每一步参数的设定，都应该从你实际的任务需求和模型的生成机制倒推回来，而不是照抄文档默认值。最后再分享一个小技巧：每次调完参数，把请求参数和对应的输出结果一起记录下来，积累到几十组数据后再看，你会明显发现自己对generate方式的手感不一样了。