企业官网建设流程全解析

1. 从调包到懂行：大模型工程的分水岭到底在哪

这两年做大模型应用开发的人越来越多，随便拉一个后端工程师过来，给他一份接口文档，半天时间就能把对话接口跑通。再花两天，流式输出、多轮上下文、函数调用这些也能接上。表面上看，门槛确实不高，会调 API 的人一抓一大把。但真正到了线上环境，问题就开始暴露了：同样的模型，别人家的应用响应又快又准，你家的又慢又胡说；别人一天烧几百块能扛住几千用户，你一天烧几千块还天天超时；别人改一个参数就能解决的事，你改来改去都不知道问题出在哪。

这个分水岭，就在于你是把大模型当成一个黑盒接口在用，还是真正理解它内部在发生什么。我做了几个落地项目之后最大的感受是：调 API 只是入场券，懂原理才是你能不能把东西做稳、做便宜、做快的关键。这篇文章不打算讲什么高深论文，而是从工程视角，把大模型应用开发里那些“你必须知道但文档不会写”的原理掰开揉碎讲清楚。适合已经能跑通接口、但一遇到性能、成本、稳定性问题就抓瞎的开发者，也适合想从传统后端转到大模型方向、需要建立系统认知的朋友。

我会围绕四个核心问题展开：第一，为什么同样的接口，不同人用出来的效果天差地别，背后的架构设计逻辑是什么；第二，推理过程中的关键参数到底在控制什么，怎么调才不是瞎调；第三，一个完整的请求从进入到返回，中间经历了哪些环节，每个环节的瓶颈在哪；第四，线上最常见的几类故障，怎么快速定位和解决。每一部分我都会给出可以直接参考的参数、步骤和排查思路，尽量做到看完就能用。

2. 大模型应用的架构设计逻辑与选型考量

2.1 为什么不能把大模型当成普通微服务来用

很多从传统后端转过来的开发者，第一反应是把大模型接口封装成一个内部服务，然后像调用数据库一样去调用它。这个思路本身没错，但问题在于，大模型接口和普通微服务有本质区别。普通微服务的响应时间通常在几十毫秒级别，而且基本是确定性的——同样的输入，只要代码没改，输出就稳定。大模型不是这样，它的响应时间从几百毫秒到几十秒不等，输出内容每次都可能不同，而且成本是按 token 计算的，不是按调用次数。

这就导致一个很现实的问题：如果你用传统的同步阻塞方式去调大模型，一个请求占一个线程，那你的服务并发能力会被死死卡住。我见过一个项目，用最朴素的同步 HTTP 客户端去调对话接口，结果 20 个并发就把服务打挂了，不是模型扛不住，是自己的线程池被占满了。正确的做法是全程异步，用异步 HTTP 客户端配合协程或者响应式编程模型，让等待模型返回的时间不占用实际线程资源。

另一个常见误区是把大模型接口当成无状态服务。实际上，多轮对话是有状态的，但这个状态不在模型那边，而在你的应用层。模型本身不记忆任何东西，每次请求你都得把历史对话重新传进去。这就带来一个设计选择：历史对话是每次全量传，还是做摘要压缩，还是用向量检索只取相关的几轮。全量传最简单，但 token 消耗会随着对话轮次线性增长，成本很快就失控。摘要压缩能控制 token，但会丢失细节，而且摘要本身也要消耗一次模型调用。向量检索适合知识库场景，但对话场景下效果不一定好，因为对话的上下文关联性很强，不是简单的语义相似就能覆盖。

2.2 同步、异步、流式三种调用方式怎么选

从工程实现角度，大模型调用方式基本就三种：同步等待完整结果、异步等待完整结果、流式逐步返回。这三种方式没有绝对的好坏，关键看你的场景。

同步方式最简单，适合后台批处理任务，比如批量生成摘要、批量翻译。这种场景对响应时间不敏感，对吞吐量要求高，同步方式配合线程池反而容易控制并发。但要注意，同步方式下线程池大小不能拍脑袋定，得根据模型的平均响应时间和你的超时设置来算。举个例子，如果模型平均 5 秒返回，你设置超时 30 秒，那一个线程最多 30 秒就被释放，理论上 100 个并发需要大约 17 个线程（100 乘以 5 除以 30）。但实际要考虑峰值，一般会留一倍余量。

