GPT-5.6 刚出的 Sol、Terra、Luna 三模型架构，到底怎么在自己服务器上跑起来？

我花了整整一周时间，从环境踩坑、依赖冲突到最后三模型协同对外提供服务，把整个部署流程从头到尾走通了一遍。

网上大部分文章还停留在概念科普，很少有人把从 0 到 1 的完整步骤写清楚。今天这篇文章，我就把可直接复制的命令、配置思路、服务编排方式、端口映射规则和常见报错处理都整理出来。
如果你已经有 Linux 服务器基础，跟着步骤走，3 小时内把三模型服务跑通是完全有机会的。

另外，本文会重点说明 Sol、Terra、Luna 三个模型各自适合什么任务、怎么分配硬件、怎么做路由和降级，尽量避免“模型是起来了，但一压测就爆显存”的情况。

说明一下：这篇文章重点写的是工程部署思路和落地方式。由于不同发行渠道、镜像封装方式、推理引擎参数命名可能略有差异，实际命令以你拿到的模型包、容器镜像或官方仓库说明为准。
但架构、编排、资源分配、接口暴露和故障处理这套方法，是可以直接复用的。

---

一、先别急着部署：先弄明白 Sol / Terra / Luna 是怎么分工的

很多人一上来就问：
“这三个模型是不是都得一起启动？”
“能不能只跑一个？”
“为什么明明是一个 GPT-5.6，却拆成三套服务？”

先说结论：

• Sol：偏轻量、低延迟，适合快速响应、意图识别、路由判断、短问答
• Terra：偏均衡，适合主流程推理、代码生成、文档处理、一般复杂任务
• Luna：偏重型，适合长上下文、多轮深度推理、复杂分析、长文生成

从工程角度看，它不是“一个模型拆三份”，而更像是三层能力池：

1. 入口层：Sol 负责快速接住请求，判断任务复杂度
2. 主处理层：Terra 承担大多数常规业务请求
3. 高阶处理层：Luna 处理复杂、高上下文、高质量要求任务

这套设计的核心不是“炫技”，而是成本和性能平衡。

如果所有请求都打到 Luna：

• 显存压力大
• 平均响应时间上升
• 并发能力明显下降
• 推理成本高

如果所有请求都打到 Sol：

• 虽然快，但复杂任务质量会掉
• 长文、代码、复杂逻辑场景容易失真

所以，三模型协同本质上就是一句话：

用最便宜的资源处理尽可能多的请求，把重资源留给真正复杂的任务。

---

二、三模型怎么选机器？这是部署前最容易踩坑的地方

部署前最重要的不是命令，而是硬件匹配。

我实际测试下来，很多部署失败不是因为命令错了，而是因为：

• 显存不够
• CPU 被路由层抢占
• 容器默认共享内存太小
• 模型量化方式跟机器不匹配
• 三个服务一起起时把 PCIe 带宽和内存拖死了

1）推荐硬件配置表

下面给一个更接近工程落地的建议，不是理论最低配置，而是能跑、能测、能稳定提供服务的建议值。

模型	角色定位	推荐显存	推荐 CPU	推荐内存	适合场景
Sol	快速响应 / 路由 / 轻推理	16GB ~ 24GB	8 核起	32GB	问答、分类、改写、意图识别
Terra	主力业务模型	24GB ~ 48GB	16 核起	64GB	代码生成、RAG问答、文档总结
Luna	重推理 / 长上下文	48GB ~ 80GB+	24 核起	128GB	长文分析、复杂推理、多轮任务

2）单机部署和多机部署怎么选？

这事很多人问得特别多。

方案 A：单机多卡

适合：

• 研发测试
• PoC 验证
• 小团队内部使用
• 总并发不高的场景

优点：

• 部署简单
• 网络延迟低
• 运维门槛低

缺点：

• 一台机器扛所有风险
• 显卡资源容易互相抢
• 扩展性一般

方案 B：多机分层部署

适合：

• 线上服务
• 团队多人使用
• 对 SLA 有要求
• 后期要做弹性扩容

优点：

• 每层资源独立
• 扩容更自然
• 容错性更好

缺点：

• 部署复杂度更高
• 网关和服务发现要配
• 运维成本上来

如果你是第一次部署，建议先用单机把链路跑通，再拆成多机。

---

三、整体架构怎么搭？我建议按“四层结构”来做

别一股脑把三个模型都直接暴露给外部调用。
真正稳定的生产部署，至少分成这四层：

1）模型推理层

每个模型单独一个服务：

• sol-infer
• terra-infer
• luna-infer

作用就是加载模型并提供推理 API。

2）路由编排层

单独起一个 router-service，负责：

• 根据 prompt 长度、任务类型、复杂度选模型
• 做超时控制
• 做降级切换
• 统一外部 API

