运营模型卡：实验室不发布的部署文档

模型卡会告诉你模型是否经过了针对CBRN误用的红队测试，以及它对哪些人群服务不足。但它不会告诉你：在10,000个并发请求下的p95 TTFT、性能在上下文窗口80%处出现的断崖、复杂JSON模式的格式错误率，或者自模型卡发布以来模型行为漂移了多少。

这种差距是结构性的，而非偶然。模型卡设计于2019年，用于公平性和安全性文档，目标受众是公民社会组织和监管机构。构建生产系统的工程团队并不是其使用场景。七年的推广之后，这一框架依然未变——而将模型卡视为部署规范的代价从未如此高昂。

2025年基础模型透明度指数（斯坦福CRFM + 伯克利）证实了这一遗漏的范围：OpenAI在100项透明度指标中得24/100，Anthropic得32/100，Google得27/100。平均分从58分降至40分，这意味着随着模型能力增强，AI透明度不升反降。四大主要实验室均不披露训练数据构成、能源使用情况或与部署相关的性能特征。

以下是自行生成运营模型卡的测试套件——无论实验室发布了什么，在将模型投入生产之前你都需要的文档。

实验室卡覆盖的内容（以及未覆盖的内容）

已发布的模型卡遵循可辨识的模板：MMLU、HumanEval、GPQA分数；安全红队测试结果；对齐评估；知识截止日期。这些对于评估模型向用户公开是否安全确实有价值。

但这不是运行模型的文档。缺少的内容：

• 延迟规格。 没有p50/p95/p99 TTFT。没有代表性并发下的吞吐量数据。没有延迟-上下文长度曲线。无服务器部署的冷启动时间：完全缺失。
• 上下文窗口退化。 宣传的窗口大小不是实际的可靠限制。对于当前大多数模型，两者相差30-50%。
• 结构化输出失败率。 不同模式复杂度下的JSON模式遵从性。当模型无法遵从时会发生什么——是明确报错还是用貌似合理的垃圾数据填充必填字段？
• 特定任务可靠性。 同一模型在有依据的摘要、提取和工具调用方面的准确率表现不同。聚合基准分数掩盖了这一点。
• 行为稳定性。 自模型卡编写以来，模型行为发生了多大变化？命名版本固定（如gpt-4o-2024-08-06）不能保证行为稳定。
• 缓存行为。 提示缓存命中/未命中延迟差异。最小缓存阈值。TTL。这些在已发布的文档中均未出现。

这不是在抱怨实验室保密。问题在于模型卡回答的问题与工程团队提问的问题不同。

延迟分析

首先要测量的是延迟分解：首个令牌时间（TTFT）和令牌间延迟（ITL）行为不同，需要不同的干预措施。

TTFT由预填充主导。它随提示长度变化——对于标准注意力机制，大约是O(n²)。一个10,000个令牌的提示预填充时间明显长于1,000个令牌的提示，且关系非线性。这很重要，因为许多生产故障隐藏在P99中：一个平均TTFT为200ms的系统，在并发峰值下同时可能有3,000ms的P99。

ITL一旦模型开始生成就受内存带宽限制。它更具可预测性，但对批量大小和硬件敏感。在高并发下，排队效应占主导地位。

要生成有用的延迟文档，在代表性提示长度（短、中、长）和代表性并发级别（1、10、50、100个并发请求）下运行测试，记录：

• 每种组合的TTFT（p50、p95、p99）
• ITL（p50和p95）
• 典型长度输出的总请求延迟

冷启动是单独的测量。如果你在无服务器或使用缩放到零的基础设施上部署，冷热推断之间的延迟差距是巨大的——冷容器通常需要30-120秒，而热容器需要200ms。这个差距应该与相应的架构含义一起写入你的运营文档：缩放到零通常与交互式延迟要求不兼容。

