CubeStudio：一键部署开源模型为OpenAI兼容API

1. 为什么非得把 HuggingFace 模型“套”进 OpenAI API 这个壳子？

我第一次在客户现场看到这个需求时，心里直犯嘀咕：HuggingFace 本地跑得好好的，模型权重、Tokenizer、推理脚本全都有，干嘛非得绕一圈去模拟 OpenAI 的/v1/chat/completions接口？结果客户甩过来三份代码——一份是前端团队用openaiPython SDK 写的聊天界面，一份是内部低代码平台调用openai.ChatCompletion.create()的流程编排逻辑，还有一份是运维组刚上线的统一 API 网关，所有流量都按 OpenAI 的 header 格式（Authorization: Bearer sk-xxx）、请求体结构（{"model": "qwen2-7b", "messages": [...]}）、响应字段（"choices": [{"message": {"content": "..."}]}）做鉴权和日志归集。

那一刻我才真正明白：这不是技术洁癖，而是工程现实。OpenAI API 已经不是一种协议，它成了一种事实标准接口契约。就像 USB-C 口之所以普及，不是因为它比 Micro-USB 更先进，而是因为 MacBook、iPad、安卓旗舰、充电宝、显示器全认它。你手头有 Qwen3-8B、DeepSeek-V3、Yi-1.5-9B 这些优质开源模型，但只要你的下游系统只认openai客户端，你就得把它们“翻译”成 OpenAI 的语言。

更现实的是部署链路。我们团队去年做过对比测试：直接用 Transformers + Flask 封装一个/generate接口，前端调用时要重写所有错误处理逻辑（OpenAI 的429 rate_limit_exceeded、401 invalid_api_key、503 server_unavailable），还要手动拼接 streaming 的 SSE 格式；而一旦接入 OpenAI 兼容层，前端一行client.chat.completions.create(...)就能复用全部已有逻辑，连 retry 机制都不用改。实测下来，迁移成本从 3 人日压缩到 2 小时——这还不算后续新增模型时，运维只需改一个 YAML 文件就能上线，不用再协调前后端联调。

所以，“部署成 OpenAI 兼容 API”本质是解耦模型能力与业务系统。HuggingFace 提供的是“原材料”，OpenAI API 提供的是“标准化插座”，CubeStudio 就是那个帮你把不同形状的插头（vLLM/Ollama/MindIE/TensorRT-LLM）统一做成标准插座的工具箱。它不关心你底层用 CUDA 还是 ROCm，不关心你是量化还是 FP16，只确保上游系统插上就能用。这也是为什么标题里强调“一键上线”——真正的价值不在“能跑”，而在“跑得像原生 OpenAI 一样稳”。

提示：别被“兼容”二字误导。真正的兼容不是表面字段一致，而是行为级对齐。比如 OpenAI 的stream=True返回的是带delta字段的 chunk，而原生 vLLM 的 streaming 是纯文本流；Ollama 的/api/chat响应格式和 OpenAI 的/v1/chat/completions有细微差异（如finish_reason字段名不同）。CubeStudio 的核心工作，就是把这些“方言”翻译成标准普通话。

2. CubeStudio 的底层架构：不是简单转发，而是协议翻译引擎

很多人以为 CubeStudio 就是个带 Web UI 的 Docker Compose 脚本生成器，点几下按钮就启动一个vllm-openai容器。实际拆开看，它的核心是一套分层协议适配器，共三层，每层解决一类兼容性问题：

2.1 接入层：统一模型注册与生命周期管理

传统方案中，vLLM 启动命令是python -m vllm.entrypoints.openai.api_server --model qwen2-7b --tensor-parallel-size 2，Ollama 是ollama run qwen2:7b，MindIE 是mindie serve --model-path /models/qwen2-7b --port 8000。这些命令参数、环境变量、模型路径约定各不相同。CubeStudio 在接入层做了三件事：

• 模型元数据抽象：定义统一的ModelSpec结构，包含hf_repo_id（如Qwen/Qwen2-7b-Instruct）、quantization（awq/gptq/none）、device（cuda:0/cuda:1,2/rocm:0）、max_model_len（必须显式声明，避免 vLLM 动态计算导致 OOM）。当你在 UI 里填Qwen/Qwen2-7b-Instruct，CubeStudio 会自动解析config.json中的max_position_embeddings，并建议默认值（如 32768），但允许你覆盖。

