1. 先搞清楚AI 微服务底座到底解决什么问题1.1 为什么单独的模型接口不够用把一个大模型或者几个开源模型部署好暴露一个 HTTP 接口出来这在今天已经不算难事。真正让团队头疼的是模型服务上线之后那一堆绕不开的工程问题多个模型服务怎么统一管理不同业务线的请求怎么路由到对应的模型限流、鉴权、日志、监控怎么做模型升级的时候怎么做到不中断服务我见过不少团队前期图省事直接让业务代码硬编码调用模型地址。模型一多环境一复杂马上就乱了。今天 A 服务要调 Llama明天 B 服务要调 Qwen后天还要接一个 embedding 模型每个模型的地址、端口、超时时间都不一样配置散落在各个业务代码里出了问题根本没法查。这时候你就需要一套底层的支撑设施让模型服务像数据库、缓存一样变成平台内部一个标准化的基础能力。谁来调用都走统一入口不需要关心模型部署在哪台机器、什么端口、什么协议。这套东西就是所谓的 AI 微服务底座。1.2 底座该由哪些部分组成一套能实际干活的 AI 微服务底座至少要包含这几个角色统一入口网关负责接收所有模型调用请求做路由、鉴权、限流、负载均衡。业务方只需要知道网关地址不用关心背后有多少个模型实例。模型服务层真正跑模型推理的服务。可能是 vLLM、TGI、Ollama也可能是你自己用 Python 封装的一个推理服务每个模型一个或多个副本。注册与配置中心记录当前有哪些模型服务在线、地址是什么、权重是多少。服务上下线时能自动感知配置变更时能动态刷新。基础依赖日志收集、指标采集、链路追踪。模型调用出问题的时候你得能快速定位是网络问题、模型推理问题还是参数传错了。管理界面或运维入口让你能直观看到服务状态、调用量、延迟、错误率。这套东西如果全部手动搭建懂行的人也得折腾一天不懂的人可能一周都搭不起来。所以就有了向导式安装这个需求把整个搭建过程固化成一步步引导式的流程跟着点下一步就能搞定。2. 向导式安装的落地思路与方案选型2.1 向导式安装和传统安装方式到底差在哪传统的安装方式本质上是给你一份文档你自己照着敲命令、改配置。文档写得再好也难免遇到环境差异、依赖冲突、版本不兼容的问题。你在网上搜教程十个人有十种装法抄作业都未必抄得对。向导式安装做的事情是把那些踩坑经验直接固化到程序里。安装过程不再是零散的命令而是一个完整的交互式流程——它先探测你的机器环境告诉你哪里不满足要求再让你按需勾选要装哪些组件然后自动把镜像拉下来、把配置生成好、把服务拉起来最后跑一个自检脚本告诉你安装是否成功。整个过程不需要你理解底层细节跟着引导走就行。我用一个生活化的类比来说手动安装是给你一堆乐高零件和图纸让你自己拼向导式安装是给你一个自动拼装流水线你只需要选好要拼成什么样子按一下启动按钮成品就出来了。2.2 我用到的方案容器化加编排再加一层交互封装市面上没有一款现成的工具能直接叫“AI 微服务底座向导”所以我实际落地的时候是组合了一套方案底座运行时基于 Docker 与 Docker Compose。安装引导层用 Python 脚本加 Web 交互页面实现。核心组件全部用官方镜像或者社区成熟的镜像避免自己从头造轮子。选 Docker Compose 而不是 Kubernetes是因为在大多数团队的实际场景中底座的规模不会一开始就很大。一台 GPU 服务器或者一台高配 CPU 服务器完全能承载初期所有模型服务的运行。Kubernetes 的学习成本和运维成本都很高为一个小底座硬上 K8s 有点杀鸡用牛刀。等你后面规模真的大了底座里的组件本身已经容器化迁移到 K8s 也不是什么难事。架构上先跑通比一步到位更重要。2.3 需要准备哪些硬件和软件先说硬件。如果你只是跑一些中小尺寸的模型比如 7B、13B 参数量的量化模型一块 24GB 显存的消费级显卡就够用。如果要做 70B 级别模型的推理那就需要两块或者更多大显存卡。没有 GPU 也能跑CPU 推理慢一些但做开发测试、验证流程完全没有问题。软件方面宿主机要求 Linux 环境Ubuntu 20.04 或者 22.04 我都实测过CentOS 7 以后也问题不大。Docker 和 Docker Compose 插件是必须的。如果你的服务器在国内建议提前把 Docker 的镜像源配置好不然拉镜像那一步会非常痛苦。Python 环境只需要 3.8 以上用来跑安装引导程序。这里有个细节我特别提醒一下向导脚本一定要做环境预检。我遇到过有人直接在没装 Docker 的机器上跑向导卡在中间一步报错整个安装流程中断排查了半天才发现是 Docker 没装。有了预检这种事在一开始就拦住了。3. 10 分钟跑起底座的完整实操3.1 第一步环境预检向导启动后第一个页面就是环境预检。它主要检查这几项Docker 是否已安装并且版本在 20.10 以上。Docker Compose 插件是否可用。宿主机剩余磁盘空间是否大于 20GB。内存是否大于 8GB。如果检测到 NVIDIA GPU会继续检查 nvidia-container-toolkit 是否安装。每项检测通过后显示绿色状态不满足的项会给出具体的修复命令。比如检测到没有安装 nvidia-container-toolkit页面会直接提示你执行sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker这个设计我花了不少功夫。安装过程最怕的不是报错而是用户不知道下一步该做什么。预检把所有可能的问题前置逐项给出解决方案避免了中途卡死的情况。3.2 第二步选择要安装的组件预检通过之后进入组件选择页面。这里不是让用户二选一而是按需勾选。我设计了四类组件组件类别包含内容适用场景基础运行时网关、注册中心、配置中心所有场景必选观测体系Prometheus、Grafana、日志采集生产环境强烈建议推理引擎vLLM、Ollama、CPU 推理服务根据实际模型需求选择示例应用一个简单的调用客户端 Demo本地测试和功能验证这里有一个比较容易犯的错第一次装的时候什么都想装。其实你只需要先装基础运行和一个推理引擎跑通全链路后再按需扩。全选安装不是不行只是首次安装的复杂度会上升出了问题不好定位问题在哪一部分。向导默认只勾选最核心的几项反而更符合 10 分钟跑通的目标。3.3 第三步配置核心参数组件选完接下来是参数配置。这一步是向导式安装的核心价值所在——它把散落在各个配置文件里的关键参数收集到一个页面上用交互式表单让用户填写再自动生成对应的配置文件。需要填写的参数主要有网关对外端口默认 8000注意不要和宿主机已有服务冲突。模型名称和模型文件路径支持填写 Hugging Face 模型 ID 或本地路径。GPU 使用策略是每张卡跑一个模型实例还是多个模型共享一张卡。管理员账号和密码用于登录管理后台。这些参数看似简单但背后涉及很多细节判断。举个实际例子GPU 使用策略这块如果检测到有 2 张显卡默认建议每张卡跑一个模型服务并自动为两个服务配置不同的显存分配。如果用户不熟悉显存管理向导就按照保守方案生成配置保证两个服务能同时稳定运行不会出现显存溢出导致互相抢占的问题。配置完成后向导会展示一份生成的配置预览。任何不会写配置的人都能在这里核对每一项设置是否符合预期确认无误再点击下一步。3.4 第四步自动部署与初始化点击部署按钮之后向导就开始干体力活了。它会按照你刚才的选择依次执行这些操作创建必要的目录结构。拉取选定的容器镜像。生成 docker-compose.yml 文件。启动依赖组件如配置中心、注册中心。启动网关并等待网关健康检查通过。启动推理引擎加载模型。执行初始化脚本向注册中心登记所有服务。运行端到端自检模拟一次真实的模型调用请求。这个过程中页面会实时显示部署日志每一步成功或失败都有清晰的状态标记。等模型加载完成可能需要一些时间7B 模型在 GPU 上一般 30 秒到 2 分钟内能完成加载如果是 CPU 跑可能得等几分钟。向导在这一步会特别提示用户不要因为界面看起来“卡住”就强制关闭实际上后台正在加载模型权重。3.5 第五步验证全链路是否真的通了部署结束不代表万事大吉最后一步验证至关重要。向导会自动执行一轮自检模拟真实请求打一遍全链路检查网关是否能正常返回健康状态。调用一次文本生成接口确认推理引擎的响应正常。检查监控指标采集是否在持续上报数据。自检通过后向导会给出一个汇总信息页面展示访问地址、管理员账号、模型调用示例代码。我强烈建议你在这一步之后再手动调一次接口做二次确认。命令行执行示例curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [{role: user, content: 请简单介绍一下你自己}] }如果返回了正常的响应内容说明底座已经真实可用10 分钟之内的目标基本达成。4. 常见问题与排查技巧实录4.1 端口冲突导致的启动失败这是最容易踩的坑。向导默认使用 8000 端口但很多机器上 8000 已经被别的服务占用了。服务启动时日志会提示address already in use。处理方式是在向导的端口配置页改成其他端口或者先停掉占用端口的服务。排查命令其实很简单sudo lsof -i :8000看到占用进程后判断是否能安全停掉。如果是可以停的就 kill 掉如果不确定就换个端口重新部署。我用向导落地时还专门做了一个逻辑在部署前自动检测端口占用并警告避免用户启动完才发现端口冲突又要从头来一遍。4.2 模型加载慢或者一直加载中很多人第一次用 vLLM 或者 Ollama 拉模型发现模型文件非常大7B 模型量化后的文件也有 4GB 左右。如果网络状况不好下载可能要等很久界面看起来就像卡住了。另外如果是在国内网络环境下直接从 Hugging Face 拉模型大概率会非常慢甚至失败。我建议提前配置好镜像站地址或者在向导里加一个选项允许用户填写自定义模型下载地址。本地已经有模型文件的话直接填本地路径就可以跳过下载步骤。4.3 容器内存溢出导致自动重启默认配置里每个容器的内存限制我是按照保守值设定的。网关分配 512MB推理引擎根据显存自动推断。但如果你在一个只有 16GB 内存的机器上同时跑多个服务还是有内存溢出的风险。当容器反复重启时先查看日志docker logs --tail 100 容器名称如果日志尾部出现了Killed或者Out of memory那就是内存不够。解决方式是减少同时运行的组件数量或者调整 compose 文件中的内存限制参数。向导生成的配置文件中所有参数都是可改的改完重新执行docker compose up -d即可生效。4.4 GPU 显存不足导致的初始化失败多模型同时加载时如果每个模型都试图占满整张显卡的显存后面的服务必然会启动失败。在实践中我总结出一条原则模型的显存占用估算公式大致是模型参数量的两倍。7B 模型用 FP16 精度加载大约需要 14GB 显存如果用 4bit 量化需求会大幅下降到 5GB 左右。所以你如果在 24GB 显存的卡上跑 7B 模型想再跑一个 embedding 模型空间是够的。但如果同时跑两个 13B 模型就不要用 FP16改成量化版本会更稳妥。向导的参数配置页里我专门加了显存预估提示引导用户合理设置。4.5 自检通过但业务调用报 401 鉴权失败这个问题主要出在 API Key 配置不一致上。向导初始化的过程中会生成一个默认的管理员密钥业务调用时需要在请求头里带上这个密钥curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-xxxx \ -d {model: qwen2.5-7b, messages: [{role: user, content: 你好}]}很多人漏掉这一步或者用了旧配置里的密钥就会一直报 401。日志里也会提示invalid or expired token。这种问题其实不难查但新手往往会在代码层面反复折腾忽略最简单的密钥配置项。5. 进阶优化从能跑到跑好5.1 镜像瘦身与离线部署如果你的底座是要交付给客户或者部署到内网环境的有一个问题逃不掉内网机器没法直接拉取镜像。这时候有两个思路。一个是在有外网的机器上先把所有镜像打成 tar 包再拷贝到内网机器上加载docker save -o ai-base-images.tar 镜像1 镜像2 镜像3 # 内网机器执行 docker load -i ai-base-images.tar另一个思路是搭建一个内网镜像仓库把用到的镜像统一推上去。我实际用到比较多的是第一种方案简单直接。另外向导式安装的镜像选择上我尽量选 Alpine 为基础镜像的版本体积会小很多内网传输也快。我用向导初始化完一个底座全套镜像压缩后大概 2GB 左右在千兆内网传输也就一两分钟这个体量完全能接受。5.2 网关性能参数调整网关默认配置偏向稳健而不是激进。我实测过默认参数下网关单实例能支撑每秒 200 次左右的并发调用延迟大约增加了 2 到 3 毫秒。如果业务量再上来可以调整几个关键的并发参数。在网关的配置文件中核心要调整的是worker_connections和proxy_read_timeout。前者控制单个 worker 能同时维持的连接数后者控制模型服务的响应超时时间。大模型推理本身耗时较长7B 模型生成 100 个 token 可能就要几秒到十几秒所以超时时间一定要给足我之前见过有人把超时设置成 3 秒结果所有模型调用全部超时。5.3 数据与访问安全加固底座跑起来之后安全这块不能忽略。首当其冲的是网关对外暴露的管理端口。默认配置为了方便管理接口和模型调用接口是同一个端口。生产环境一定要把管理接口单独拆分用防火墙限制来源 IP只允许运维网段访问。其次是 API 密钥的定期轮换。向导初始化时生成的密钥是长密钥如果怀疑泄露可以通过管理后台重新生成。密钥的保存建议放到环境变量或者专门的密钥管理工具里不要硬编码在业务代码中。最后是模型服务的网络隔离。推理引擎容器不需要对外暴露端口只需要让网关能访问到它。Docker Compose 默认会创建一个内部网络推理服务可以不映射宿主机端口只在容器网络内部通信。这样即使宿主机被入侵攻击者也很难直接访问到模型服务。写在最后的个人体会我做完这套向导后最大的感触是安装部署这件事难度并不在于某个单独的技术点而在于把整个流程拧成一股绳。向导式安装的核心不是我写了多少脚本而是我把过去踩过的坑、反复试错的结论、不同环境的差异全部变成了默认值和引导提示。这个过程很花时间但一旦做好后面每次部署都能节省大量的沟通和排障成本。如果你也要在自己的团队里落地类似的东西我的建议是先不要追求大而全优先跑通一个最小可用的闭环。能完成一次真实的模型调用比界面上堆满功能重要得多。等团队里所有人都习惯了这条路径再逐步叠加监控、告警、多模型管理这些能力整个底座的成熟度会自然提升。 AI微服务底座向导式安装实战：10分钟跑通大模型服务链路
1. 先搞清楚AI 微服务底座到底解决什么问题1.1 为什么单独的模型接口不够用把一个大模型或者几个开源模型部署好暴露一个 HTTP 接口出来这在今天已经不算难事。真正让团队头疼的是模型服务上线之后那一堆绕不开的工程问题多个模型服务怎么统一管理不同业务线的请求怎么路由到对应的模型限流、鉴权、日志、监控怎么做模型升级的时候怎么做到不中断服务我见过不少团队前期图省事直接让业务代码硬编码调用模型地址。模型一多环境一复杂马上就乱了。今天 A 服务要调 Llama明天 B 服务要调 Qwen后天还要接一个 embedding 模型每个模型的地址、端口、超时时间都不一样配置散落在各个业务代码里出了问题根本没法查。这时候你就需要一套底层的支撑设施让模型服务像数据库、缓存一样变成平台内部一个标准化的基础能力。谁来调用都走统一入口不需要关心模型部署在哪台机器、什么端口、什么协议。这套东西就是所谓的 AI 微服务底座。1.2 底座该由哪些部分组成一套能实际干活的 AI 微服务底座至少要包含这几个角色统一入口网关负责接收所有模型调用请求做路由、鉴权、限流、负载均衡。业务方只需要知道网关地址不用关心背后有多少个模型实例。模型服务层真正跑模型推理的服务。可能是 vLLM、TGI、Ollama也可能是你自己用 Python 封装的一个推理服务每个模型一个或多个副本。注册与配置中心记录当前有哪些模型服务在线、地址是什么、权重是多少。服务上下线时能自动感知配置变更时能动态刷新。基础依赖日志收集、指标采集、链路追踪。模型调用出问题的时候你得能快速定位是网络问题、模型推理问题还是参数传错了。管理界面或运维入口让你能直观看到服务状态、调用量、延迟、错误率。这套东西如果全部手动搭建懂行的人也得折腾一天不懂的人可能一周都搭不起来。所以就有了向导式安装这个需求把整个搭建过程固化成一步步引导式的流程跟着点下一步就能搞定。2. 向导式安装的落地思路与方案选型2.1 向导式安装和传统安装方式到底差在哪传统的安装方式本质上是给你一份文档你自己照着敲命令、改配置。文档写得再好也难免遇到环境差异、依赖冲突、版本不兼容的问题。你在网上搜教程十个人有十种装法抄作业都未必抄得对。向导式安装做的事情是把那些踩坑经验直接固化到程序里。安装过程不再是零散的命令而是一个完整的交互式流程——它先探测你的机器环境告诉你哪里不满足要求再让你按需勾选要装哪些组件然后自动把镜像拉下来、把配置生成好、把服务拉起来最后跑一个自检脚本告诉你安装是否成功。整个过程不需要你理解底层细节跟着引导走就行。我用一个生活化的类比来说手动安装是给你一堆乐高零件和图纸让你自己拼向导式安装是给你一个自动拼装流水线你只需要选好要拼成什么样子按一下启动按钮成品就出来了。2.2 我用到的方案容器化加编排再加一层交互封装市面上没有一款现成的工具能直接叫“AI 微服务底座向导”所以我实际落地的时候是组合了一套方案底座运行时基于 Docker 与 Docker Compose。安装引导层用 Python 脚本加 Web 交互页面实现。核心组件全部用官方镜像或者社区成熟的镜像避免自己从头造轮子。选 Docker Compose 而不是 Kubernetes是因为在大多数团队的实际场景中底座的规模不会一开始就很大。一台 GPU 服务器或者一台高配 CPU 服务器完全能承载初期所有模型服务的运行。Kubernetes 的学习成本和运维成本都很高为一个小底座硬上 K8s 有点杀鸡用牛刀。等你后面规模真的大了底座里的组件本身已经容器化迁移到 K8s 也不是什么难事。架构上先跑通比一步到位更重要。2.3 需要准备哪些硬件和软件先说硬件。如果你只是跑一些中小尺寸的模型比如 7B、13B 参数量的量化模型一块 24GB 显存的消费级显卡就够用。如果要做 70B 级别模型的推理那就需要两块或者更多大显存卡。没有 GPU 也能跑CPU 推理慢一些但做开发测试、验证流程完全没有问题。软件方面宿主机要求 Linux 环境Ubuntu 20.04 或者 22.04 我都实测过CentOS 7 以后也问题不大。Docker 和 Docker Compose 插件是必须的。如果你的服务器在国内建议提前把 Docker 的镜像源配置好不然拉镜像那一步会非常痛苦。Python 环境只需要 3.8 以上用来跑安装引导程序。这里有个细节我特别提醒一下向导脚本一定要做环境预检。我遇到过有人直接在没装 Docker 的机器上跑向导卡在中间一步报错整个安装流程中断排查了半天才发现是 Docker 没装。有了预检这种事在一开始就拦住了。3. 10 分钟跑起底座的完整实操3.1 第一步环境预检向导启动后第一个页面就是环境预检。它主要检查这几项Docker 是否已安装并且版本在 20.10 以上。Docker Compose 插件是否可用。宿主机剩余磁盘空间是否大于 20GB。内存是否大于 8GB。如果检测到 NVIDIA GPU会继续检查 nvidia-container-toolkit 是否安装。每项检测通过后显示绿色状态不满足的项会给出具体的修复命令。比如检测到没有安装 nvidia-container-toolkit页面会直接提示你执行sudo apt-get install -y nvidia-container-toolkit sudo systemctl restart docker这个设计我花了不少功夫。安装过程最怕的不是报错而是用户不知道下一步该做什么。预检把所有可能的问题前置逐项给出解决方案避免了中途卡死的情况。3.2 第二步选择要安装的组件预检通过之后进入组件选择页面。这里不是让用户二选一而是按需勾选。我设计了四类组件组件类别包含内容适用场景基础运行时网关、注册中心、配置中心所有场景必选观测体系Prometheus、Grafana、日志采集生产环境强烈建议推理引擎vLLM、Ollama、CPU 推理服务根据实际模型需求选择示例应用一个简单的调用客户端 Demo本地测试和功能验证这里有一个比较容易犯的错第一次装的时候什么都想装。其实你只需要先装基础运行和一个推理引擎跑通全链路后再按需扩。全选安装不是不行只是首次安装的复杂度会上升出了问题不好定位问题在哪一部分。向导默认只勾选最核心的几项反而更符合 10 分钟跑通的目标。3.3 第三步配置核心参数组件选完接下来是参数配置。这一步是向导式安装的核心价值所在——它把散落在各个配置文件里的关键参数收集到一个页面上用交互式表单让用户填写再自动生成对应的配置文件。需要填写的参数主要有网关对外端口默认 8000注意不要和宿主机已有服务冲突。模型名称和模型文件路径支持填写 Hugging Face 模型 ID 或本地路径。GPU 使用策略是每张卡跑一个模型实例还是多个模型共享一张卡。管理员账号和密码用于登录管理后台。这些参数看似简单但背后涉及很多细节判断。举个实际例子GPU 使用策略这块如果检测到有 2 张显卡默认建议每张卡跑一个模型服务并自动为两个服务配置不同的显存分配。如果用户不熟悉显存管理向导就按照保守方案生成配置保证两个服务能同时稳定运行不会出现显存溢出导致互相抢占的问题。配置完成后向导会展示一份生成的配置预览。任何不会写配置的人都能在这里核对每一项设置是否符合预期确认无误再点击下一步。3.4 第四步自动部署与初始化点击部署按钮之后向导就开始干体力活了。它会按照你刚才的选择依次执行这些操作创建必要的目录结构。拉取选定的容器镜像。生成 docker-compose.yml 文件。启动依赖组件如配置中心、注册中心。启动网关并等待网关健康检查通过。启动推理引擎加载模型。执行初始化脚本向注册中心登记所有服务。运行端到端自检模拟一次真实的模型调用请求。这个过程中页面会实时显示部署日志每一步成功或失败都有清晰的状态标记。等模型加载完成可能需要一些时间7B 模型在 GPU 上一般 30 秒到 2 分钟内能完成加载如果是 CPU 跑可能得等几分钟。向导在这一步会特别提示用户不要因为界面看起来“卡住”就强制关闭实际上后台正在加载模型权重。3.5 第五步验证全链路是否真的通了部署结束不代表万事大吉最后一步验证至关重要。向导会自动执行一轮自检模拟真实请求打一遍全链路检查网关是否能正常返回健康状态。调用一次文本生成接口确认推理引擎的响应正常。检查监控指标采集是否在持续上报数据。自检通过后向导会给出一个汇总信息页面展示访问地址、管理员账号、模型调用示例代码。我强烈建议你在这一步之后再手动调一次接口做二次确认。命令行执行示例curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5-7b, messages: [{role: user, content: 请简单介绍一下你自己}] }如果返回了正常的响应内容说明底座已经真实可用10 分钟之内的目标基本达成。4. 常见问题与排查技巧实录4.1 端口冲突导致的启动失败这是最容易踩的坑。向导默认使用 8000 端口但很多机器上 8000 已经被别的服务占用了。服务启动时日志会提示address already in use。处理方式是在向导的端口配置页改成其他端口或者先停掉占用端口的服务。排查命令其实很简单sudo lsof -i :8000看到占用进程后判断是否能安全停掉。如果是可以停的就 kill 掉如果不确定就换个端口重新部署。我用向导落地时还专门做了一个逻辑在部署前自动检测端口占用并警告避免用户启动完才发现端口冲突又要从头来一遍。4.2 模型加载慢或者一直加载中很多人第一次用 vLLM 或者 Ollama 拉模型发现模型文件非常大7B 模型量化后的文件也有 4GB 左右。如果网络状况不好下载可能要等很久界面看起来就像卡住了。另外如果是在国内网络环境下直接从 Hugging Face 拉模型大概率会非常慢甚至失败。我建议提前配置好镜像站地址或者在向导里加一个选项允许用户填写自定义模型下载地址。本地已经有模型文件的话直接填本地路径就可以跳过下载步骤。4.3 容器内存溢出导致自动重启默认配置里每个容器的内存限制我是按照保守值设定的。网关分配 512MB推理引擎根据显存自动推断。但如果你在一个只有 16GB 内存的机器上同时跑多个服务还是有内存溢出的风险。当容器反复重启时先查看日志docker logs --tail 100 容器名称如果日志尾部出现了Killed或者Out of memory那就是内存不够。解决方式是减少同时运行的组件数量或者调整 compose 文件中的内存限制参数。向导生成的配置文件中所有参数都是可改的改完重新执行docker compose up -d即可生效。4.4 GPU 显存不足导致的初始化失败多模型同时加载时如果每个模型都试图占满整张显卡的显存后面的服务必然会启动失败。在实践中我总结出一条原则模型的显存占用估算公式大致是模型参数量的两倍。7B 模型用 FP16 精度加载大约需要 14GB 显存如果用 4bit 量化需求会大幅下降到 5GB 左右。所以你如果在 24GB 显存的卡上跑 7B 模型想再跑一个 embedding 模型空间是够的。但如果同时跑两个 13B 模型就不要用 FP16改成量化版本会更稳妥。向导的参数配置页里我专门加了显存预估提示引导用户合理设置。4.5 自检通过但业务调用报 401 鉴权失败这个问题主要出在 API Key 配置不一致上。向导初始化的过程中会生成一个默认的管理员密钥业务调用时需要在请求头里带上这个密钥curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-xxxx \ -d {model: qwen2.5-7b, messages: [{role: user, content: 你好}]}很多人漏掉这一步或者用了旧配置里的密钥就会一直报 401。日志里也会提示invalid or expired token。这种问题其实不难查但新手往往会在代码层面反复折腾忽略最简单的密钥配置项。5. 进阶优化从能跑到跑好5.1 镜像瘦身与离线部署如果你的底座是要交付给客户或者部署到内网环境的有一个问题逃不掉内网机器没法直接拉取镜像。这时候有两个思路。一个是在有外网的机器上先把所有镜像打成 tar 包再拷贝到内网机器上加载docker save -o ai-base-images.tar 镜像1 镜像2 镜像3 # 内网机器执行 docker load -i ai-base-images.tar另一个思路是搭建一个内网镜像仓库把用到的镜像统一推上去。我实际用到比较多的是第一种方案简单直接。另外向导式安装的镜像选择上我尽量选 Alpine 为基础镜像的版本体积会小很多内网传输也快。我用向导初始化完一个底座全套镜像压缩后大概 2GB 左右在千兆内网传输也就一两分钟这个体量完全能接受。5.2 网关性能参数调整网关默认配置偏向稳健而不是激进。我实测过默认参数下网关单实例能支撑每秒 200 次左右的并发调用延迟大约增加了 2 到 3 毫秒。如果业务量再上来可以调整几个关键的并发参数。在网关的配置文件中核心要调整的是worker_connections和proxy_read_timeout。前者控制单个 worker 能同时维持的连接数后者控制模型服务的响应超时时间。大模型推理本身耗时较长7B 模型生成 100 个 token 可能就要几秒到十几秒所以超时时间一定要给足我之前见过有人把超时设置成 3 秒结果所有模型调用全部超时。5.3 数据与访问安全加固底座跑起来之后安全这块不能忽略。首当其冲的是网关对外暴露的管理端口。默认配置为了方便管理接口和模型调用接口是同一个端口。生产环境一定要把管理接口单独拆分用防火墙限制来源 IP只允许运维网段访问。其次是 API 密钥的定期轮换。向导初始化时生成的密钥是长密钥如果怀疑泄露可以通过管理后台重新生成。密钥的保存建议放到环境变量或者专门的密钥管理工具里不要硬编码在业务代码中。最后是模型服务的网络隔离。推理引擎容器不需要对外暴露端口只需要让网关能访问到它。Docker Compose 默认会创建一个内部网络推理服务可以不映射宿主机端口只在容器网络内部通信。这样即使宿主机被入侵攻击者也很难直接访问到模型服务。写在最后的个人体会我做完这套向导后最大的感触是安装部署这件事难度并不在于某个单独的技术点而在于把整个流程拧成一股绳。向导式安装的核心不是我写了多少脚本而是我把过去踩过的坑、反复试错的结论、不同环境的差异全部变成了默认值和引导提示。这个过程很花时间但一旦做好后面每次部署都能节省大量的沟通和排障成本。如果你也要在自己的团队里落地类似的东西我的建议是先不要追求大而全优先跑通一个最小可用的闭环。能完成一次真实的模型调用比界面上堆满功能重要得多。等团队里所有人都习惯了这条路径再逐步叠加监控、告警、多模型管理这些能力整个底座的成熟度会自然提升。