企业官网建设流程全解析

这个标题是我某天半夜临时建的一个内部备忘录。Strata 是我们那边的统一推理服务层，3.8-Flash-Next 是某开源语言模型项目跑出来的一个轻量分支，参数体量不大，但做生产化接入的时候问题一点不比大模型少。后来这句话被同事转述成“Strata 跑 Q3.8-Flash-Next”，听起来像某种基础设施的验收单，实际上我们确实在很短的时间里把这件事从能跑到跑稳了，过程里有不少值得讲的东西。

这篇文章并不是为了介绍某个模型的版本号。我想记录的是：在一套已有调度能力的内部平台里，把一个 3.8B 级别的开源模型变成可以被业务稳定调用的服务，需要经过哪些估算、接入、调优和踩坑动作。适合正在做模型落地、刚接手部署任务、或者很好奇“小模型为什么也没那么好伺候”的读者。

1. 折腾 3.8 级别模型之前，先把“为什么”捋清楚

1.1 轻量体量不等于部署省心

很多人都以为，参数越小的模型部署越容易，实际上这种体量的模型在真实业务环境里极其容易翻车。大模型配大卡，资源不够就直接挂，行为很明确；3.8B 这种不上不下的模型，反而要反复权衡单卡并发、批处理、KV 缓存、量化损失这些细节。随便一台机器都能装，但要装得稳定、延迟低、不拖垮服务，工作量并不比旗舰模型少多少。

我们这次上线的目标很实在：给内部工具链提供短文本摘要、意图分类、格式化输出这类能力。这些任务对复杂推理要求不高，但对响应速度和并发稳定性很敏感。团队里也讨论过要不要直接上 70B 或者更大参数，最后算了一下夜间批处理量和单次请求成本，发现大部分流量用 3.8B 完全够，而且能在一张卡上同时跑两套不同环境，省下的算力预算可以留给后面做模型迭代。

1.2 Strata 在中间到底扮演什么角色

Strata 这个名字在团队内部不算某个具体软件产品，而是我们对一套“模型统一接入层”的称呼。它的职责很朴素：把模型从裸跑状态包装成可观察、可灰度、可回退的业务服务。业务线不需要自己拼接口，不需要关心模型权重放哪个目录，也不需要自己实现过滤逻辑，Strata 把这些统一收走。

放在这个背景下看，3.8-Flash-Next 就只是一个权重产物，真正要改造的是怎么让它适配这套平台。当时我给自己定了一个标准：接入后必须能在控制台上看到请求并发、推理队列长度、首字延迟和显存水位，否则不算完成部署。这比单纯把模型跑起来难，因为平台层会强加很多约束，而这些约束正是生产环境里必须面对的现实。

2. 算力规划、模型文件形态和运行参数选择

2.1 显存估算不能只看权重体积

很多人拿到一个模型，第一反应是看权重大小。3.8B 参数按半精度算，大约 7.6GB 占用量，按 8bit 量化算大约是 3.8GB 权重体积。但真正决定一张卡够不够的，是四项资源之和：权重、激活值、KV 缓存和临时缓冲。

我当时按照 8192 token 的最大上下文去算，激活值部分在并发不高的情况下预留 2GB 足够，KV 缓存留 4GB 做余量，权重用量化后的形态占 3.8GB，合计也就 10GB 上下。所以单张 24GB 显存的卡理论上很宽裕。可这只是理论上，实际部署后我发现还有两个隐藏消耗：一个是框架调度器预分配的部分中间张量，另一个是推理引擎为了加速解码而常驻的临时缓冲区。这些东西可能悄悄吃 3~4GB 显存，如果不提前留够，上线后第一波压力就可能直接把显存打满。

2.2 模型文件的三种形态：别急着选最快的

模型权重落地到 Strata 之前，通常会先转成适合推理服务的格式。我们对比了三种常见形态，下面用表格整理一下当时的取舍：