• 运行时环境隔离：为每个模型实例分配独立的 Docker 容器或 Kubernetes Pod，而非共享进程。这样 Ollama 的OLLAMA_MODELS环境变量、vLLM 的VLLM_ATTENTION_BACKEND、TensorRT-LLM 的TRTLLM_ENGINE_DIR都互不干扰。实测发现，当同时部署 Qwen2-7b（vLLM）和 DeepSeek-V3（TensorRT-LLM）时，若共用容器，CUDA 上下文会因 driver 版本冲突（vLLM 需 CUDA 12.1+，TRT-LLM 1.0.0a 需 CUDA 12.4）直接崩溃；而 CubeStudio 的隔离机制让它们各自用匹配的 base image（nvcr.io/nvidia/pytorch:23.10-py3vsnvcr.io/nvidia/tensorrt:24.07-py3）。

• 健康检查穿透：不是简单 ping/health，而是调用/v1/models并验证返回的data[0].id是否匹配注册的hf_repo_id。曾遇到一次 Ollama 模型加载失败但/api/version仍返回 200 的情况，CubeStudio 的深度探针立刻捕获到models列表为空，自动触发告警并回滚部署。

2.2 协议转换层：OpenAI API 的语义对齐

这是最易被低估的部分。OpenAI API 表面是 REST，实则暗藏大量隐含契约：

关键细节在于messages数组的处理。OpenAI 要求role必须是system/user/assistant，且system只能出现在首位。而 HuggingFace 的 tokenizer（如 Qwen）期望"<|im_start|>system\n..."格式。CubeStudio 的转换器会：

1. 检查messages[0].role == "system"，若存在则提取content；
2. 将剩余user/assistant消息按 tokenizer 规则拼接（Qwen 用<|im_start|>user\n{content}<|im_end|>）；
3. 对于assistant消息，仅保留content（忽略tool_calls等 OpenAI 扩展字段）；
4. 最终调用底层引擎时，传入prompt字符串而非原始 messages。

注意：tools和tool_choice字段目前 CubeStudio 仅做透传，不解析。因为 vLLM/Ollama 均未实现 function calling 的完整 pipeline（需 LLM 输出 tool call JSON，再由 runtime 执行并注入结果）。若业务强依赖此功能，建议先用llama.cpp+llamafile方案，其--enable-tools支持更成熟。

2.3 服务治理层：API 网关级能力注入

CubeStudio 不止于协议转换，它把 OpenAI API 当作一个可编程的服务网格节点：

• 动态路由：支持基于model字段的负载均衡。例如将qwen2-7b流量导向 vLLM 实例（高吞吐），deepseek-v3导向 TensorRT-LLM 实例（低延迟），yi-1.5-9b导向 Ollama 实例（开发调试）。配置在gateway.yaml中：

  routes: - model: "qwen2-7b" backend: "vllm-qwen2" weight: 80 - model: "deepseek-v3" backend: "trtllm-deepseek" weight: 20

• 细粒度限流：不是简单的 QPS 限制，而是按model+user组合计费。例如qwen2-7b免费额度 1000 tokens/min，deepseek-v3付费额度 5000 tokens/min。CubeStudio 通过 Redis 的INCRBY命令实时累加tokens_used:{model}:{user_id}，并在响应头中返回X-RateLimit-Remaining。

• 审计日志增强：原生 OpenAI 日志只有request_id和model。CubeStudio 注入x-cube-model-id（CubeStudio 内部模型 UUID）、x-cube-engine（vllm/ollama/mindie）、x-cube-gpu-util（NVIDIA SMI 采集的 GPU 利用率）。某次线上故障中，正是通过x-cube-gpu-util发现 vLLM 实例 GPU 利用率长期低于 10%，进而定位到--block-size 16参数过大导致内存碎片，调整为32后吞吐提升 3.2 倍。

这套架构让 CubeStudio 超越了单纯“部署工具”的定位，成为连接开源模型生态与企业级 API 治理体系的桥梁。

3. 四大引擎实操对比：选型不是看 benchmark，而是看你的运维水位

