给一家 120 人律所做私有化 AI 部署的 11 天：踩过的坑和一些数据
前段时间接了一个案子：帮一家 120 人规模的律所把四个国产大模型（DeepSeek、通义千问、豆包、Kimi）私有化部署到所里内网，做统一网关、统一账号、部门计量、审计日志。
项目从签合同到正式上线用了 11 个工作日，合伙人最后反馈"省心"。这篇把技术方案和踩过的坑完整写出来，给同样在做企业 AI 落地的朋友参考。
一、需求背景
律所主任找过来的时候，问题说得很具体：
"所里年轻律师都在用 DeepSeek 和 Kimi 查案例、写合同稿，但有两件事让合伙人睡不着觉。
一是上周我发现有个律师把一个工伤索赔客户的完整卷宗粘到 Kimi 网页版让它总结——这案子涉及某上市公司，资料如果流出我们要被客户起诉。
二是每人自己开会员，有人包月、有人按次，没人算得清所里到底在 AI 上花了多少钱，谁用得多。"
这是典型的中小企业 AI 使用痛点：便宜的工具带来的数据风险和管理混乱。
律所的构成也比较典型：
- 公司业务部（40 人，合同起草为主）
- 诉讼部（35 人，案例检索、法条查询）
- 家事部（18 人，离婚协议、调解书等）
- 知产部（12 人，专利、商标）
- 行政/财务（15 人）
二、方案评估：为什么不用现成的
讨论过三条路，都被否了。
路径 A：公司统一买钉钉/飞书的企业 AI
- 飞书 Aily 在法律场景表现一般，合同和案例的专业性不够
- 核心痛点没解决：数据依然上云到飞书服务器
路径 B：买 DeepSeek 企业版 + 通义企业版 + 其他
算过账：120 人 × 3-4 个模型会员 × 人均 ¥300/月 ≈ ¥12 万-¥15 万/月。
- 贵
- 数据依然出内网
- 账号管理还是一团乱
路径 C：自己招人开发
律所哪有技术团队，招一个后端 25K/月起，半年才能上线，一年成本 40 万起。对 120 人规模的律所不划算。
最终选：自建私有化网关（基于开源项目二次开发）
核心判断是：这个问题开源社区已经解决了 70%，剩下 30% 是企业场景的适配。
底座用 one-hub（Apache 2.0 协议，one-api 的一个 fork），在它基础上加：
- 企业微信单点登录
- 部门级 Token 计量和报表
- 审计日志（脱敏 + 加密）
- 场景化模型路由
- 律所专用的提示词模板库
三、技术架构
员工浏览器/企业微信
↓ 内网 HTTPS
所里局域网 AI 网关 (Docker Compose)
├── 认证中间件（对接企业微信扫码登录）
├── 审计日志（每条 prompt 脱敏后存 PostgreSQL）
├── Token 计量（按部门/个人/项目三维度）
└── 模型路由层
├── DeepSeek V3（合同起草）- 走专线到 api.deepseek.com
├── 通义 Qwen-Max（案例检索）- 走阿里云 VPC 专线
├── Kimi K1.5（长卷宗摘要）- 走公网 API
└── 本地 Qwen-14B-Chat（敏感内容脱敏/初筛）
└── 部署在所里一台带 A100 的工作站
分层思路很重要：敏感内容走本地模型，一般查询走 API，长文档走 Kimi（128K 上下文这个点其他国产 API 还没完全跟上）。
技术点 1：OpenAI 兼容层的隐藏差异
四个模型都号称 OpenAI 兼容，实际有不少坑：
| 模型 | 实际差异 |
|---|---|
| DeepSeek | finish_reason 在流式响应中会漂移，有时 stop，有时 length，需要后置归一化 |
| 通义 DashScope | 兼容模式对 tool_calls 不完全支持，要切回 function_call |
| 豆包 | Rate limit 错误码不返回标准 429，返回自定义的 ResourceExhausted |
| Kimi | 首 token 延迟较高（实测平均 2.3 秒），流式体验得加"AI 正在思考..."的中间态 |
我们做了一层 provider adapter，每个模型一个实现，对外暴露统一的 OpenAI 接口。
技术点 2：部门级 Token 统计
合伙人最在意的功能。实现上看着简单，但要考虑三维度聚合：
CREATE TABLE usage_logs (
id BIGSERIAL PRIMARY KEY,
user_id INT NOT NULL,
department_id INT NOT NULL,
project_tag VARCHAR(64), -- 可选,案件编号
model_name VARCHAR(32) NOT NULL,
prompt_tokens INT NOT NULL,
completion_tokens INT NOT NULL,
cost_cents INT NOT NULL, -- 用分而不是元,避免浮点
prompt_hash VARCHAR(64), -- SHA256(prompt),用于审计查找
created_at TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX idx_usage_dept_time ON usage_logs(department_id, created_at DESC);
CREATE INDEX idx_usage_user_time ON usage_logs(user_id, created_at DESC);
每天凌晨跑一个聚合任务，把明细数据压缩到日报表，保留两个月原始数据。报表直接用 Metabase 搭出来，合伙人自己在手机上看。
技术点 3：审计日志脱敏
合伙人要求每条 prompt 都能追溯，但又不想把身份证号、合同金额这些真实信息直接存数据库（万一数据库被脱，反而更糟）。
方案分两层：
- 脱敏版：正则替换身份证、手机号、金额、姓名等敏感字段后存储，用于日常查询统计
- 原文版：AES-256 加密后存到隔离的审计表，需要合伙人双人授权才能解密，用于真出事了的取证
这个设计过了所里法务内审。
技术点 4：场景化路由
一开始给所有场景默认 DeepSeek V3。结果家事部的律师抱怨"离婚协议模板生成得太啰嗦"，换成 Qwen-Max 后反馈立刻好。
最后的路由规则：
routing_rules:
合同起草: deepseek-chat
案例检索: qwen-max
调解文书: qwen-max # 风格更贴中文行政公文
专利文书: deepseek-chat
长卷宗摘要: kimi-latest # 128K 上下文
敏感内容预处理: local-qwen-14b
默认: deepseek-chat
国产模型各有擅长，不是一个模型打天下。 这是之前没想到的。
四、部署过程
从签合同到所里员工正式使用，11 个工作日：
| 时间 | 做了什么 |
|---|---|
| Day 1 | 现场调研，梳理 5 个部门的使用场景 |
| Day 2-3 | 采购机器（一台 Mac Studio M2 Ultra 跑 Qwen-14B + 一台 2U 服务器跑网关和数据库） |
| Day 4-6 | 环境部署、模型测试、企业微信接入 |
| Day 7 | 合伙人 + 3 个种子律师试用 |
| Day 8-9 | 根据反馈调整：UI 中文化、常用 Prompt 模板、快捷键 |
| Day 10 | 全员培训 2 小时 |
| Day 11 | 正式上线 |
硬件清单（可以直接参考）：
- Mac Studio M2 Ultra 192GB / ¥56,000（跑 14B 模型绰绰有余，比买 A100 卡省一半）
- 戴尔 R740 2U 服务器 / ¥28,000（跑网关、PG、Redis、Metabase）
- 千兆内网交换机 + 企业 SSL 证书
五、上线 45 天后的数据
| 指标 | 数值 |
|---|---|
| 日活员工 | 81 / 120（67.5%） |
| 月总请求 | 18.4 万次 |
| 月 Token 消耗 | 3.1 亿（输入 2.2 亿，输出 0.9 亿） |
| 月成本（API + 电费） | 约 ¥4,200 |
| 审计日志抓到的"可疑粘贴" | 7 次，其中 2 次确认是客户敏感资料（被系统拦截未流出） |
| 律师反馈"离不开" | 63% |
部门消耗排名：
- 公司业务部（合同起草多）—— 42%
- 诉讼部（案例检索、法条查询）—— 28%
- 家事部（调解书、离婚协议等模板）—— 15%
- 知产部 —— 9%
- 行政/财务 —— 6%
比"每人一个 Kimi/DeepSeek 会员"方案每月省约 ¥34,000。一次性投入（硬件 + 部署服务费）在 6-8 个月内回本。
六、文档里不会写的真正麻烦
几个实施过程里踩到的坑，分享一下：
1. 律师年龄结构大，培训比技术难
所里最年长的合伙人 58 岁，用电脑习惯双击浏览器图标。培训 2 小时里有 40 分钟是在教他新建对话、复制回答。后来专门做了一个内部 wiki，录了 6 个 5 分钟的教学视频，按岗位拆开（诉讼律师看诉讼的，合同律师看合同的）。
启示：企业 AI 项目的易用性天花板不是技术，是最老的那批员工能不能用。
2. 合伙人要的不是"AI 变强"，是"省心"
最后发现律所老板真正关心的不是模型多聪明，是：
- 我所里员工数据外流的概率是不是降低了？
- 我这月到底花了多少钱？
- 律师生产力有没有提升？
前两个问题是主要诉求，第三个是锦上添花。我们上线后做的仪表盘，首页就是这三个数字的月环比，合伙人每周会主动看一次。
3. 企业微信 SSO 的权限同步是长期麻烦
员工离职、部门调整，企业微信里改了，网关这边要同步。一开始是每天跑一次定时任务，后来发现有 24 小时延迟风险（离职那天还能用内网 AI 查客户资料），改成了监听企业微信的通讯录变更 webhook，5 分钟内同步。
这种细节不做，项目就是半成品。
4. 选型上的两个后悔
- PostgreSQL 没选 MySQL：后来发现所里原有系统（OA、案管系统）全是 MySQL，DBA 对 PG 不熟。下个项目会根据客户现有技术栈决定数据库
- 没做离线模型冷启动预热：本地 Qwen-14B 冷启动要 20 秒，第一次用户体验很差。后来加了启动后自动做一次 warmup 请求
七、对其他企业的建议
如果你们公司规模在 50-500 人，也在考虑把 AI 能力统一接入、解决数据合规问题，以下几点可以参考：
1. 不要一上来就开发
先盘清楚几个数字：
- 公司现在有多少员工在私下用 AI？（通常远超你想象）
- 他们都用在什么场景？
- 如果不做，未来 3-6 个月最坏情况是什么？（数据泄露？业务部门私自买工具的预算失控？）
这些数字比任何"AI 战略"都重要。
2. 国产四大模型都要接，但不是都要同等对待
实测下来：
- DeepSeek V3：性价比王，日常 80% 的请求都用它
- 通义 Qwen-Max：中文文风最正，写正式文书用它
- Kimi：长文档处理刚需，短对话不推荐（延迟高）
- 豆包：营销/创意场景更强，白领办公场景一般
3. 私有化部署不等于本地跑大模型
很多人误解私有化 = 本地 GPU 跑 70B 模型。实际上对大多数中小企业，"本地网关 + API 专线"就够了，数据在企业内网做脱敏和审计，大模型算力走云端 API。
真正要本地跑模型的场景：
- 法律、医疗、军工等行业监管明确要求的
- 数据极敏感、全链路不能出内网的
- 长期使用量巨大、算云 API 成本反而比本地贵的
4. 审计日志是销售卖点，不是技术细节
做企业项目，客户老板不懂 Token、不懂模型，但他们懂"出了事我能不能交代"。审计能力几乎是 to-B AI 项目里转化率最高的功能点。
八、如果你也有类似需求
我目前主要接的项目类型：
- 50-300 人规模的律所、会计所、医院信息科、制造业、金融科技
- 需要私有化部署国产大模型（DeepSeek / 通义 / 豆包 / Kimi）
- 需要做统一账号管理、部门计量、审计日志、合规审查
项目周期一般 10-15 天，费用看规模（5-12 万为主流区间）。
如果你们公司也在考虑这个方向，可以通过知乎私信我简单聊聊你们的场景。我会先免费帮你评估一下值不值得做这个项目——有些需求其实公网 SaaS 加个脱敏层就够了，不一定非得私有化。别一上来就花大钱。
也欢迎评论区讨论：你们公司现在的 AI 使用是怎么管理的？遇到过什么坑？
后续会继续写几篇实战复盘：
- 《给一家会计师事务所做 AI 审计助手的技术方案》
- 《医院信息科的 AI 病例辅助系统：为什么必须本地化部署》
- 《企业私有化 AI 网关的成本怎么算：一张表说清楚》
关注一下，不迷路。