提示缓存行为也值得单独描述。缓存命中可以将TTFT减少50-85%，并将令牌成本降低80-90%。对预期会被缓存的内容发生缓存未命中是延迟回归的常见来源，看起来像是模型性能问题。

上下文退化曲线

宣传的上下文窗口是模型无错误接受的最大值。它不是模型可靠使用上下文的范围。

经验结果——在多个模型中有记录并反复验证——是U形性能曲线：当相关信息出现在上下文的开头或结尾附近时，准确率达到峰值，而当它在中间时则大幅下降。当相关文档从20个文档中的第1位移到第10位时，多文档问答准确率下降30-60%是典型情况。

更近期的研究量化了即使模型具有完美检索访问时的退化：在数学推理、代码生成和问答任务上，随着输入长度增加到宣传限制，准确率退化14-85%。当前没有任何前沿模型免疫。Llama-3.1-8B-Instruct在30,000个令牌的知识任务上显示准确率下降24%；Llama在相同长度的算术任务上下降48%。

实用经验法则：可靠性能通常在宣传上下文窗口的约50%处开始明显退化。对于具有128K令牌窗口的模型，在可靠性重要的任务中，将50,000个令牌作为实际限制。这应该出现在你的文档中，配以特定任务的测量，而非通用估计。

要描述这一点，在宣传窗口的10%、25%、50%、75%和100%处运行你的代表性任务类型——模型在生产中实际要做的任何事情。记录每个级别的准确率。结果曲线是你能产生的最有用的运营文档之一。

结构化输出失败率

结构化输出可靠性在过去两年中有了实质性改善，但不同可靠性层级之间的差距对你设计错误处理方式很重要。

使用约束解码（语法采样输出、原生结构化输出模式），语法正确请求的模式遵从性超过99.9%。如果使用正确的工具，这基本上是一个已解决的问题。

未解决的是：语义正确性。模式遵从意味着输出与声明的形状匹配。这不意味着值是正确的。模型会自信地用看起来合理的浮点数填充confidence_score字段，或在任务被放弃时将status字段标记为"complete"，因为拒绝填充必填字段比编造一个值更难。

从原始文本到正确、可信输出之间存在八个可靠性层：语法有效性、模式遵从性、引用完整性、语义准确性、逻辑一致性、时间有效性、策略遵从性和推理合理性。约束解码强制执行前两层。其余六层需要单独验证——或者一个不假设模式有效响应就是正确响应的架构。

要描述你的模型的结构化输出行为，在三个模式复杂度级别上测试模式遵从性：简单（平坦，3-5个字段）、嵌套（2-3层嵌套）和数组密集型（具有约束元素的对象数组）。还要测试语义有效性：模式有效输出中包含事实错误、内部矛盾或貌似合理但不正确值的百分比是多少？这更难自动化，但更值得了解。

行为稳定性

模型行为会随版本漂移。这是有记录的，而非推测。斯坦福和伯克利追踪2023年3月至6月GPT-4行为的研究发现：质数识别准确率从84%降至51%，该任务的思维链推理从97.6%降至2.4%的响应，可直接执行的代码从52%降至10%的输出——所有这些都没有发生主要版本更改。

这种模式延续到了更近期的模型版本。命名版本固定减少但不能消除行为漂移。一项监控研究发现GPT-4在监控期间响应长度变化23%；Mixtral在指令遵从方面表现出31%的不一致性。

你的运营文档应该捕获行为基线：一组参考输入和预期输出特征（不是精确输出，而是基于属性的期望），你可以将未来的模型行为与之比较。当模型更新到来——或者你在评估是否升级到更新版本时——对这个基线运行测试会给你一个具体的信号，而不是依赖回归是否在质感上感觉不同。

这也是检测静默模型替换的机制。一些供应商在没有版本升级的情况下发布了模型更新。一套特征探针——边缘情况响应、校准输出、已知能力标记——与生产流量并行持续运行，可以捕获这类不可见的变化。