CubeStudio 支持 vLLM、Ollama、MindIE、TensorRT-LLM 四大引擎，但它们绝非平替。选择哪个，取决于你的团队技能栈、硬件条件和 SLA 要求。下面用真实部署案例说明：

3.1 vLLM：适合 GPU 资源充足、追求极致吞吐的场景

适用画像：拥有 A100/H100 集群，日均请求 > 10 万，对首 token 延迟不敏感（< 500ms 可接受），需要支持长上下文（> 128K tokens）。

实操要点：

• CUDA 版本陷阱：vLLM 0.4.2 要求 CUDA 12.1+，但 Ubuntu 22.04 默认nvidia-driver-535仅支持 CUDA 12.2。若强行安装cuda-toolkit-12-1，会导致nvidia-smi不识别 GPU。正确做法是升级驱动：sudo apt install nvidia-driver-535-server（支持 CUDA 12.4）。
• PagedAttention 内存优化：--block-size 16是默认值，但在 A100-80G 上，对 Qwen2-72B 模型，实测--block-size 32可减少 22% 显存占用。计算公式：max_num_blocks = total_gpu_memory / (block_size * head_size * num_heads * 2)，其中2是 FP16 字节数。
• 量化部署：AWQ 量化模型（如Qwen/Qwen2-7b-Instruct-AWQ）需指定--quantization awq，且必须用--dtype half（不能auto），否则 vLLM 会尝试加载 FP16 权重导致 OOM。

踩坑记录：某次部署 Qwen2-72B 时，--tensor-parallel-size 4启动失败，报错CUDA error: device-side assert triggered。排查发现是--max-num-seqs 256过大，A100 单卡显存不足以容纳 256 个序列的 KV Cache。改为--max-num-seqs 64后正常，吞吐下降 18%，但稳定性达标。

3.2 Ollama：适合快速验证、边缘设备或 CI/CD 集成

适用画像：开发测试环境、MacBook M2/M3 笔记本、树莓派 5（ARM64）、需要git clone → make build → ./ollama run三步上线的极简流程。

实操要点：

• 国内镜像加速：Ollama 默认从https://registry.ollama.ai拉取模型，国内常超时。CubeStudio 提供OLLAMA_HOST环境变量，可设为http://192.168.1.100:8080（自建 Nexus 代理）或https://mirrors.tuna.tsinghua.edu.cn/ollama/（清华镜像）。注意：清华镜像仅同步官方模型（llama3/qwen2），社区模型（deepseek-coder）需自行构建。
• 离线部署包：ollama serve启动后，访问http://localhost:11434/api/show?qwen2:7b获取模型 blob，保存为qwen2-7b.sif。在无网环境执行ollama create qwen2-7b -f Modelfile（Modelfile 内容为FROM ./qwen2-7b.sif）。
• Mac M系列芯片优化：启用--num-gpu 1强制使用 ANE（Apple Neural Engine），实测 Qwen2-7b 在 M2 Max 上time_to_first_token从 1200ms 降至 450ms。需确认ollama list中模型状态为gpu: true。

避坑经验：Ollama 的--keep-alive参数默认-1（永驻），但内存泄漏严重。生产环境务必设为--keep-alive 30m，并配合 CubeStudio 的健康检查自动重启。我们曾因未设此参数，导致 Ollama 进程 72 小时后 RSS 内存涨至 12GB（初始 2GB）。

3.3 MindIE：适合国产算力平台（昇腾/寒武纪）的合规替代

适用画像：政务云、金融私有云等要求国产化适配的场景，硬件为 Atlas 900/MLU370，需通过等保三级认证。

实操要点：

• 模型转换强制项：MindIE 不接受原始 HF 格式，必须用mindie convert工具转 ONNX。例如：

  mindie convert \ --model-type qwen2 \ --input-path /models/Qwen2-7b-Instruct \ --output-path /models/qwen2-7b-mindie \ --precision fp16 \ --seq-length 4096

  关键是--model-type必须匹配，Qwen2 用qwen2，Llama3 用llama，否则 runtime 加载失败。
• 昇腾 NPU 绑核：--device-id 0指定 NPU 卡，但需提前执行export ASCEND_DEVICE_ID=0，否则报错Invalid device id。CubeStudio 的容器启动脚本会自动注入此环境变量。
• 安全加固：MindIE 默认禁用--enable-http，需显式添加。且必须配置--ssl-cert-file和--ssl-key-file，否则 CubeStudio 网关无法建立 HTTPS 连接。