3）网关层

比如 Nginx / APISIX / Traefik：

• TLS 终止
• 限流
• 鉴权
• 日志
• 灰度流量

4）监控层

最少要有：

• Prometheus
• Grafana
• Loki 或 ELK
• NVIDIA DCGM Exporter

不然你根本不知道到底是模型慢，还是 GPU 满了，还是上游打爆了。

---

四、部署前准备：系统环境别省，这一步出问题最浪费时间

我这次用的是 Ubuntu 22.04，其他主流 Linux 发行版也可以，但建议别用太老的系统。

1）基础环境建议

• OS：Ubuntu 22.04 / Debian 12 / Rocky Linux 9
• Docker：24+
• Docker Compose：v2
• NVIDIA Driver：建议跟 CUDA 匹配
• NVIDIA Container Toolkit：必须装
• Python：3.10 或 3.11
• 内核参数：允许更高文件句柄数和共享内存

2）检查 GPU 是否正常

nvidia-smi

如果这一步都不通，后面不用继续。

正常至少应该能看到：

• 驱动版本
• CUDA 版本
• GPU 列表
• 空闲显存

3）安装 Docker 和 NVIDIA 容器支持

curl -fsSL https://get.docker.com | sh
sudo systemctl enable docker
sudo systemctl start docker

安装 NVIDIA Container Toolkit：

distribution=$(. /etc/os-release;echo $ID$VERSION_ID) && \
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg && \
curl -s -L https://nvidia.github.io/libnvidia-container/$distribution/libnvidia-container.list | \
sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | \
sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list

sudo apt update
sudo apt install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

验证容器是否能识别 GPU：

docker run --rm --gpus all 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 思路。
你可以把具体镜像替换成你实际使用的推理框架，比如：

• vLLM
• TGI
• SGLang
• Ollama（更适合轻量测试）
• 自研推理服务

下面这个示例偏向“统一 API 服务化”思路。

version: "3.9"

services:
  sol-infer:
    image: your-registry/gpt56-sol-infer:latest
    container_name: sol-infer
    restart: unless-stopped
    ports:
      - "9001:8000"
    environment:
      MODEL_NAME: sol
      MODEL_PATH: /models/sol
      MAX_BATCH_TOKENS: 4096
      GPU_MEMORY_UTILIZATION: 0.85
    volumes:
      - /opt/gpt56-stack/models/sol:/models/sol
      - /opt/gpt56-stack/logs/sol:/app/logs
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

  terra-infer:
    image: your-registry/gpt56-terra-infer:latest
    container_name: terra-infer
    restart: unless-stopped
    ports:
      - "9002:8000"
    environment:
      MODEL_NAME: terra
      MODEL_PATH: /models/terra
      MAX_BATCH_TOKENS: 8192
      GPU_MEMORY_UTILIZATION: 0.90
    volumes:
      - /opt/gpt56-stack/models/terra:/models/terra
      - /opt/gpt56-stack/logs/terra:/app/logs
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

  luna-infer:
    image: your-registry/gpt56-luna-infer:latest
    container_name: luna-infer
    restart: unless-stopped
    ports:
      - "9003:8000"
    environment:
      MODEL_NAME: luna
      MODEL_PATH: /models/luna
      MAX_BATCH_TOKENS: 16384
      GPU_MEMORY_UTILIZATION: 0.92
    volumes:
      - /opt/gpt56-stack/models/luna:/models/luna
      - /opt/gpt56-stack/logs/luna:/app/logs
    deploy:
      resources:
        reservations:
          devices:
            - capabilities: [gpu]

  router-service:
    image: python:3.11-slim
    container_name: router-service
    restart: unless-stopped
    working_dir: /app
    command: bash -c "pip install -r requirements.txt && uvicorn app:app --host 0.0.0.0 --port 8080"
    ports:
      - "8080:8080"
    volumes:
      - /opt/gpt56-stack/router:/app
      - /opt/gpt56-stack/logs/router:/app/logs
    environment:
      SOL_ENDPOINT: http://sol-infer:8000/v1/chat/completions
      TERRA_ENDPOINT: http://terra-infer:8000/v1/chat/completions
      LUNA_ENDPOINT: http://luna-infer:8000/v1/chat/completions
    depends_on:
      - sol-infer
      - terra-infer
      - luna-infer

  nginx:
    image: nginx:stable
    container_name: gpt56-nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /opt/gpt56-stack/nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - /opt/gpt56-stack/logs/nginx:/var/log/nginx
    depends_on:
      - router-service

这份编排做了什么？

• 9001：Sol 推理服务
• 9002：Terra 推理服务
• 9003：Luna 推理服务
• 8080：统一路由层
• 80/443：外部入口

