1. 为什么能跑起来和能进内网是两码事我见过太多团队在自托管 AI 助手的落地上栽跟头而且栽的方式出奇地一致在开发机上跑得飞起一挪到内网环境就各种幺蛾子。有人觉得是模型的问题有人怀疑是网络的问题折腾两三天最后发现——压根不是技术故障是进内网之前该做的检查一项都没做。自托管 AI 助手这件事本质上和把一台调试好的服务器推进生产机房是一个道理。你在自家客厅里怎么折腾都行但进了机房供电、散热、网络隔离、安全策略每一项都可能让你的设备变成一块砖。AI 助手进内网也是同样的逻辑内网有自己的一套规则有防火墙策略、有 DNS 解析体系、有代理限制、有安全审计要求你在公网环境下习以为常的那些调用方式进了内网可能全部失效。这篇文章要聊的就是这件事在你把自托管 AI 助手正式部署到内网之前有 5 项检查必须做完。这 5 项检查不是拍脑袋想出来的而是从实际踩坑经验里总结出来的。我会把每一项检查拆开讲清楚——为什么要查、怎么查、查完发现有问题怎么处理。不管你是用 Octop 这类自托管方案还是自己基于开源模型搭的 AI 代理助手这套检查流程都适用。适合读这篇内容的人正在或计划把 AI 助手部署到企业内网、实验室隔离网络、生产车间的工程技术人员。如果你只是在自己笔记本上跑个本地模型玩玩那这篇内容对你来说可能偏重了但提前了解一下内网部署的坑也没坏处。2. 第一项检查模型文件与依赖的离线可用性2.1 内网环境最致命的假设一切都能在线获取在公网环境部署 AI 助手你已经习惯了pip install、npm install、docker pull这些操作。模型权重文件从 HuggingFace 或者 ModelScope 拉取依赖包从 PyPI 或 npm 仓库下载Docker 镜像从公共 registry 拉取。整个过程行云流水你甚至不会意识到这些操作背后依赖了多少外部服务。但内网环境的核心特征就是没有直接的外网访问能力。有些内网通过代理可以访问部分外网资源有些内网则是完全物理隔离的。你在部署前如果不确认这一点到了内网你会发现pip install卡住不动docker pull直接超时模型文件下载到一半断了——而你连排查的方向都没有。我踩过最典型的一个坑在开发环境用pip install装了一个 AI 助手的依赖包这个包本身不大但它依赖了一个需要编译的 C 扩展。在开发机上编译很顺利因为系统里有完整的编译工具链。到了内网服务器上编译工具链不全pip install直接报错而这个错误信息又指向了一个内网根本访问不了的源。最后不得不回到开发机上把整个依赖树导出做成离线包再传进去。2.2 离线依赖包的完整制作流程正确的做法是在有外网的环境里把所有依赖提前打包好。具体操作分三步第一步导出完整的依赖清单。如果你用的是 Python 环境不要只导出requirements.txt那个文件通常只记录了顶层依赖。用pip freeze requirements_full.txt导出所有已安装包的精确版本。对于 Node.js 项目npm ls --all --json可以导出完整的依赖树。Docker 环境则用docker save把镜像导出为 tar 文件。第二步下载所有依赖的离线包。Python 环境下用pip download -r requirements_full.txt -d ./offline_packages把所有 wheel 文件下载到本地目录。注意要加上--platform和--python-version参数确保下载的 wheel 文件与目标内网服务器的系统架构和 Python 版本匹配。这一步经常被忽略结果到了内网发现下载的是 macOS 的 wheel而服务器是 Linux x86_64完全用不了。第三步在内网环境安装时指定离线源。用pip install --no-index --find-links./offline_packages -r requirements_full.txt来安装。--no-index告诉 pip 不要尝试访问任何在线源--find-links指定本地包目录。这两个参数缺一不可少了任何一个pip 都可能尝试联网然后卡住。对于模型权重文件情况更复杂一些。一个 7B 参数的模型FP16 精度下大约 14GB量化后可能 4-8GB。你需要确认内网服务器的磁盘空间是否足够以及文件传输通道是否支持大文件。我一般建议用分卷压缩加校验的方式传输传完后用sha256sum校验文件完整性。别问为什么问就是曾经传了 14GB 的模型文件加载时报格式错误重新传了一遍才发现是传输过程中文件损坏了。2.3 依赖版本锁定与冲突排查内网环境还有一个隐蔽的坑依赖版本冲突。在公网环境你可以随时升级或降级某个包来解决问题。但在内网每一次依赖变更都意味着重新走一遍离线打包流程成本极高。所以在进内网之前一定要在开发环境把所有依赖的版本锁定并且做一次完整的冲突检查。Python 环境下可以用pip check来验证已安装包之间的依赖关系是否一致。如果发现有冲突在开发环境就解决掉不要带到内网去。另外注意那些在运行时动态下载资源的依赖。有些 AI 框架会在首次运行时自动下载分词器文件、配置文件或者小的辅助模型。这些文件不在你的依赖清单里但内网环境同样下载不了。解决办法是提前在开发环境触发一次完整运行把所有运行时下载的资源都缓存到本地然后连同缓存目录一起打包带走。3. 第二项检查网络策略与端口连通性验证3.1 内网防火墙不是关掉就行的很多人对防火墙的理解还停留在关掉防火墙就能通的阶段。在内网环境防火墙策略往往是由网络管理员统一管理的你根本没有权限去关。而且即使你有权限也不应该关——内网的安全策略是有意义的绕过它只会带来更大的问题。AI 助手在内网运行时通常需要监听某个端口来提供服务。这个端口能不能被内网的其他机器访问取决于防火墙的入站规则。同时AI 助手如果需要调用内网的其他服务比如数据库、向量存储、内部 API还需要确认出站规则是否允许。我遇到过一个案例AI 助手部署在内网服务器 A 上监听 8080 端口。内网用户从机器 B 访问一直连接超时。排查了半天发现服务器 A 的防火墙只开放了 80 和 4438080 被挡住了。而网络管理员那边走变更流程开放端口花了三天。如果提前做了端口连通性检查这三天完全可以省下来。3.2 端口连通性检查的实操方法进内网之前你需要列一份清单AI 助手需要监听哪些端口、需要访问哪些内网地址和端口。然后逐一验证连通性。在目标内网服务器上用ss -tlnp查看当前监听的端口确认 AI 助手要用的端口没有被其他服务占用。用telnet或nc测试到其他内网服务的连通性比如nc -zv 10.0.1.100 5432测试能否连到内网的 PostgreSQL 数据库。如果发现端口不通先确认是防火墙问题还是服务本身的问题。在服务器本地用curl localhost:端口测试服务是否正常响应如果本地能通但远程不通基本就是防火墙策略的问题。这时候需要联系网络管理员提供具体的源 IP、目标 IP、端口号和协议类型申请开放策略。注意不要试图用内网穿透工具来绕过防火墙策略。内网穿透工具在公网环境用于临时暴露本地服务是可以的但在企业内网环境使用这类工具往往违反安全合规要求可能触发安全审计告警。正确的做法是走正规的防火墙策略申请流程。3.3 DNS 解析与代理配置的隐性依赖除了端口连通性还有两个容易被忽略的网络依赖DNS 解析和代理配置。内网的 DNS 解析体系通常和公网不同。你的 AI 助手如果配置了某个域名来访问内部服务需要确认这个域名在内网 DNS 里能正确解析。我见过一个情况AI 助手配置里写的是http://model-server:8080在开发环境因为/etc/hosts里有映射所以能通到了内网没有这个映射DNS 也解析不了直接报域名解析失败。代理配置也是类似的问题。有些内网要求所有出站流量必须走代理如果你的 AI 助手没有配置代理或者配置的代理地址在内网不可用那么所有需要访问外部资源的操作都会失败。即使你的 AI 助手主要在内网运行如果它需要调用任何外部 API比如某些模型服务、更新检查等代理配置就是必须的。检查方法很简单在内网服务器上curl -v一个你需要的地址看它走的是直连还是代理是否成功。对于 DNS用nslookup或dig确认域名解析结果是否符合预期。4. 第三项检查计算资源与存储的实际承载能力4.1 别用开发机的配置去推测内网服务器这是另一个高频踩坑点在开发机上用 GPU 跑模型推理速度飞快于是想当然地认为内网服务器也能跑出同样的性能。结果到了内网发现服务器没有 GPU或者 GPU 型号不同、显存不够模型根本加载不了。AI 助手对计算资源的需求取决于模型规模和推理框架。一个 7B 参数的模型FP16 精度下需要大约 14GB 显存INT8 量化后大约 7GBINT4 量化后大约 4GB。如果你用的是 CPU 推理速度会慢一个数量级而且需要足够的内存来加载模型。进内网之前必须确认目标服务器的以下信息资源类型需要确认的内容检查命令CPU核心数、架构、是否支持 AVX2 等指令集lscpu内存总容量、可用容量free -hGPU型号、显存、驱动版本、CUDA 版本nvidia-smi磁盘总容量、可用容量、读写速度df -h、fio操作系统发行版、内核版本uname -a、cat /etc/os-release这些信息看起来基础但每一条都可能成为部署失败的根因。比如 CPU 不支持 AVX2 指令集某些推理框架会直接崩溃CUDA 版本和推理框架要求的版本不匹配GPU 加速用不了磁盘可用空间不够模型文件加载到一半报磁盘写入错误。4.2 模型加载与推理的内存峰值估算除了静态的资源确认还需要估算运行时的资源峰值。模型加载阶段的内存占用通常比推理阶段高因为加载时需要同时持有模型文件、中间计算结果和运行时环境。一个粗略的估算方法模型文件大小乘以 1.5 到 2 倍就是加载阶段的内存峰值。比如一个 4GB 的量化模型加载时可能需要 6-8GB 内存。如果服务器的可用内存刚好卡在边界上加载过程中就可能触发 OOM内存不足被系统杀掉。推理阶段的资源消耗取决于并发请求数。单用户单请求的情况下资源消耗相对可控。但如果内网有多个用户同时使用并发请求会导致内存和显存占用成倍增长。进内网之前最好做一次简单的压力测试用ab或wrk模拟多并发请求观察资源占用情况。提示如果内网服务器的资源确实不足以运行你选择的模型不要硬撑。考虑换用更小的模型、更高的量化精度或者把推理服务部署在资源更充足的机器上通过内网 API 调用。硬撑的结果通常是服务频繁崩溃用户体验极差。4.3 存储规划模型文件、日志与缓存的磁盘分配磁盘空间是另一个容易被低估的资源。除了模型文件本身AI 助手在运行过程中还会产生日志、缓存、临时文件。如果磁盘空间规划不当运行一段时间后磁盘写满服务就会异常。我一般建议给 AI 助手单独划分一个数据目录把模型文件、日志、缓存都放在这个目录下。模型文件按需加载不需要的模型可以清理掉。日志要配置轮转策略避免单个日志文件无限增长。缓存目录要定期清理特别是那些临时生成的中间文件。对于内网环境还要考虑数据备份的问题。模型文件通常可以从外部重新获取但 AI 助手的配置、用户数据、对话历史这些如果丢失了恢复起来很麻烦。进内网之前确认好备份策略是手动备份还是自动同步备份存储在哪里。5. 第四项检查安全策略与访问控制的合规性5.1 内网安全审计对 AI 助手的特殊要求企业内网通常有安全审计系统对网络流量、系统操作、文件访问都有监控。AI 助手作为一个持续运行的服务会产生大量的网络请求和文件读写操作这些操作如果不符合安全策略可能触发告警甚至被阻断。常见的安全审计关注点包括AI 助手是否尝试访问未授权的网络地址、是否读取了敏感文件、是否产生了异常的大量网络流量。进内网之前你需要了解内网的安全策略确认 AI 助手的正常运行不会触发这些告警。比如有些 AI 助手框架默认会尝试连接外部服务进行版本检查或遥测数据上报。在内网环境这些连接尝试会被安全系统拦截并记录。虽然不一定会导致服务不可用但频繁的告警会给安全团队带来困扰也可能导致你的服务被临时封禁。解决办法是在配置中关闭这些外部连接功能或者把相关地址加入白名单。5.2 身份认证与访问控制的配置要点AI 助手在内网运行时通常需要一套身份认证机制来控制谁能访问。裸奔的服务在内网也是不安全的内网不等于可信网络这一点已经被无数次安全事件证明了。最简单的做法是配置一个 API Key所有请求都需要携带正确的 Key 才能访问。稍微复杂一点的做法是接入内网已有的身份认证系统比如 LDAP 或 OAuth。选择哪种方式取决于内网的现有基础设施和安全要求。访问控制方面需要明确哪些内网地址可以访问 AI 助手哪些不可以。如果 AI 助手只服务于某个部门就把访问来源限制在这个部门的网段。如果需要对所有内网用户开放那至少要做好速率限制防止个别用户的大量请求影响其他人使用。注意不要在 AI 助手的配置文件中明文存储密码或密钥。使用环境变量或者独立的密钥管理服务来管理敏感信息。配置文件如果必须包含敏感信息确保文件权限设置为仅服务账户可读。5.3 数据不出内网的边界确认自托管 AI 助手的一个核心卖点就是数据不出内网。但数据不出内网这个承诺需要实际验证而不是想当然。你需要确认AI 助手在处理用户请求时是否会把请求内容发送到外部服务模型推理是否完全在本地完成日志和缓存中是否包含了敏感数据如果 AI 助手集成了外部 API比如某些云服务那么数据实际上已经出了内网。验证方法在内网服务器上抓包观察 AI 助手运行时的网络流量。如果发现有到外部地址的连接分析这些连接传输了什么数据。对于确实需要外部服务的场景评估是否可以用内网服务替代或者对传输数据进行脱敏处理。这一步经常被跳过因为大家默认自托管就等于数据不出内网。但自托管只是说软件部署在你自己的服务器上不代表它不会主动往外发数据。进内网之前把这个问题确认清楚避免后续的合规风险。6. 第五项检查故障恢复与回滚预案6.1 内网环境出故障时你无法随时重装在公网环境服务出问题了最坏的情况就是重装一遍。你有 root 权限有网络访问有各种现成的工具和镜像重装一个服务可能就十几分钟的事。但在内网环境重装的成本完全不同。你可能没有 root 权限需要走审批流程你可能没有网络访问所有依赖都要重新传输你可能连物理访问都做不到只能远程操作。一个在公网环境十分钟能解决的问题在内网可能变成三天的噩梦。所以进内网之前必须准备好故障恢复和回滚预案。这不是可选项是必选项。6.2 最小化回滚方案的设计回滚方案的核心思路是在进内网之前把所有能提前准备的东西都准备好把内网环境里需要做的操作降到最少。具体来说我一般会准备以下内容完整的离线安装包包括 AI 助手本体、所有依赖、模型文件、配置文件模板。打包成一个自解压的安装包在内网环境只需要执行一个命令就能完成部署。一键启动脚本把启动 AI 助手所需的所有命令写成一个脚本包括环境变量设置、依赖检查、服务启动、健康检查。在内网环境只需要运行这个脚本不需要手动敲一堆命令。回滚脚本如果新版本部署失败能够快速回滚到上一个可用版本。回滚脚本要包含停止当前服务、恢复备份文件、启动旧版本服务这几个步骤。配置备份AI 助手的配置文件、数据库、用户数据在每次变更前都要备份。备份文件要放在独立于服务运行目录的位置避免服务异常时把备份也一起损坏了。这些准备工作在开发环境做可能只需要一两个小时。但在内网环境临时做可能需要好几天。这笔时间账怎么算都划算。6.3 日志与监控的最小可用配置内网环境的另一个挑战是出了问题之后排查手段有限。你可能无法安装额外的监控工具无法访问外部的日志分析服务甚至无法方便地查看日志文件。所以进内网之前要配置好最小可用的日志和监控。日志方面确保 AI 助手的关键操作都有日志记录日志级别配置合理不要只记录 ERRORINFO 级别的日志对排查问题很重要日志文件有轮转策略避免磁盘写满。监控方面如果内网有现成的监控系统比如 Prometheus、Zabbix把 AI 助手的健康检查接口接入进去。如果没有至少配置一个简单的健康检查脚本定期检查服务是否正常响应异常时通过内网邮件或消息通知管理员。我自己的习惯是在 AI 助手的部署目录下放一个healthcheck.sh脚本用curl请求服务的健康检查接口根据返回状态码判断服务是否正常。这个脚本可以手动执行也可以配置成定时任务。简单但管用。7. 五项检查都过了之后还有什么要注意的五项检查做完你的自托管 AI 助手基本具备了进内网的条件。但根据我的经验还有几个细节值得在正式上线前再确认一遍。第一确认内网服务器的系统时间是否准确。这个听起来很基础但系统时间偏差过大会导致 HTTPS 证书验证失败、日志时间戳混乱、定时任务执行异常。内网服务器如果长时间没有同步时间偏差可能达到几分钟甚至几小时。用date命令确认一下如果偏差大配置 NTP 同步。第二确认 AI 助手的配置文件编码和换行符。在 Windows 开发环境编辑的配置文件换行符是 CRLF到了 Linux 内网服务器上可能被解析成多余字符。用file命令检查一下配置文件确保是 UTF-8 编码和 LF 换行符。第三确认内网用户的使用习惯和访问方式。AI 助手部署好了用户怎么访问是通过浏览器打开一个 Web 界面还是通过 API 调用还是集成到现有的办公系统里不同的访问方式对网络策略、认证方式、客户端配置的要求不同。提前和用户确认好避免部署完了发现用户根本用不了。第四留一个后门给自己。这里说的后门不是安全意义上的后门而是说在内网环境里你要确保自己能够远程管理和维护 AI 助手。如果只能通过物理接触服务器来管理那每次出问题都要跑机房效率太低。确认 SSH 或远程管理通道是否可用管理账号是否有足够的权限。第五做好心理准备。内网部署 AI 助手这件事第一次做大概率不会一帆风顺。你可能会遇到各种意料之外的问题可能是网络策略的可能是系统兼容性的可能是安全审计的。遇到问题不要慌按照检查清单逐项排查大部分问题都能定位到具体原因。实在解决不了的找内网的网络管理员或系统管理员协助他们对内网环境比你熟悉得多。我在实际部署中最大的体会是准备工作做得越充分内网部署越顺利。那些在开发环境花几个小时做的检查、打包、测试到了内网环境会成倍地节省你的时间。反过来如果抱着先部署上去再说有问题再解决的心态内网环境会让你付出更大的代价。最后分享一个小技巧把上面这五项检查做成一个 checklist每次部署新服务到内网之前都过一遍。时间长了你会发现大部分部署失败的原因都逃不出这五项检查的范围。形成习惯之后内网部署的成功率会明显提升。