真实反馈：某银行项目中，MindIE 在 Atlas 900 上部署 Qwen2-7b，首 token 延迟 320ms（vLLM 在 A100 上为 180ms），但满足其 SLA（< 500ms）。优势在于全程国产栈，审计报告中“模型推理环节无境外组件”这一条顺利通过。

3.4 TensorRT-LLM：适合对首 token 延迟极度敏感的场景

适用画像：实时语音助手、高频交易问答、车载语音交互，要求time_to_first_token < 100ms，GPU 为 RTX 4090/A100。

实操要点：

• 引擎构建耗时：TRT-LLM 的trtllm-build是离线过程，Qwen2-7b 构建时间约 45 分钟（A100-80G）。CubeStudio 提供build_cache机制，将engine目录挂载为 PVC，下次部署同模型时跳过构建。
• 动态批处理（Dynamic Batching）：必须启用--enable-streaming和--max-num-batched-tokens 8192。实测显示，当并发请求数从 1 增至 16，ttft仅增加 12ms（从 85ms 到 97ms），而 vLLM 在同等条件下从 180ms 涨至 310ms。
• 量化精度选择：FP8 量化（--use-fp8）在 H100 上提速 1.8 倍，但 RTX 4090 不支持 FP8，只能用 INT8（--use-int8），此时需--int8-kv-cache启用 KV Cache 量化，否则精度损失过大。

关键教训：TRT-LLM 的--max-input-len和--max-output-len必须严格匹配业务需求。某次设置--max-output-len 1024，但用户提问生成答案需 1200 tokens，导致 TRT-LLM 直接 truncation 并返回500 internal_error，而非 OpenAI 的length错误码。CubeStudio 的协议层已修复此问题，现在会主动拦截并返回标准400。

4. 从零部署 Qwen2-7b：CubeStudio 一键上线全流程拆解

以最典型的 Qwen2-7b 模型为例，演示 CubeStudio 的完整部署链路。这里不讲 UI 点击，而是聚焦 CLI 和配置文件，因为这才是生产环境的真实操作方式。

4.1 环境准备：最小可行依赖

CubeStudio 本身是容器化应用，但宿主机需预装：

• Docker 24.0+：旧版 Docker（< 23.0）不支持--gpus all的 device mapping，会导致 vLLM 无法访问 GPU。
• NVIDIA Container Toolkit：sudo apt-get install nvidia-container-toolkit，并执行sudo nvidia-ctk runtime configure --runtime=docker。
• CUDA 驱动：A100 需nvidia-driver-535，RTX 4090 需nvidia-driver-535-server（支持 CUDA 12.4）。

验证命令：docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi。若输出 GPU 信息，则环境就绪。

4.2 模型拉取与预处理

不要直接git cloneHF 仓库，HF 的git lfs在国内常失败。推荐两种可靠方式：

方式一：HF 镜像站 + git clone

# 设置全局镜像 git config --global url."https://hf-mirror.com/".insteadOf "https://huggingface.co/" # 拉取模型（不含大文件） git clone https://huggingface.co/Qwen/Qwen2-7b-Instruct # 进入目录，用 hf-mirror 下载大文件 cd Qwen2-7b-Instruct curl -s https://hf-mirror.com/Qwen/Qwen2-7b-Instruct/resolve/main/model.safetensors | dd of=model.safetensors bs=1M

方式二：直接下载 safetensors（推荐）

# 从镜像站获取下载链接 MODEL_URL=$(curl -s "https://hf-mirror.com/Qwen/Qwen2-7b-Instruct/refs/main" | grep -o 'https://hf-mirror.com/Qwen/Qwen2-7b-Instruct/resolve/main/model.safetensors.*' | head -1) wget "$MODEL_URL" -O model.safetensors # 创建标准 HF 结构 mkdir -p Qwen2-7b-Instruct mv model.safetensors Qwen2-7b-Instruct/ cp {config.json,tokenizer.json,tokenizer.model} Qwen2-7b-Instruct/

4.3 CubeStudio 配置文件编写

