容量估算题

容量估算不是要求你在面试现场算出一个绝对准确的数字，而是看你能否先澄清口径，再用可解释的假设完成数量级估算，最后把结果落到机器数、存储、队列、成本和 SLO 上。

使用方法

估算客服容量时，先把“每天一百万用户”换成真实问答次数、活跃时段和峰值，再拆模型、检索、工具和存储。一个数字没有口径，就像只说要准备很多饭，却没问来几桌客人。

建议按下面的顺序回答每道题：

1. 先问清楚用户规模、请求类型、峰值比例、SLO 和数据保留周期。
2. 统一单位，把每天请求换算成平均 QPS，再乘峰值系数和安全余量。
3. 把一次请求拆成输入 Token、输出 Token、模型调用次数、检索和工具调用。
4. 区分平均值和尾部值。机器数通常按峰值和 P95/P99 约束，而不是按平均 QPS。
5. 给出一个基线方案，并说明哪些参数需要压测或线上观测来校准。

常用换算：

平均 QPS = 日请求数 / 86400
峰值 QPS = 平均 QPS × 峰值系数
并发数 ≈ QPS × 平均响应时间（Little's Law）
月度 Token = 日请求数 × 每请求 Token × 计费天数
实例数 = ceil(峰值负载 / 单实例稳定处理能力) × 冗余系数

估算时优先使用 1 万 = 10^4、1 百万 = 10^6 这样的数量级，最后再说明误差来源。不要把“每台机器理论峰值”直接当作“生产可用容量”，需要留出模型波动、故障、扩容和突发流量的空间。

一、通用估算方法

Q1：面试官只说“设计一个日活 100 万的 AI 问答系统”，你会先问什么？

考察点

• 能否把 DAU 转换为真正影响容量的请求量。
• 是否意识到交互问答、批处理和异步任务的资源模型不同。
• 是否会先确认 SLO、数据和多租户边界。

回答脉络

先问业务动作和时间分布，再问单次请求的模型、Token、检索和工具调用，最后确认可靠性、合规和增长假设。没有这些口径，直接报机器数量没有意义。

参考答案

我会先确认：

• 100 万是注册用户、日活用户，还是每天实际提问次数？每个用户平均提问几次？
• 流量是否集中在工作日和工作时间？最高 5 分钟峰值是平均值的几倍？
• 请求是同步问答、流式对话，还是包含文档解析、批量总结等异步任务？
• 每次请求的输入、输出 Token 大概多少，是否可能多轮、调用工具或触发 RAG 多路检索？
• 使用第三方模型 API、自建模型，还是两者混合？供应商的并发和限额是多少？
• 目标是 P95 首 Token 多少、P95 总耗时多少、成功率多少？是否要求跨可用区容灾？
• 数据库、向量库、原始文件和日志分别保留多久，是否按租户隔离？

例如确认每天 100 万次问答、平均每人 2 次、工作时段占全天 30%、工作时段流量占全天 70%，我会先算日均 QPS，再用工作时段分布和 5 分钟突发系数得到峰值 QPS。模型、检索和存储分别估算，最后用压测数据替换假设值。

追问或扣分点

• 只根据 DAU 直接说“需要 100 台 GPU”，没有询问请求次数和模型形态，会被认为没有容量口径。
• 把平均 QPS 当成峰值 QPS，忽略工作日、活动和局部热点。
• 没有问数据保留和租户隔离，后面的存储和缓存估算会失真。

Q2：如何把日请求量换成平均 QPS 和峰值 QPS？

考察点

• 基本单位换算。
• 峰值系数和安全余量的使用方式。
• 是否知道要区分长周期峰值和短时突发。

回答脉络

先算平均 QPS，再按照业务时间分布得到活跃时段 QPS，最后叠加短时峰值系数和容量余量。所有系数都要标明是业务假设还是压测结论。

参考答案

假设每天 100 万次请求：

日均 QPS = 1,000,000 / 86,400 ≈ 11.6

如果 70% 请求集中在 8 小时内：

活跃时段平均 QPS = 700,000 / (8 × 3,600) ≈ 24.3

如果活跃时段的 5 分钟峰值是活跃时段平均值的 4 倍：

峰值 QPS ≈ 24.3 × 4 ≈ 97

实际部署不会按 97 QPS 刚好打满。我会再留 30%～50% 的容量余量，或者按 峰值 QPS / 单实例稳定 QPS 计算并向上取整。若存在发布、促销、月末结算等特殊事件，还要单独估算事件峰值，不把短时突发隐藏在一个平均系数里。

追问或扣分点

• 直接用 100 万 / 24 小时 作为机器容量，忽略流量集中。
• 峰值系数没有来源，也不说明需要压测校准。
• 只估算入口 QPS，不继续拆到模型、向量库和工具调用的下游 QPS。