异步方式适合 API 服务，用户发起请求后不需要立即看到结果，可以轮询或者等回调。这种方式能最大化利用系统资源，但实现复杂度高一些，需要处理好任务队列、结果存储和超时重试。流式方式适合对话类应用，用户能实时看到文字一个个蹦出来，体验最好。但流式方式对前端和后端的要求都更高，前端要处理 SSE 或者 WebSocket，后端要处理流的中断、重连和错误恢复。

我个人的经验是，对话类应用无脑选流式，这是用户体验的底线。后台任务选异步，用消息队列解耦。只有那些对实时性完全没要求、而且调用量很小的场景，才用同步。另外提醒一点，流式方式下 token 计数和成本统计会更麻烦，因为你是边收边算的，需要在流式解析的过程中同步累加 token 数量，不能等流结束了再算。

2.3 多模型路由与降级策略的设计

线上环境不可能只依赖一个模型。原因很简单：再好的模型也有抖动的时候，响应变慢、返回错误、甚至整个区域不可用，这些都会发生。所以一个成熟的大模型应用，必须有路由和降级能力。

路由策略一般分两种：按任务类型路由和按负载路由。按任务类型路由是指，简单任务用便宜的小模型，复杂任务用贵的大模型。比如意图识别、文本分类这种，小模型完全够用，没必要上大模型。按负载路由是指，当主模型响应时间超过阈值或者错误率上升时，自动切到备用模型。这个切换逻辑要做得足够细，不能一刀切。比如流式请求切到非流式模型，体验会断崖式下降，所以备用模型最好也支持流式。

降级策略要分层次。第一层是重试，同一个模型重试一次，适合偶发的网络抖动。第二层是切换，重试失败后切到备用模型。第三层是兜底，所有模型都不可用时，返回一个预设的友好提示，而不是直接报错。这里有个细节很多人忽略：重试和切换都要考虑幂等性。如果第一次请求实际上已经成功了，只是响应丢了，你重试会导致重复生成，用户可能收到两条一样的回复。解决办法是在请求里带一个唯一标识，服务端做去重。

3. 推理关键参数的底层原理与调优方法

3.1 温度与核采样：控制随机性的两个旋钮

温度这个参数，几乎所有文档都会提，但真正理解它在干什么的人不多。简单说，模型在生成每个 token 的时候，会先算出一个概率分布，比如下一个词是“好”的概率 0.6，“坏”的概率 0.3，“一般”的概率 0.1。温度的作用是调整这个分布的陡峭程度。温度越低，分布越尖锐，高概率的词更容易被选中，输出更确定。温度越高，分布越平坦，低概率的词也有机会被选中，输出更多样。

但温度不是唯一控制随机性的参数，还有一个叫核采样，也叫 top-p。它的逻辑是：把所有候选词按概率从高到低排序，然后从前往后累加概率，直到累加值超过 p，然后只在这个候选集合里采样。比如 p 设为 0.9，那可能只保留前 5 个词，后面的全扔掉。这样做的好处是，不管分布多平坦，都不会采样到那些概率极低的离谱词。

这两个参数怎么配合用？我的经验是，不要同时调。要么固定 top-p 为 1，只调温度；要么固定温度为 1，只调 top-p。同时调两个，你根本不知道是哪个在起作用。具体数值上，需要确定答案的场景，比如代码生成、数学解题，温度设 0 到 0.3。需要创意的场景，比如文案写作、头脑风暴，温度设 0.7 到 1.0。核采样一般设 0.9 到 0.95，很少设 1，因为设 1 等于不限制，长尾词会跑出来。

还有一个参数叫 top-k，就是直接保留概率最高的 k 个词。这个参数现在用得少了，因为 top-p 更灵活。但在某些场景下，top-k 更稳定，比如你明确知道候选词范围很小的时候。这三个参数的关系，你可以理解为：温度是调整整体陡峭度，top-k 是硬性截断，top-p 是动态截断。实际调优的时候，建议先用默认值跑一批测试用例，然后固定其他参数，只调一个，观察输出变化，找到最合适的值。

3.2 最大生成长度与停止序列的工程陷阱

最大生成长度这个参数，看起来很简单，就是限制模型最多生成多少个 token。但工程上有很多坑。第一个坑是，这个长度限制的是生成部分，不包括输入部分。很多人以为设了 1000 就是总长度 1000，结果输入就占了 800，输出只剩 200，回答被硬生生截断。正确的做法是，先算输入 token 数，然后用模型的最大上下文长度减去输入长度，再留一些余量给输出。