创建qwen2-7b.yaml：

name: "qwen2-7b-instruct" description: "Qwen2-7b-Instruct with vLLM backend" engine: "vllm" model_spec: hf_repo_id: "Qwen/Qwen2-7b-Instruct" quantization: "none" device: "cuda:0" max_model_len: 32768 tensor_parallel_size: 1 dtype: "half" gpu_memory_utilization: 0.9 enable_chunked_prefill: true block_size: 32 max_num_seqs: 256 download_dir: "/models" service: port: 8000 host: "0.0.0.0" api_key: "sk-cube-qwen2-7b-xxxxxx" # 用于 CubeStudio 网关鉴权 cors_allowed_origins: ["*"] log_level: "INFO"

参数详解：

• download_dir: "/models"：vLLM 启动时会从 HF 下载模型到此目录，需确保容器有写权限。
• gpu_memory_utilization: 0.9：预留 10% 显存给系统，避免 OOM。
• enable_chunked_prefill: true：对长上下文（> 8K）必备，否则 prefill 阶段显存爆炸。

4.4 一键部署与验证

# 启动 CubeStudio（假设已安装） cube-cli deploy -f qwen2-7b.yaml # 查看部署状态 cube-cli status qwen2-7b-instruct # 验证 OpenAI 兼容接口 curl http://localhost:8000/v1/models # 发送测试请求（注意：CubeStudio 网关默认监听 8000，模型实例监听 8001） curl -X POST http://localhost:8000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-cube-qwen2-7b-xxxxxx" \ -d '{ "model": "qwen2-7b-instruct", "messages": [ {"role": "system", "content": "你是一个严谨的助手"}, {"role": "user", "content": "你好，请用中文介绍你自己"} ], "stream": false }'

预期响应：

{ "id": "chatcmpl-xxx", "object": "chat.completion", "created": 1717023456, "model": "qwen2-7b-instruct", "choices": [{ "index": 0, "message": { "role": "assistant", "content": "我是通义千问Qwen2-7b，一个由通义实验室研发的大语言模型..." }, "finish_reason": "stop" }], "usage": { "prompt_tokens": 28, "completion_tokens": 42, "total_tokens": 70 } }

4.5 生产环境加固：不止于“能跑”

上线只是开始，生产环境需额外配置：

• 资源限制：在qwen2-7b.yaml中添加：

  resources: limits: nvidia.com/gpu: "1" memory: "40Gi" requests: nvidia.com/gpu: "1" memory: "32Gi"

  避免单个模型实例吃光节点资源。

• 健康检查增强：CubeStudio 默认/health仅检查进程存活。添加自定义探针：

  liveness_probe: http_get: path: "/v1/models" port: 8000 initial_delay_seconds: 120 period_seconds: 30

• 日志归集：配置log_config将日志输出到 stdout，并用 Loki + Promtail 采集。关键字段x-cube-model-id和x-cube-engine必须保留。