Q3：为什么要用 Little's Law 估算并发？

考察点

• 是否理解并发和 QPS 不是同一个概念。
• 能否把长响应时间、流式请求和连接占用联系起来。

回答脉络

给出 L = λW，再说明它是稳定系统中的近似。在线服务还要区分活跃请求、排队请求和保持连接的流式请求。

参考答案

Little's Law 表示系统平均在途请求数 L 约等于到达率 λ 乘平均停留时间 W。如果峰值 QPS 是 100，平均端到端耗时是 8 秒，那么在途请求大约是：

并发数 ≈ 100 × 8 = 800

对于流式问答，连接可能保持 10～30 秒，即使模型已经开始输出，网关、连接池、事件循环和会话状态仍然占资源，所以不能只看首 Token。若系统有排队，W 还包含排队时间；这时要分别观测活跃执行数和等待队列长度。估算连接数、内存和限流时，我会用 P95 或压力场景下的响应时间，而不是只用平均值。

追问或扣分点

• 说“100 QPS 就是 100 并发”，没有考虑响应时间。
• 把排队中的请求算成模型正在执行的请求，导致 GPU 并发估算偏大。
• 没有设置最大并发和排队超时，最终只能无限堆积。

Q4：容量估算中的安全余量应该怎么定？

考察点

• 是否会处理不确定性，而不是给出虚假的精确数字。
• 能否解释余量和冗余的区别。

回答脉络

先区分流量余量、性能余量和故障冗余，再结合增长周期、扩容速度和 SLO 选择系数。余量需要通过压测和线上曲线持续校准。

参考答案

我会把容量拆成三层：

• 波动余量：应对 5 分钟或 1 小时内的流量波动，常从 20%～50% 起步。
• 增长余量：覆盖未来一段时间的用户增长和业务活动，通常按照月度预测计算，而不是永久固定一个百分比。
• 故障冗余：例如要求单可用区故障后仍能承受峰值，则至少要让剩余可用区有足够容量。

例如当前峰值 100 QPS、单实例稳定能力 20 QPS，按 40% 性能余量需要 7 个实例；如果还要求任意一个实例故障不影响 SLO，可以再按 N+1 或跨区副本计算。这里的 40% 不是定律，要通过压测观察 CPU、GPU、队列、P99 和错误率接近饱和时的行为。对第三方 API，还要把供应商限额作为硬上限，而不是用内部实例数掩盖外部瓶颈。

追问或扣分点

• 把余量和高可用副本混为一谈。
• 余量过大却不说明成本，或余量过小导致峰值时排队爆炸。
• 忽略扩容耗时：自动扩容需要几分钟时，不能只准备刚好够用的容量。

二、Token 与模型调用

Q5：如何估算一个问答系统的 Token 量？

考察点

• 能否拆分用户输入、系统提示、工具定义、历史消息、检索上下文和输出。
• 是否注意多轮对话和重试会放大 Token。

回答脉络

先给单次请求的 Token 账本，再乘模型调用次数、日请求量和缓存命中率，最后区分输入、缓存输入、输出和推理 Token。

参考答案

单次请求的输入可以拆成：

输入 Token = 系统提示 + 工具定义 + 对话历史 + 用户问题 + RAG 上下文
输出 Token = 答案 + 结构化字段 + 可能的推理/工具调用参数

假设系统提示 1,000、工具定义 1,500、历史 2,000、用户问题 200、RAG 上下文 4,000，平均输入约 8,700 Token；输出 800 Token。若一次任务平均触发 1.4 次模型调用，则每个用户请求的模型处理量约为 9,500 × 1.4，还要考虑失败重试和多 Agent 分支。缓存命中时，稳定前缀的计费和计算量可能不同，必须使用供应商返回的 cached_tokens，不能简单把所有输入都按普通输入价格计算。

我会用 tokenizer 对真实样本做 P50、P95，而不是只取一个平均字符串长度，并把超长请求截断、摘要或拒绝策略计入容量设计。

追问或扣分点

• 只计算用户问题，不计算系统提示、工具 schema、历史和检索上下文。
• 说“每请求 1,000 token”，却不说明长尾输入如何处理。
• 把推理 Token、缓存 Token 和普通输入 Token 当成一种价格。

Q6：如何根据 Token 估算第三方模型 API 的月度成本？

考察点

• 成本分项和价格版本意识。
• 是否把失败重试、embedding、rerank、OCR 等成本算入总账。

回答脉络

按照输入、缓存输入、输出和其他服务分别建立成本公式，用 P50/P95 估算区间，最后以供应商 usage 和账单校准。

参考答案

假设每天 100 万次请求，每次平均输入 8,700 Token、输出 800 Token，平均 1.4 次模型调用，则月度普通处理量约为：

