私有化法律 AI 上线三个月后,最常出现在 IT 邮箱里的一句话是:「这系统怎么这么慢?」接下来的剧本几乎千篇一律——IT 去看监控,发现 GPU 没跑满,又不敢说没问题,于是提一份加卡预算。但真相往往相反:多数律所私有化 AI 的「慢」,不是卡不够,而是批处理和显存没调。更要命的是,单个律师的响应体感和整所的并发吞吐,是两件完全不同的事;按前者的体感去买卡,很容易把预算买爆,高峰期照样卡顿。真正的杠杆不在采购单上,在 KV cache、连续批处理和上下文长度治理这三件几乎不花钱的事上。本文把这一层讲透:三个最常见的误判、必须分清的三个性能指标、法律长上下文为什么让显存被 KV cache 吃掉、六个可落地的优化手段与取舍、容量怎么测算、GPU 利用率低于三成说明什么,以及一份十项推理性能自查清单。买什么卡是上一篇的题目,这一篇讲的是买了卡之后,怎么把它跑满、跑快。
一、先纠三个最贵的误判
「系统慢」是一个体感描述,不是一个诊断。在没有量出瓶颈之前就动手,几乎必然走进这三个坑之一:
误判一:以为要加卡
这是最贵的一个。加卡解决的是算力不足,但律所私有化 AI 的慢,大部分时候是排队——请求在调度队列里等,GPU 其实有相当一部分时间在空转。如果调度和批处理没做对,加第二张卡只是把同一套低效逻辑复制一份,两张卡一起闲着,律师照样等。一个非常直接的自查信号:律师抱怨慢的同时,GPU 利用率却长期在低位——这基本可以断定是调度问题,不是算力问题,此时加卡就是纯粹的浪费。
误判二:以为要换更小的模型
换小模型确实能提高生成速度、降低权重占用,但它是用能力换性能,而能力恰恰是法律场景最不该让的东西。更关键的是,如果瓶颈在排队、在超长上下文的预填充、在 KV cache 占满,换小模型的收益会远低于预期——几万 token 的检索上下文,该算还是要算,不会因为模型小了就凭空消失。结果常常是「快了,但答得不好」,律师用两周就弃用,能力的损失是永久的,性能的收益却很有限。底座模型选型应该基于能力评测来定,而不是被性能焦虑倒逼。
误判三:以为是网络
内网部署的场景里,网络几乎从来不是大模型推理的瓶颈——真正的时间开销在 GPU 上的预填充和逐 token 生成,这两段跟带宽没什么关系。之所以老被怀疑到网络头上,是因为「点了半天不出字」的体感,和网络卡顿的体感高度相似。分辨方法也简单:如果是排队或预填充慢,现象是首字迟迟不来、但一旦开始出字就很流畅;如果真是网络问题,现象通常是出字过程本身一顿一顿的。花半天时间量一下这两段,能省下几周的错误排查。
一句话原则:性能问题必须先量再调,最后才考虑买。跳过前两步直接买硬件,是私有化法律 AI 里最常见、也最难向合伙人交代的一笔冤枉钱。
二、先分清三个指标:律师体感只对应其中一个
「快」这个字,在推理性能里至少对应三个互不相同的指标。它们的优化手段不同、瓶颈位置不同,混为一谈就必然调错方向:
| 指标 | 它衡量什么 | 谁在意 / 优化杠杆 |
|---|---|---|
| 首 token 延迟(TTFT) | 按下回车,到屏幕上出第一个字的时间。包含排队时间 + 上下文预填充时间 | 律师体感只对应这一项。杠杆=压上下文长度、减少排队、prompt 缓存 |
| 生成吞吐(tokens/s) | 开始出字之后,字往外冒的速度 | 只要快过人的阅读速度,再快边际收益极小。杠杆=模型规模、量化、批处理效率 |
| 整所并发(QPS / 同时在跑请求数) | 系统同时能扛住多少人一起用而不排队 | IT 与预算在意。杠杆=连续批处理、显存(KV cache)预算、分池调度 |
这张表最重要的一句话是:律师的「慢」几乎全部落在 TTFT 上。他不知道也不关心 tokens/s,他只知道按了回车之后要盯着空白屏幕等多久。而高峰期 TTFT 变差,主因通常不是模型算得慢,而是排队——也就是并发容量不够。这就解释了本文开头那个反直觉的主线:
单请求延迟和整所吞吐是两件事。你在深夜一个人测试时,TTFT 很漂亮,于是按这个体感去推算「再买两张卡就能撑全所」;但上午十点全所一起用时,卡顿的成因是排队而非算力,加卡如果没配上正确的批处理调度,并不会等比例地缩短队列。按单请求体感买卡,会买爆预算却仍然卡顿——这是私有化法律 AI 预算失控最常见的路径。
三、法律场景的特殊性:显存主要被 KV cache 吃掉,不是权重
要理解为什么调度和上下文治理是杠杆,得先看清一件事:推理时的显存,到底被谁占了。
很多人的直觉停留在「模型多大,就要多大显存」。这在单人试用时大致成立,但一进入多人并发就完全失效。显存构成大致是三块:
| 显存构成 | 特点 | 随什么增长 |
|---|---|---|
| 模型权重 | 固定占用,模型和精度选定就定死了,不随用户数变化 | 不增长(除非换模型或改量化档位) |
| KV cache(法律场景的大头) | 每个进行中的请求、每个 token 都要占的中间状态,用完才释放 | 并发请求数 × 每个请求的上下文长度,线性增长 |
| 激活值与运行时开销 | 计算过程中的临时占用、框架预留与显存碎片 | 随批次大小变化;粗放的显存管理会额外浪费不少 |
关键在第二行。法律场景的上下文特别长——这是它和普通客服问答、通用助手最本质的区别。律师问一个类案问题,系统要从知识库里检索召回若干篇判例、合同条款或卷宗片段塞进上下文,动辄几万 token;而一次普通的客服问答可能只有几百 token。两个数量级的差距,直接体现在 KV cache 的占用上。
后果是:并发一上来,KV cache 的占用可能迅速逼近甚至超过模型权重本身,把剩余显存吃干净。系统这时只有三条路——降低并发让人排队、抢占已有请求把它的 KV cache 丢掉稍后重算、或者直接拒绝新请求。三条路对律师而言都是同一个体感:人一多就集体变慢。
由此推出一条最反直觉、也最省钱的结论:在法律场景里,把检索召回的条数从二十条压到五条精准的,对性能的改善往往超过加半张卡——因为它同时降低了预填充时间(TTFT 变好)和 KV cache 占用(并发容量变大),而且如果重排做得好,答案质量还会一起变好。这几乎是私有化法律 AI 里唯一一个「性能、成本、质量三赢」的动作。
四、六个可落地的优化手段与取舍
按「不损失能力优先、花钱最少优先」排序,这六项是私有化法律 AI 性能调优的主力。以 2026 年年中的常见实践看,前三项通常就能拿到大部分收益,具体幅度必须在自己的数据和问法上实测:
| 手段 | 怎么起作用 | 取舍 / 注意 |
|---|---|---|
| ① 连续批处理 + 分页显存管理 (vLLM 一类推理框架) | 新请求随时插进正在跑的批次,不必等整批结束,GPU 有效利用率显著提升;KV cache 按块分配,大幅减少碎片浪费,同样硬件支撑更高并发 | 投入产出比最高的一步。选型要一并看私有化 / 信创环境兼容性、是否支持你选定的模型与量化格式、可观测性是否够(指标拿不到就没法调) |
| ② 上下文裁剪与重排 (把召回条数压下来) | 直接缩短预填充时间、直接降低 KV cache 占用。TTFT 和并发一起改善 | 法律场景收益最大的一项。前提是检索与重排够准——压条数不是随机砍,是靠重排把最相关的留下,砍错了会掉召回 |
| ③ prompt 缓存复用 | 系统提示词、固定的角色设定与格式要求这些每次都一样的前缀,缓存起来跨请求复用,省掉重复预填充 | 对有长固定前缀的法律应用收益明显。多租户场景下务必确认缓存按租户隔离,别让权限隔离从缓存这条侧门破功 |
| ④ 量化(INT8 / INT4) | 降低权重占用,腾出显存给 KV cache,提高可承载并发 | 有精度红线。法条号、案号、当事人、金额、日期这些一字不能错的要素,以及引用准确性,必须用自建评测集实测量化前后的正确率。越激进的档位越要谨慎;错误成本不在性能账上,在执业风险上,可配合引用核验机制一起看 |
| ⑤ 长文档分段 + 流式输出 | 流式让字一出来就往屏幕上推,不必等整段生成完;长文档分段处理避免一次性塞爆上下文 | 改善的是体感而非真实吞吐——但律师的满意度本来就建立在体感上,这是性价比极高的「感知优化」。分段要注意跨段的一致性 |
| ⑥ 批量任务与交互任务分池 | 卷宗入库、向量化、批量摘要这类不要求实时的任务,与律师的交互问答分开资源池或错峰调度 | 防止一个大批量作业把交互请求全部挤到队尾。没分池的话,一次夜间任务跑过了点,第二天上午全所都在等 |
顺序建议很明确:①②③ 是不损失能力的纯赚项,先做完;④ 涉及精度取舍,必须评测后再决定;⑤ 见效快且几乎零风险,可以随时做;⑥ 是运维纪律问题,一旦有批量作业就必须做。把这六项走完还不达标,再谈加卡,那时候的预算申请也才站得住脚。
五、容量怎么测算:一个可以自己套的方法
不要照抄别人的配置单,法律场景的上下文长度和检索负载跟通用基准差别太大,外推必错。下面这个五步法可以直接套自己的数:
- 估总量:所内会真正使用的律师人数 × 日均问答次数。注意是实际活跃人数,不是全所花名册——新系统上线初期的真实活跃率通常远低于预期,按花名册算会一次性买多。
- 折算峰值:全天用量不是平摊的,通常集中在上午和下班前几个小时。用一个峰值系数把日均折算成峰值时段的每秒请求数。系数取多少?先用一个保守估计,上线后用真实日志修正——这是唯一可靠的办法。
- 换算并发:每个请求会占用系统一段时间(预填充 + 生成)。峰值请求速率 × 单请求平均占用时长 = 需要同时在跑的请求数,这才是真正要支撑的并发,也是所有显存计算的输入。
- 算显存:峰值并发数 × 平均上下文长度 → KV cache 预算,加上模型权重占用与运行时开销,再留一段余量。法律场景务必用真实的检索上下文长度,而不是拍脑袋的「几千 token」。
- 反推硬件并实测验证:用上面的显存和吞吐需求反推配置,然后必须在自己的真实问法和真实检索材料上压测。任何通用跑分数字在这里都只有参考意义。
一条经验之谈:宁可先按保守配置上线、用真实使用数据修正,也不要在零真实负载数据的情况下按最悲观假设一次性买满。私有化的硬件是买断成本,买多了就是持续折旧的沉没成本;而真实用量数据,只有上线之后才有。这一点在算三年 TCO 时尤其关键。
六、性能与成本:利用率低于三成,问题在调度不在卡
私有化的账和云上的账完全不同:云上是按用量付费,不用就不花钱;私有化的卡是买断的,闲着也在折旧。所以性能优化在私有化场景里,同时就是成本优化——同一张卡承载的有效工作量越大,单位成本越低。
由此有两条判断标准,要分时段看,不要笼统地追求一个平均利用率数字:
- 交互高峰期:看的是排队时长和 TTFT 是否达标。如果此时 GPU 利用率长期低于三成、律师却在抱怨慢,这就是调度和批处理没做好的铁证——请求在串着跑,卡大部分时间在等待而不是在算。这种状态下加卡纯属浪费,先去启用连续批处理、把并发请求真正合并起来喂给 GPU,再看利用率是否上来。
- 低峰期与夜间:利用率近乎为零不是浪费,而是机会。把卷宗入库、文档向量化、批量摘要、模型评测、索引重建这些不要求实时的批量任务安排到低峰跑,把利用率填满。买断的算力闲着就是白折旧,填满它等于凭空多出一份产能。
另外一句必须说的:性能指标拿不到,就无从调优。TTFT、生成吞吐、排队时长、显存占用、GPU 利用率这几个数,应该是常态化采集并可回溯的,而不是出了问题才临时去抓。这属于监控告警体系的一部分,建议在系统上线的同一天就建起来——晚建一天,就多一天只能靠猜的排查。
七、推理引擎是容器,数据才是护城河
把这一整套调优做完,系统会变快、变省、变得扛得住全所并发。但要把话说清楚:推理性能决定的是这套 AI 好不好用,不是它值不值得用。
推理框架、显存管理、批处理调度,本质上都是容器——它们决定材料能以多快的速度被送进模型、答案能以多快的速度回到律师屏幕上。但容器里装的是什么,决定了这套系统对律师到底有没有价值。同一套调优得当的推理栈,喂进去残缺的、无结构的、无法回链的数据,律师得到的只是更快地拿到不可信的答案——这比慢更糟,因为快而错的东西更容易被直接采信。
而且这两件事是咬合的:上一节说过,法律场景性能优化里性价比最高的动作是把召回条数压下来,而能不能只召回五条就够准,取决于底层数据是否结构化、字段齐全、可精确过滤。法院、审级、年份、案由、当事人这些字段齐全,检索才能先精确圈定范围再做语义排序,五条就能覆盖律师真正要的类案;数据一团散、无字段可过滤,就只能靠语义粗筛召回二十条兜底,上下文被撑爆,性能和质量一起掉。这就是为什么我们反复说:法律 AI 的护城河在数据。一套覆盖全国全量、字段齐全、能回链原文的裁判文书数据底座(文书查 1.5 亿+ 裁判文书),既撑得起类案检索的准确性,也直接决定了你的推理栈能调到多快、多省——而且数据不出内网。
八、给信息化负责人 / 法律科技 CTO 的一页纸性能自查清单
在批任何一笔加卡预算之前,把这十条逐条过一遍:
- 先量再调:有没有分别量出 TTFT、生成吞吐、排队时长三个数,判断瓶颈到底在哪一段?
- 指标可回溯:这几个数是常态化采集的,还是出了事才临时去抓?
- 连续批处理:用的是成熟推理服务框架(vLLM 一类),还是最基础的串行加载方式?
- 分页显存管理:KV cache 是按块按需分配,还是粗放预留、碎片浪费严重?
- 上下文治理:检索召回条数压过没有?有没有靠重排把二十条压到五条精准的?
- prompt 缓存:固定的系统提示词前缀有没有跨请求复用?多租户下缓存按租户隔离了吗?
- 量化红线:如果做了量化,有没有用自建评测集验过法条号、案号、当事人、金额、日期和引用准确性?
- 体感优化:流式输出开了吗?长文档有没有分段处理避免撑爆上下文?
- 分池调度:批量入库 / 向量化任务和律师交互问答分开资源池或错峰了吗?
- 利用率分时看:高峰期利用率是否长期低于三成(=调度问题)?低峰期有没有拿批量任务填满闲置算力?
把这十项做成加卡预算的前置门槛,性能这件事就从「一慢就买卡」变成「先调后买、每一分硬件钱都花在真瓶颈上」。记住那句反直觉的话:大多数律所私有化 AI 的卡顿,是排队问题不是算力问题;而排队问题,加卡治不好。
九、常见问题
Q:系统卡,是不是该加显卡?
A:大多数情况不该先加。先量出 TTFT、生成吞吐和排队时长三个数:如果 GPU 利用率长期在低位而律师还喊慢,那是调度和批处理的问题,加卡只是把低效逻辑复制一份。正确顺序是调参数、换推理框架、压上下文,最后才谈加卡。
Q:TTFT、吞吐、并发,律师体感对应哪个?
A:只对应 TTFT(按回车到出第一个字)。生成吞吐只要快过阅读速度,再快边际收益极小;并发 QPS 是整所容量指标,律师感知不到,但它不够时所有人的 TTFT 都会被排队拖垮。单请求延迟和整所吞吐是两件事,别用前者的体感去推后者的采购。
Q:显存主要被什么吃掉?
A:法律场景里是 KV cache,不是模型权重。权重是固定占用,KV cache 随「并发数 × 上下文长度」线性增长。而法律检索召回动辄几万 token,比普通问答高两个数量级,所以并发一上来 KV cache 就可能吃干显存,表现为人一多就集体变慢。这也是压召回条数为什么这么值钱。
Q:量化能用吗?法律场景的红线在哪?
A:能用,但必须实测。红线是法条号、案号、当事人、金额、日期这类一字不能错的要素,以及引用准确性。用贴合本所业务的评测集跑量化前后同一套题,重点看引用错误率而不是「读起来通顺」。错了就退回更保守的档位——法律 AI 的错误成本在执业风险上,不在性能账上。
Q:GPU 利用率一直很低,是不是买大了?
A:通常是调度有问题而不是卡大了。高峰期利用率低于三成还喊慢,基本可断定是请求在串行跑;先开连续批处理再看。夜里利用率为零不是浪费而是机会——把卷宗入库、向量化、批量摘要挪到低峰跑,买断的算力闲着就是白折旧。
Q:换更小的模型能解决卡顿吗?
A:能缓解一点,但常常是错误的第一步——它用能力换性能。如果瓶颈在排队和长上下文预填充,几万 token 该算还是要算,换小模型收益远低于预期,却会明显削弱长文档理解和引用准确性,律师会觉得「快了但答得不好」。先把不损失能力的手段用完。
推理栈你来调,调得动的结构化数据我们来供
文书查提供 1.5 亿+ 结构化裁判文书私有化部署——法院、审级、年份、案由、当事人字段齐全,支持先精确过滤再语义排序,让检索能用五条精准结果替代二十条兜底召回,直接压下上下文长度与 KV cache 占用,可回链原文,数据不出内网。无论你用哪套推理框架、怎么调批处理和显存,我们负责把那套覆盖全、结构化、能回链、可更新的法律数据喂进去,让系统既跑得快,又答得准。
📞 联系商务 Jack · 131 6872 7779或邮件 chenjiaxin@wenshucha.com · 查看 私有化方案详情 · API/MCP 定价
相关阅读:律所内网大模型 GPU 选型 · 向量库与检索引擎选型 · 律所 RAG 知识库搭建 · RAG 还是微调 · 开源底座模型选型 · 私有化监控与告警 · 三年 TCO 测算 · 律所 AI 私有化部署指南