我当时第一反应是直接上最激进的量化方案，理由是显存占用小、加载快。但跑了几轮长文本用例之后，发现输出内容在特定领域中开始出现重复词和前后矛盾。后来排查发现，激进量化对注意力权重太敏感，稍长一点的上下文就会放大误差。最终生产环境选的是 8bit 量化，并且保留了一份半精度原始权重用于离线回归对比。

这里有个经验分享：别把量化后的效果好不好寄托在跑通几个短句子上。靠更多参数补充背景，它就是个印象中的提醒，应该至少在超过 2000 token 的输入上做一组成对测试，才能判断量化损耗是否在业务可接受范围内。如果拿手工例子看不出区别，那就拿一批真实业务样本来做输出重合度对比，往往会有意料之外的发现。

2.3 容器配额和底层参数的一次性配置参考

Strata 底层通过容器来管理每个推理服务实例，配置不当会直接限制后面的调优空间。我最后定下来的资源配额如下，这套组合在之后的并发测试中没有出现系统层面的资源争抢：

• CPU：8 核，解码线程和调度线程分开
• 内存：32GB，其中预留 4GB 给加载器和日志缓冲
• 显存：单实例上限 16GB，给同卡第二实例留出余量
• 最大并发请求：单实例 32，超过后拒绝而不是排队
• 最大上下文：8192 token，生成长度限制 2048 token

关于并发数要特别解释一句：Strata 允许把请求排队，但这种排队往往掩盖了推理引擎的瓶颈。我宁可在入口层直接拒绝超出能力的请求，也不愿意让请求无限堆积，因为排队时间一旦过长，业务侧会反复超时重试，最终可能造成更严重的雪崩。所以配额里“拒绝”是比“排队”更优先的策略。

3. 正式接入 Strata 的步骤、接口细节和过滤层

3.1 从权重到服务的四步接入流程

Strata 的接入方式不算复杂，但每一步都有容易忽略的细节。我把完整流程分成四步，这四步的顺序尽量别乱：

第一步，把权重文件同步到模型目录，并把目录权限设置为服务实例可读。这里非常容易踩坑：有些团队的推理服务以前用 root 启动，后来切到低权限用户时，模型目录却没跟着改权限，结果服务能启动但加载到一半失败。

第二步，注册模型版本并指定入口文件。如果一个目录下存在多个口径相近的权重文件，务必备注清楚是原始半精度还是量化版本。我第一次漏了这份备注，回退时差点把量化版本当成原始权重加载。

第三步，配置服务端口和健康检查地址。Strata 会在实例启动后自动发一个探活请求，如果健康检查路径不匹配，平台会把实例误判为失败并不停重启。

第四步，绑定资源配额和并发上限。这一步就是套用上一节列出的配置，启动后先做一次冒烟测试，确认日志里没有任何警告再接入真实流量。

这套流程在内部平台的执行命今形式上其实很短，大概就是由运维侧执行一行实例建立语句、再执行一次流量绑定就完事。但真正把字符串敲进去之前，必须把资源约定写在配置里，否则默认配置大概率会拉爆宿主机。

3.2 接口设计：不是把所有采样参数都透传就完了

推理服务对外暴露一个 HTTP 接口，请求体里除了文本本身，还会携带一组生成参数。团队最初直接照搬模型开源时的默认参数，把 temperature、top_p 全部透传给上层，结果业务侧很快反馈生成结果不稳定。

后来定位到原因：业务方并不清楚这些参数的含义，传入的 temperature 经常超过 1.5，生成结果乱飘，催生了一大批重复句。我们最后改成“白名单参数透传”：temperature、top_p、max_tokens 这三个允许外部设置，但 temperature 被强制截断在 0.8 以下；其余参数全部固定，由服务端配置决定。

这个设计实际上是在保护生成质量和保护业务灵活性之间找一个平衡点。你完全可以把所有参数都开放给上层，但那会让异常排查变得极其困难，因为你根本不知道是哪一层的参数把结果带偏了。建议至少做一层统一配置，保留必要的外部可调项。

3.3 输入输出过滤层，不能只靠模型自我约束

开源模型本身有基本的安全对齐，但在业务场景里不能完全指望它。我们接入 Strata 时挂了两层过滤：