输入 Token ≈ 1,000,000 × 8,700 × 1.4 × 30
输出 Token ≈ 1,000,000 ×   800 × 1.4 × 30

再按模型价格表拆成普通输入、缓存输入、缓存写入和输出费用。如果 60% 的输入是稳定前缀并命中缓存，不能直接假设成本按 60% 线性下降，因为缓存规则可能有最小长度、TTL、写入费用和不同折扣。还要加上 embedding、rerank、搜索、OCR、ASR/TTS、工具调用和重试成本。对于同一请求，我会在网关记录 tenant、model、price_version、input_tokens、cached_tokens、output_tokens 和 retry_count，让预算能追溯到业务。

面试中不必背某家供应商的实时价格；应明确“价格以当前官方价格表为准”，给出公式和数量级，并说明可通过历史 usage 回算实际账单。

追问或扣分点

• 只说“请求数乘模型单价”，没有输入/输出 Token 口径。
• 忽略重试和多步 Agent 调用，成本会被低估。
• 用过期价格给出看似精确的金额，却没有价格版本。

Q7：多轮 Agent 如何估算模型调用次数和容量放大？

考察点

• 能否识别 Agent loop、工具调用和并行分支造成的放大。
• 是否设置轮数、Token 和成本上限。

回答脉络

给出每个阶段的平均调用次数和 P95 调用次数，区分串行和并行，再把失败重试、评审模型和工具结果回填纳入预算。

参考答案

我会先画出最小执行图，例如“规划 1 次 + 检索判断 1 次 + 工具调用后总结 1 次”，基线是 3 次模型调用。如果有两路并行检索，模型调用次数可能仍是 3 次，但下游检索 QPS 和并发会增加；如果每个子任务由独立 Agent 完成，则还要乘子任务数。对每一步记录 attempt、parent_run_id 和 tool_call_id，从历史 trace 统计平均值、P95 和最大值。

容量预算可以设：单任务最多 8 轮、最多 100k 输入 Token、最多 2 次重试、最多 0.1 美元或内部成本单位。超过预算时优先停止低价值分支、压缩上下文或转人工，而不是让循环继续。估算不能只看平均 3 次调用，因为 P99 的复杂任务可能是 12 次，正是它们把模型并发和成本顶上去。

追问或扣分点

• 用“平均 3 次调用”作为所有请求的固定值。
• 忽略并行分支对瞬时并发的影响。
• 没有最大轮数、最大 Token 和最大成本预算。

Q8：模型服务的单实例吞吐如何测算？

考察点

• 是否知道吞吐同时受输入长度、输出速度、批处理和 GPU 显存影响。
• 能否区分 tokens/s、requests/s、TTFT 和总耗时。

回答脉络

先定义固定的输入/输出长度和 SLO，再用代表性流量压测单实例稳定吞吐，最后根据峰值 Token/s 而非请求数计算实例数。

参考答案

我不会直接引用模型宣传的最大 tokens/s。压测矩阵至少包含短输入/长输入、短输出/长输出、并发 1/8/32、不同 batch、缓存命中和流式输出，并记录 TTFT、TPOT、P50/P95/P99、GPU 利用率、显存、OOM 和错误率。假设线上平均每请求需要 10k 输入 Token 和 1k 输出 Token，峰值 500 QPS，那么输入吞吐约 5M Token/s、输出吞吐约 500k Token/s；单实例能在目标 P95 下稳定处理 100k 输入 Token/s 和 20k 输出 Token/s 时，不能只除一次得到 50 台，因为输入和输出可能由不同瓶颈限制，应按资源约束取较大值再加冗余。

如果调用第三方 API，则把供应商每分钟 Token 限额和并发限额当作实例等价容量，并设计本地排队、分区配额和备用模型。

追问或扣分点

• 把最大吞吐当成稳定生产吞吐。
• 只看 requests/s，不看 Token 长度和 P95 延迟。
• 用单一平均长度压测，线上长上下文一来就 OOM 或排队。

三、RAG 存储与检索容量

Q9：如何估算企业知识库的原始文件、切片和向量存储？

考察点

• 能否从文件量推到 chunk 数、embedding 维度和副本。
• 是否考虑版本、增量重建、元数据和备份。

回答脉络

先估算原始数据量和有效文本量，再用平均 chunk 长度得到 chunk 数，最后计算向量、倒排索引、元数据、索引副本和增长余量。

参考答案

假设 10TB 原始文件中只有 40% 是可检索文本，平均每个 chunk 约 500 Token，按中文和英文混合估算每个 chunk 约 2KB 文本，则有效文本约 4TB、chunk 数约 20 亿。这个数量级已经不是单机向量库问题，需要重新确认“10TB 是否都需要在线检索”，并按租户、热度、时间和权限做冷热分层。