第二个坑是，不同模型对最大生成长度的默认值不一样。有的默认 256，有的默认 1024，有的默认不限制。如果你不显式设置，可能会遇到回答突然断掉的情况。我建议在所有请求里都显式设置这个参数，不要依赖默认值。设置多少合适？看场景。对话场景一般 512 到 1024 够用，长文生成场景可能需要 2048 甚至 4096。但要注意，生成长度越长，响应时间越长，成本越高，而且模型在长文本后半段的质量可能会下降。

停止序列是另一个容易被忽略的参数。它的作用是，当模型生成的内容里出现你指定的字符串时，立即停止生成。这个参数在结构化输出场景下特别有用。比如你让模型输出 JSON，你可以把停止序列设为右花括号，这样模型生成完 JSON 就停了，不会在后面继续啰嗦。但停止序列有个陷阱：如果模型生成的内容里自然包含了这个字符串，就会提前停止。比如你设停止序列为“###”，而模型在解释 Markdown 语法时正好写了“###”，那就断了。所以停止序列要选那些不太可能自然出现的字符串，比如特殊的标记符。

3.3 频率惩罚与存在惩罚：解决重复生成的实际效果

模型有时候会陷入重复循环，比如一直说“好的好的好的”，或者反复重复同一句话。频率惩罚和存在惩罚就是用来缓解这个问题的。频率惩罚是根据一个词已经出现的次数来降低它的概率，出现次数越多，惩罚越大。存在惩罚是只要一个词出现过，就降低它的概率，不管出现几次。

这两个参数的区别很微妙。频率惩罚更适合控制重复用词，比如你不想让模型反复用“非常”这个词，就调高频率惩罚。存在惩罚更适合鼓励模型引入新词，比如在长文生成时，你希望模型不要一直围绕同一个概念打转，就调高存在惩罚。但这两个参数都不能调太高，否则模型会为了避免惩罚而选择一些不自然的表达，输出质量反而下降。一般建议在 0 到 1 之间调，超过 1 就很容易出问题。

我实测下来的经验是，频率惩罚对解决短文本重复有效，比如对话场景下模型反复说“我理解你的感受”，调频率惩罚到 0.5 左右就能明显改善。存在惩罚对长文生成更有效，比如写报告时模型反复提同一个论点，调存在惩罚到 0.3 左右就有改善。但这两个参数不是万能的，如果模型本身能力不够，或者提示词写得不好，调参数只能缓解，不能根治。

4. 一次完整请求的全链路拆解与瓶颈定位

4.1 从输入到输出的七个阶段

一个请求从你的代码发出，到最终拿到结果，中间经历了七个阶段。理解这七个阶段，是定位性能问题的前提。

第一阶段是输入预处理。包括拼接提示词、插入历史对话、做敏感词过滤、计算 token 数量。这个阶段通常很快，但如果你的历史对话很长，拼接和 token 计算可能会花掉几十毫秒。第二阶段是网络传输到模型服务端。这个阶段取决于你的网络环境和模型服务商的接入点，通常几十到几百毫秒。第三阶段是排队等待。如果模型服务端负载高，你的请求会在队列里等，这个时间完全不可控，可能几秒也可能几十秒。

第四阶段是预填充。模型把你的输入全部读一遍，计算出每个位置的内部表示。这个阶段的计算量和输入长度成正比，输入越长，预填充越慢。第五阶段是逐 token 生成。模型一个词一个词地往外蹦，每生成一个词都要做一次完整的计算。这个阶段的计算量和输出长度成正比。第六阶段是输出后处理。包括拼接流式片段、过滤敏感词、格式化输出。第七阶段是网络传回你的客户端。

这七个阶段里，排队和生成是最大的两个瓶颈。排队你控制不了，只能通过选择负载低的时段或者多模型路由来规避。生成阶段你能控制的，就是输出长度和模型选择。输出越短，生成越快。模型越小，生成越快。所以如果你对响应时间要求高，就要在输出质量和输出长度之间做权衡。

4.2 首 token 延迟与整体延迟的优化取舍

流式场景下，有两个关键指标：首 token 延迟和整体延迟。首 token 延迟是指从发出请求到收到第一个 token 的时间，整体延迟是指从发出请求到收到最后一个 token 的时间。用户对首 token 延迟最敏感，因为只要第一个字出来了，用户就知道系统在响应，心理上就能接受更长的等待。

优化首 token 延迟的手段主要有三个。第一是缩短输入长度，因为预填充阶段和输入长度成正比。你可以通过摘要压缩历史对话、去掉不必要的提示词来减少输入。第二是选择预填充速度快的模型，不同模型的预填充效率不一样，有的模型对长输入优化得更好。第三是使用支持预填充缓存的接口，如果多个请求有相同的提示词前缀，缓存可以大幅减少重复计算。