输入侧，请求进来先做关键词分级和敏感命中判断。敏感的请求直接返回明确提示，不进入模型推理，这样做一方面保护模型不被恶意提示词覆盖，另一方面也能减少无效算力消耗。

输出侧，模型生成结束后会做一次校验，命中明显风险的内容会被拦截。同时会记录触发次数和具体片段，方便后续补充过滤词表。

这里一定要强调：任何过滤策略都会存在误伤。所以我们的做法是输入侧从严、输出侧从宽，输出侧只在确定风险时拦截，降低正常业务被错误阻断的概率。日志里保留全部事件，每两周复盘一次误拦率和漏网率，再决定是否调整规则。

4. 三轮调优记录：从“能跑”到“扛得住”

4.1 第一轮：把批处理从 1 提到 8，吞吐量立刻有了质的改善

上线初期，我们的推理服务默认单请求执行，也就是 batch size 固定为 1。压测时单请求延迟确实低，但总吞吐惨不忍睹。一千个并发请求直接把服务打穿，响应成功率往下掉，排队队列堆满了任务。

我随后把批处理参数改为 8，同时开启请求动态拼接。这里的动态拼接不是简单地把 8 个请求硬塞进一个 batch，而是由调度器每 20 毫秒收集一次待处理请求，凑够 8 个再统一推理，没凑够就用短超时兜底。这个机制让显卡利用率明显提升，测试结果如下：

虽然延迟略有上升，但吞吐量翻了三倍多，对于批量摘要类任务来说，这完全值得。可如果把批处理继续调到 16，问题就来了：显存占用超过 16GB，压缩了同卡第二实例的空间，而且尾延迟开始出现明显的放大，个别请求会等前一批长文本完事才被处理。所以批处理 8 成了我们当时的生产配置。

4.2 第二轮：KV Cache 复用是隐藏的吞吐放大器

第一轮调完之后，我本来觉得已经很满意了，但在看详细日志时发现，同一 session 的连续追问请求明明共享了绝大部分上下文，服务端却没有复用之前的 KV 缓存，每次都重新计算一遍前缀。这部分开销极大，尤其是在长文档摘要场景里，同一个文档被反复追问十个问题，就要把前缀重复算十次。

我们随后开启了前缀缓存，让相同会话的前缀只计算一次。效果立刻反映在指标上：连续追问场景下，QPS 从原来的 118 提升到 190，单请求延迟 p95 从 2.6 秒下降到 1.3 秒。代价是缓存会占用少量显存，随着活跃会话变多，占用量会逐渐上升。这里需要一个缓存淘汰策略，我们设定的是闲置超过五分钟的会话直接释放缓存。

这一轮的启发是：模型部署不要只盯着 batch size 和量化，要站在业务真实流量形态上看优化点。如果业务是单轮短问答，前缀缓存几乎没有意义；如果是多轮、长文档高频复用，复用缓存就是一台机器当两台用。

4.3 第三轮：宁可快速失败，也不要无限等待

第三轮的问题来自调用方的超时设置。业务服务调用推理接口时，原先统一设置了 10 秒超时，但生成长文本时经常超过这个时间。于是业务方每 10 秒重试一次，重试请求又叠加到 Strata 队列里，造成队列积压。

我们调整了两端策略：服务端明确返回 429 状态码而不是让请求挂在队列里；调用方收到 429 后退避重试，并把超时放宽到 30 秒。与此同时，Strata 侧把单请求的最大生成时长限制为 20 秒，超过就被强行断开，防止个别长生成任务占用整个推理实例。

从结果看，请求成功率和平均延迟都更健康，因为快速失败反而让系统回到了可控状态。这里要有一个原则：如果无法在约定时间内完成，就立即失败并让调用方感知，而不是把额外交互链堆积成一个隐性的资源吞食器。

5. 翻车复盘：加载即崩溃、间歇超时和版本回退

5.1 灾难现场：模型加载成功，上线五分钟就 OOM

第一次正式接流量的时候，服务健康检查通过，模型加载日志正常，我对这套配置信心很足。但流量上去五分钟，监控开始报警显存占用量直线上升，随后某个实例 OOM 被平台强杀。