单个 1536 维 float32 向量约 1536 × 4 = 6KB，20 亿条仅原始向量就约 12TB；还要加 HNSW/IVF 索引、文档 ID、权限标签、倒排索引、副本和碎片开销，实际可能达到 2～4 倍。生产方案通常保留对象存储中的原始文件，向量库只放在线检索所需的热数据，历史版本放低成本存储，索引按版本增量构建。真实估算要用样本统计 chunk 平均大小和每页/每段切分比例，不要只用文件数乘一个固定向量数。

追问或扣分点

• 只算向量字节，不算索引、元数据、副本和备份。
• 默认所有原始文档都在线，忽略冷热分层。
• 没有权限过滤字段，后续无法估算过滤索引和租户隔离成本。

Q10：Embedding 服务需要多少吞吐和机器？

考察点

• 能否区分离线入库和在线查询的 embedding 负载。
• 是否考虑批处理、重建峰值和模型版本迁移。

回答脉络

分别估算每日增量、全量重建和在线查询的 Token/s，再根据单实例压测吞吐和可接受完成窗口计算实例数。

参考答案

离线入库假设每天新增 1,000 万 Token，要求 2 小时完成：

最低吞吐 = 10,000,000 / (2 × 3,600) ≈ 1,389 Token/s

若 embedding 实例在目标批大小下稳定处理 5,000 Token/s，按 50% 余量至少需要 ceil(1,389 / 5,000 / 0.5) = 1 个，但生产通常部署 2 个跨区实例以应对故障和重试。若模型升级需要重建 20 亿历史 chunk，不能把离线任务和在线 query 共用无上限资源，应建立低优先级队列、限并发并为在线查询预留容量。

在线 query 负载还要按峰值 QPS 计算。短问题可能是 50～200 Token，批量文档则差异很大。embedding 结果可以按规范化 query、模型版本和租户权限做缓存，但不能用有权限差异的结果跨租户复用。

追问或扣分点

• 只按文档数量，不按 Token 或字符量估算 embedding 计算。
• 全量重建时占满 GPU，导致在线查询超时。
• 没有区分 embedding 模型版本，重建后无法解释向量混用问题。

Q11：向量检索和 rerank 的下游 QPS 如何估算？

考察点

• 能否把一条用户请求拆成并行下游调用。
• 是否考虑 top_k、候选数和 rerank 成本。

回答脉络

列出每个请求触发的 dense、sparse、结构化检索和 rerank 次数；并行会减少端到端时间，但不会减少总 QPS，重试和多 query 还要单独乘系数。

参考答案

假设入口峰值 100 QPS，每次请求执行 1 次 dense、1 次 sparse 和 20% 请求执行 1 次 metadata 查询，那么三类服务的峰值 QPS约为 100、100 和 20。如果 30% 请求启用 multi-query，每个 query 产生 3 个变体，则 dense 和 sparse 的平均放大系数约为 0.7 × 1 + 0.3 × 3 = 1.6，对应约 160 QPS；如果 rerank 对每次请求的 50 个候选只调用一次，则 rerank 服务约 100 QPS，但单次计算量与候选数相关。

我会优先让 dense、sparse 和结构化检索并行，设置每路超时和取消；rerank 按置信度或问题类型按需开启。容量以峰值请求数乘下游调用放大系数计算，并为超时重试留出预算。不能因为调用是并行的就把下游容量按 100 QPS 以内估算。

追问或扣分点

• 只看入口 QPS，忽略 multi-query 和重试放大。
• 认为并行等于减少下游 QPS。
• rerank 候选数没有上限，输入一长延迟和成本都会失控。

四、GPU、KV Cache 与推理资源

Q12：如何估算长上下文模型的 KV Cache 显存？

考察点

• 是否理解 KV Cache 随层数、头数、序列长度和并发增长。
• 能否说明量化、PagedAttention、Prefix Cache 的影响。

回答脉络

给出近似公式，强调不同模型的 GQA/MQA、数据类型和实现会改变常数；再从单请求 KV 占用推到并发容量。

参考答案

KV Cache 可用近似式估算：

KV bytes ≈ 2（K 和 V）× 层数 × 序列长度
         × KV heads × head_dim × 每元素字节数

例如 32 层、8 个 KV head、每个 head 128 维、序列长度 8,192、FP16 约 2 字节：

2 × 32 × 8,192 × 8 × 128 × 2 ≈ 1.07GB/请求

实际 KV Cache 占用还受 batch layout、block、padding、GQA/MQA 和框架元数据影响。若 80GB GPU 需要为模型权重、运行时和激活保留 40GB，可用于 KV 的空间可能只有 40GB，理论上只能同时容纳几十个这样的长上下文请求，且还要为输出增长动态留空间。

降低占用可以使用 GQA/MQA、KV 量化、PagedAttention、限制最大上下文、Prefix Cache 和会话淘汰。Prefix Cache 只能复用完全匹配且权限安全的前缀，不能把不同租户的私有上下文混在同一个缓存 key 下。

