企业大模型私有化部署：采购前先验证服务容量

推理评测正在把更多业务步骤纳入边界

MLCommons 于 2026 年 9 月 17 日发布的 MLPerf Inference v6.1 分析指出，本轮增加了端到端 RAG 与边缘智能体推理评测。RAG 是检索增强生成，即先检索资料，再由模型形成回答；智能体工作负载则可能包含多轮模型调用。这是近期可核实的评测范围变化，不是所有企业采购行为已经改变的统计证明。[1]

本文由此提出一个采购判断：当应用由单次生成扩展为多个组件协作，验收边界也应覆盖用户实际等待的流程。数据库检索、文档解析或工具响应如果占用了大部分时间，更换生成模型的显卡未必解决交付延迟。已有系统需要先测清耗时位置，集成商则需要明确自己承诺的是模型接口速度，还是完整任务的完成时间。

标准基准依然有价值。MLPerf 为不同测试规定负载场景、质量目标和结果分类，可帮助比较满足共同条件的系统。[2] 但企业材料长度、业务工具和高峰流量并不必然匹配标准负载。合理的使用方式是用公开结果筛选候选，再用本企业任务验证容量，而非把榜单名次直接写成现场承诺。

先区分三类任务，再讨论支持多少人

建议把需求拆为交互问答、长任务和批处理。交互问答关心用户等待首个有效内容及完整答案的时间；长任务关心最终材料何时可交付、进度是否可见；批处理关心在截止时点前能否完成一组工作。相同账号数下，这三类任务会产生不同负载。

需求记录至少包括输入与输出长度的分布、任务到达时间、单任务模型调用次数，以及共享资料或前缀的比例。长度应按候选模型的分词器统计，不能把中文字数直接当作 token 数。平均长度也不够：少量超长请求可能决定内存压力，集中提交可能决定排队时间。

容量单位宜是“特定任务组合下每分钟接受多少请求、其中多少按期完成”，而非笼统的“支持百人”。一百名偶尔查询的用户与十名同时分析长文档的用户，不能用人数直接比较。首次试点没有真实日志时，可以先建立标注清楚的负载假设，再用试运行数据替换。

显存、排队与生成速度为什么不能分开看

生成模型先处理输入，再逐步生成输出，通常分别称为预填充与解码。DistServe 的研究分析了两阶段共同运行时的资源干扰，并以同时满足首个输出延迟和每个输出 token 耗时约束为优化目标。[3] 这说明，同一模型在不同输入长度和任务组合下，服务表现可能不同；本文不把该论文的性能增益外推到企业单机。

运行时还要容纳请求的 KV 缓存，即注意力计算使用的键和值状态，以及其他工作空间。vLLM 的调优文档说明，KV 缓存不足可能引起抢占与重计算，影响端到端延迟。[5] 因此，模型权重能加载只满足一个条件；长上下文和并发请求还需要现场测试。

本文建议同时观察排队长度、内存余量和任务延迟。若延迟增长主要来自等待，先评估限流和长短任务分队；若来自长输入处理，检查输入裁剪、必要资料选择与前缀复用；若来自业务工具，先治理工具链。分离预填充和解码是集群层面的候选方案，也会引入传输与运维复杂度，不应成为小规模部署的默认配置。[3]

把服务容量写成四项可以复测的约定

第一项是质量底线：用代表真实任务的样本规定答案或产物的合格条件，并记录模型版本、量化方式、提示配置与数据版本。为了提高速度而换用更小模型、降低精度或截短输入后，应重新验证质量。仅比较 tokens/s，会遗漏输出已经不能满足业务要求的情况。

第二项是时间边界。vLLM 的基准文档把 TTFT 定义为客户端发出请求到收到首个流式输出的时间，并区分逐请求的 TPOT 与流式输出之间的间隔。[4] 企业还应测量从用户提交到最终可用结果的总时间；首个输出可能只是中间内容。报告中要写清测量起止点、分位数和失败处理，不能仅以平均值代表体验。

第三项是负载边界：在固定任务组合下逐级增加到达速率，记录按期成功完成的任务数除以观测时长，同时报告超时、拒绝、错误和未完成任务。本文将其称为该任务组合的有效完成速率。质量验证另列，不应把工具中的性能 goodput 自动解释为业务正确率。

第四项是故障边界：一个服务实例停止、模型重启或依赖暂时不可用时，哪些任务仍须按期完成，哪些可以排队，哪些必须回到人工流程。正常状态下刚好够用的配置，不等于具有备用容量。若企业允许维护窗口，单机可以是合理选择，但要把可接受中断和恢复办法明确写入交付条件。

一个构造示例：先调度，再决定是否增加设备

假设某企业每天有 600 次内部问答，其中 120 次集中在十分钟内提交，其余分散发生。高峰到达速率为每分钟 12 次。再假设候选配置在约定质量检查和延迟目标下，持续只能处理每分钟 8 次同类请求。以下均为算术推演，并非壹典项目数据、实测结果或通用性能指标。

若所有请求均被接受、处理速率保持不变且不发生取消，十分钟结束时约积压 40 个请求。即使之后不再有新请求，也需约五分钟清空。这个简化计算没有模拟随机服务时间，不能预测某个用户的精确延迟；它已足以否定“全天总量不大，所以高峰一定够用”的判断。

若高峰期间另有可延后的文档批处理，应先暂停或迁移该批处理，再压测问答容量。若每分钟 8 次已经是独立问答的上限，仅移动批处理并不能解决每分钟 12 次的需求。此时可增加资源、允许更长等待，或在质量复测通过后采用分级模型；最终选项取决于业务能否接受这些改变。

增加第二个实例也不能未经测试就把容量乘二。共享检索服务、存储、网络和负载分配仍可能限制整体表现。应重放同一负载，并验证一个实例失效后的容量，再决定是否足以支撑承诺。

采购比较应保留峰值，也保留低利用率的反例

持续稳定的内部负载、明确的数据边界，以及具备维护能力的团队，通常更适合认真评估私有化。若需求高度波动、任务仍在探索，且数据使用条件允许，外部托管服务可能减少闲置设备投入；混合方式也可将适合外部处理的任务分流。以上是有条件的工程与经营判断，不是关于哪种部署必然更便宜的结论。

比较时固定相同质量与时间要求，再分别列设备投入、实施维护、能耗、备用容量和故障处置成本。单机加人工应急、双实例冗余、内部服务加合规分流，应被视为不同服务方案。不能把没有备用能力的报价与包含持续服务承诺的报价直接比较。

可以要求供应方提交一份容量证据包：脱敏任务样本和到达轨迹、完整环境版本、质量结果、各负载档的延迟与失败记录、恢复演练记录，以及适用范围。该包应能在目标环境复测；若只能提供一张吞吐截图，采购依据仍然不足。

从配置验收到服务验收

对正在建设企业 AI 的团队，下一步可以很具体：选择一类高频任务，确定质量与时间要求，采集一个有代表性的高峰窗口，在候选环境中重放，再检查故障时如何交付。没有把握的数据先写成假设，不以想象中的未来用量一次性扩大采购。

本文建议最终决策分为可承诺、需约束和待验证三种：可承诺的任务进入服务范围；需约束的任务写明长度、并发与截止时间；待验证的任务保留试点身份。这样，设备配置有了对应的业务边界，后续扩容也有了可比较的证据。本文引用的在线技术文档核查于 2026 年 10 月 1 日；实际验收应冻结所用软件版本，不默认动态文档与现场环境一致。