智能体失败模式

如果模型被部署在智能体环境中——进行工具调用、采取多步骤行动——失败模式会转变。单轮任务的基准无法预测这些。

对三个前沿模型（参数从32B到671B不等）在文件系统、文本提取、CSV分析和SQL任务上的900个执行跟踪分析发现，成功率在58.5%到92.2%之间。在所有模型中出现的失败原型：

• 未经确认的过早行动。 猜测数据结构而不是先检查它。
• 不确定性下的过度帮助。 用貌似合理的值替代缺失实体，而不是返回null或请求澄清。
• 上下文污染。 上下文中的干扰数据导致错误的推理路径。
• 认知负荷下脆弱的执行。 随着任务复杂性增加，出现格式错误的工具调用、生成循环和不一致的错误恢复。

造成最多生产损害的失败通常是不确定性下的过度帮助。返回null或要求澄清的模型比自信地编造看起来合理答案的模型更容易处理。描述你特定用例的这种行为——模型如何响应不完整、模糊或对抗性输入——应该与对干净输入的准确性一起出现在你的运营文档中。

构建测试套件

运营模型卡的测试套件分三个阶段运行：

基线描述（在任何部署之前运行）：

• 在代表性并发下的TTFT和ITL（p50/p95/p99）
• 冷启动时间和预热行为
• 宣传窗口25%、50%、75%、100%处的上下文退化曲线
• 提示缓存命中/未命中延迟差异
• 简单、嵌套和数组密集模式的模式遵从率
• 模式有效输出的语义正确率（如果无法自动化验证，则进行抽样人工审查）

特定任务可靠性（在你的实际生产任务上运行）：

• 你领域200-500个代表性样本的准确率
• 你文档类型的幻觉率
• 失败模式行为：模型如何处理不完整输入、非常长的输入、对抗性输入？
• 你的智能体实际使用的工具的工具调用成功率

漂移检测（每次模型版本更新时运行）：

• 对1,000个参考示例的行为基线比较
• 延迟回归比较
• 结构化输出失败率比较

支持这一点的工具：GuideLLM（Red Hat / vLLM项目）模拟可配置的生产工作负载并测量TTFT、ITL和吞吐量；Langfuse和Arize Phoenix提供生产追踪；DeepEval支持自定义特定任务指标。

团队为何跳过这一步（以及为何后来会改变）

数百个LLM生产部署记录的典型模式：团队快速达到80%的质量，然后将大部分开发时间花在从80%到95%的差距上。在第二阶段出现的失败——长文档的上下文退化、结构化输出语义失败、模型更新后的行为漂移、规模下的延迟回归——正是预生产测试套件本可以描述的失败。

跳过运营描述的团队不会立即失败。他们在六个月后失败，那时他们已经弃用了之前的模型，那时他们的用户已经建立了期望，那时架构已经围绕关于模型行为的假设建立，而实验室从未承诺过这些假设。

已发布的模型卡回答"这个模型安全吗？"你的运营模型卡回答"这个模型在我的系统中能用吗？"两者都是必要的。只有一个是你的工作。

模型提交前的最终检查清单

在弃用你的前一个模型并将新模型提交到生产之前：

• 在目标并发下测量TTFT p95——在SLA预算范围内
• 在你的代表性提示长度下测量上下文退化曲线
• 在你的模式复杂度级别下了解模式遵从率——理解它，并据此设计错误处理
• 在领域代表性输入上抽样语义失败率——可接受或已缓解
• 捕获行为基线以供未来漂移比较
• 如果使用无服务器或可变容量基础设施，描述冷启动行为
• 为你的提示模式测量缓存命中率和命中/未命中延迟差异

在提交模型后才发现其生产限制的团队，是那些将实验室发布的基准视为规范的团队。他们希望得到那份文档并没有错——它应该存在。只是它还不存在。在它出现之前，测试套件是你来运行的。