追问或扣分点

• 只说“显存越大并发越高”，没有说明 KV 与序列长度近似线性。
• 把模型权重显存全部拿来放 KV，忽略运行时和碎片。
• 用缓存复用跨用户私有上下文，造成数据泄露风险。

Q13：如何从吞吐和显存估算 GPU 数量？

考察点

• 是否会分别处理权重、KV Cache、计算吞吐和高可用。
• 能否把压测结果转成实例数。

回答脉络

先确认模型权重和并行策略能否放入单卡/多卡，再按峰值输入输出 Token/s 与单实例稳定吞吐计算，最后叠加故障冗余和低优先级任务隔离。

参考答案

我会先做显存下界：模型参数、量化格式、权重副本、运行时、激活和最大并发 KV Cache 必须同时放下。显存满足后，再以压测得到的单实例稳定吞吐为准。假设峰值需要 1.2M output Token/s，单个 8-GPU 实例在目标 P95 下能稳定处理 100k output Token/s，则计算需要 12 个实例；如果要求任一实例故障后仍承受峰值，至少按 13 个或跨区 N+1 部署，并考虑扩容速度。

输入和输出瓶颈可能不同，长输入会压 Prefill，长输出会压 Decode，不能只用一个总 tokens/s。Continuous batching 能提高总体吞吐，但会增加短请求等待；在线交互和离线批处理应分资源池或设不同优先级。最终实例数必须来自与线上长度分布一致的压测，而不是 GPU 厂商的峰值宣传数字。

追问或扣分点

• 只按参数量除以显存计算 GPU，忽略 KV 和运行时。
• 不区分 Prefill/Decode，长上下文请求一来就超时。
• 没有 N+1、跨区和扩容时间的考虑。

Q14：Continuous Batching 会如何改变容量估算？

考察点

• 是否理解吞吐、排队和公平性的取舍。
• 能否为交互和批处理设计优先级。

回答脉络

说明 continuous batching 能让不同请求动态加入/退出 batch，提高 GPU 利用率，但并不能突破显存和单 token 计算上限；容量要以目标延迟下的有效吞吐测量。

参考答案

静态 batching 要等一批请求凑齐，适合长度相近的离线任务；continuous batching 可以在生成过程中让新请求加入，提高 Decode 阶段利用率，通常能提高吞吐。但长请求可能占住 KV 和调度时间，使短请求 TTFT 变差，所以要给请求设置最大上下文、最大输出、优先级和等待上限。

压测时我会记录 batch size、活跃序列数、GPU 利用率、TTFT、TPOT、P95/P99 和被拒绝/超时的请求。容量目标不应写成“GPU 90% 就算够”，而应写成“在 P95 TTFT 2 秒、P95 总耗时 15 秒时稳定处理 X Token/s”。交互请求和离线总结可以分队列，避免大批量任务吃掉在线容量。

追问或扣分点

• 把 batch 越大越好，忽略显存和尾延迟。
• 只看吞吐，不看用户交互的 TTFT。
• 没有队列公平性和大请求隔离策略。

五、队列、异步任务与语音链路

Q15：如何为文档解析和批量评估设计队列容量？

考察点

• 是否会用到达率、处理率和积压时间估算 worker。
• 能否区分在线任务和离线任务。

回答脉络

先计算单位时间到达任务量和单 worker 处理率，再按目标完成窗口和积压告警计算 worker、队列存储和重试容量。

参考答案

假设每天新增 50 万个文档页，要求 4 小时内完成解析和 embedding：

处理速率 = 500,000 / (4 × 3,600) ≈ 35 页/秒

若单 worker 在包含 OCR、切分和 embedding 的完整链路中稳定处理 2 页/秒，理论需要 18 个 worker；按 50% 余量和失败重试，可先部署 27 个，并通过压测调整。若输入在白天集中到达，要按 15 分钟峰值而不是全天平均估算；离线任务应使用低优先级队列，并为在线查询预留 embedding 和向量库资源。

队列需要记录任务状态、幂等键、租户、重试次数、预计成本和文档版本。监控 queue_depth、oldest_message_age、处理速率和死信数量；当预计完成时间超过 SLA 时扩容或降低非必要步骤，而不是无限增加重试。

追问或扣分点

• 只计算 worker 数，不计算消息存储、死信、重试和幂等。
• 用日均到达率应对白天集中上传。
• 离线任务与在线问答共用无限资源，导致线上 P99 变差。

Q16：如何估算 ASR（语音识别）和 TTS（语音合成）容量？

考察点

• 能否使用音频时长、实时率和并发流估算，而不是套用文本 QPS。
• 是否考虑实时流式和离线转写的不同资源模型。

回答脉络