排查过程比想象中曲折。

第一步，检查显存占用。加载完成后约 7GB，符合预期，没有异常。

第二步，检查压测期间显存变化曲线。发现只要请求到来，显存会额外增加 3~4GB，而且不随请求结束释放。

第三步，逐条关闭配置项做二分定位。关闭动态批处理之后，现象消失，说明问题出在批处理机制预分配了临时缓冲。

第四步，确认原因：该推理服务在批处理模式下会按最大 batch 预分配完整中间张量，即便每个 batch 只有两三个人，也要按上限 8 人准备空间。长上下文的叠加放大，让这个预留空间超出了预期。

第五步，修复方案：不改变 batch 上限，改为缩小最大上下文预留窗口，并把临时缓冲区改为按需扩展，而不是一次性分配最大值。

这个问题的关键在于，显存规划不能只看权重和 KV 缓存，要连推理框架的内部预留机制一起考虑。预估时要留出 25% 的缓冲空间，尤其是开启动态批处理之后。

5.2 另一类翻车：批处理扩大后，输出出现大量重复

还有一次值得记录。压测时把 batch size 调到 16，显存还够用，但生成的文本频繁出现整句重复，像复制粘贴了一样。我当时以为是模型量化有问题，试了原始半精度权重仍然复现，排除权重因素。

接着看日志，发现重复现象主要集中在某些固定长度区间。后来核对生成参数时才意识到，批量推理时调度器为了不阻塞同一个批次，自动把采样时的随机种子重置了。种子一致会让批量中的较短请求几乎产生高度相似的输出，长度稍长之后又因为贪心路径进入重复循环。

修复方式也很简单：关闭批量内种子固定，让每个请求沿用自己的随机种子；同时对复读模式做了一层检测，检测到连续两段高度重复时主动调整采样温度。这部分属于很难从官方文档里直接看到的生产经验，建议所有做批处理的人提前注意。

5.3 回退策略：事先准备好一条龙

调优过程中我们也碰到过一次模型版本更新带来的不稳定。新版权重在离线评测上分数更高，但上线后某些领域格式变得奇怪，生成列表时总是多出无意义的标号。当时没有犹豫，直接回退到上一个稳定版本。

Strata 对这种操作的支持很成熟，仅需将流量网关指向上一版实例即可。所有请求立刻过渡到回退实例，新版本保留一天用于抓取现场数据，然后下线。回退前很重要的准备工作是：模型版本目录里保留完整的历史权重文件，不能只留最近一个版本。

回退这个动作没有什么技术含量，难的是触发回退的判断标准。我们的判断条件是：在线错误率连续十分钟超过阈值，或者用户反馈某类输出格式异常超过三条人工复现，就进入回退流程。建议每个接入新模型的团队，都在切流量之前把这条标准写成文档，避免人脑在深夜面对告警时犹豫。

6. 一些没有写进官方文档的经验

整个项目跑下来，有几个体会一直想找人说一说。

第一个是：轻量模型在生产环境中，往往比大模型更依赖周边工程。3.8B 的参数规模决定了单次推理成本很低，也因此更容易被业务放大并发，所有微小的配置问题都会被流量倍数放大。你不能拿跑通一个 demo 的心态来做生产接入。

第二个是：调优的顺序很重要。建议先调批处理和资源配额，再考虑量化格式，最后才去动采样参数。批处理是结构性问题，采样参数是表现层问题，结构不对时再怎么调温度也只是给错误配置打补丁。

第三个是：所有优化都要为回退留好后路。模型中可能某个版本在长文本上更好，但另一些场景会退化。永远保留至少一个已知稳定的历史版本，比所谓“最新最优”更可靠。

如果后面有机会把 Strata 上的另一套大模型也接入进来，我觉得这次沉淀的接入流程、参数白名单和回退标准都可以直接平移复用。模型的参数变了，成本和显存规划变了，但生产接入的骨架几乎不用改，这也是我们这轮折腾下来最值钱的部分。