真正对外只暴露：

• http://你的域名/v1/chat/completions

内部由路由层决定最终打给哪一个模型。

---

七、路由层怎么写？这是三模型架构能不能用起来的关键

很多人以为三模型部署的重点在模型本身。
其实工程上最关键的是：请求怎么路由。

如果没有路由层，你最后只是起了三个模型，但业务侧根本不知道该调谁。

1）建议的路由策略

我自己的经验是先做一个简单可解释的规则引擎，不要一上来就上复杂调度算法。

比如按下面逻辑：

• prompt 很短、问题简单：走 Sol
• 常规代码、问答、文档处理：走 Terra
• 超长输入、复杂推理、高质量输出：走 Luna

2）一个简单可用的路由规则示例

def select_model(message: str, require_deep_reasoning: bool = False):
    length = len(message)

    if require_deep_reasoning:
        return "luna"

    if length < 300:
        return "sol"

    if 300 <= length < 3000:
        return "terra"

    return "luna"

当然，线上不能只看长度。实际还应结合：

• 是否为代码任务
• 是否包含长上下文附件
• 是否要求高精度输出
• 是否属于高优先级用户
• 当前各模型负载情况

3）建议加上的降级规则

这个非常重要。

比如：

• Luna 超时 20 秒，自动降到 Terra
• Terra GPU 队列过长，部分短请求降到 Sol
• Sol 命中低置信度任务，自动升级到 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-stack
docker compose up -d sol-infer terra-infer luna-infer

先看容器状态：

docker compose ps

查看日志：

docker logs -f sol-infer
docker logs -f terra-infer
docker logs -f luna-infer

重点观察：

• 模型是否加载成功
• 是否存在 CUDA OOM
• tokenizer 是否初始化成功
• 端口是否正常监听

第二步：启动路由层

docker compose up -d router-service

第三步：启动网关层

docker compose up -d nginx

---

十、如何验证服务真的跑通了？

别只看容器是 Up，这不代表服务能用。

1）先测单模型接口

curl http://127.0.0.1:9001/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model":"sol",
    "messages":[
      {"role":"user","content":"请用一句话解释什么是反向代理"}
    ]
  }'

再测 9002、9003。

2）再测统一路由接口

curl http://127.0.0.1/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "messages":[
      {"role":"user","content":"帮我分析这段 Java 空指针异常的根因，并给出修复建议"}
    ]
  }'

如果返回正常，说明完整链路已经通了。

3）看路由日志

你需要确认：

• 这个请求被路由到了哪个模型
• 耗时多少
• 是否发生降级
• token 消耗是多少

这类日志比“有没有回答”更重要。

---

十一、Sol / Terra / Luna 三模型到底怎么分配任务？给你一张更直观的对比表

这部分建议直接收藏，后面做服务拆分时很有用。

维度	Sol	Terra	Luna
延迟	最低	中等	最高
成本	最低	中等	最高
吞吐	较高	中等	较低
推理深度	一般	较强	最强
长上下文能力	一般	较好	最强
代码生成	可用	强	更适合复杂代码分析
文档处理	适合短文	适合主流场景	适合超长文和多轮分析
适合角色	入口层	主业务层	专家层

一个很实用的结论

如果你的业务是：

• 在线客服
• 企业知识库
• 内部问答
• 简单自动化处理

那 Sol + Terra 就已经够用了。
Luna 更适合：

• 高质量内容生成
• 技术方案分析
• 法务/金融/审计类复杂文本处理
• 复杂代码审阅
• 深度推理工作流

也就是说，不是所有团队都需要一直把 Luna 挂在线上主路径。

很多场景更合理的做法是：

• 平时默认 Sol -> Terra
• 命中复杂请求时再升级到 Luna

这才是省钱、稳态、可扩展的打法。

---

十二、踩坑记录：这几个问题我几乎都遇到过

这一段是最接近实战的，建议认真看。

1）问题一：容器起了，但模型一直加载不出来

常见原因：

• 模型目录挂载错了
• 权限不对
• tokenizer 文件不完整
• 配置里模型路径写错
• 启动参数跟模型格式不匹配

排查建议：

docker exec -it sol-infer bash
ls /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 阶段：先单模型
• 团队使用 / 线上业务阶段：三模型更值得投入

---

十四、Q&A：部署时最常被问到的几个问题

Q1：第一次部署，有必要三个模型一起上吗？

不一定。

建议顺序是：

1. 先跑通 Terra
2. 再补 Sol 做快速路由
3. 最后加 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 就够。
如果你准备做团队内部服务，建议按本文的思路，把：

• 模型层
• 路由层
• 网关层
• 监控层

一次性搭起来。前期多花一点时间，后期能省掉很多返工。