分别用“音频分钟数/时间窗口”和“并发音频流 × 实时率”计算，区分上传后转写、实时通话和 TTS 播放队列。

参考答案

离线 ASR 假设每天 10 万分钟音频，要求 6 小时完成：

平均处理需求 = 100,000 / 360 ≈ 278 音频分钟/墙钟分钟

如果单个 ASR worker 的稳定实时率是 10x，即每墙钟分钟处理 10 音频分钟，则至少需要 28 个 worker，再按峰值、故障和重试留余量。实时通话则不看日均分钟，而看同时在线流数；如果模型实时率需要 1x，1000 路并发至少需要能维持 1000 路实时计算的容量，并为抖动和网络缓冲预留空间。

TTS 需要按输出文本字符/Token、音频时长和并发播放流估算；流式 TTS 还要关注首音频延迟和分片大小。音频文件、转写结果和中间分片要设置保留周期，敏感录音必须有租户隔离、加密和删除策略。

追问或扣分点

• 把 ASR 的“请求数”当作主要容量单位，忽略音频时长。
• 只按平均每日分钟数估算实时通话。
• 不考虑音频对象存储、转码、网络出口和隐私保留周期。

六、多租户、成本与尾延迟

Q17：多租户平台如何做容量和配额估算？

考察点

• 是否能防止大租户挤占共享资源。
• 能否把硬配额、软配额、优先级和成本归因联系起来。

回答脉络

先按租户等级建立流量、Token、并发和存储配额，再在共享池上做全局上限与公平调度，最后为大租户或高敏租户设置独立资源池。

参考答案

我会定义至少四类配额：请求 QPS、并发任务数、Token/分钟或 Token/月、存储和索引空间。企业大客户可以有保底吞吐和独立队列，普通租户共享弹性池；所有租户再受全局模型供应商限额约束。调度时使用租户级 token bucket、任务优先级和最大并发，避免某个租户的长上下文请求占满 KV Cache。

容量估算既看总峰值，也看租户叠加系数。如果 100 个租户各自峰值 10 QPS，不一定同时达到 1000 QPS；但高价值租户的保底容量必须在最坏组合下可兑现。成本账单至少按租户、应用、模型、输入/输出 Token、缓存命中和工具费用归因。缓存、向量索引、队列和日志都要在 key 和资源层面隔离，不能仅在前端带一个 tenant 字段。

追问或扣分点

• 只做全局限流，大租户会压垮小租户。
• 只按请求数计费，不考虑 Token、检索、GPU 和存储。
• 权限、缓存和向量库没有租户隔离，容量再大也不安全。

Q18：如何估算一个请求的单位成本？

考察点

• 是否有完整成本账本，而不是只看模型 API 价格。
• 能否把固定成本分摊到请求和峰值容量。

回答脉络

区分可变成本、固定成本和峰值冗余成本；先算单请求直接成本，再按有效利用率分摊 GPU、数据库、日志和运维成本。

参考答案

单请求直接成本可以写成：

模型输入/输出成本
+ embedding、rerank、OCR、ASR/TTS 成本
+ 搜索、工具和网络出口成本
+ 重试、失败任务和人工审核成本

自建模型还要把 GPU 小时、存储、机房或云网络、监控和运维分摊进去。比如一台 GPU 实例每小时成本为 C，稳定有效吞吐为每小时 R 个请求，利用率按 60% 计，则 GPU 分摊约为 C / (R × 0.6)；不能用理论峰值 R，否则成本会被低估。固定成本可以按请求、Token 或租户预算分摊，但要保持口径稳定。

我会同时看 P50 和 P95 单请求成本：长上下文、多工具、多轮 Agent 通常由尾部请求贡献大部分成本，应设置单任务预算和异常告警。

追问或扣分点

• 只拿供应商输入/输出单价当完整成本。
• 没有考虑低利用率和预留冗余。
• 只看平均成本，忽略复杂长尾任务。

Q19：容量规划为什么必须看 P50、P95 和 P99？

考察点

• 是否理解长尾延迟和平均值的局限。
• 能否将尾延迟定位到不同阶段。

回答脉络

先解释百分位含义，再拆 TTFT、检索、模型 Decode、工具调用和排队的分位数，最后说明 P99 不能简单把各阶段 P99 相加。

参考答案

P50 代表典型体验，P95 用于大多数用户的 SLO，P99 用于少量但严重的长尾问题。AI 请求的总延迟可以拆成排队、鉴权、query rewrite、检索、rerank、模型 TTFT、Decode 和工具等待。容量不足时，GPU 队列可能先抬高 TTFT，长上下文和慢工具再拉高总耗时。