优化整体延迟的手段主要是控制输出长度。你可以通过设置最大生成长度、使用停止序列、在提示词里明确要求简洁回答来控制。另外，选择生成速度快的模型也很关键，有些模型虽然质量高，但生成速度慢，不适合实时对话场景。我一般会准备两个模型，一个高质量但慢，一个中等质量但快，根据场景切换。对话场景用快的，后台生成用慢的。

4.3 并发压力下的资源分配与限流设计

大模型应用的并发控制和普通 Web 服务不一样。普通 Web 服务的瓶颈通常在 CPU 和内存，大模型应用的瓶颈在模型服务端的配额和你的钱包。如果你不加限制地并发调用，结果就是请求被模型服务端限流，大量请求失败，用户体验极差。

正确的做法是在你的应用层做限流。限流策略要分用户和全局两个维度。用户维度是限制单个用户的请求频率，防止某个用户刷接口。全局维度是限制你的应用对模型服务端的总体请求频率，防止超过配额。用户维度的限流可以用令牌桶算法，全局维度的限流可以用信号量或者漏桶算法。

还有一个容易被忽略的点是超时设置。大模型请求的超时不能设太短，因为模型生成确实需要时间。但也不能设太长，否则请求堆积会拖垮整个系统。我的经验是，流式请求的超时设在 60 到 120 秒，非流式请求设在 30 到 60 秒。超时后要立即释放资源，不要傻等。另外，超时后要不要重试，要看场景。如果是流式请求，已经收到部分内容了，重试会导致内容重复，不建议重试。如果是非流式请求，且确认是网络问题，可以重试一次。

5. 线上高频故障的排查思路与实战技巧

5.1 响应突然变慢的五个常见原因

线上最常遇到的问题就是响应突然变慢。排查思路要从外到内，一层层排除。第一层，先看是不是你的网络问题。用简单的 ping 或者 curl 测试到模型服务商的连通性，如果网络延迟正常，排除网络问题。第二层，看是不是模型服务商整体故障。查一下服务商的状态页，或者用最简单的请求测试一下，如果所有请求都慢，那就是服务商的问题，只能等或者切备用模型。

第三层，看是不是你的请求本身变重了。检查输入 token 数是不是突然增加了，比如历史对话没有正确截断，导致每次请求都带着全部历史。第四层，看是不是并发量上来了。检查你的请求队列长度和线程池状态，如果队列积压严重，说明并发超过了处理能力，需要限流或者扩容。第五层，看是不是模型本身在特定输入下变慢。有些模型在处理某些特定内容时，生成速度会明显下降，比如代码或者数学公式。这种情况只能通过测试不同输入来定位。

排查的时候，建议在日志里记录每个阶段的耗时：请求发出时间、首 token 到达时间、最后一个 token 到达时间、总耗时。有了这些数据，你就能快速判断瓶颈在哪个阶段。我一般会在日志里加一个 trace id，把一次请求的所有相关日志串起来，排查起来效率高很多。

5.2 输出质量下降的排查清单

输出质量下降比响应变慢更难排查，因为“质量”本身很难量化。我的做法是建立一个排查清单，按顺序检查。

第一，检查提示词有没有被意外修改。有时候是代码合并冲突，有时候是配置中心被误改，导致提示词变了。第二，检查模型版本有没有变。模型服务商可能会悄悄更新模型，新版本的行为可能和旧版本不一样。第三，检查参数有没有变。温度、top-p 这些参数如果被调过，输出风格会变。第四，检查输入内容有没有变。如果用户输入的内容分布变了，比如突然来了很多之前没见过的类型，模型表现可能会下降。

第五，检查上下文长度是不是超了。如果输入超过了模型的最大上下文长度，模型可能会截断或者表现异常。第六，检查是不是触发了内容过滤。有些模型服务商会对输出做安全过滤，如果触发了，输出会被替换成安全回复，看起来就像质量下降。第七，检查是不是模型服务商在高峰期降级了。有些服务商在负载高的时候会偷偷用更小的模型来响应，输出质量会明显下降。

排查质量问题时，最重要的是保留现场。每次请求的完整输入、输出、参数、模型版本都要记录下来，方便对比。我一般会抽样保留 1% 的请求日志，既能控制存储成本，又能在出问题时快速定位。

5.3 成本失控的预警与止损手段

成本失控是大模型应用最致命的问题之一。我见过一个项目，上线第一天就烧掉了几千块，原因是一个循环调用没有加退出条件，模型一直在自我对话。避免成本失控，关键在预防，不在事后补救。

