14 模型负载

14.1 分词入口

没有负载分布，就没有容量结论。支持 128K 上下文、平均每请求 2000 token、模型 70B 参数，这些都不是完整的负载描述。推理系统处理的是一串不断到达、长度不同、共享状态不同的请求；同一个模型在短问答、长文档和 agent 工作流下，会把压力放到完全不同的资源上。本章先把负载这个词定义清楚，后面所有性能和产能数字都要挂在它上面。

文本进入模型前先过分词器（tokenizer），被编码为整数序列。分词不是简单按字或按词切：常见流水线包含规范化、预分词、子词模型和后处理，BPE、Unigram 等算法会让同一段文字得到不同 token 序列。核这件事同时改变技术负载和账单：token 数决定输入长度、KV 缓存容量和计算量，API 又按输入、输出或缓存 token 计量。同样一页中文、英文或代码，在不同分词器版本下没有固定 token 数。比较价格或容量前，必须用目标模型的分词器和对话模板重算，字符数或另一个模型的账单都不能代替。批处理还会遇到补齐和截断：补齐带来无效计算，截断丢内容，产品要明确超长内容是拒绝、截断、摘要还是拆成多轮。

14.2 上下文窗

上下文窗口是模型一次请求允许看到的 token 范围，不是免费仓库。模型卡标注 128K 只证明接口支持范围，不证明每种 128K 输入都有同样质量，更不证明延迟、吞吐和成本不变。长上下文同时改变两个阶段：prefill 要处理更长输入，注意力和矩阵运算增加；decode 要保存并反复读取更大的 KV 缓存。对密集 KV 缓存，可用一个近似式做第一轮容量规划：KV 显存约等于 2 乘 层数 乘 缓存 token 数 乘 KV 头数 乘 头维度 乘 每元素字节 乘 活跃序列数。这个式子不含块分配、并行切分、共享前缀和运行时余量，只适合数量级检查；采用分组查询注意力或滑动窗口的模型，增长系数会不同，不能一个公式套所有模型。核

14.3 三类负载

三类典型负载压的是不同资源。短问答输入输出都短，但到达率高、交互性强，对首字延迟的高分位最敏感。长文档让 prefill 和 KV 变重，单个请求就可能占据大量显存。agent 工作流会经历多轮模型调用、工具等待、共享系统提示、重试和长度变化，一次用户任务在后端展开成多次请求。因此负载必须用分布描述，不能只给平均值：

模型版本也是负载定义的一部分：同名模型可能有不同权重、分词器、上下文配置、对话模板和量化，一次可复现实验必须固定权重哈希、分词器文件和模板。模型能力指标与服务指标还要分开：准确率回答输出是否有用，延迟和错误率回答系统怎样交付；量化或截断可能改善服务容量却让质量下降，一个合格的优化必须同时守住质量门槛和服务门槛。

14.4 负载合同

8K 输入、1K 输出这样一句测试说明，仍然缺四项关键信息。

• 8K 是固定值、上限，还是平均
• 1K 是强制生成，还是最多生成
• 提示词是自然文本、随机 token，还是共享系统提示
• 请求是一次性发出、固定并发循环，还是按独立到达过程进入

这四个选择会改变 prefill、KV、缓存命中和队列。一份可执行的负载说明应包含四类字段：内容（语言、领域、模板、质量标签）、形状（输入输出 token 的联合分布）、时间（到达率、突发、会话间隔、持续时间）、状态（共享前缀、多轮历史、缓存命中、取消与重试）。另一支团队只有拿到这四类字段才能复现实验。输入和输出长度还可能相关：agent 的工具返回会扩大下一轮上下文，分别随机采样会破坏真实相关性，容量模型最好从脱敏的生产追踪抽样，保留联合分布。

14.5 数据陷阱

三个常见数据集陷阱。第一是随机 token：便于控制长度，却没有自然语言的前缀和停止行为，适合测底层形状，不能代表产品流量。第二是复制同一个提示词：制造极高的前缀缓存命中，适合测缓存上界，不能当一般吞吐。第三是只保留成功请求：被截断、取消、超时和重试的请求也占过资源，删掉它们会系统性低估容量。上线前至少建四套负载集：单请求微基准确认阶段下界，标准混合负载做版本回归，高峰突发负载测准入和队列，真实业务回放做最终验收。服务方容易展示短、整齐、可批处理的样本，客户带来的长尾、重试和多轮调用才是抬高成本与尾延迟的部分，最终验收必须保留真实分布。