不能简单把每个阶段的 P99 相加当作总 P99，因为各阶段并不完全同步相关；但可以先用阶段预算做上界，再用端到端 trace 观察真实分布。若 P50 很好而 P99 恶化，我会优先查队列长度、慢租户、长 Token、重试风暴和冷启动，而不是只提升平均吞吐。容量应以“在峰值和故障场景下 P95/P99 仍可接受”为验收条件。

追问或扣分点

• 只报平均延迟，宣称系统满足 SLO。
• 把 P99 当成一个固定慢请求，没追踪其来源。
• 只优化模型生成，不看排队、检索和网络尾延迟。

Q20：如果要求 P95 首 Token 2 秒，如何分配延迟预算？

考察点

• 能否把总 SLO 拆成阶段预算并做降级。
• 是否理解 TTFT 与总响应时间、输出 Token 数的关系。

回答脉络

先建立预算表，再根据依赖并行和可选步骤决定哪些链路必须快速完成，最后制定超时、降级和观测指标。

参考答案

一个示例预算可以是：网关和鉴权 100ms、query 规范化 100ms、并行检索 300ms、rerank 300ms、模型排队 300ms、Prefill/首 Token 700ms，总计 1.8 秒，留 200ms 余量。具体数字必须靠压测校准。Multi-query、复杂 rewrite 和 rerank 不应无条件放在所有请求上；简单问题走快速路径，复杂问题再走增强路径。

如果某一路检索超过 300ms，应该取消或使用已有候选，而不是无限等待。模型服务要区分排队时间和计算时间，网关不能缓冲首个 SSE chunk 导致客户端误以为模型迟迟没响应。P95 预算满足后，还要检查 P99 是否因为冷启动、限流或第三方网络抖动严重超标。

追问或扣分点

• 只说“换更快的模型”，没有预算和分阶段指标。
• 把总响应时间当作 TTFT，忽略流式首块和网关缓冲。
• 所有请求都启用最复杂的 rewrite/rerank，导致预算失守。

七、综合场景题

Q21：为一个企业知识库问答系统做完整容量估算，你会怎么答？

考察点

• 能否从入口流量一路推导到模型、RAG、存储和成本。
• 是否能明确假设并识别需要压测的关键参数。

回答脉络

按“用户请求 -> 检索放大 -> Token -> 模型并发 -> 存储 -> 成本 -> SLO 和故障”逐层展开，最后收敛为基线和验证计划。

参考答案

我会先声明一组假设：每天 100 万次问答，活跃时段峰值 100 QPS，平均输入 8k Token、输出 800 Token，30% 请求启用 multi-query（平均 3 个变体），每次 dense+sparse 并行，20% 请求 rerank，P95 TTFT 2 秒、P95 总耗时 10 秒。

据此：

• dense 和 sparse 的峰值调用量约为 100 × (0.7 × 1 + 0.3 × 3) = 160 QPS，还要加重试余量。
• rerank 峰值约 20 QPS，候选数、模型吞吐和超时要用压测确认。
• 模型输入约 100 × 8k = 800k Token/s，输出约 80k Token/s；模型实例数按真实长度分布下的稳定吞吐计算。
• 向量存储从 chunk 数、维度、索引类型、副本和权限元数据推导，原始文件放对象存储，热向量放在线集群。
• 入口和各下游都按租户限流；离线索引构建走低优先级队列，不影响在线容量。
• 成本按模型 input/output/cache、embedding、rerank、存储、GPU/第三方 API 和重试分摊到租户。

最后我会做三类验证：代表性 Token 长度和长尾请求的端到端压测；单服务在 P95/P99 SLO 下的基准测试；单可用区故障、模型供应商 429、向量库降级和队列积压演练。没有实测的部分标为假设，不把估算结果当作上线承诺。

追问或扣分点

• 只回答模型 GPU 数，不回答向量存储、队列、租户和成本。
• 公式看似完整，但没有列出输入长度、峰值系数和多路检索放大假设。
• 没有故障场景和压测计划，容量无法验收。

Q22：流量突然增长 10 倍，但 GPU 和第三方 API 不能马上扩容，你会怎么处理？

考察点

• 是否会优先保护核心 SLO 和安全，而不是盲目排队。
• 能否设计分级降级、配额和恢复策略。

回答脉络

先保护已有请求和高优先级租户，再减少可选计算，最后把可延迟任务异步化或拒绝，并说明恢复后如何消化积压。

参考答案

我会按优先级采取措施：

1. 启用租户和用户级限流，保护健康检查、关键业务和已开始的流式请求。
2. 关闭默认 multi-query、复杂 rerank、非必要工具和低价值历史上下文，走快速路径。
3. 使用稳定且权限安全的缓存、较小模型或模板答案；高风险任务不能静默降级为不受控的小模型。
4. 将文档解析、批量总结、评估等任务转入低优先级队列，设置最大排队时间和死信。
5. 超过容量时快速失败并返回可重试时间，而不是让请求无限堆积导致全系统雪崩。

