把 HuggingFace 上扒下来的模型变成公司内部能调用的 API，这件事我折腾了小半年。早期部署模型，我都是先起一个 FastAPI 服务，把 transformers 的 generate 包一层写个 /chat 接口；后来模型多了才发现，vLLM、Ollama、TensorRT-LLM 各有各的调用方式，客户端代码得给每个引擎单独写一套。直到后面统一走 CubeStudio 这类推理服务平台，把 OpenAI 兼容 API 作为标准出口，问题才算彻底解决：业务层永远只管一个 base_url、一把 API Key，后端到底用 vLLM 还是 Ollama，对调用方来说完全不重要。这篇文章就把这次从混乱到统一的完整路径拆开讲，包含资源与显存预算、vLLM / Ollama / MindIE / TensorRT-LLM 四种引擎的一键上线实操、兼容性验证清单，以及我实实在在踩过的坑。适合正在做企业大模型私有化部署、或者想把开源模型快速接进内部系统的同学参考。
1. 为什么 OpenAI 兼容格式值得折腾
1.1 生态里默认的"接口语言"
这波 AI 应用生态，实际上是用 OpenAI 协议串起来的。无论是 LangChain、LlamaIndex、Dify、FastGPT、One API，还是企业内部自研的 Agent 框架，默认都实现了对 OpenAI API 的客户端。我第一次意识到这件事，是发现公司采购的第三方客服系统，各种大模型插件参数里就一个 base_url、一个 api_key、一个 model 名，它根本不关心你背后是什么模型，只要协议长得像 OpenAI 就行。
这个"协议"的核心就那么几个端点：
- GET /v1/models：列出可用模型；
- POST /v1/chat/completions：聊天补全，也是绝大多数业务唯一在用的接口；
- POST /v1/completions：纯文本补全，现在用得比较少了；
- POST /v1/embeddings：文本向量化，做 RAG 时绕不开。
再加上一套请求/响应字段约定：请求里有 model、messages、temperature、max_tokens、stream 这些；响应里有 choices[0].message.content、usage.prompt_tokens、usage.completion_tokens。别小看这套字段约定，你后面换任何模型、任何引擎，只要出口还是这个形状，业务代码就一行都不用动。
1.2 不统一的痛点：每个引擎一套调用方式
如果只是部署一个模型，自己包个 HTTP 层也不难。真正麻烦的是模型多了、引擎多了之后。HuggingFace 上的模型迁移到不同推理框架里，调用风格严重分裂：transformers 本身没有标准 HTTP 接口，vLLM 自带 /v1 风格端点但参数细节随版本变化，Ollama 有自己的一套 /api/chat，TensorRT-LLM 部署后的服务接口要单独适配，MindIE 在昇腾硬件上又是另一套对话格式。
我早期就吃过这个亏：同一个业务，为了切不同模型，搞了三套 Client 代码。后面意识到这不合理，因为模型的异构性是永远存在的，而业务恰恰不需要感知这种异构性。于是我做了一个决定：不管后端用什么引擎，一律对外暴露 OpenAI 格式。这也是我后来选择 CubeStudio 这类平台的根本原因——它把引擎差异消化在了平台内部，对外只吐一个标准网关。
1.3 怎么判断你的部署方式合不合格
我的朴素标准：开发环境里把模型从 A 换到 B，业务代码改了超过三行，说明接入层不合格。换成 OpenAI 兼容之后，换模型基本只是把 model 字段改一下。如果你有多个内部系统要接大模型，这个收益会被放大很多倍：第一个系统接入花一天，后续系统接入可能只需要加一个环境变量。
从成本角度再说一句：OpenAI 兼容 API 并不是 OpenAI 的私产，它本质上是把 HTTP 请求和 JSON 字段做成了一套惯例。为这套惯例做一个私有部署版本，是在给整个公司省重复劳动，而不是替 OpenAI 做宣传。真到业务量上来，你大概率还要接多模型路由、限流、按部门计量，这些功能只有在统一协议之上才做得顺手。
2. 部署前的资源账和模型预处理
2.1 显存预算是第一步，权重只是起步
很多人第一步就翻车，是因为只算了权重大小。权重只是底数，真正吃显存的大头还包括 KV Cache 和激活值。所谓 KV Cache，就是模型生成每个 token 时要保存的中间状态，它和并发请求数、上下文长度成正比。这也是为什么同样一个 7B 模型，max_model_len 设 4096 和设 32768，显存占用能差出好几 GB。
我自己的估算法：权重占用约等于参数量乘以精度字节数。7B 用 BF16 是 14GB 左右，13B 是 26GB，70B 是 140GB。再加上 KV Cache 和运行预留，7B BF16 在单卡 4090 上能比较舒服地跑，但上下文别开太大；70B BF16 再怎么说也得 4 张 80GB 以上的卡，或者老老实实量化。如果手里只捏着 2 张 4090，我不会去碰 70B 的原版权重，要么选量化版，要么选 14B 这个级别。
再强调一下：显存不是"放得下权重"就行，还要同时容纳多路并发和长上下文。在平台里选 GPU 规格时，我习惯给权重留满之后，再额外留 10%-20% 余量给 KV Cache 的临时弹性。
2.2 HuggingFace 模型获取：镜像与目录管理
从 HuggingFace 拉模型，正常路径是 huggingface_hub 的 snapshot_download。但国内网络环境访问 HF 主站不太稳定，最省事的是把环境变量指到镜像站：
export HF_ENDPOINT=https://hf-mirror.com huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir /data/models/Qwen2.5-7B-Instruct或者用 ModelScope 的下载命令：
modelscope download --model Qwen/Qwen2.5-7B-Instruct --local_dir /data/models/Qwen2.5-7B-Instruct下载之前先看清楚模型仓库里有什么文件。safetensors 权重至少要跟 config.json、tokenizer.json、tokenizer_config.json 在一起；如果缺 tokenizer 文件，服务能起来，但一调 chat 接口就会发现没法把 prompt 编码成 token，返回的全是乱码或者直接报错。
还有一个习惯我强烈建议保留：把 HF_HOME 固定到一个大磁盘目录。有人下载了多个模型，默认缓存目录散落在 home 下，最后磁盘爆了都找不到是谁占的空间。模型动辄几十 GB，这个坑一次就能吃够。
2.3 量化选型：BF16、FP8 还是 AWQ/GPTQ
模型下载时通常有一堆量化版本，部署前得想明白目标：
- BF16 原版：效果最好最稳，代价是显存和吞吐；
- FP8：H 系列 GPU（如 H20、H100）上性价比高，vLLM 和 TensorRT-LLM 都比较成熟；
- AWQ / GPTQ 4bit：显存占用小，但精度有所损失，适合高并发低成本场景；
- GGUF（Q4_K_M 等）：Ollama 生态的主力格式，文件最小，CPU 也能跑，但高吞吐性能上限低于 vLLM 体系。
千万不要拿着 GGUF 文件去让 vLLM 加载，也不要把 AWQ 的模型目录当作原版权重上传，否则引擎初始化阶段很可能直接报权重格式错误。每个引擎对量化的支持矩阵不一样，平台选型时最好选能自动识别量化格式的版本，省去一堆手动声明。
2.4 模型目录做好隔离，才能换来换去
我最后成型的目录是这样：
/data/models/ Qwen2.5-7B-Instruct/ config.json model-00001-of-00004.safetensors ... Qwen2.5-14B-Instruct-AWQ/ config.json model.safetensors ... bge-m3/ config.json ...一个模型一个目录，目录里放全套文件，不混放、不压缩。这个习惯特别重要，因为推理平台在导入模型时往往是扫描目录读取 config.json 的；目录干净，平台才能正确识别模型的类型、参数量、精度，从而给出合适的引擎模板。我有一次把多个模型混在一个父目录里，导致平台识别出错误的 model type，部署出来接口全 404，白白排查了一下午。
3. CubeStudio 一键上线的完整操作链
3.1 为什么不用手写 docker run
网上常见的部署教程都是手把手教命令：
docker run --runtime nvidia --gpus all \ -v /data/models:/models \ -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen2.5-7B-Instruct \ --served-model-name qwen25-7b这条命令本身没问题，问题是模型多起来之后，每一套服务都要管理端口、环境变量、日志、健康检查、重启策略、多卡参数、升级迁移。二十个模型就是二十套部署脚本，总有人忘了改端口导致冲突，或升级 vLLM 镜像后参数变了导致服务起不来。
这也是我后面把部署迁到 CubeStudio 的直接原因。这类平台本质上干一件事：把"模型下载 + 引擎装配 + GPU 资源分配 + API 网关注册"变成标准流程。你负责提供模型和选引擎，平台负责把它变成稳定在线服务。
我理解"一键上线"不是魔法，而是把高频操作模板化了。点一个部署按钮，背后是平台调度器在拉镜像、挂载模型目录、按模板生成启动命令、做健康检查、然后把地址和 Key 注册到网关。
3.2 从模型导入到服务上线的四个步骤
我按实际操作流程记一下，具体界面不同版本可能有差异，但步骤基本是这几步：
- 模型管理里"导入模型"。可以填 HuggingFace 仓库地址，也可以导入本地目录。如果你手头已经有模型文件，导入后平台会做文件完整性校验，常见报错是文件数量不对、config.json 缺失。
- 创建推理服务。选模型、选引擎、选资源规格。这一步是核心，选择逻辑后面单独讲。
- 配置运行参数。包括 max_model_len、gpu_memory_utilization、tensor_parallel_size、并发上限等。平台一般会给默认值，但我建议按实际场景改，别偷懒。
- 发布。平台开始部署，状态从 Creating 变 Running。此时会分配 API 域名和 Key，你手里就有了一台"私有 OpenAI 服务"。
第一次部署时最容易被忽略的反而是第四步之后：你需要确认这个服务绑定的模型名。因为业务调用时 model 字段到底填什么，取决于 API 网关注册的名字，不一定等于模型目录名。最好在导入时就把"served model name"设计好，比如统一用 llm-qwen7b-instruct 这类带用途的标识，而不是文件名那串英文加数字。
3.3 关键运行参数别只看默认值
具体到 vLLM 引擎，我基本只关心四个参数：
| 参数 | 作用 | 我的建议值 |
|---|---|---|
| max_model_len | 上下文最大长度 | 按业务最大输入留 20% 余量，常用 16384 或 32768 |
| gpu_memory_utilization | 显存利用率 | 独占卡 0.9，共享卡 0.7-0.8 |
| tensor_parallel_size | 多卡并行数 | 70B 建议 4-8，7B 建议 1-2 |
| max_num_seqs | 最大并发序列数 | 压测后再调，默认值通常够用 |
Ollama 引擎则简单很多，它基于 GGUF，会自己管理显存占用，参数主要是 context size 和 num_gpu。我的经验是：Ollama 适合"能跑"验证，目标明确要上线生产，一般还是切到 vLLM 或 TensorRT-LLM。
3.4 API 网关：统一域名、Key 和路由
平台提供的地址通常是 https://xxx.gpu.example.com/v1 这种，外加一个 sk- 开头的 Key。从这里开始，所有客户端行为就和调用 OpenAI 一样了：base_url 填 /v1，headers 里填 Authorization: Bearer sk-xxx。
网关层还有两个容易被忽视的价值：
- 统一的限流配额：可以给某个服务 Key 设置一天多少 token 上限，部门接入时特别好用；
- 多副本路由：一个模型服务挂多副本，网关自动负载均衡，用户无感切换。
单副本部署时改参数要重启，会出现短暂 502；多副本可以滚动更新，流量不中断。所以凡是要给团队用的模型，我至少会配置两个副本。
4. vLLM、Ollama、MindIE、TensorRT-LLM 怎么选
4.1 vLLM：默认发动机，高并发首选
vLLM 是当前开源社区事实上的默认引擎。它最大的贡献是 PagedAttention 显存管理，把 KV Cache 按页分配，显存碎片少、利用率高；配合 continuous batching，来一个新请求不用等当前批次跑完，生成过程中随时可以插入，并发吞吐明显优于传统方式。
所以只要目标是多用户在线调用，我的默认选择就是 vLLM。CubeStudio 里 vLLM 模板覆盖了大部分模型，启动时平台自动生成大致这样的命令：
vllm serve /models/Qwen2.5-7B-Instruct \ --host 0.0.0.0 --port 8000 \ --served-model-name qwen25-7b \ --gpu-memory-utilization 0.9 \ --max-model-len 32768说一下版本问题：从 vLLM 0.8 之后，启动命令统一收敛成 vllm serve，老教程里的 python -m vllm.entrypoints.openai.api_server 写法已经退役。如果你自己写脚本遇到不认识的参数，大概率是版本跨太大，别硬改，直接翻对应版本文档。
vLLM 原生支持 /v1/chat/completions、/v1/completions、/v1/embeddings，这是平台能"一键兼容 OpenAI"最省力的点。但不同 vLLM 版本对 OpenAI 协议细节的支持在演进，function calling 现在比较完整了，早期版本有偏差。平台锁定的 vLLM 版本如果偏旧，遇到 tools 参数报错不必惊讶，升版本或换引擎都能解决。
4.2 Ollama：轻量验证和本地调试的好帮手
Ollama 走的是另一条路线：开箱即用，模型以 GGUF 为主，一条命令就能拉模型起服务。它的 OpenAI 兼容端点在 /v1，用法和 OpenAI 一样。很多人不知道 Ollama 自带这个端点，我早期也是先跑起来 ollama run qwen2.5:7b，才发现它已经把协议暴露出来了。
它的优势是轻：CPU 也能跑，内存占用可以被量化格式压得很低，适合开发机、离线环境、单用户测试。劣势也明显：在高并发接入场景的吞吐挖掘上不如 vLLM；工具调用和结构化输出的兼容性需要逐项验证。
所以我的建议是：如果只是个人验证 prompt 效果，或者给内部小工具做后端，Ollama 是成本最低的路径；如果预期有几十上百人同时调用，别纠结量化文件能省多少显存，直接用 vLLM 高并发模板会省下很多运维烦恼。
4.3 TensorRT-LLM：性能压榨机，但构建链路长
TensorRT-LLM 是 NVIDIA 的推理加速方案，思路是提前把模型编译成针对特定 GPU 的优化 engine，推理时能榨出比通用框架更高的吞吐和更低的延迟，再加上 FP8、INT4 等量化支持。但"性能换复杂"是逃不掉的：权重要用官方脚本转成 checkpoint，再 trtllm-build 成 engine，不同 GPU 型号还要重新 build。手动流程长、容易错，这也是它在工程师群体里口碑两极的原因。
平台上选 TensorRT-LLM 的价值就在这：平台把 checkpoint 转换和构建步骤托管了，模型文件进，engine 产物被缓存，后续多副本调度可以直接复用。我观察到的典型场景是：生产环境已经吃满 GPU、业务对延迟极其敏感、模型基本固定不变。如果模型每周换一次，你会把时间全花在构建上，那就不如 vLLM。
4.4 MindIE：昇腾硬件上的推理路径
MindIE 对应的是昇腾 NPU 生态，走的是 CANN 工具链。如果你手头是昇腾加速卡而非 N 卡，那 vLLM / TensorRT-LLM 在多数情况下不是首选，MindIE 是更成熟的本地推理服务方案，同样可以暴露 OpenAI 风格接口。
使用 MindIE 时，最需要注意的是整个调试思路和 CUDA 生态不同：算子、量化、精度对齐都要按昇腾文档来验证。平台如果支持 MindIE 模板，最大的帮助是把 CANN 环境、服务进程、端口这些运维层面的活变成配置项，避免你第一周全在装驱动和调环境。我的经验是：不要拿 N 卡的命令直接往昇腾上套，参数名字和默认值都可能不同。
4.5 选型对照表
| 引擎 | 硬件依赖 | 量化支持 | 并发能力 | 上手成本 | 典型场景 |
|---|---|---|---|---|---|
| vLLM | NVIDIA GPU | AWQ/GPTQ/FP8/BF16 | 高，continuous batching | 中 | 多用户生产服务 |
| Ollama | CPU/GPU 均可 | GGUF | 中低 | 极低 | 本地验证、轻量小工具 |
| TensorRT-LLM | NVIDIA GPU，按卡构建 | FP8/INT4/INT8 | 很高，需编译优化 | 高 | 固定模型的峰值压榨 |
| MindIE | 昇腾 NPU | 昇腾生态量化 | 视硬件配置而定 | 高 | 昇腾硬件私有化部署 |
我的选型口诀：先看硬件，再看并发，最后看模型稳定性。N 卡默认 vLLM，小规模选 Ollama；追求单 GPU 极限性能用 TensorRT-LLM；昇腾设备就别挣扎，踏实用 MindIE。
5. 上线后的兼容性验证清单
服务上线那一刻才是开始。我的经验是，不要直接在业务代码里接，先花五分钟把接口全部打一遍，确认协议形状对不对。
5.1 curl 把基础端点打一遍
先看模型列表：
curl -s http://your-endpoint/v1/models \ -H "Authorization: Bearer sk-xxx"正常会返回类似 {"data": [{"id": "qwen25-7b", ...}]}，里面的 id 就是要填给 model 字段的名字。如果返回空数组，去查 API 网关注册名和 served-model-name 是否一致。
再打聊天接口：
curl -s http://your-endpoint/v1/chat/completions \ -H "Authorization: Bearer sk-xxx" \ -H "Content-Type: application/json" \ -d '{ "model": "qwen25-7b", "messages": [{"role": "user", "content": "用一句话介绍自己"}], "stream": false }'看返回 JSON 里 choices[0].message.content 是不是正常文本。如果报 model 不存在，多半是模型名不对；报认证失败，检查 Key；报 413 或超长，多半是 max_model_len 卡住了输入。这一套查下来，是平台问题还是模型问题基本能定位。
5.2 OpenAI SDK 一行不改接入
curl 通了，下一步用 OpenAI SDK 验证"代码兼容层"是否真的合格：
from openai import OpenAI client = OpenAI( base_url="http://your-endpoint/v1", api_key="sk-xxx" ) resp = client.chat.completions.create( model="qwen25-7b", messages=[ {"role": "system", "content": "你是一个严谨的会计"}, {"role": "user", "content": "3.11 和 3.9 谁大？"} ], temperature=0.0, max_tokens=256 ) print(resp.choices[0].message.content) print(resp.usage)这里有个重要细节：OpenAI SDK 里的所有参数，比如 presence_penalty、frequency_penalty、top_p，不是每个引擎都实现。传了某个参数而引擎不支持，有的平台会直接忽略，有的会报错。我建议业务代码里先用最小参数集，跑通之后再逐步加。
5.3 流式输出 SSE 的验证与网关缓冲坑
聊天类的真实交互基本都要流式。直接设 stream=true 看返回格式：
- 响应头 Content-Type 是 text/event-stream；
- 每行是 data: {...}；
- 末尾必须出现 data: [DONE]。
我写过一个小脚本，逐行打印 data 的到达时间，如果发现所有内容是一次性返回的，问题多半出在网关或反向代理的缓冲上，而不是模型引擎。平台如果有"透传流式响应"开关，把它打开；如果你自己套了 Nginx，记得关掉 proxy_buffering。
5.4 Embedding 模型与 RAG 场景单独部署
检索增强这种场景，一般要单独部署 embedding 模型。比较典型的组合是 chat 模型加 embedding 模型分开跑。比如用 vLLM 加载 Qwen3-Embedding-0.6B 这类小模型：
vllm serve Qwen/Qwen3-Embedding-0.6B \ --task embedding \ --served-model-name qwen3-embedding-06b \ --port 8001然后用 OpenAI SDK 的 embeddings.create 调 /v1/embeddings。我要提醒的是：embedding 模型和 chat 模型的引擎参数、并发策略完全不同，embedding 通常不需要长上下文和连续批处理的超长输入；在平台里给两类模型分开建服务、分开配资源是更好的习惯。
5.5 压测看什么指标
最后做一个简单并发验证。我常用的一段脚本逻辑是：准备 20 个并发线程，每个发 30 次请求，记录首 token 延迟、总耗时、错误码。重点看两个数字：
- 首 token 延迟：用户感知的"开始回答"速度，通常 0.2-1 秒算不错；
- tokens/s：吞吐，单卡 7B 模型一般能到几百到上千 token/s，具体看硬件和量化。
如果并发一高错误率就上来，先看显存是不是打满，再看 max_num_seqs 是不是太小。平台监控页面一般有 GPU 利用率和 KV Cache 使用率的曲线，这两条曲线比代码更能说明问题。我曾经遇到一个模型单请求延迟正常，并发一到 16 就大量超时，把 gpu_memory_utilization 从 0.9 调到 0.8 之后反而稳定了，原因是系统里其他进程占了显存，强行 0.9 导致了显存抖动。
6. 我实际踩过的七个坑
6.1 明明 curl 成功，SDK 却 401
我自己遇到过一次很奇怪的问题：带 Authorization 头的 curl 能通，换成 openai SDK 却一直 401。查了半天发现，SDK 里我填的 api_key 环境变量前面被内部代理加了一层 sk- 前缀过滤逻辑。很多平台为了区分"平台主 Key"和"部署服务 Key"，会在网关层校验 Key 的前缀类型；你拿管理台的 Key 去调部署服务，认证当然过不了。解决办法很简单：在 API 管理页单独为这个服务生成一个 Key，用服务级 Key。
6.2 显存 OOM 和 503 的连锁反应
vLLM 模式下显存不够，表现往往不是"部署失败"，而是某个请求进去后引擎初始化 CUDA context 失败，平台健康检查连续失败，于是对外报 503。最典型场景是：一个节点的 GPU 上已经跑了一个模型，你又在这个节点开了第二个部署，gpu_memory_utilization 还是 0.9，直接撞 OOM。后来我习惯在平台里把每台 GPU 的可用显存配额显式写清楚，再开新部署时先看剩余显存，而不是闭眼选规格。
6.3 max_model_len 和超长输入
业务侧喜欢把一个几千字的文档整个塞进 prompt。max_model_len 如果设 8192，输入 8000 字再加上 system 和历史消息，直接就爆了。vLLM 遇到超长输入默认会报 400 或截断，用户看到的就是"请求失败"或"回答不完整"。
我的建议是：先统计业务侧真实 prompt 的最大长度，再加 20% 余量，作为 max_model_len。宁可设成 16384 而牺牲一点 KV Cache 余量，也别让业务频繁因为超长报错。这个参数在一键部署模板里往往是默认值，恰恰是最需要手动改的。
6.4 量化参数忘了传
把 AWQ/GPTQ 目录直接交给 vLLM，如果不指定量化参数，很可能加载失败或权重大小对不上。平台的模型导入如果识别不出量化格式，你在部署参数里要手动补上。判断标准很朴素：部署时日志里如果出现 Failed to load the model weights 或 size mismatch，先查精度格式声明，别急着怀疑 GPU 问题。
6.5 流式响应被网关吞掉
最坑的一个问题：客户端请求 stream=true，等 30 秒，结果一次性收到整段回答。排查之后发现是平台网关对响应做了缓冲，SSE 事件全被攒到最后才 flush。这个和上面 5.3 说的同一个问题。解决方案：平台里找流式透传或禁用响应缓冲的选项；如果网关不可配，就在引擎层再套一个直连端口做对比测试，确认是网关问题而不是引擎行为。
6.6 多副本与冷启动
vLLM 加载一个 70B 模型可能要好几分钟，多副本扩容时新副本没就绪之前，所有流量还压在老副本上。如果业务流量是突发的，冷启动期间的排队延迟会很难看。我的做法是：给关键模型设置最小副本数，平时保两个副本热着；把模型目录放到高速存储上，减少加载时间；大版本模型尽量安排在低峰期更新，避免滚动更新时服务中断。
6.7 function calling 的兼容度差异
最后说一个最容易让业务侧抓狂的：function calling，也就是工具调用。同为 OpenAI 兼容接口，不同引擎对 tools 参数的支持深度完全不一样。vLLM 新一些的版本支持工具调用的元数据注入，Ollama 的 /v1 里部分版本支持不完整，MindIE / TensorRT-LLM 里也要看模板具体实现。测试方法很直接：像 OpenAI 文档那样传一个 get_weather 的 tools 数组，看是否返回 tool_calls 字段，以及输出格式是否能被你的 Agent 框架解析。不要假设"兼容 OpenAI"就等于"function calling 一定可用"，这是两件事。
最后留一句我的体会。模型服务这件事，90% 的复杂度不在模型本身，而在工程整合：显存的边界、引擎的差异、协议的细节、网关的行为。CubeStudio 这类平台把一部分复杂度封装了，但它封装不了你对模型的了解。我每次新上一个模型前，都会先在小规格 GPU 上手动起一次 vLLM 或 Ollama，确认权重、tokenizer、量化格式都没问题，再交平台做正式部署。这个小习惯，帮我绕开了后面 80% 的坑。如果你也在搭建内部的大模型 API，我建议同样保留这个步骤，别把平台当成黑盒。
