GPT-5.6 刚出的 Sol、Terra、Luna 三模型架构到底怎么在自己服务器上跑起来我花了整整一周时间从环境踩坑、依赖冲突到最后三模型协同对外提供服务把整个部署流程从头到尾走通了一遍。网上大部分文章还停留在概念科普很少有人把从 0 到 1 的完整步骤写清楚。今天这篇文章我就把可直接复制的命令、配置思路、服务编排方式、端口映射规则和常见报错处理都整理出来。如果你已经有 Linux 服务器基础跟着步骤走3 小时内把三模型服务跑通是完全有机会的。另外本文会重点说明Sol、Terra、Luna 三个模型各自适合什么任务、怎么分配硬件、怎么做路由和降级尽量避免“模型是起来了但一压测就爆显存”的情况。说明一下这篇文章重点写的是工程部署思路和落地方式。由于不同发行渠道、镜像封装方式、推理引擎参数命名可能略有差异实际命令以你拿到的模型包、容器镜像或官方仓库说明为准。但架构、编排、资源分配、接口暴露和故障处理这套方法是可以直接复用的。一、先别急着部署先弄明白 Sol / Terra / Luna 是怎么分工的很多人一上来就问“这三个模型是不是都得一起启动”“能不能只跑一个”“为什么明明是一个 GPT-5.6却拆成三套服务”先说结论Sol偏轻量、低延迟适合快速响应、意图识别、路由判断、短问答Terra偏均衡适合主流程推理、代码生成、文档处理、一般复杂任务Luna偏重型适合长上下文、多轮深度推理、复杂分析、长文生成从工程角度看它不是“一个模型拆三份”而更像是三层能力池入口层Sol 负责快速接住请求判断任务复杂度主处理层Terra 承担大多数常规业务请求高阶处理层Luna 处理复杂、高上下文、高质量要求任务这套设计的核心不是“炫技”而是成本和性能平衡。如果所有请求都打到 Luna显存压力大平均响应时间上升并发能力明显下降推理成本高如果所有请求都打到 Sol虽然快但复杂任务质量会掉长文、代码、复杂逻辑场景容易失真所以三模型协同本质上就是一句话用最便宜的资源处理尽可能多的请求把重资源留给真正复杂的任务。二、三模型怎么选机器这是部署前最容易踩坑的地方部署前最重要的不是命令而是硬件匹配。我实际测试下来很多部署失败不是因为命令错了而是因为显存不够CPU 被路由层抢占容器默认共享内存太小模型量化方式跟机器不匹配三个服务一起起时把 PCIe 带宽和内存拖死了1推荐硬件配置表下面给一个更接近工程落地的建议不是理论最低配置而是能跑、能测、能稳定提供服务的建议值。模型角色定位推荐显存推荐 CPU推荐内存适合场景Sol快速响应 / 路由 / 轻推理16GB ~ 24GB8 核起32GB问答、分类、改写、意图识别Terra主力业务模型24GB ~ 48GB16 核起64GB代码生成、RAG问答、文档总结Luna重推理 / 长上下文48GB ~ 80GB24 核起128GB长文分析、复杂推理、多轮任务2单机部署和多机部署怎么选这事很多人问得特别多。方案 A单机多卡适合研发测试PoC 验证小团队内部使用总并发不高的场景优点部署简单网络延迟低运维门槛低缺点一台机器扛所有风险显卡资源容易互相抢扩展性一般方案 B多机分层部署适合线上服务团队多人使用对 SLA 有要求后期要做弹性扩容优点每层资源独立扩容更自然容错性更好缺点部署复杂度更高网关和服务发现要配运维成本上来如果你是第一次部署建议先用单机把链路跑通再拆成多机。三、整体架构怎么搭我建议按“四层结构”来做别一股脑把三个模型都直接暴露给外部调用。真正稳定的生产部署至少分成这四层1模型推理层每个模型单独一个服务sol-inferterra-inferluna-infer作用就是加载模型并提供推理 API。2路由编排层单独起一个router-service负责根据 prompt 长度、任务类型、复杂度选模型做超时控制做降级切换统一外部 API3网关层比如 Nginx / APISIX / TraefikTLS 终止限流鉴权日志灰度流量4监控层最少要有PrometheusGrafanaLoki 或 ELKNVIDIA DCGM Exporter不然你根本不知道到底是模型慢还是 GPU 满了还是上游打爆了。四、部署前准备系统环境别省这一步出问题最浪费时间我这次用的是 Ubuntu 22.04其他主流 Linux 发行版也可以但建议别用太老的系统。1基础环境建议OSUbuntu 22.04 / Debian 12 / Rocky Linux 9Docker24Docker Composev2NVIDIA Driver建议跟 CUDA 匹配NVIDIA Container Toolkit必须装Python3.10 或 3.11内核参数允许更高文件句柄数和共享内存2检查 GPU 是否正常nvidia-smi如果这一步都不通后面不用继续。正常至少应该能看到驱动版本CUDA 版本GPU 列表空闲显存3安装 Docker 和 NVIDIA 容器支持curl-fsSLhttps://get.docker.com|shsudosystemctlenabledockersudosystemctl startdocker安装 NVIDIA Container Toolkitdistribution$(./etc/os-release;echo$ID$VERSION_ID)\curl-fsSLhttps://nvidia.github.io/libnvidia-container/gpgkey|sudogpg--dearmor-o/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg\curl-s-Lhttps://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list|\seds#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g|\sudotee/etc/apt/sources.list.d/nvidia-container-toolkit.listsudoaptupdatesudoaptinstall-ynvidia-container-toolkitsudonvidia-ctk runtime configure--runtimedockersudosystemctl restartdocker验证容器是否能识别 GPUdockerrun--rm--gpusall nvidia/cuda:12.3.2-base-ubuntu22.04 nvidia-smi如果这里输出 GPU 信息说明容器层没问题。五、目录结构怎么规划别把模型、日志、配置全堆一起我建议按下面这种目录来建mkdir-p/opt/gpt56-stack/{models,logs,config,router,nginx,prometheus,grafana}mkdir-p/opt/gpt56-stack/models/{sol,terra,luna}mkdir-p/opt/gpt56-stack/logs/{sol,terra,luna,router,nginx}建议分清楚models/模型权重或挂载点config/模型参数配置logs/推理日志router/路由服务代码nginx/反向代理配置prometheus/监控配置这个习惯后面非常重要不然后期排查问题会很痛苦。六、核心部署用 Docker Compose 把三模型和路由层一次编排起来这里我给一个通用工程版的docker-compose.yml思路。你可以把具体镜像替换成你实际使用的推理框架比如vLLMTGISGLangOllama更适合轻量测试自研推理服务下面这个示例偏向“统一 API 服务化”思路。version:3.9services:sol-infer:image:your-registry/gpt56-sol-infer:latestcontainer_name:sol-inferrestart:unless-stoppedports:-9001:8000environment:MODEL_NAME:solMODEL_PATH:/models/solMAX_BATCH_TOKENS:4096GPU_MEMORY_UTILIZATION:0.85volumes:-/opt/gpt56-stack/models/sol:/models/sol-/opt/gpt56-stack/logs/sol:/app/logsdeploy:resources:reservations:devices:-capabilities:[gpu]terra-infer:image:your-registry/gpt56-terra-infer:latestcontainer_name:terra-inferrestart:unless-stoppedports:-9002:8000environment:MODEL_NAME:terraMODEL_PATH:/models/terraMAX_BATCH_TOKENS:8192GPU_MEMORY_UTILIZATION:0.90volumes:-/opt/gpt56-stack/models/terra:/models/terra-/opt/gpt56-stack/logs/terra:/app/logsdeploy:resources:reservations:devices:-capabilities:[gpu]luna-infer:image:your-registry/gpt56-luna-infer:latestcontainer_name:luna-inferrestart:unless-stoppedports:-9003:8000environment:MODEL_NAME:lunaMODEL_PATH:/models/lunaMAX_BATCH_TOKENS:16384GPU_MEMORY_UTILIZATION:0.92volumes:-/opt/gpt56-stack/models/luna:/models/luna-/opt/gpt56-stack/logs/luna:/app/logsdeploy:resources:reservations:devices:-capabilities:[gpu]router-service:image:python:3.11-slimcontainer_name:router-servicerestart:unless-stoppedworking_dir:/appcommand:bash-c pip install-r requirements.txtuvicorn app:app--host 0.0.0.0--port 8080ports:-8080:8080volumes:-/opt/gpt56-stack/router:/app-/opt/gpt56-stack/logs/router:/app/logsenvironment:SOL_ENDPOINT:http://sol-infer:8000/v1/chat/completionsTERRA_ENDPOINT:http://terra-infer:8000/v1/chat/completionsLUNA_ENDPOINT:http://luna-infer:8000/v1/chat/completionsdepends_on:-sol-infer-terra-infer-luna-infernginx:image:nginx:stablecontainer_name:gpt56-nginxrestart:unless-stoppedports:-80:80-443:443volumes:-/opt/gpt56-stack/nginx/nginx.conf:/etc/nginx/nginx.conf:ro-/opt/gpt56-stack/logs/nginx:/var/log/nginxdepends_on:-router-service这份编排做了什么9001Sol 推理服务9002Terra 推理服务9003Luna 推理服务8080统一路由层80/443外部入口真正对外只暴露http://你的域名/v1/chat/completions内部由路由层决定最终打给哪一个模型。七、路由层怎么写这是三模型架构能不能用起来的关键很多人以为三模型部署的重点在模型本身。其实工程上最关键的是请求怎么路由。如果没有路由层你最后只是起了三个模型但业务侧根本不知道该调谁。1建议的路由策略我自己的经验是先做一个简单可解释的规则引擎不要一上来就上复杂调度算法。比如按下面逻辑prompt 很短、问题简单走Sol常规代码、问答、文档处理走Terra超长输入、复杂推理、高质量输出走Luna2一个简单可用的路由规则示例defselect_model(message:str,require_deep_reasoning:boolFalse):lengthlen(message)ifrequire_deep_reasoning:returnlunaiflength300:returnsolif300length3000:returnterrareturnluna当然线上不能只看长度。实际还应结合是否为代码任务是否包含长上下文附件是否要求高精度输出是否属于高优先级用户当前各模型负载情况3建议加上的降级规则这个非常重要。比如Luna 超时 20 秒自动降到 TerraTerra GPU 队列过长部分短请求降到 SolSol 命中低置信度任务自动升级到 Terra这样三模型不是并排摆着而是真正形成梯度协同。八、Nginx 怎么配统一入口、限流、超时一个都不能少下面给一份简化版 Nginx 配置思路worker_processes auto; events { worker_connections 4096; } http { upstream gpt56_router { server router-service:8080; keepalive 64; } server { listen 80; server_name _; client_max_body_size 20m; proxy_read_timeout 300s; proxy_connect_timeout 10s; proxy_send_timeout 300s; location /v1/chat/completions { proxy_pass http://gpt56_router; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Real-IP $remote_addr; } location /healthz { return 200 ok\n; } } }为什么需要网关因为模型服务本身一般不擅长做这些事限流黑白名单统一鉴权HTTPS访问日志熔断尤其是对外提供 API 的时候网关不是锦上添花是基础设施。九、启动顺序别搞错不然你会看到一堆“服务已启动但不可用”建议启动顺序如下第一步启动模型层cd/opt/gpt56-stackdockercompose up-dsol-infer terra-infer luna-infer先看容器状态dockercomposeps查看日志dockerlogs-fsol-inferdockerlogs-fterra-inferdockerlogs-fluna-infer重点观察模型是否加载成功是否存在 CUDA OOMtokenizer 是否初始化成功端口是否正常监听第二步启动路由层dockercompose up-drouter-service第三步启动网关层dockercompose up-dnginx十、如何验证服务真的跑通了别只看容器是Up这不代表服务能用。1先测单模型接口curlhttp://127.0.0.1:9001/v1/chat/completions\-HContent-Type: application/json\-d{ model:sol, messages:[ {role:user,content:请用一句话解释什么是反向代理} ] }再测9002、9003。2再测统一路由接口curlhttp://127.0.0.1/v1/chat/completions\-HContent-Type: application/json\-d{ messages:[ {role:user,content:帮我分析这段 Java 空指针异常的根因并给出修复建议} ] }如果返回正常说明完整链路已经通了。3看路由日志你需要确认这个请求被路由到了哪个模型耗时多少是否发生降级token 消耗是多少这类日志比“有没有回答”更重要。十一、Sol / Terra / Luna 三模型到底怎么分配任务给你一张更直观的对比表这部分建议直接收藏后面做服务拆分时很有用。维度SolTerraLuna延迟最低中等最高成本最低中等最高吞吐较高中等较低推理深度一般较强最强长上下文能力一般较好最强代码生成可用强更适合复杂代码分析文档处理适合短文适合主流场景适合超长文和多轮分析适合角色入口层主业务层专家层一个很实用的结论如果你的业务是在线客服企业知识库内部问答简单自动化处理那Sol Terra就已经够用了。Luna更适合高质量内容生成技术方案分析法务/金融/审计类复杂文本处理复杂代码审阅深度推理工作流也就是说不是所有团队都需要一直把 Luna 挂在线上主路径。很多场景更合理的做法是平时默认Sol - Terra命中复杂请求时再升级到Luna这才是省钱、稳态、可扩展的打法。十二、踩坑记录这几个问题我几乎都遇到过这一段是最接近实战的建议认真看。1问题一容器起了但模型一直加载不出来常见原因模型目录挂载错了权限不对tokenizer 文件不完整配置里模型路径写错启动参数跟模型格式不匹配排查建议dockerexec-itsol-inferbashls/models/sol先确认容器内部真的看得到文件。2问题二显存明明够还是 OOM这类问题非常常见。原因不一定是“模型太大”还可能是batch size 太大context length 配太高KV cache 预留太多多容器共享同一块 GPU推理引擎默认预占显存比例过高解决思路降低GPU_MEMORY_UTILIZATION降低MAX_BATCH_TOKENS缩小最大上下文明确绑定 GPU把 Luna 独占一张卡3问题三接口能返回但特别慢这不一定是模型问题。要查是模型首轮加载慢还是每次推理都慢是 GPU 忙还是 CPU 打满是 tokenizer 慢还是生成阶段慢是网关超时还是下游队列堆积我自己的经验是路由层不记录阶段性耗时后面基本没法调优。至少记录入站时间选模型时间下游请求开始时间首 token 时间完成时间4问题四三个模型一起跑系统整体越来越卡大概率是资源隔离没做好。建议至少做这些事给每个模型绑定明确 GPU限制 CPU 核心使用日志别输出过量别把监控和推理放到同一块最忙的机器上关闭不必要的 debug 模式十三、从工程角度看单模型和三模型架构到底差在哪很多人会问“我直接上一个大模型不就完了为什么还要 Sol / Terra / Luna 三层”这是个好问题。单模型方案的优点部署简单接入快维护成本低适合原型验证单模型方案的缺点所有请求成本一样高并发能力受限复杂请求和简单请求抢资源难做分层优化三模型方案的优点响应速度更稳定资源利用率更高成本更可控易于按任务类型扩容三模型方案的缺点架构更复杂路由策略要持续优化监控与日志体系必须跟上对运维能力要求更高所以我的建议很明确个人测试 / Demo 阶段先单模型团队使用 / 线上业务阶段三模型更值得投入十四、QA部署时最常被问到的几个问题Q1第一次部署有必要三个模型一起上吗不一定。建议顺序是先跑通 Terra再补 Sol 做快速路由最后加 Luna 做高阶处理这样最稳。Q2三模型一定要三张卡吗不一定但强烈建议至少把Luna单独放一张卡。如果三者共卡容易显存争抢延迟会抖高峰期非常不稳定测试环境可以共卡生产环境尽量分开。Q3如果预算有限应该优先保哪一个优先保Terra。因为它是最均衡的主力模型业务覆盖面最大。预算紧张时Terra常驻Sol轻量补充Luna按需启用这是性价比更高的方案。Q4路由规则必须很复杂吗不用。一开始只要做到短文本走 Sol常规任务走 Terra长文本和复杂任务走 Luna这就够了。别一开始就把系统做成难以维护的“智能黑盒”。Q5怎么判断该不该上 Luna看两个指标是否经常处理超长文本或复杂推理任务Terra 的输出是否已经明显不够用如果大多数任务 Terra 都能解决Luna 可以先不常驻主链路。十五、我的实战建议别只追求“能跑”要追求“能稳”很多文章写到这里就结束了但真正上线时问题才刚开始。如果你想把这套架构用于真实业务我建议再补四件事1加健康检查不只是容器活着还要确认模型服务能正常推理。2加鉴权和限流尤其是团队多人使用不加很容易被滥用。3加缓存层对重复问答、固定模板请求可以减轻主模型压力。4加调用统计至少知道哪类请求最多哪个模型最忙哪个路由命中率最高哪类请求最贵这些数据会直接决定你后面怎么调架构。十六、总结三模型架构不是“更高级”而是“更像生产系统”如果只从“把模型跑起来”这件事看单模型确实更省事。但如果从性能、成本、延迟、并发、任务分层和后续扩展来看Sol / Terra / Luna 这种三模型架构明显更接近真实生产环境。我的实际感受是Sol负责把入口撑住解决“快”的问题Terra负责大多数业务任务解决“稳”的问题Luna负责高复杂度任务解决“深”的问题这三者不是替代关系而是分工关系。如果你只是本地测试先跑一个 Terra 就够。如果你准备做团队内部服务建议按本文的思路把模型层路由层网关层监控层一次性搭起来。前期多花一点时间后期能省掉很多返工。