本文只讲容量这一层:从「所里有多少律师、他们怎么用」推出「要多少卡、多少显存、什么时候该加」。不是选型——买什么卡见内网大模型 GPU 选型;不是单机调优——把一张卡跑满见推理性能与 GPU 利用率;不是算钱——见私有化 TCO 测算;不是宕机冗余——见灾备与高可用;也不是指标怎么采——见运维监控与告警。边界很窄:容量从哪来、什么信号说明不够了、不够了按什么顺序补。
一、三个真实的翻车场景
第一种,按峰值买卡,钱一次烧光。立项时按「万一大家同时用」推配置,一次采购到位。半年后翻监控,一天里真正压到高位的不超过两小时;钱已花在硬件上,想补检索层内存时预算没了。峰值是排队策略的依据,不是采购基线。
第二种,按「人头 × 1」估算,早高峰照样排队。另一种极端是拿律师总数除以某个系数。但法律 AI 的使用高度集中:开庭前一天、月末交底稿、大案组集体检索的那个下午,请求挤在很窄的时间窗里,按平均值配的容量在这些时刻变成十几秒起步的排队(见用户导入与推广)。
第三种,检索层先崩,却一直在加 GPU。用户说变慢,IT 看 GPU 利用率不高又不敢说没事,于是加卡;还慢,再加。真瓶颈在检索层:索引涨上来内存放不下,查询频繁读盘,请求进推理前就等了很久(见向量库与检索引擎选型)。
共同点:把容量当成一个采购数字,而不是一条从使用形态推到硬件的可复算链路。
二、先画使用形态,再谈卡
容量规划的起点不是模型参数量,是人的行为,至少问清四件事:
| 要素 | 问什么 | 为什么影响容量 |
|---|---|---|
| 日活律师数 | 全所人数 × 真实渗透率 | 注册数虚高,按它配会过量 |
| 人均频次 | 每天几次会话 | 决定日会话总量 |
| 时段分布 | 高峰在哪几小时 | 决定峰值系数,最易忽略 |
| 业务形态占比 | 短问答 / 长文档 / 批量抽取 | 单位算力消耗差一个量级 |
推算链路本身很简单,难在数据要真实:
峰值并发 = 日会话量 ÷ 工作小时数 × 峰值系数 × 会话占用时长
渗透率和峰值系数最该实测、最不该拍脑袋。渗透率在推广初期通常远低于预期;峰值系数在法律行业往往偏高,因为律师的节奏被开庭日、举证期限、交付节点推着走。首期按保守渗透率配一套能跑的,把埋点做好,用真实曲线校正后再定第二期。
三、容量要分三层各算一遍
私有化法律 AI 至少有三层容量,三本账互不通用,任一层见底整体就见底:
| 层 | 吃什么资源 | 容量口径 | 见底表现 |
|---|---|---|---|
| 推理层 | GPU 显存与算力 | 并发会话数、输出速度、上下文长度 | 排队、被拒、截断 |
| 检索层 | CPU、内存、磁盘 IO | 并发查询、单查延迟、索引常驻内存 | 变慢但 GPU 空闲 |
| 存储带宽 | 磁盘容量、网络吞吐 | 语料与索引体积、并发读取带宽 | 入库变慢、重建拖累 |
最常被低估的是中间那层。裁判文书这类语料入库后索引体积往往比原始文本还大,而向量索引要快就得尽量常驻内存;内存不够,查询退化成读盘,延迟从毫秒变成秒。规划时把索引常驻内存单独列一行,别塞进「服务器内存」含混带过(见文书私有库架构与律所 RAG 知识库)。
第三层要留一次性峰值:换 embedding、重建索引、批量导入卷宗对磁盘带宽的压力远高于日常,按日常水位配就会被一次全量重建拖垮(见模型版本管理与升级)。
四、显存怎么估:一条可以自己算的式子
显存是容量规划里唯一能算准的部分,由公开参数决定,不需要猜:
权重显存 = 参数量 × 每参数字节数(FP16≈2,INT8≈1,INT4≈0.5)
每 token KV 字节数 = 2 × 层数 × KV 头数 × 每头维度 × 精度字节数
第二行决定装不装得下,第三行决定能扛多少并发。层数、KV 头数、每头维度在模型配置文件里都查得到。三点:
- 权重是固定成本,KV cache 是可变成本。后者随「并发数 × 上下文长度」线性增长,才是真正的变量。只算权重就以为够,一上并发必崩。
- 量化腾出的显存直接换成并发。权重从 FP16 降到 INT8,空出的部分能装更多 KV cache,代价是要用自建回归集验证效果。
- 预留余量。激活值、框架开销、显存碎片都占地方,按常见部署经验留 10% 到 15% 并以实测为准。卡到 99% 会在峰值时以「随机报错」惩罚你。
算力侧另有一条口径:单卡实测输出速度 ÷ 单会话可接受的输出速度 ≈ 能撑的并发数。显存与算力各出一个上限,取更小的;差很远说明配置不均衡。见GPU 选型实战与信创国产化栈部署。
五、长文档:法律场景特有的容量放大器
式子里的平均上下文长度在法律场景下会被显著抬高:一般问答只有一两千 token,而律所的日常输入是几十页的合同、成册卷宗、多篇判决拼起来做类案比对,再加 RAG 召回的参考段落。上下文翻几倍,KV cache 就翻几倍,并发按同样比例往下掉。
由此得到一个反直觉的结论:瓶颈往往不是「人多」而是「文档长」。容量必须按业务形态分别估算再加权:
| 业务形态 | 上下文特征 | 对容量的影响 | 规划建议 |
|---|---|---|---|
| 短问答 / 法条检索 | 短输入短输出 | 并发高、单位消耗低 | 同一资源池承载 |
| 长文档审阅 / 比对 | 超长输入、中等输出 | KV cache 主要消耗方 | 单独估算,限长分段 |
| 批量要素抽取 | 中等长度任务量大 | 吃吞吐不吃时延 | 放非高峰跑 |
| 长文书生成 | 输出长 | 长时间占住槽位 | 槽位单独限额 |
三条实操建议:给上下文设上限、超长输入改分段,这是最省钱的优化;批量任务挪到夜间,让白天的交互流量独享算力;召回条数不是越多越好,它抬高上下文长度,边际收益却很快见顶。
六、什么信号说明真的该扩容了
「变慢了」不是依据,「利用率高」也不是。可用的触发条件只有几条,且都要求连续多日、已排除软件侧问题:
| 触发指标 | 判定口径 | 先排除什么 | 扩容动作 |
|---|---|---|---|
| 排队时延 P95 | 繁忙时段连续多日超上限 | 批处理配置、上下文失控 | 加卡或加节点 |
| 显存水位 | 峰值贴顶,出现拒绝或截断 | 能否先量化、先限长 | 换大显存卡或加节点 |
| 吞吐触顶 | 输出速度接近单卡实测上限 | 是否长任务占住槽位 | 横向加节点 |
| 检索 QPS 与延迟 | 延迟随索引增长上台阶 | 索引是否放不下内存 | 加内存 / 扩检索节点 |
| 趋势线 | 日活与会话量连续数月上行 | 是否一次性活动的高峰 | 提前排采购 |
最后一行值得单独说:扩容有交付周期。等 P95 报警才立项,中间几个月律师都在忍受排队。做法是把日活与会话量做成月度趋势看板,稳态峰值占到额定容量一定比例就启动流程(见运维监控与告警)。
七、扩容顺序:从不花钱的开始
确认要扩容后按下面顺序走,每步做完重测再进入下一步:
| 步骤 | 动作 | 成本 | 典型收益 | 代价 |
|---|---|---|---|---|
| 第一步 | 量化 + 批处理 + 上下文治理 | 几乎为零 | 腾显存、提吞吐 | 需回归验证 |
| 第二步 | 现有节点加卡 | 低 | 并发上台阶 | 受槽位与供电限制 |
| 第三步 | 横向加推理节点 | 中 | 容量线性扩展 | 需负载均衡与路由 |
| 第四步 | 拆分资源池与读写分离 | 高 | 互不干扰 | 运维复杂度上升 |
第一步排最前面的理由:不用采购、不停业务、当天见效。量化腾出的显存全变成并发;连续批处理让卡在等待期间处理别的请求;上下文治理砍掉可变成本的分母。三件事叠加,常能把加卡推迟一整个采购周期。
第四步是规模上来后的必经之路:交互问答、长文档批处理、离线抽取分进不同资源池,互不抢显存(见多租户与权限隔离架构)。另有一条纪律常被跳过:每次扩容都当一次变更来管,加卡看似只是「插上去」,实际牵动驱动、并行策略与路由(见上线切换与数据迁移)。
八、一张容量规划表模板
把上面的推算收敛到一张表,立项与复盘都用:
| 字段 | 填写说明 |
|---|---|
| 律师数 / 渗透率 / 日活 | 分开填,渗透率注明预估还是实测 |
| 时段分布与峰值系数 | 注明数据来源与统计周期 |
| 业务形态占比 | 短问答 / 长文档 / 批量任务 |
| 平均与 P95 上下文长度 | 分形态填,长文档单列 |
| 模型与精度 | 参数量、量化方案、层数、KV 头 |
| 权重显存 / KV 显存 | 按第四节公式算出,过程留档 |
| 单卡实测吞吐 | 注明上下文长度与批大小 |
| 推理层结论 | 节点数、单节点卡数、并发上限 |
| 检索层结论 | 索引体积、常驻内存、延迟目标 |
| 存储与带宽 | 语料索引占用、重建峰值 |
| 扩容触发线 | 各指标阈值、动作与判定人 |
| 预留周期 | 本期能撑多久,下期何时启动 |
最后两行是它和普通配置单的区别:要写「什么时候会不够」,而不只是「现在够不够」。见三年 TCO 测算与法律 AI 投入产出测算。
九、容量规划十项自查清单
- 日活用的是实测渗透率,还是拿注册数顶替?
- 峰值系数有数据来源吗?是否覆盖开庭前这类高峰?
- 推理、检索、存储带宽三本账是否分别算过?
- 显存是否按「权重 + KV cache + 余量」逐项算过?
- 长文档是否单独估算,而非用平均上下文长度糊过去?
- 单卡吞吐是实测的吗?测试参数是否贴合真实业务?
- 显存与算力各自推出的并发上限,是否取了更小的那个?
- 扩容触发线是否写死为具体阈值,并明确判定人?
- 加卡之前,量化、批处理调度、上下文治理做完了吗?
- 索引重建、批量导入的一次性峰值,预算里留位置了吗?
十、常见问题
Q:到底要几张卡,能给个直接的数吗?
A:给不了。链路是律师数 × 渗透率 × 人均会话数 → 峰值并发,再用实测吞吐与显存公式各推一次取更紧的。
Q:GPU 利用率只有两三成,是不是买多了?
A:更常见的是批处理没开、请求卡在检索层、并发没起来。排除调度与检索再下结论。
Q:先买够三年,还是先小后大?
A:除非有强制的上线规模,否则先配一套能跑的,趋势看板做扎实再定第二期。硬件买早了折旧和电费都在跑。
Q:量化会不会影响回答质量?
A:可能会,须用自建回归集验证,别看公开榜单;要专门比对引证类题目。见开源底座选型。
Q:检索层的容量怎么估?
A:索引体积、常驻内存比例、并发查询与延迟目标。核心是索引能否放进内存,放不下就退化成读盘。
Q:能用排队限流代替扩容吗?
A:短期可以。稳态峰值超容量时,排队只会变成持续等待。看 P95 是偶发还是常态。
Q:多部门共用一套,容量怎么分?
A:先分资源池再谈配额,至少把交互流量与批量任务隔开。见多租户与权限隔离与私有化部署方案。
Q:小所人少,这套还有必要做吗?
A:必要,可简化到三样:写明来源的推算过程、一次单卡吞吐实测、一条扩容触发线。见律所私有化部署指南与API / MCP 定价。
容量方案先算一遍再采购
提供律师人数、使用形态与拟用模型,1 个工作日内反馈容量推算建议。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情
相关阅读:推理性能与 GPU 利用率 · GPU 选型 · 三年 TCO · 灾备高可用 · 工作台 · API / MCP 定价