预防手段有三个。第一是设置硬性上限。在代码里对每次请求的输入输出 token 数做限制，超过就拒绝。第二是设置预算告警。每天统计 token 消耗，超过预算的 80% 就告警，超过 100% 就自动降级到便宜模型或者停止服务。第三是定期审计。每周 review 一次 token 消耗分布，看看哪些接口消耗最多，有没有优化空间。

止损手段也有三个。第一是快速定位消耗大户。通过日志分析，找出消耗 token 最多的接口和用户。第二是临时限流。对消耗大的用户或接口做临时限流，先止血。第三是切换模型。把非核心业务临时切到便宜模型，等成本控制住再切回来。这里有个经验：便宜模型和贵模型的成本差距可能是十倍甚至几十倍，但质量差距可能只有 20%。所以对于很多场景，便宜模型完全够用，没必要上最贵的。

6. 从会调到懂行的进阶路径

6.1 建立自己的评测集与回归测试

想从会调 API 进阶到懂原理，第一步是建立自己的评测集。不要依赖网上的通用评测，那些和你的业务场景差太远。评测集要来自你的真实业务，覆盖你的典型场景和边界情况。比如你做客服机器人，评测集就要包含常见问题、复杂问题、多轮追问、情绪化表达这些类型。

评测集的规模不用很大，初期 50 到 100 条就够，关键是每条都要有明确的预期输出或者评分标准。评分标准可以是人工打分，也可以是用另一个模型来打分。我一般用人工打分建立基准，然后用模型打分做大规模回归。每次修改提示词、换模型、调参数，都跑一遍评测集，看分数有没有下降。这样你就能客观地知道你的改动是变好了还是变坏了，而不是凭感觉。

回归测试要自动化。把评测集和评分脚本集成到 CI 流程里，每次代码合并前自动跑一遍。如果分数下降超过阈值，就阻止合并。这样做虽然前期麻烦，但长期来看能避免很多低级错误。我踩过的坑是，有一次改了一个看似无关的提示词，结果导致某个场景的准确率从 90% 掉到 60%，因为没有回归测试，上线一周后才发现。

6.2 读源码与论文的正确姿势

懂原理的另一个关键是读源码和论文。但大模型相关的论文浩如烟海，全读是不可能的。我的建议是，先读你用的模型的官方技术报告，了解它的架构、训练数据、能力边界。然后读推理框架的源码，比如你用的推理引擎是怎么做批处理、怎么做缓存的。最后再挑几篇经典论文精读，比如注意力机制、位置编码这些基础组件的原始论文。

读论文不要逐字逐句读，先读摘要和结论，知道这篇论文解决了什么问题，然后读方法部分，理解它的核心思路，最后如果有代码，跑一下代码，看看实际效果。读源码也是，不要一上来就啃最复杂的部分，先从入口函数开始，跟着一个最简单的请求走一遍全流程，把主干逻辑搞清楚，再深入细节。

我个人的经验是，读十篇论文不如把一个推理框架的源码读透。因为论文往往只讲思路，不讲工程实现，而工程实现里的细节才是真正影响性能和稳定性的东西。比如批处理策略、内存管理、并发控制，这些在论文里通常一笔带过，但在源码里能看到具体的实现和权衡。

6.3 动手做一个最小可用的推理服务

最后一个进阶路径，是自己动手做一个最小可用的推理服务。不需要从头训练模型，而是拿一个开源的小模型，自己写一个简单的推理服务，支持流式输出、并发请求、token 计数。这个过程中你会遇到很多在调 API 时不会遇到的问题，比如怎么管理 KV 缓存、怎么做批处理、怎么处理超长输入。

做这个服务的目的不是替代现有的推理框架，而是通过动手理解推理的底层机制。当你自己实现过一遍之后，再回头看那些推理框架的配置项，你就能明白每个参数在控制什么，为什么要那样设。比如批处理大小，你自己实现过就知道，批处理越大吞吐越高，但延迟也越高，因为要等凑够一批才能开始计算。这个权衡在调 API 的时候是感受不到的。

我当初做这个练习花了大概一周时间，用了一个几亿参数的小模型，在一张消费级显卡上跑。虽然性能很差，但收获很大。后来再调线上服务的参数时，心里就有底了，知道每个参数背后的代价是什么。这个练习不需要很深的机器学习背景，只要会写 Python、了解基本的矩阵运算就行。网上有很多教程可以参考，关键是动手做，不要只看。

内容输出完毕。