上周和一个制造企业的朋友聊他们想上AI质检的事对方第一句就把我堵住了能不能把产线工艺参数、设备震动数据、缺陷图片传到云的API上去调大模型答案当然是不行这些工艺数据一旦出内网先不说保密协议合规那一关就过不去。这不是个别现象医疗、金融、政务、制造业几乎每个对数据敏感的行当都卡在同一个矛盾上业务想用AI数据却不能上云。这个矛盾其实有解而且解的思路很朴素——把AI跑在本地让模型和数据一起待在防火墙后面。我实际操作过的方案是在内网用开源模型做推理用本地知识库做私有业务问答再配上权限、审计、脱敏这套工程措施形成一个完整的安全合规落地链路。这篇文章就把我这段时间从选型到上线踩过的坑、测过的数据、总结出的经验完整写出来给同样被“数据不能上云”卡住的团队作个参考。1. 为什么“数据不能上云”不是小题大做三条躲不开的红线先说个容易产生误解的前提。很多研发同学第一反应是“把API地址配一下、数据脱敏一下就传上去了能有多大事”。但从业务方和合规方的视角看数据出域这件事从来不是一个技术开关而是一整套约束条件。我做本地化AI之前专门花了一周时间跟法务、安全、业务三方开会总结下来有三条红线是绕不过去的。1.1 数据敏感度分级不是所有数据都“看起来不敏感”很多数据单独看没感觉但组合起来就是核心资产。比如一条设备日志单拎出来是数字但堆上三个月、关联上工艺参数就能反推出良品率变化和配方比例一条门诊记录单看是文本但批量跑出统计规律就涉及患者隐私。业务AI最麻烦的地方在于它要处理的不只是“你觉得敏感”的那几张表而是把散落在OA、ERP、MES、数据库里的数据聚到一起建模。数据一集中敏感度就指数级上升这是很多团队一开始没意识到的。所以我建议任何想上业务AI的团队先做一次数据分类盘点。至少要区分绝密工艺配方、客户合同、核心代码、受限员工信息、部分经营数据、内部规章制度、产品文档、公开宣传材料。分类结果直接决定哪些数据能进AI系统、进到什么级别的环境里。这个动作看起来不产代码但它是后面所有技术选型的前提。1.2 出域风险不只是“黑客攻击”一种大多数人一想到数据上云的风险第一反应是“服务器被拖库”“接口被扫到”。但实际业务里更常见的是三类灰色风险一是供应链风险你调了某个大模型API数据经过对方链路时到底存没存、存多久、怎么删你根本不可控二是跨境管辖风险数据中心的物理位置决定了数据在哪个法域落地一旦出了问题责任说不清三是看不见的第三方——很多API背后还有嵌套的供应商你签的合同只约束了直接服务商但数据包会经过谁没人给你打包票。这三类风险靠签NDA、靠对方承诺“不训练你的数据”是堵不住的。唯一可控的办法就是让数据压根不出网。这也是“本地化部署AI”这几年从可选变成必选的根本原因——不是云端方案不好用而是数据主权这件事不能托管给任何第三方。1.3 合规不是一个名词而是一套流程等真正开始做的时候才发现合规不是上线前检查一遍就算完而是要落成一套持续的流程。至少包括数据访问有授权记录、模型对数据的调用有日志可溯、输出内容有敏感信息过滤、定期有权限复核和数据清理。一个能过审的本地AI系统本质上是能拿出“谁在什么时间、通过哪个应用、调用了哪些数据、得到了什么回答”的完整链路。这条流程没跑通之前哪怕模型效果再好也过不了内部评审。下文讲的整套开源方案技术选型只占一半另一半精力全在这套流程的工程化落地。2. 本地化AI的整体架构从“能用”到“好用”的组件选型明确了红线之后接下来就是架构设计。我最初以为本地化AI就是“内网服务器上装个大模型然后写个Web页面聊天”真做起来才发现生产可用级别的本地AI至少分四层模型层、推理引擎层、知识库层、应用与管控层。每一层都有开源组件可选但选型逻辑完全不同。2.1 四层架构每层解决一个独立问题模型层解决的是“AI的脑子够不够用”核心是参数量、量化等级、上下文长度推理引擎层解决的是“模型怎么跑得又快又稳”核心是显存管理、并发优化、推理加速知识库层解决的是“模型怎么知道你们公司的业务细节”核心是文档解析、向量化、召回排序应用与管控层解决的是“这东西怎么给业务人员用且不失控”核心是权限、审计、问答界面和接口。四层之间的耦合度比想象中低。模型可以只换不重启引擎知识库换一个向量库也不影响上层业务。所以搭建的时候不要一上来就追求大而全先把每一层的开源组件定好再逐层联调这样出问题好定位后面换组件也不伤筋骨。2.2 推理引擎选型三款主流开源方案怎么挑推理引擎是本地AI的“发动机”选错后面全部跟着遭罪。我主要测过三款Ollama、vLLM、llama.cpp。简单说下我的使用结论。Ollama适合起步和中小负载。安装简单一条命令就能拉起一个带 OpenAI 兼容接口的模型服务内置模型管理支持 AMD、NVIDIA 甚至纯 CPU 跑。缺点是高级调度能力弱单卡高并发场景下吞吐上不去。我自己第一版Demo就是用Ollama起的从装到聊天不超过十分钟。vLLM适合生产级高并发。它用PagedAttention做显存管理能让吞吐量比原生推理高好几倍支持连续批处理适合做成内部AI网关供多个业务系统调用。缺点是配置复杂度高对CUDA版本和模型格式有要求Quantized模型支持不如前两者顺手。llama.cpp适合资源受限环境。它把推理做到了极致轻量GGUF量化格式、CPU推理、显存不够也能硬跑甚至树莓派上都能玩。缺点是部署相对原始要自己写服务封装不适合业务团队直接对接。三款的选型逻辑很简单先拿Ollama验证业务效果效果确认了再根据并发要求评估是否上vLLM边缘小机器上用llama.cpp。不要一上来就分布式那一套多数企业的业务量根本到不了那个量级。2.3 模型服务接口统一省掉未来换引擎的麻烦换推理引擎最大的痛点是上层应用的代码跟着大改。所以我在设计时就强制加了一个约定不管底层用哪个引擎对外都暴露OpenAI兼容的/v1/chat/completions接口。Ollama本身自带兼容接口vLLM更是原生支持中间层用一个小代理做转发就行。这样做的好处是知识库和应用层只认接口不认引擎。今天用Ollama明天要上高并发换vLLM只改代理配置上层代码一行不动。这条经验看着不起眼但第二次换引擎时你会回来感谢它。3. 模型选型不是越大越好7B到70B怎么定架构定了之后真正花时间的其实是模型选型。我的经验是业务AI场景里“越大越好”是最贵的错觉。70B模型效果是好但显存要求也是7B的十倍起步推理速度还慢多数业务场景根本用不满它的能力。选模型要跟着任务走。3.1 按任务复杂度匹配模型体量我拆过一个实际的内部智能助手需求典型的任务有合同条款定位、制度文档问答、报表数据解释、客服话术生成。前两类本质是检索加抽取7B到14B模型完全能扛最后这类生成任务对语言组织要求高一些14B也够用。真正需要70B的场景通常是复杂推理、多文档综合归纳、代码生成这类高难度任务。所以选型第一步是列任务清单然后逐条判断“这个任务需要什么能力”。判断标准很简单如果人工看一眼文档就能答的问题小模型微调得好也能答如果必须跨五六个文档做推理的才考虑上大模型。3.2 量化等级和显存预算要一起算模型选型绕不开量化。以我常用的Qwen系列开源模型为例7B模型FP16权重大约14GB显存用4-bit量化能压到5GB左右14B模型4-bit量化约9GB70B模型哪怕4-bit也要40GB左右。显卡选择上7B量化版一张24GB的卡就能跑14B需要单卡32GB或双卡24GB70B大概率要上多卡或者索性租内网服务器。这里有个容易踩的坑只看权重显存不看推理时的KV Cache和中间激活。同样一个模型上下文拉到32K时KV Cache能吃掉好几GB。所以我给别人做配置表的时候习惯给一个“1.3倍安全系数”预留推理峰值免得一到长对话就OOM。3.3 用评测集说话别信“聊天感觉”本地化AI最忌讳用“和模型聊天感觉不错”来定版本。我吃过这个亏——第一版选了聊天效果更自然的模型结果一到专业术语问答就一本正经地胡说。后来老老实实做了评测集把业务里最典型的50个问题整理成标准答案每次换模型先跑一遍评测再谈感受。评测维度我固定用三个答对率答案包含正确信息点的比例、格式合规率能不能按要求输出结构化内容、敏感信息拦截率问到不该答的会不会答。三者在精不在多。一次实测里14B模型在答对率上比7B高了约14个百分点但推理速度慢了近一半最终我们根据“绝大多数问题的答案在文档里能搜到”这个前提选了折中方案才落地。3.4 开源协议和商用授权最容易被忽略的一关技术选型选得再漂亮协议不过关也是白搭。业界主流的几个开源模型用的都是宽松类协议允许商用但其中有些要求“月活用户超过一定规模需要单独申请授权”有些对输出保留、衍生模型标注有额外要求。我建议选型阶段就把协议条款过一遍至少确认三件事能不能商用、能不能用它微调后的模型对外提供服务、需不需要开源自己的微调版本。这四条不确认清楚就往上冲后面法务找上门的滋味不好受。4. 本地RAG知识库让AI真正“懂”你的业务基础模型再强它也没读过你的标书范本、设备手册和历史故障记录。业务AI和通用聊天AI的分水岭就在这一步上不上知识库。我做的是本地RAG检索增强生成方案整体流程是文档解析成文本、切分成小块、向量化、存入向量库问答时先检索相关片段再丢给大模型组织答案。4.1 为什么业务AI几乎绕不开RAG微调也是一种让模型懂业务的方式但成本高、更新慢每变一次业务就要重训一次。RAG的思路则是“模型不需要背下来文档需要的时候现查就行”把知识维护从模型训练变成文档库管理业务人员直接改Word就能更新AI的知识这两者的维护成本差距是数量级的。拿合同问答来举例合同模板一周一改如果走微调每次改版都要重新准备数据、训练、评测、发版走RAG只要把新版合同传到知识库里答案自动基于新版内容生成。哪个适合业务团队不用我说了。4.2 文档切分和向量化RAG效果的两条命RAG效果好不好一半看切分一半看向量化。切分太粗检索出来的片段里一半是废话模型抓不住重点切分太细语义被切断检索不准。我实测下来纯文本用512到768个中文字符、带20%重叠的切分方案效果最稳。但表格、合同这种结构化文档要特殊处理最好按章节标题切或者先用工具把表格转成文本描述再切。向量化用的是开源的 embedding 模型。这里有一个很多人不知道的细节embedding模型对中文的支持差异极大通用模型在“设备故障描述”这类垂直文本上经常召回不准建议用经过中文语料训练的模型并且最好拿自己的领域文本做一版小测试集看Top5召回率再决定。我在项目里测试过不同 embedding 模型的差别同一个问题上召回结果的相关性可以差出一大截。4.3 召回优化从“搜到”到“搜准”RAG最常见的失败是“明明知识库里有答案但AI就是答不出来”。我排查过很多次结果大部分不是模型笨而是检索环节没召回对。最实用的一组调优手段是一是给不同的文档类型打元数据标签检索时可以按业务域过滤二是引入混合检索纯向量检索加BM25关键词检索合并排序专有名词场景效果提升明显三是设定一个召回阈值低于相似度下限就不给模型喂数据宁可让AI说“知识库里没有”也别让它硬编。这组手段看着简单但每一条都能实打实提高召回质量。我做了个对比在内部设备FAQ上单纯向量检索的Top5命中率大约70%加上BM25混合检索后能到85%以上效果非常直观。4.4 一个实测案例设备故障问答的效果对比拿我们一个模拟的生产设备FAQ库举例总共500条问答对涉及机械臂、PLC、传感器常见报错。同一个8B模型不做知识库时回答纯靠通用知识三句话里有一句是编的接上本地RAG后答案准确率明显上了一个台阶基本能从库里准确定位到故障码对应的处理建议。推理时间也从裸问答的200ms涨到了800ms左右但换来了对业务问题的靠谱回答这个时延完全可以接受。5. 安全合规落到工程上的四件事权限、审计、脱敏、生命周期很多做技术的同学以为“安全合规”就是加个登录页其实完全不是。我把整个工程侧的经验浓缩成四件事每一件都必须有开源组件和落地方案兜底。5.1 最小权限不是“能登录就行”而是“能看见什么数据都受控”本地AI系统最容易出现的权限漏洞是“能访问AI的人就能访问全部知识库”。这绝对不行。比如市场部的人问AI合同条款AI不应该把研发部门的工艺文档也检索出来喂答案。工程上最简单的做法是给知识库目录打标、给用户分组检索时强制带权限过滤条件。我用的方案是权限模型放在应用层控制向量检索只接收“用户所属分组”参数查询前先剔除无权限的文档再执行检索。这样就算查到了也不能进上下文。这一步直接决定了AI回答里会带出谁的内部数据是合规评审时最被盯着的地方。5.2 审计日志没有日志就没有合规“谁问了什么、系统回答了哪些片段、有没有人试图问敏感话题”这些记录必须有而且要完整落到本地库里保留时间按内部规定执行。技术上完全可以用开源方案解决——NGINX层记访问日志应用层记问答明细推理引擎层记Token消耗三份日志按请求ID关联起来就能复现完整链路。不要小看日志这件事。有一次合规评审审计人员抽了一条问答要求还原当时检索了哪些知识片段、命中了哪个文档、模型基于哪段上下文生成的回答。因为我们的日志设计得全十分钟就把链路拉出来了。那一刻我深刻体会到审计日志就是合规的底气。5.3 数据脱敏与输出过滤双向都要拦业务AI要防两件事一是输入侧——用户提问时无意泄露了手机号、身份证号二是输出侧——模型从文档里检索到了个人信息然后原样吐出。所以要在输入和输出两个方向都加过滤。工程上输入侧用正则加实体识别命中敏感类型就做掩码输出侧除了同样的过滤还要加一层“合规答复兜底”——当模型被问到政策红线、涉密话题时直接返回固定话术。开源社区里有现成的敏感信息识别工具拉下来和RAG链路拼一起就能用。5.4 数据生命周期真的能删干净才算闭环本地化AI跑久了知识库、问答日志、向量库会积累越来越多数据。合规要求不只是“存得安全”还包括“到期能删干净”。这里有个技术坑向量库里的数据删除不是删一条记录就行索引和缓存里可能还有残留。所以我的做法是给每一份上传文档打唯一标识需要删除时同时清掉原始文件、切分后的文本块、对应的向量索引、以及问答日志里关联的引用记录。这四件事做齐安全合规才算是从概念变成了工程事实。缺任何一件到了评审阶段都拿不出完整证据链。6. 实测数据与踩坑记录一个生产项目的复盘理论讲完把这半年实际跑下来的硬件、参数、问题点记录一下给准备动手的团队一个参考。6.1 硬件配置与性能基准我的测试环境是一台双路服务器配了一张24GB的GPU模型用的是14B量化版Ollama拉起服务知识库有1200多篇内部文档。实际测得的性能如下表场景模型/配置平均首Token延迟生成速度备注裸聊天不挂知识库14B Q4量化约300ms约25 Token/s单用户测试RAG问答挂500条FAQ14B Q4量化约500-900ms约20 Token/s含检索耗时RAG长文档问答32K上下文14B Q4量化约1.2s约15 Token/s显存占用接近上限高并发测试20并发14B Q4量化明显劣化约8 Token/s建议上vLLM或限流这个数据说明一个问题单卡24GB跑14B模型单用户、低并发的知识库问答完全够用但并发一上来立刻吃紧。如果业务方明确说“全公司几百号人都在用”那就得加卡或者换vLLM做批处理。6.2 踩坑一上下文拉满之后显存爆了第一次压测32K上下文时程序直接OOM。排查之后发现根因是KV Cache峰值算漏了14B模型4-bit量化权重约9GB但上下文拉满时KV Cache额外要吃近7GB加上输入输出缓冲24GB的卡在极限状态下就很悬了。解决方法是限制最大上下文长度、把KV Cache量化打开并在网关层控制单请求的输入长度。6.3 踩坑二embedding模型不匹配导致“明明有答案但搜不着”第一版RAG上线后用户反馈“问一个问题知识库里有AI却说不知道”。查了半天问题出在embedding模型对中文设备术语的理解太弱。后来换了中文场景训练过的embedding模型又给文档加了标题和关键词元数据辅助检索这个问题才解决。这件事给我的教训是RAG链路里的模型不止大模型一个embedding模型选错了等于“眼睛瞎了”召回准不准直接决定AI答不答得出。6.4 踩坑三开源模型“一本正经地编造”怎么治即便挂了RAG小模型偶尔还会出现“编造文档里没有的细节”。我们的处理方案是双管齐下一是提示词里强制加约束要求“只能依据给定片段回答片段里没有的信息就明确说没有”二是给模型喂的片段里加上来源文档编号让回答带上引用出处编造的概率大幅下降。虽然不是100%根治但业务可用度已经足够。6.5 接入现有系统的最后一步模型和知识库都跑通之后还有一个经常被忽略的环节怎么让业务人员在日常工作流里用起来。我的做法是封装成OpenAI兼容接口接到内部已有的OA和IM机器人上让用户在聊天窗口直接提问而不是再单独学一个新的AI平台。这一步对业务推广的帮助极大——工具离用户越近使用率和价值兑现就越快。最后分享一个个人感觉最值得记住的经验本地化AI项目的成败七成不在模型选型而在数据准备和工程链路的完整性。很多人一开始冲着一颗大的开源模型去结果卡在文档切得不合理、权限没设计好、日志拉不出来这些“不性感”的环节上。先想清楚数据从哪来、谁能看、出了事怎么追溯再决定上多大的模型这个顺序千万别搞反。