• HTTPS 终止：在 CubeStudio 前置 Nginx，配置：

  location /v1/ { proxy_pass http://cube-backend; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Authorization $http_authorization; # 透传 API Key }

5. 故障排查实战：从503 Service Unavailable到429 Too Many Requests的全链路诊断

部署不是终点，运维才是常态。以下是我在三个不同客户现场遇到的真实故障，附完整排查链路：

5.1 故障一：503 Service Unavailable—— 模型加载失败的静默陷阱

现象：CubeStudio UI 显示qwen2-7b状态为Running，但调用/v1/models返回503，docker logs cube-qwen2-7b无错误日志。

排查链路：

1. 确认容器是否真运行：docker ps | grep qwen2，发现容器 ID 存在，但docker inspect cube-qwen2-7b | jq '.State.Status'返回"running"，看似正常。
2. 检查端口监听：docker exec -it cube-qwen2-7b ss -tlnp | grep :8000，无输出！说明 vLLM 进程未监听端口。
3. 深入容器日志：docker logs cube-qwen2-7b --tail 100，发现最后一行是INFO: Application startup complete.，但没有INFO: Uvicorn running on http://0.0.0.0:8000。Uvicorn 启动成功，但 vLLM 服务未注册。
4. 定位根本原因：进入容器docker exec -it cube-qwen2-7b bash，执行ps aux | grep vllm，发现 vLLM 进程已退出。手动运行启动命令：

   python -m vllm.entrypoints.openai.api_server \ --model /models/Qwen2-7b-Instruct \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --dtype half \ --gpu-memory-utilization 0.9

   报错：OSError: [Errno 12] Cannot allocate memory。原来--gpu-memory-utilization 0.9计算显存需求为80G * 0.9 = 72G，但 A100-80G 实际可用显存仅 78G（系统占用 2G），vLLM 预分配失败。
5. 解决方案：将gpu_memory_utilization降为0.85，并添加--swap-space 4启用 CPU swap（仅限调试，生产环境禁用）。

经验：CubeStudio 的status命令只检查容器进程，不检查内部服务健康。生产环境必须配置liveness_probe为/v1/models，而非/health。

5.2 故障二：429 Too Many Requests—— 限流策略的隐蔽冲突

现象：前端频繁收到429，但 CubeStudio 仪表盘显示qwen2-7b的tokens_used每分钟仅 2000，远低于 10000 的配额。

排查链路：

1. 确认限流维度：查阅 CubeStudio 文档，发现限流是model + user_id组合，而前端未传递user_id。默认user_id为anonymous，所有请求计入同一桶。
2. 验证请求头：curl -v http://localhost:8000/v1/chat/completions -H "X-User-ID: user-123"，429消失。
3. 根因分析：前端 SDK 使用openai包，其client.chat.completions.create()不自动添加X-User-ID。需在初始化 client 时注入：

   client = OpenAI( base_url="http://localhost:8000/v1", api_key="sk-cube-qwen2-7b-xxxxxx", default_headers={"X-User-ID": "user-123"} # 关键！ )

4. 长期方案：在 CubeStudio 网关层，若检测到X-User-ID缺失，自动从 JWT token 解析sub字段，或 fallback 到X-Forwarded-For的 IP 哈希。

5.3 故障三：stream=True返回空 content —— 协议转换的边界 case

现象：Streaming 请求返回多个 chunk，但delta.content为空字符串，最终content为空。

排查链路：

1. 抓包分析：用curl -N抓取 raw response，发现 chunk 格式为：

   data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","model":"qwen2-7b-instruct","choices":[{"index":0,"delta":{"role":"assistant"},"finish_reason":null}]} data: {"id":"chatcmpl-xxx","object":"chat.completion.chunk","model":"qwen2-7b-instruct","choices":[{"index":0,"delta":{"content":"你好"},"finish_reason":null}]}

   第一个 chunk 的delta只有role，没有content，符合 OpenAI 规范（role只在首个 chunk 出现）。
2. 定位问题：前端 SDK（如openaiPython）期望delta.content为字符串，但某些老版本 SDK 将None或空字符串视为结束。检查 SDK 版本：pip show openai，发现是1.12.0，而1.30.0+已修复此问题。
3. CubeStudio 修复：在协议转换层，对首个 chunk 强制注入delta.content = ""，确保delta对象始终有content字段：

   if is_first_chunk and "content" not in delta: delta["content"] = ""

这些故障共同揭示一个真理：OpenAI 兼容不是“能返回 JSON 就行”，而是要精确模拟其状态机行为。CubeStudio 的价值，正在于它把这种复杂性封装起来，让你专注模型本身。

6. 进阶技巧：让 CubeStudio 不止于 API 代理，成为模型能力中枢

部署完成只是起点。CubeStudio 的扩展能力，能让它从“API 网关”升级为“模型能力中枢”。以下是我在实际项目中沉淀的三个高价值技巧：

6.1 技巧一：模型热切换 —— 零 downtime 更新模型版本

传统方案更新模型需停服、卸载旧模型、加载新模型、重启服务。CubeStudio 支持运行时热切换：

1. 准备新模型：在qwen2-7b-v2.yaml中修改hf_repo_id: "Qwen/Qwen2-7b-Instruct-v2"，其他参数不变。
2. 部署新实例：cube-cli deploy -f qwen2-7b-v2.yaml --name qwen2-7b-instruct-v2
3. 流量切流：编辑 CubeStudio 网关配置gateway.yaml，将qwen2-7b的权重从100降至0，qwen2-7b-instruct-v2从0升至100。
4. **