流量恢复后按租户公平和任务优先级逐步清空积压，检查重试风暴、重复写操作和成本异常。整个过程要记录降级开关、原因和恢复时间，避免为了保可用性绕过权限和人工确认。

追问或扣分点

• 只说“扩容”，忽略扩容慢或供应商限额。
• 无限重试和排队，最终连接、内存和费用一起爆炸。
• 降级时绕过权限、引用或高风险动作确认。

Q23：如何估算缓存命中对容量的实际收益？

考察点

• 是否区分业务结果缓存、embedding 缓存、检索缓存和 Prompt/KV Cache。
• 能否把命中率转换成下游负载下降，而不是只报一个百分比。

回答脉络

先定义缓存 key 和正确性边界，再按命中率减少的调用量估算收益，最后考虑失效、权限、版本和缓存未命中的长尾。

参考答案

假设入口峰值 100 QPS，规范化 query 的 embedding 缓存命中率 60%，那么 embedding 服务的平均调用约下降到 40 QPS；如果检索结果缓存命中率只有 20%，向量库仍承受 80 QPS。最终答案缓存命中可以减少整个模型调用，但受知识库版本、租户权限、用户身份和实时性约束，不能把不同权限的结果共用。

我会分别统计命中率、命中节省的 Token、节省的 GPU/模型时间、缓存读写延迟和错误命中率。缓存 key 至少包含规范化输入、租户/权限范围、模型与 prompt 版本、知识库版本和重要参数。TTL 与主动失效要匹配数据更新；权限变更、文档删除和模型升级必须能使旧缓存失效。容量估算仍按未命中和突发失效场景准备基础能力，不能把缓存当成永远存在的容量。

追问或扣分点

• 只说“命中率 80%，容量减少 80%”，忽略不同缓存层和权限。
• 不记录版本，文档更新后返回旧答案。
• 按缓存命中后的平均负载部署，缓存雪崩时系统立即失效。

Q24：如何判断容量估算结果是否可信？

考察点

• 是否有从假设到实测的闭环。
• 能否识别估算中最敏感的变量。

回答脉络

列出假设、公式、数据来源、敏感性分析和压测验收标准，优先验证影响最大的参数。

参考答案

我会把估算表分为“已观测、压测、业务假设”三类，并给每个参数加来源和更新时间。例如 Token 长度、multi-query 比例、P95 模型吞吐、缓存命中率、单页 OCR 时间、向量索引膨胀率都是敏感变量。对这些变量做上下界分析：如果输出 Token 从 800 增长到 2,000，模型并发和成本会怎样；如果缓存从 60% 降到 10%，下游 QPS 是否还能承受。

验收时使用与线上分布一致的回放数据，验证峰值 QPS、长上下文、慢工具、模型 429、节点故障和缓存失效。通过监控持续回填真实 P50/P95/P99、Token、队列和成本，按周或按版本更新容量模型。一个可信的答案不一定是一个精确数字，而是能说清数字为什么这样来、误差可能在哪里，以及如何用实验缩小误差。

追问或扣分点

• 只展示最终机器数，不提供输入假设和数据来源。
• 没有敏感性分析，无法知道先压测哪个变量。
• 压测只测平均短请求，不覆盖长尾、故障和降级路径。

常见公式速查

场景	估算关系	注意事项
日请求转 QPS	请求数 / 86,400	还要乘活跃时段和短时峰值系数
并发	QPS × 平均停留时间	区分执行中、排队中和流式连接
Token 处理量	请求数 × 单请求 Token × 调用放大系数	输入、输出、缓存和重试分开
队列 worker	到达速率 / 单 worker 处理速率	按峰值和完成窗口留余量
向量原始大小	向量条数 × 维度 × 每元素字节数	还要加索引、元数据、副本和备份
KV Cache	2 × 层数 × 序列长度 × KV heads × head_dim × 字节数	GQA/MQA、分页和量化会改变结果
实例数量	ceil(峰值负载 / 稳定单实例能力)	加故障冗余、扩容时间和性能余量
月度成本	Token/资源用量 × 对应价格	记录价格版本，加入工具和基础设施成本

面试回答收口模板

我先确认请求量、峰值分布、Token 长度、模型调用次数、SLO、数据保留和租户隔离。
然后把入口请求拆成模型、检索、embedding、rerank、工具和存储的下游负载，分别按峰值和 P95/P99 估算。
实例数量使用压测得到的稳定能力，而不是理论峰值，并为扩容时间和 N+1 故障保留容量。
最后给出缓存、队列、降级、成本归因和容量验证计划，明确哪些数字是业务假设、哪些要通过压测确认。

容量估算的目标是做出可验证的工程决策：数字可以随着真实流量调整，但假设、公式、边界和验证方法必须经得起追问。