1000万人口的社保智能客服——本地化部署的成本、算力与信创选择

一、为什么社保智能客服必须本地化

先说一个前提：社保智能客服的LLM不能走公有云API。

不是技术问题，是合规问题。参保人的姓名、身份证号、社保缴费记录、医疗消费明细——这些都是《个人信息保护法》里明确定义的敏感个人信息。用公有云API意味着数据要通过互联网传出去，任何一个环节没拦住，出事了就是大事故。

所以部署方案只有一个选项：全链路本地化。LLM推理在本地GPU上跑，向量检索在本地Milvus上跑，会话保存在本地Redis上。数据不出政务内网，从物理上堵住外泄风险。

这条红线不可商量，剩下的问题都是工程问题：

• 1000万人口的省，要多少算力？
• 用英伟达还是国产昇腾？
• 多少钱？怎么跟领导汇报预算？

二、用1000万人口做一张算力需求表

以小型省份为参考：1000万常住人口，约700万参保人。这个规模在省级单位中算小的——比它大的有3000万、5000万。先把小规模的算力需求算清楚，再等比放大。

社保办事不是电商，不是谁每天都上去买东西。一个大致的经验公式：

日均请求量 = 参保人数 × 日活跃率 × 人均交互轮次

700万参保人，日均活跃率保守按 2‰ 算（每天有1.4万人使用），人均交互轮次按 10轮 算：

• 日请求量 ≈ 14万次
• 高峰时段（9:00-11:00）占全天请求量的 60%，即约8.4万次
• 那2小时内，平均 QPS ≈ 8.4万 / 7200s ≈ 12 QPS
• 考虑峰值波动，预估峰值 QPS 约 20-30

加上 RAG 检索 + embedding 计算的开销，实际的 LLM 推理 QPS 需求在 30-40 左右比较稳妥。如果再留20%余量，目标是 40-50 QPS。

规模	常住人口	参保人数	日均请求	峰值QPS	推荐配置
小型省	1000万	700万	14万	20-30	4×A800 或 5-6×昇腾910B
中型省	3000万	2000万	40万	60-70	8×A800 或 10-12×昇腾910B
大型省	5000万	3500万	70万	100-120	12-16×A800 或 16-24×昇腾910B

实际活跃率跟推广力度强相关。如果接入APP首页+小程序+公众号三个入口，日活可能到5‰甚至更高。建议部署时预留扩展槽位。

三、两套GPU方案：A800 vs 昇腾910B

方案一：英伟达 A800 80GB

配置	并发	一次性成本	适用
2卡	30-50 QPS	55-65万	市级/低峰期
4卡（推荐）	60-90 QPS	110-130万	小型省，有余量
6卡	90-130 QPS	170-200万	冗余过度

跑 vLLM 的 continuous batching，DeepSeek V4 Flash INT4 量化，单次 RAG 问答响应时间 2-3秒。4卡可以稳定撑住 60-90 QPS，日常跑20-30绰绰有余，峰值不怕。

优点是生态成熟、vLLM支持好、社区踩坑少。缺点是断供风险——美国制裁随时可能让后续采购卡住，所以方案一适合"先用起来，不纠结长期增购"的场景。

方案二：华为昇腾 910B 64GB

配置	并发	一次性成本	优缺点
5-6卡	60-90 QPS	40-60万	国产合规，需适配
8卡	90-130 QPS	64-80万	余量充足

910B 单卡算力大约是 A800 的 80%，但单价只有 A800 的 1/3 到 1/2。达到同样的并发需要多配 25% 的卡数，但总价更低。

真正的门槛不是价格，是适配。910B 跑大模型要走昇腾的 mindie 推理框架，不是直接拿 vLLM 就能跑。适配周期可能是几周到一个月。但一旦适配完成，信创合规这一条就满分——招标文件里"优先采用国产算力"的要求可以直接满足，不用解释。

两套方案怎么选

考量	A800	昇腾910B
总成本	110-130万	40-80万
信创合规	需另外解释	天然满分
部署速度	1-2周	3-5周（含适配）
后续采购	可能有断供风险	国产供应链稳定
社区支持	成熟	较新

如果项目时间充裕、需要过信创审计，选昇腾。如果赶时间上线、先跑效果再谈合规，选A800。

四、不只是GPU：其他资源怎么配

很多人一谈部署就只算GPU，忘了引擎周边还有一堆配套资源：

资源	规格	月成本（政务云内部价）	说明
LLM推理	4×A800或6×昇腾910B	硬件一次性	核心支出
Redis	8GB主备	几百块	存会话+SOP
Milvus	16C 32G + 200GB SSD	一两千	向量数据库
HTTPS服务	4C 8G + 10Mbps	几百块	Flask + Nginx
对象存储	500GB	几十块	上传照片临时存储

除GPU外，月度云资源费用加起来不超过三四千块。真正的预算大头永远是GPU，其他都是零头。

五、一个经常被忽视的省钱建议

政务云可能有省级统一算力池。

很多省的大数据局已经采购了一批GPU服务器放在政务云上，各个厅局的项目可以直接申请算力额度。如果你的省有这个池子，自购GPU的钱就不用花了——从算力池里申请几卡就行，费用走政务云内部结算。

所以在做预算之前，先问省大数据局：有没有统一算力池？能不能申请？额度够不够？

这件事看起来简单，但实际项目中经常被忽略。很多项目组上来就算GPU配置、报采购预算，汇报了一大圈，最后发现可以用现成的。一个电话能省几十万。

六、便民——这些算力最终服务谁

12个业务类型，涵盖了一个普通人跟社保打交道的全部场景：

类型	业务
查询类	养老金发放查询、缴费记录查询
办理类	养老金资格认证（刷脸）、社保关系转移、参保证明开具、参保登记、个人信息修改、异地就医备案、社保卡申领、医疗费用报销、失业保险金申领、生育保险申领

以前办这些事情要去社保大厅——排队、填表、等叫号。现在打开手机对着说"我要办社保关系转移"，Agent 自动引导填4个字段，提交后后台处理完推送结果。

最直接的便利不是"AI很酷"，而是看不懂政策的人终于能自己把事情办了。系统的价值不在LLM本身，在「零门槛」。

七、总结

这套方案的核心逻辑：

1. LLM必须本地部署——社保数据不能出域，不是选择题
2. GPU按参保人口推算——700万参保→峰值30-40 QPS→4卡A800或6卡昇腾910B
3. 方案可以等比缩放——换成300万人的市就砍半，换成1500万人的省就加50%
4. 昇腾是信创的最优解——比A800便宜，还自带合规加分
5. 先问大数据局有没有算力池——一个电话可能省几十万
6. 便民不是技术指标——是让不懂政策的人也能自己办事

这个方案给的是小型省份（1000万人口）的数据。但方法是通用的——换一套人口数字进去，QPS、卡数、预算都能等比算出来。

---

附：系统技术栈 — DeepSeek V4 Flash INT4 + Ollama(BGE-M3) + Milvus + Redis + Flask HTTPS，Python 3.11+。核心代码约2000行，12个业务类型均实现桩数据，待联调业务API和人脸服务后即可生产部署。