30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度在实际 AI 应用开发中我们经常需要集成 OpenAI 的 API 来构建智能对话、代码生成或内容创作功能。然而直接调用远程 API 不仅会带来网络延迟、成本不可控和单点故障风险更关键的是当我们需要定制模型行为、处理敏感数据或满足特定合规要求时远程服务往往无法满足需求。因此构建一个能够兼容 OpenAI API 格式的本地或私有化服务端点成为了许多中大型项目必须考虑的技术方案。这不仅仅是简单的“接口模仿”而是涉及到模型部署、协议适配、性能优化和工程化落地的系统性工作。本文将从工程实践角度出发为你详细拆解如何从零开始搭建一个能够完美兼容 OpenAI Chat Completions API 格式的本地服务。我们将覆盖从核心概念理解、环境与模型准备到服务端实现、客户端适配再到生产环境部署与问题排查的完整链路。无论你是希望将开源大模型如 Llama、Qwen、DeepSeek封装成企业级服务还是需要为内部 AI Agent 框架提供稳定的推理后端这篇文章都将提供一套可复现、可扩展的解决方案。1. 理解 OpenAI API 协议与兼容性设计的核心在开始动手之前我们必须先厘清目标我们不是在“山寨”一个 ChatGPT而是在实现一个与 OpenAI 官方 API 在请求格式、响应格式和错误处理上保持高度一致的替代端点。这样任何原本为 OpenAI API 编写的客户端代码SDK、脚本、应用都能以最小的改动切换到我们的服务上。1.1 OpenAI Chat Completions API 的核心契约OpenAI 的 Chat Completions API即v1/chat/completions定义了一套清晰的 HTTP RESTful 交互契约。兼容性设计的核心就在于遵守这份契约。请求契约 客户端会向服务端点发送一个 POST 请求其 Body 是一个 JSON 对象必须包含model和messages字段。messages是一个对象数组每个对象有rolesystem,user,assistant和content属性。此外还有大量可选参数控制生成行为如max_tokens,temperature,stream等。{ model: gpt-3.5-turbo, messages: [ {role: system, content: 你是一个有帮助的助手。}, {role: user, content: 你好请介绍一下你自己。} ], max_tokens: 100, temperature: 0.7, stream: false }响应契约 服务端必须返回一个 JSON 对象。对于非流式响应其结构固定核心是choices数组里面包含生成的message。id,created,model,usage等字段对于客户端 SDK 的兼容性也至关重要。{ id: chatcmpl-abc123, object: chat.completion, created: 1677858242, model: gpt-3.5-turbo, usage: { prompt_tokens: 10, completion_tokens: 50, total_tokens: 60 }, choices: [ { index: 0, message: { role: assistant, content: 你好我是一个AI助手由OpenAI的技术驱动。 }, finish_reason: stop } ] }流式响应契约 当请求中stream: true时响应变为 Server-Sent Events (SSE) 流。每个数据块是一个以data:开头的行最后以一个data: [DONE]行结束。每个数据块也是一个 JSON 对象结构与非流式类似但choices数组中的delta字段包含了本次流出的内容增量。data: {id:chatcmpl-123,object:chat.completion.chunk,created:1694268190,model:gpt-3.5-turbo,choices:[{index:0,delta:{content:Hello},finish_reason:null}]} data: {id:chatcmpl-123,object:chat.completion.chunk,created:1694268190,model:gpt-3.5-turbo,choices:[{index:0,delta:{content: world},finish_reason:null}]} data: {id:chatcmpl-123,object:chat.completion.chunk,created:1694268190,model:gpt-3.5-turbo,choices:[{index:0,delta:{},finish_reason:stop}]} data: [DONE]1.2 兼容性服务的价值与挑战实现一个兼容性服务端点的价值显而易见解耦与可控将应用逻辑与特定的模型提供商解耦可以灵活切换底层模型如从 GPT-4 切换到本地部署的 Llama 3而无需重写业务代码。成本与性能优化对于私有化部署可以避免按 token 计费并减少网络往返延迟。对于高频调用场景成本优势显著。数据安全与合规敏感数据无需离开内部网络满足金融、医疗、政务等领域的合规要求。功能定制与增强可以在服务端注入自定义的上下文、实现特定的输出格式约束、或集成内部知识库。然而挑战也同样存在协议复杂性需要完整实现非流式、流式两种响应模式并正确处理所有官方参数即使你的后端模型不支持某些参数也需要妥善处理或返回明确错误。模型差异开源模型在分词器Tokenizer、上下文长度、推理能力上与 OpenAI 模型存在差异这可能导致usage字段计算不准确或生成质量不一致。性能与稳定性需要自行处理模型的加载、推理队列、并发、显存管理等问题并保证服务的高可用性。生态兼容确保主流的 OpenAI SDK如openaiPython 库、LangChain、LlamaIndex能够无缝连接。理解了这些核心契约和价值挑战我们就能有的放矢地进行技术选型和实现。2. 环境准备与模型选型搭建兼容服务的第一步是准备好运行环境和底层的大语言模型。这里我们选择目前生态最成熟、性能较好的方案组合。2.1 基础环境与硬件要求一个典型的生产级模型服务环境需要以下组件操作系统推荐 Ubuntu 20.04/22.04 LTS 或 Rocky Linux 8/9。确保系统内核较新以支持最新的 GPU 驱动和 CUDA。Python 环境Python 3.9 或 3.10。使用conda或venv创建独立的虚拟环境避免依赖冲突。# 创建并激活虚拟环境 conda create -n openai-compatible python3.10 conda activate openai-compatibleGPU 与驱动如果使用 GPU 加速推理需要 NVIDIA GPU建议 RTX 3090/4090 或 A100/H100 等、对应的 NVIDIA 驱动以及 CUDA Toolkit如 CUDA 11.8 或 12.1。使用nvidia-smi命令验证驱动和 GPU 状态。容器化可选但推荐使用 Docker 或 Kubernetes 部署可以极大简化环境依赖管理和水平扩展。准备 Dockerfile 或 Helm Chart。硬件配置参考轻量级/测试CPU8核16GB 内存。可运行 7B 参数的量化模型如 Qwen2-7B-Instruct-GPTQ-Int4。生产级/中等规模单卡 GPU24GB 显存如 RTX 409032GB 内存。可流畅运行 13B-34B 参数的 4-bit 量化模型。高性能/大规模多卡 GPU如 2*A100 80GB128GB 内存。可运行 70B 参数模型或提供高并发服务。2.2 模型服务框架选型vLLM直接使用 PyTorch 加载模型并编写推理循环是可行的但对于生产环境我们强烈推荐使用专业的模型服务框架。它们封装了批处理、持续批处理Continuous Batching、KV Cache 优化、流量控制等复杂机制能极大提升吞吐量和资源利用率。目前主流的选择有vLLM由 UC Berkeley 团队开发以其高效的 PagedAttention 算法和极高的吞吐量著称对 OpenAI API 兼容性支持非常好。这是我们本文的首选。TGIHugging Face 的 Text Generation Inference同样优秀尤其擅长 Hugging Face 模型的部署。LMDeploy由上海人工智能实验室推出对国产芯片如华为昇腾有良好支持。我们选择 vLLM因为它原生提供了 OpenAI 兼容的 API 服务器几乎可以开箱即用。安装 vLLM# 根据你的 CUDA 版本选择安装命令 # 对于 CUDA 12.1 pip install vllm # 或者从源码安装以获得最新特性 # pip install githttps://github.com/vllm-project/vllm.git2.3 大语言模型选型与下载你需要选择一个开源大语言模型作为服务的“大脑”。选择时需考虑模型能力、大小、许可证和社区支持。推荐模型截至当前Llama 3 系列Meta 发布8B 和 70B 版本能力强劲许可证相对友好需申请。Qwen2 系列阿里通义千问开源包括 0.5B, 1.5B, 7B, 72B 等多种尺寸中文能力优秀Apache 2.0 许可证。DeepSeek 系列深度求索开源包括 V2 和 Coder 等版本在代码和数学推理上表现突出。Mistral 系列如 Mistral 7B, Mixtral 8x7B以较小的参数量实现优秀性能。这里我们以Qwen2-7B-Instruct为例它是一个指令微调模型适合对话场景且尺寸适中。使用 Hugging Face 下载模型确保网络通畅# 安装 huggingface-hub pip install huggingface-hub # 使用 huggingface-cli 下载需要登录或使用镜像站 huggingface-cli download Qwen/Qwen2-7B-Instruct --local-dir ./models/Qwen2-7B-Instruct # 或者直接使用 git lfs git lfs install git clone https://huggingface.co/Qwen/Qwen2-7B-Instruct ./models/Qwen2-7B-Instruct注意模型文件通常很大7B 的 FP16 模型约 14GB。请确保有足够的磁盘空间和稳定的网络。对于生产环境建议将模型存储在高速 SSD 或网络文件系统上。3. 使用 vLLM 启动 OpenAI 兼容 API 服务vLLM 提供了一个命令行工具和 Python API可以快速启动一个与 OpenAI API 格式兼容的 HTTP 服务器。3.1 基础启动命令最简化的启动方式如下python -m vllm.entrypoints.openai.api_server \ --model /path/to/your/models/Qwen2-7B-Instruct \ --served-model-name qwen2-7b-instruct \ --host 0.0.0.0 \ --port 8000参数详解--model:必选。指定模型在本地文件系统中的路径。--served-model-name:必选。指定服务对外暴露的模型名称。客户端请求中的model字段需要与此匹配或服务端会忽略该字段取决于配置。--host: 服务绑定的主机地址。0.0.0.0表示监听所有网络接口允许远程访问。--port: 服务监听的端口默认为 8000。--tensor-parallel-size: 张量并行大小用于多 GPU 推理。例如在 2 张 GPU 上运行模型则设置为 2。--max-model-len: 模型支持的最大上下文长度token 数。可以设置为小于模型原始长度以节省显存。--gpu-memory-utilization: GPU 显存利用率默认为 0.9。如果遇到 OOM内存不足错误可以适当调低如 0.8。--dtype: 加载模型的数据类型如auto,half(FP16),bfloat16。auto会根据模型和硬件自动选择。--api-key: 如果希望启用简单的 API 密钥认证可以设置此参数。客户端需要在请求头中携带Authorization: Bearer api-key。启动成功后你将在终端看到类似以下的日志INFO 07-28 10:00:00 llm_engine.py:197] Initializing an LLM engine (v0.3.0) with config: model/path/to/model, tokenizer/path/to/model, tokenizer_modeauto, revisionNone, tokenizer_revisionNone, trust_remote_codeTrue, dtypetorch.float16, ... INFO 07-28 10:00:00 llm_engine.py:376] # GPU blocks: 861, # CPU blocks: 512 INFO 07-28 10:00:00 api_server.py:107] Started server process [12345] INFO 07-28 10:00:00 api_server.py:108] Waiting for application startup. INFO 07-28 10:00:00 api_server.py:113] Application startup complete. INFO 07-28 10:00:00 api_server.py:114] Your server is running at http://0.0.0.0:80003.2 验证服务是否正常运行使用curl命令或 Python 脚本测试服务端点。使用 curl 测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2-7b-instruct, messages: [ {role: user, content: 请用一句话介绍你自己。} ], max_tokens: 50, temperature: 0.7 }如果服务正常你会收到一个结构完整的 JSON 响应。使用 OpenAI Python SDK 测试 这是更真实的测试因为你的客户端很可能就是用这个 SDK。pip install openai# test_client.py from openai import OpenAI # 关键将 base_url 指向你的本地服务地址 client OpenAI( base_urlhttp://localhost:8000/v1, # vLLM 的 OpenAI 兼容端点 api_keytoken-abc123 # 如果启动服务时未设置 --api-key这里可以填任意非空字符串 ) response client.chat.completions.create( modelqwen2-7b-instruct, # 必须与 --served-model-name 一致 messages[ {role: user, content: 请用一句话介绍你自己。} ], max_tokens50, temperature0.7 ) print(response.choices[0].message.content)运行python test_client.py你应该能看到模型生成的回复。3.3 处理流式响应vLLM 同样完美支持流式响应。在客户端你只需要将streamTrue传入并迭代返回的流。# test_stream.py from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) stream client.chat.completions.create( modelqwen2-7b-instruct, messages[ {role: user, content: 写一首关于春天的五言绝句。} ], max_tokens100, temperature0.8, streamTrue # 启用流式 ) for chunk in stream: if chunk.choices[0].delta.content is not None: print(chunk.choices[0].delta.content, end, flushTrue) print() # 换行运行此脚本你会看到诗句被逐词或逐句地实时打印出来。至此一个最基本的、兼容 OpenAI API 的本地大模型服务就已经搭建完成并可以工作了。但这仅仅是开始要用于生产环境我们还需要解决一系列工程化问题。4. 生产环境部署与配置优化直接将上述命令行启动的服务用于生产是危险的。我们需要考虑高可用、可观测性、安全性和性能调优。4.1 使用 Supervisor 或 Systemd 管理进程在 Linux 服务器上我们需要确保服务在崩溃后能自动重启并且能随系统启动。使用 Systemd 创建一个服务文件/etc/systemd/system/vllm-openai.service。[Unit] DescriptionvLLM OpenAI Compatible API Server Afternetwork.target [Service] Typesimple Useryour_username Groupyour_groupname WorkingDirectory/path/to/your/project EnvironmentPATH/path/to/your/conda/env/bin ExecStart/path/to/your/conda/env/bin/python -m vllm.entrypoints.openai.api_server \ --model /path/to/models/Qwen2-7B-Instruct \ --served-model-name qwen2-7b-instruct \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 4096 \ --gpu-memory-utilization 0.85 \ --api-key your-secure-api-key-here # 强烈建议设置 Restartalways RestartSec10 StandardOutputjournal StandardErrorjournal [Install] WantedBymulti-user.target然后启用并启动服务sudo systemctl daemon-reload sudo systemctl enable vllm-openai sudo systemctl start vllm-openai sudo systemctl status vllm-openai # 查看状态 sudo journalctl -u vllm-openai -f # 跟踪日志4.2 配置反向代理与 HTTPS在生产环境中通常不会让应用直接监听公网 IP 和端口。我们会使用 Nginx 或 Caddy 作为反向代理提供 HTTPS、负载均衡如果有多实例、静态文件服务和访问控制。Nginx 配置示例(/etc/nginx/sites-available/vllm)server { listen 443 ssl http2; server_name your-domain.com; # 你的域名 ssl_certificate /path/to/your/fullchain.pem; ssl_certificate_key /path/to/your/privkey.pem; # 限制客户端 body 大小防止过大请求 client_max_body_size 10M; location /v1/ { proxy_pass http://127.0.0.1:8000/v1/; # 指向 vLLM 服务 proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # 以下配置对 SSE (流式响应) 至关重要 proxy_buffering off; proxy_cache off; chunked_transfer_encoding off; proxy_read_timeout 300s; # 长生成任务需要更长的超时时间 proxy_send_timeout 300s; } # 可选的健康检查端点 location /health { proxy_pass http://127.0.0.1:8000/health; access_log off; } }配置完成后重启 Nginxsudo systemctl restart nginx。现在你的服务就可以通过https://your-domain.com/v1/chat/completions安全访问了。4.3 性能调优与监控vLLM 提供了许多参数来优化性能和资源使用。以下是一些关键参数--max-num-batched-tokens限制一次前向传播中处理的最大 token 数用于控制峰值显存。如果遇到 OOM可以调低此值。--max-num-seqs同时处理的最大请求数批次大小。增大此值可以提高吞吐量但会增加延迟和显存占用。需要根据 GPU 显存和业务延迟要求权衡。--block-sizePagedAttention 的块大小。通常保持默认16即可对于极长上下文可以尝试调整为 8。--swap-space当物理显存不足时可以使用 CPU 内存作为交换空间的大小GB。这会影响性能仅作为应急方案。--quantization量化方式如awq,gptq,squeezellm。可以显著减少显存占用但可能轻微影响质量。例如--quantization awq。监控除了系统级的监控如 GPU 使用率、显存、温度vLLM 还提供了 Prometheus 格式的指标端点 (/metrics)。你可以配置 Prometheus 和 Grafana 来监控请求速率、延迟、队列长度、缓存命中率等关键指标。启动命令示例整合了部分优化参数python -m vllm.entrypoints.openai.api_server \ --model /path/to/models/Qwen2-7B-Instruct-GPTQ-Int4 \ # 使用量化模型 --served-model-name qwen2-7b-instruct \ --host 0.0.0.0 \ --port 8000 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --max-num-seqs 32 \ --max-num-batched-tokens 2048 \ --quantization gptq \ --api-key $YOUR_API_KEY5. 客户端适配与高级用法服务端就绪后客户端需要做最小的改动来接入。同时我们也会探讨一些高级集成场景。5.1 修改 OpenAI SDK 配置这是最常见的场景。你只需要修改初始化客户端时的base_url和api_key。# 原版调用 OpenAI # from openai import OpenAI # client OpenAI(api_keysk-...) # 切换到本地兼容服务 from openai import OpenAI client OpenAI( base_urlhttps://your-domain.com/v1, # 你的服务地址 api_keyyour-secure-api-key-here # 与服务端设置的 --api-key 一致 ) # 后续所有 chat.completions.create 等调用都无需修改 response client.chat.completions.create(...)5.2 在 LangChain 或 LlamaIndex 中使用这些高级框架通常也支持自定义 OpenAI 兼容的端点。在 LangChain 中from langchain_openai import ChatOpenAI llm ChatOpenAI( modelqwen2-7b-instruct, openai_api_basehttps://your-domain.com/v1, openai_api_keyyour-secure-api-key-here, temperature0.7, max_tokens500, ) # 之后可以像使用普通 ChatOpenAI 一样使用 llm在 LlamaIndex 中from llama_index.llms.openai import OpenAI llm OpenAI( modelqwen2-7b-instruct, api_basehttps://your-domain.com/v1, api_keyyour-secure-api-key-here, )5.3 处理模型差异与参数映射开源模型与 GPT 系列存在差异客户端代码可能需要调整上下文长度GPT-4 支持 128K而你的本地模型可能只支持 8K 或 32K。客户端发送的对话历史总 token 数不能超过--max-model-len。需要在客户端或服务端前置进行长度截断。系统提示词并非所有模型都像 GPT 一样对systemrole 有特殊优化。有些模型可能将system消息与user消息同等对待。必要时可以将system提示词合并到第一个user消息中。停止词OpenAI API 的stop参数可能在某些模型上表现不一致。如果遇到问题可以尝试在服务端后处理中实现停止逻辑。Function Calling / JSON Mode这些是 OpenAI 的专有特性。如果你的本地模型不支持客户端相关代码会失效。要么寻找支持类似功能的开源模型如特定微调版本要么在业务层规避这些特性。6. 常见问题排查与解决方案在实际部署和运行过程中你几乎一定会遇到以下问题。这里提供系统的排查路径。6.1 服务启动失败问题现象可能原因检查方式解决方案ModuleNotFoundError: No module named vllmPython 环境未安装 vLLM或不在正确的虚拟环境中。执行 pip listgrep vllmCUDA error: out of memoryGPU 显存不足无法加载模型。运行nvidia-smi查看显存占用。1. 使用量化模型GPTQ, AWQ。2. 减小--gpu-memory-utilization。3. 使用--max-model-len限制上下文长度。4. 升级硬件。Failed to load model ...模型路径错误或模型文件损坏。检查--model参数指向的路径是否存在且包含config.json,pytorch_model.bin等文件。确认模型路径重新下载模型。ValueError: Tokenizer class ... does not exist.模型需要trust_remote_codeTrue。查看完整错误信息。在启动命令中显式添加--trust-remote-code参数。6.2 客户端请求失败问题现象可能原因检查方式解决方案Connection refused或Timeout服务未启动或防火墙/安全组阻止了端口。在服务器上执行curl http://localhost:8000/v1/models。检查 netstat -tlnpgrep 8000。404 Not Found请求的 URL 路径不正确。确认客户端base_url是否以/v1结尾。vLLM 的 OpenAI 端点在/v1下。将base_url设置为http://your-server:8000/v1。401 UnauthorizedAPI 密钥未设置或不匹配。检查服务启动命令是否有--api-key以及客户端请求头Authorization是否正确。在服务端设置--api-key并在客户端请求头中携带Bearer key。422 Unprocessable Entity请求体 JSON 格式错误或缺少必填字段。查看服务端日志或响应 body 中的详细错误信息。确保请求 JSON 包含model和messages字段且格式正确。使用json.dumps()确保编码正确。6.3 推理结果异常问题现象可能原因检查方式解决方案生成内容乱码或重复模型本身生成问题或temperature参数过低导致确定性过强。尝试相同的提示词和参数在 WebUI如 oobabooga中测试。调整temperature(如 0.7-0.9) 和top_p。检查提示词是否清晰。对于某些模型可能需要调整repetition_penaltyvLLM 通过--repetition-penalty启动参数设置。响应速度极慢首次请求需要加载模型和预热或请求队列过长或硬件性能不足。观察服务端日志的排队和预处理时间。使用nvidia-smi查看 GPU 利用率。1. 服务预热先发送一个简单请求。2. 性能调优参考第 4.3 节调整 vLLM 参数。3. 硬件升级。usage字段的 token 数不准确开源模型的分词器与 OpenAI 的tiktoken不同。比较本地模型分词和tiktoken分词的结果。vLLM 会使用模型自带的分词器计算 token 数这与 OpenAI 的统计方式有差异。这是正常现象。如果必须一致可以在客户端用tiktoken重新计算但意义不大。流式响应不完整或中断网络代理或负载均衡器缓冲了 SSE 流。检查 Nginx 等代理的配置是否设置了proxy_buffering on。在反向代理配置中必须为流式路径设置proxy_buffering off;和chunked_transfer_encoding off;。6.4 高级问题多模型部署vLLM 支持同时加载多个模型。使用--model参数指定一个模型列表以空格分隔并为每个模型使用--served-model-name指定别名。客户端请求时model字段需要与某个别名匹配。自定义身份验证与鉴权--api-key是简单的认证。如果需要复杂的 OAuth、JWT 或基于角色的访问控制需要在 vLLM 服务器前再架设一个认证网关如使用 FastAPI 编写或者修改 vLLM 的源码不推荐维护成本高。输入输出预处理/后处理如果你需要在每个请求/响应前后执行自定义逻辑如日志记录、敏感词过滤、输出格式化最佳实践是再包装一层 API 网关。这层网关接收客户端请求调用 vLLM 服务处理后再返回给客户端。7. 最佳实践清单为了确保服务的稳定性、安全性和可维护性请遵循以下清单安全第一永远不要将服务直接暴露在公网而不设认证--api-key。使用 HTTPS通过反向代理配置。定期轮换 API 密钥。在网关上实施速率限制和 DDoS 防护。配置外置化不要将 API 密钥、模型路径等硬编码在命令行或代码中。使用环境变量或配置文件管理。例如export VLLM_API_KEYyour_key然后在启动命令中使用--api-key $VLLM_API_KEY。完善的监控与告警监控服务进程状态Systemd/Supervisor。监控 GPU 显存、利用率、温度。监控 API 请求的 QPS、延迟、错误率通过 Prometheus/metrics。设置关键指标如错误率 1%延迟 P99 10s的告警。日志标准化配置 vLLM 的日志级别--log-level。将日志收集到集中式系统如 ELK Stack中便于排查问题。在日志中记录请求 ID、模型、输入 token 数等关键信息。版本管理与回滚对模型文件、vLLM 版本、服务配置进行版本控制。制定清晰的回滚方案当新模型或新版本出现问题时能快速切换回旧版本。容量规划与压测在上线前使用工具如locust,wrk模拟真实流量进行压测。根据压测结果确定单实例的承载能力并规划好水平扩展方案。客户端健壮性在客户端代码中实现重试机制使用指数退避和熔断机制如circuitbreaker。设置合理的超时时间连接超时、读取超时避免线程被长时间阻塞。通过以上步骤你构建的就不再是一个简单的“本地 ChatGPT 替代品”而是一个符合生产标准的、可控的、高性能的企业级大模型推理服务。这套架构可以平滑地集成到现有的 AI Agent、RAG 系统或自动化工作流中为你的业务提供稳定可靠的智能内核。后续的迭代可以围绕模型更新、功能扩展如支持视觉模型、工具调用和架构优化如模型并行、流水线并行展开。 30款热门AI模型一站整合DeepSeek/GLM/Qwen 随心用限时 5 折。 点击领海量免费额度