1. 企业AI落地的第一道坎数据出域和“不敢用”做了几年企业级AI落地我越来越确认一件事很多AI项目不是被技术难死的是被“数据能不能出内网”这个问题卡死的。业务部门拿着智能客服、工艺优化、文档助手的需求过来技术团队也评估过开源大模型效果不错结果安全合规一参与公有云API路线直接被否项目原地搁置。于是“把企业数据留在内网把AI开发门槛降到最低”就成了我最近两年听得最多、也做得最多的一个方向。1.1 数据“出域”到底在怕什么很多人一说数据不能出域第一反应是“你们公司太保守”。其实真不是保守而是有些行业的数据属性决定了它不适合走公有云API。我接触过的几类典型场景制造业产线上的工艺参数、设备运行日志、质检图像这些数据直接反映产能缺陷和成本结构属于核心商业机密。有一次客户想用大模型分析热处理车间的温度曲线谈方案时对方主管很直白“这批参数外传哪怕一条我都要负责任的。”医疗行业病历、影像、检验报告涉及患者隐私和监管要求。医院的信息科往往比企业更谨慎内网服务器装个软件都要走流程审计更别说把数据送到外部大模型接口。金融和政务客户信息、业务流水、公文材料数据安全等级高合规要求严格几乎所有涉及外部调用的方案在立项阶段就会被挡掉。数据不能出域技术上的含义不止是“不能上传”还包括“不能被间接获取”。所以大家真正需要的不是一句“我们加密传输”的承诺而是一套完整跑在企业自有网络里的AI开发环境模型、推理服务、开发框架、应用入口全部都在内网。1.2 内网化不等于性能妥协开源模型已经够打两年前说起内网部署大模型大家第一反应是“效果太差”。那时候能用的开源模型确实不够看7B参数的中文模型连基本的指令遵循都时好时坏。但现在情况完全变了。以目前开源社区主力模型为例模型参数规模量化后显存占用Q4足够胜任的场景Qwen2.5系列7B / 14B / 32B约4.7GB / 9GB / 19GB中英文问答、代码生成、结构化提取Llama 3.1系列8B / 70B约5GB / 40GB英文为主、多轮对话、Agent推理GLM系列4B / 9B / 32B约2.6GB / 6GB / 18GB中文办公场景、工具调用实测下来14B级别的模型经过量化后放在一张16GB显存的卡上日常处理文档摘要、报表问答、代码辅助、信息抽取这些企业高频任务效果已经能到“直接可用”的线。很多场景甚至用8B模型就够了。所以现在我的结论很明确不是“效果不行所以不能私有化”而是“私有化部署后如何在有限资源下把效果调到最优”的问题。这个转变非常关键它意味着内网AI开发这件事从“能不能做”变成了“怎么高效做”。2. 内网AI开发平台的四层拼图先想清楚再动手给企业搭建内网AI环境我最怕的就是一上来就装Ollama、拉模型、开WebUI热闹半天等真正要开发业务应用的时候发现没人知道怎么接入。内网AI开发不是“装个聊天机器人”而是一套能让多个团队持续开发、持续上线的平台。我习惯把它拆成四层来规划。2.1 模型推理层把大模型跑在自己的服务器上这一层是整个平台的地基解决“模型在哪跑、怎么被调用”的问题。当前主流方案是两类Ollama轻量级推理框架安装简单一条命令拉模型自带OpenAI兼容接口适合开发测试环境和中小规模并发。vLLM推理吞吐高、显存管理好支持高并发场景适合正式生产环境但部署和调参门槛明显高一些。对于绝大多数起步阶段的企业我建议先从Ollama跑起来把业务验证通了等并行调用量真的大了再迁到vLLM。没必要第一阶段就给自己上高难度。2.2 Agent编排层给开发者一条统一调用通道模型跑起来只是第一步关键是让企业内部的开发人员能低成本写出AI应用。现在主流的做法是提供一套Agent编排能力定义大模型要调用哪些工具、按什么步骤执行、怎么处理中间结果。我在内网环境里常用Dify、LangChain这类开源框架。它们解决的问题很实际需要做一个“查库存再生成补货建议”的AI应用Agent框架负责判断什么时候调库存接口、什么时候调用大模型生成文本。需要接入企业知识库做RAGAgent框架负责文档切分、向量检索、召回内容拼装。需要让多个模型按指令路由Agent框架可以配置哪类问题走小模型、哪类走大模型。2.3 应用集成层业务系统通过API接入这一层决定企业现有的OA、ERP、MES、报表系统能不能快速把AI能力用起来。统一API网关的意义在于业务系统不需要关心底层是哪个模型只要拿到一个标准的“对话接口”或者“分析接口”就能把AI功能嵌入现有业务流程。我一般会在推理服务前面加一层薄网关做三件事统一API地址、统一Key管理、统一请求日志。这样以后换模型、加模型对业务系统都是透明的开发人员不用改代码。2.4 运维观测层内网也需要“监控”很多内网AI项目栽在“没人管”上。模型服务挂了没人知道显存打满了没人看调用日报根本出不来。所以在搭好前三层后我强烈建议同步部署一套轻量监控哪怕是Zabbix加Grafana或者简单的脚本盯端口和显存。观测层解决的是平台能不能长期稳定跑的问题这一层省掉后面会花几倍的时间填坑。3. 手把手半天搭出一套可用的内网AI开发环境说再多不如直接上手。下面这套部署方案我帮多个企业落地过所有组件都能跑在内网逻辑清晰扩展也方便。整体就四步准备机器、启动容器、拉模型、验证接口。熟练的话半天足够。3.1 硬件和系统准备先看硬件。起步阶段最务实的配置是方案A一台物理机 16GB显存显卡如RTX 4080/4090或同级别专业卡跑14B量化模型。方案B一台纯CPU服务器 64GB内存跑7B量化模型推理速度慢一些但能跑。方案C几台旧工作站组成小集群分布跑不同模型适合阻力较大的场景。操作系统推荐Ubuntu 22.04 LTS省心稳定。需要提前装好Docker Engine和NVIDIA容器工具包。注意Docker官方安装脚本在纯内网环境经常超时我习惯把docker-ce的deb包提前下载好用dpkg -i离线安装再把镜像通过docker save和docker load在机器间搬运。确认GPU能被Docker识别很关键执行下面这条命令docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi能看到显卡信息说明GPU透传正常后面跑模型就不会抓瞎。3.2 用Docker Compose把推理服务和Web入口框架起来这里用最简单的Ollama加Open WebUI组合。Ollama提供推理能力和标准接口Open WebUI给业务人员一个图形化聊天入口两者都在内网。version: 3.8 services: ollama: image: ollama/ollama:0.3.13 container_name: ollama restart: always ports: - 11434:11434 volumes: - ./ollama_data:/root/.ollama # 有NVIDIA GPU时放开下面配置 # deploy: # resources: # reservations: # devices: # - driver: nvidia # count: 1 # capabilities: [gpu] open-webui: image: ghcr.io/open-webui/open-webui:v0.3.8 container_name: open-webui restart: always ports: - 3000:8080 environment: OLLAMA_BASE_URL: http://ollama:11434 volumes: - ./webui_data:/app/backend/data保存为docker-compose.yml然后执行docker compose up -d启动后内网其他机器访问http://服务器IP:3000就能打开AI聊天界面。第一次打开要注册管理员账号注册完进去设置一下模型把Ollama服务地址填成http://ollama:11434。3.3 拉取并验证开源模型在服务器上拉模型docker exec -it ollama ollama pull qwen2.5:14b-instruct docker exec -it ollama ollama pull bge-m3第一个是主对话模型第二个是嵌入模型后面做知识库会用到。如果企业网络不能访问外网模型仓库就需要在能上网的机器上预先ollama pull然后把整个模型目录拷贝进去或者直接docker commit一个带着模型的镜像再在内网导入。这一步看起来很笨但确实最稳。验证模型能不能正常对话docker exec -it ollama ollama run qwen2.5:14b-instruct 请用一句话介绍你自己正常会返回一段中文自我介绍。如果出现显存不足报错考虑换更小参数量级或更低精度量化模型。3.4 给AI Agent开发留一个统一API入口聊天界面只是表象真正给开发人员用的是API接口。Ollama兼容OpenAI接口格式所以企业内网的Python开发可以直接这样调用from openai import OpenAI client OpenAI( base_urlhttp://10.0.0.8:11434/v1, api_keyollama, # 本地服务任意非空字符串即可 ) resp client.chat.completions.create( modelqwen2.5:14b-instruct, messages[ {role: system, content: 你是企业数据分析助手回答要简洁、严谨只依据给定知识输出。}, {role: user, content: 请总结三号产线本周异常工单的共性问题。} ], temperature0.1 ) print(resp.choices[0].message.content)这样开发测试环境基本就通了。后面的Agent开发都可以直接在这个接口上叠框架。比如用LangChain做一个带知识库的问答Agent只需要把OpenAI的base_url指到内网地址模型名换成内网已经拉取的名字整体代码迁移成本非常低。4. 落地时最容易翻车的五个细节搭建过程看似流畅但真正上生产时我几乎每次都栽在这五个细节上。提前绕开能省很多事。4.1 显存估算不是简单看模型文件大小很多人以为“模型文件4.7GB那我8GB显存的卡足够了”。这是最大的误区。模型文件的大小只是权重的体积推理时还需要额外空间存KV Cache和激活值。KV Cache和上下文长度强相关上下文越长占得越多。我建议按以下经验值预留模型规模量化位数权重占用上下文8K时KV Cache占用建议最低显存7B~8BQ4_K_M约4.7GB约0.8GB8GB偏紧12GB舒适14BQ4_K_M约9GB约1.5GB16GB起步32BQ4_K_M约19GB约2.5GB32GB起步如果还想用更高量化精度或者把上下文设到32K以上显存也要同步上浮。我的原则是显存宁多勿少差一档卡在OOM和稳定运行之间体验天差地别。4.2 GPU驱动与Docker的可用性问题最常见的离线安装场景是内网机器装好了驱动但Docker容器里访问不到GPU。原因通常是NVIDIA Container Toolkit没装或者驱动的CUDA版本和镜像基础环境不匹配。排查分三步# 1. 确认主机能看到显卡 nvidia-smi # 2. 确认容器工具包已装 dpkg -l | grep nvidia-container-toolkit # 3. 确认Docker API能使用GPU docker info | grep -i runtime如果docker info里看不到nvidia运行时需要重新安装nvidia-container-toolkit并重启Docker。离线环境需要准备好这个工具包的deb包没法临时从网上拉。4.3 旧服务器或Windows主机能怎么办还真有不少单位的内网机器是Windows Server 2016这类古董环境。直接装Docker Desktop在Server 2016上基本行不通工商反复也不值得。我的处理方式是两种在Windows Server上用Hyper-V开一个Ubuntu虚拟机虚拟机的网络设成桥接模式让内网其他机器可以直接访问。性能损耗不大胜在隔离干净。如果连Hyper-V都没有就直接用WSL2跑Ubuntu然后在里面装Docker。不过Server 2016默认不支持WSL2可能要先确认功能更新情况。老服务器如果没有NVIDIA GPU老老实实CPU推理跑7B模型每秒出几个token做后台离线分析还行做实时对话就有点难受。这种环境建议不要追求大模型把业务拆小能通过小模型加规则解决的就别硬上14B。4.4 多团队共用时的Key管理与限流内网平台搭起来后业务部门、研发部门、数据分析团队都会来要接口。如果所有人共用一个访问地址一个团队跑批任务就能把推理资源耗到满别人的实时调用全卡住。所以Gateway这层很关键。我在实际项目中会用一个简单的OpenResty或FastAPI服务包一层每个团队一个独立API Key同时给不同Key设置不同的每分钟请求数上限。资源配额不是给开发添麻烦是让平台在多人共用环境下还能稳定服务的基本保障。4.5 数据回流AI要长期可用必须解决“知识的更新”内网模型跑起来之后很快会遇到一个问题模型不会自动知道企业内部的制度变更、新项目进度、最新产品手册。这时必须搭一套知识库更新流程。我推荐的做法是用本地嵌入模型把文档向量化存到向量数据库里。每次业务文档更新就跑一次异步任务重新切分、嵌入、入库。这样用户提问时答案能从最新文档里检索。整套流程完全内网运行数据不出域。5. 从“能跑”到“好用”我的内网AI开发心得平台搭好只是第一步。结合我落地过的项目经验想把内网AI真正变成开发团队依赖的能力还有几条容易被忽略的经验。5.1 先别急着微调先搞好“上下文”经常有人一上来就说“我要微调模型”我基本都会劝住。企业场景里头90%的“效果不好”问题不在模型本身而在没有把企业知识送进推理过程。先做RAG梳理业务文档、建好向量索引、设计好检索切片效果提升往往立竿见影。微调成本高、周期长而且没有足够的优质标注数据时微调结果可能还不如直接调提示词。我的建议是上下文工程排在微调前面等RAG这套真跑透了、数据积累够了再考虑微调。5.2 让业务部门觉得“好用”的最小闭环很多内网AI项目死在“只会聊天”上。Chat界面演示很惊艳但业务部门真正想要的是在Excel里点一下就能生成分析报告在工单系统里点一下就能自动分类。所以平台搭完我总会挑一两个高频痛点先做成最小闭环比如把OA里堆积的公文自动生成摘要发到相关人邮箱。把售后工单按“设备故障/软件问题/投诉建议”自动分类推进到对应处理组。把生产日报数据传给模型让模型生成带结论的分析意见。这不需要多复杂的Agent几个定时脚本加API调用就能做出来。但每做成一个业务部门对平台的信任就增加一分后续推广会顺畅很多。5.3 技术上留一根“离线路由”备份与恢复内网环境最大的特点是“和外网隔离”这意味着一旦某个组件坏了没法临时上网重装。我在每台部署机器上都会维护一个本地镜像目录把用到的所有镜像、模型的离线包、依赖工具的deb包都存一份。每季度做一次恢复演练保证即使服务器重装也能在半天内把整套环境拉起来。这个习惯一开始觉得麻烦但真遇到磁盘损坏或者机房迁移会感谢自己。5.4 一个容易被忽略但重要的问题模型授权与员工使用边界开源模型也有各自的许可证企业内部商用前需要确认模型授权范围这关系到企业能不能把模型用在真实业务流程里。同时内网AI平台上线后务必给员工明确使用边界哪些数据可以传给模型、哪些岗位权限能访问哪些功能。这既是安全要求也是让平台长期良性运行的基础。我的习惯是和法务、安全团队提前对齐把这些内容写进平台申请材料里避免事后补锅。内网AI开发这条路技术方案已经非常成熟真正能拉开差距的是组织协同和对场景的理解。把模型跑起来一点也不难难的是让数据安全、开发效率、业务价值三者真正同时成立。希望我踩过的这些坑能帮你少走一些弯路。