拓冰网站定制 
GLM-5.3-Flash 这名字刚出来的时候我其实没太当回事——Flash 后缀这些年见多了无非是快一点、便宜一点的 API 版本。直到我同时接到两个正经需求一个要把这个模型接进公司内部的 Agent 平台另一个要把开源权重部署到我们那批“东拼西凑”的 GPU 机器上我才意识到这个模型的部署路径比想象中更有讲究。先说结论GLM-5.3-Flash 是一条典型的三段式部署路径——最快的 API 接入、性价比最高的单机异构推理、以及真正意义上的多卡生产服务。绝大多数团队会先从 API 开始跑通业务逻辑再因为数据合规、调用成本或者并发压力把模型挪到自己的 GPU 上。这篇教程就沿着这条路一步步走覆盖我实际踩过的坑包括模型名配置错误、异构卡间通信失败、生产环境网关转发超时等能帮你省下至少两三天的排查时间。内容对三类读者最有用刚接触大模型部署、手里有几张卡但不知道怎么规划的新手有 API 调用经验、正打算把业务迁到私有化部署的工程师以及需要在多卡环境里做性能评估和容量规划的运维同学。下面直接开整。1. 部署路线怎么选先看场景再选方案1.1 三条路线分别解决什么问题GLM-5.3-Flash 最大的特点是“一条模型多条出路”官方开放平台可以直接调用社区也放出了开源权重。但很多人在这一步就开始纠结到底是调 API 还是自己部署我的建议是别凭感觉选先拿场景做匹配。API 接入适合业务还没定型、需要快速验证效果的阶段。你不需要管 GPU、驱动、显存只要有一个 Key 就能在十分钟内把模型接进代码。代价是单次调用计费、有并发上限、请求会出内网数据敏感的场景直接排除。单机异构部署适合预算有限但有存量 GPU 的团队。比如手里有两张 A100、四张 4090放在一台机器上想把这 6 张卡都用起来。这个场景最考验部署经验因为不同型号的卡混在一起处理不好性能还不如只开两张卡。多卡生产服务适合模型已经进入核心业务流程、需要稳定高并发响应的团队。这时候不是“能跑”就行而是要解决多副本负载、健康检查、扩容缩容、监控告警这一整套生产问题。我见过最典型的反面案例是API 还没跑通就先把 8 张卡买回来照着网上教程部署结果卡在驱动和框架版本上整整一周。正确顺序永远是 API 验证逻辑、单机验证性能、多卡验证容量层层递进。1.2 为什么我不建议“一步到位”上多卡“一步到位”的诱惑很大尤其当你看到别人晒出 8 卡并行的吞吐数据时。但多卡部署的复杂度是成倍增长的不是线性增长。单机单卡只需要管显存够不够单机多卡开始要管卡间通信拓扑多机多卡还要再加一层网络延迟和集群调度的问题。一个很现实的理由是排障范围。单卡部署出了问题99% 是权重路径、量化格式、显存这老三样多机多卡出现问题可能是 NCCL 超时、可能是 Ray 集群某个节点掉了、也可能是防火墙拦了通信端口排查面完全不在一个量级。我自己在写这篇教程前特意把三种形态都重新跑了一遍就是因为不同形态之间的问题其实很难互相覆盖。1.3 先分清开源权重和 API 的差异GLM-5.3-Flash 的开源权重和 API 是两个独立通道模型能力基本对齐但使用方式差别很大。API 通道有 glm-5.3-flash 和 glm-5.3-flash-1m 两个模型名后者支持百万级上下文窗口适合超长文档解析场景。开源权重则不具备这个“自动扩窗”能力你能用的上下文长度由部署时的 max-model-len 参数决定受显存约束。另一个差异在成本结构上。API 是“用多少付多少”适合低频或波动大、内网出得去的业务本地部署是“先砸硬件再摊薄”只有当请求量足够大、或对延迟和隐私有硬性要求时才划算。另外如果你打算商用务必先看权重仓库里的 LICENSE 和官方商用条款别等上线了才发现授权不允许这是很多人忽略的第一步。2. API 接入实操从 Key 申请到生产级调用2.1 申请 Key并且一定确认“模型名归谁管”第一个步骤没有任何技术含量去智谱开放平台注册账号创建一个 API Key保存下来。但这里有个特别容易翻车的细节——模型名不是通用的它是跟着网关走的。你的请求发到哪个平台就要用哪个平台注册的模型名。比如你用某个云厂商的 OpenAI 兼容端点或第三方聚合网关它的底层只认识它自己在平台上注册的那几个名字。网上有兄弟在 DeepSeek 的兼容端点上填了 glm-5.3-flash结果报错提示 the supported api model names are deepseek-v4-pro, deepseek-v4-flash, and so on这就是典型的模型名归属搞错了。你在 A 平台填 B 平台的模型名服务端根本没有这个模型自然报 model not exist。用官方端点就没有这个问题。智谱的 OpenAI 兼容地址是https://open.bigmodel.cn/api/paas/v4/在官方平台创建的 Key 可以直接用。先把环境变量准备好export ZHIPU_API_KEY你的 Key2.2 用 OpenAI SDK 完成第一次调用GLM-5.3-Flash 的接口兼容 OpenAI Chat Completions 协议所以不需要额外的专用 SDK直接装 openai 包就行。很多框架已经内置了 OpenAI 兼容调用能力这意味着你之前怎么写 GPT 或 DeepSeek现在就怎么写 GLM。pip install openaiimport os from openai import OpenAI client OpenAI( api_keyos.environ[ZHIPU_API_KEY], base_urlhttps://open.bigmodel.cn/api/paas/v4/, ) resp client.chat.completions.create( modelglm-5.3-flash, messages[ {role: system, content: 你是严谨的运维助手。}, {role: user, content: 用三句话总结这段部署日志里的问题。}, ], temperature0.3, max_tokens2048, streamTrue, ) for chunk in resp: if chunk.choices and chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)streamTrue 是必须养成的习惯。大模型接口即使是在内网非流式也要等全部 token 生成完才返回一个 500 token 的回答可能让你等十几秒体验很差。流式模式下首字返回快用户能立刻看到内容在滚动业务侧的“感觉延迟”会大幅下降。2.3 thinking_budget 和 max_tokens别把扩展参数塞错位置如果 GLM-5.3-Flash 接了思考能力reasoning modeOpenAI 原生参数里并没有“思考预算”这个字段它属于平台扩展字段。常见报错是api error: 400 the thinking_budget parameter must be a positive integer这个报错的原因通常是三种传了 0 或负数、传了字符串或小数、放在了 messages 之外不正确的顶层字段。如果你的实现希望开启思考模式需要把它放到扩展字段或对应 SDK 的 extra 参数里而且必须是正整数。例如resp client.chat.completions.create( modelglm-5.3-flash, messages[ {role: user, content: 分析这份 Trace 日志的耗时瓶颈} ], extra_body{thinking_budget: 2048}, max_tokens4096, )我自己的经验是并不是所有任务都需要思考模式。像简单的关键词抽取、格式转换、意图分类这类任务关掉思考能省一半 token延迟也低很多。只有需要推理、排障、多步规划时才值得打开。产品上线前最好用代表性样本做一次对比不要想当然。这里还要提一个容易和 max_tokens 混淆的点max_tokens 限制的是最终回复的长度如果你同时开了思考模式思考内容也会占用 token 配额。如果你的回复经常被截断检查一下是不是思考 token 把预算吃光了。2.4 生产级调用超时、重试和 503 的处理姿势API 调用进入生产环境后最常遇到的就是限流和服务过载。GLM-5.3-Flash 本身定位是高吞吐低延迟但任何公共 API 在高峰期都可能出现下面这种报错api error: 503 server overloaded. this is a server-side issue, usually temporary503 是服务端过载的明确信号不是你的参数问题。健康的重试策略应该是指数退避加抖动第一次重试等 1 秒第二次等 2 秒第三次等 4 秒每次加上随机偏移避免所有请求像约好了一样同时撞上去。OpenAI SDK 内置了重试机制可以在初始化时直接控制client OpenAI( api_keyos.environ[ZHIPU_API_KEY], base_urlhttps://open.bigmodel.cn/api/paas/v4/, timeout60.0, # 单次请求总超时 max_retries3, # 自动处理连接错误和 5xx )另外团队内部一定要限制并发。很多“被限流”其实是自己客户端写了个 for 循环几百个线程同时打 API打到限流阈值后开始连环 429。靠谱的做法是在后端统一维护一个并发池或令牌桶控制峰值速率。这一层不做换什么模型都会出事。2.5 把 GLM-5.3-Flash 接进 Codex CLI 这类工具的通用思路现在很多开发工具都支持自定义模型端点比如有人问怎么在 Codex 里配置 glm-5.3-flash。原理很简单这些工具内部都是 OpenAI 兼容客户端只需要你告诉它三件事——模型名、API 地址、API Key。以 Codex CLI 为例核心配置无非是下面这些字段的变体{ model: glm-5.3-flash, base_url: https://open.bigmodel.cn/api/paas/v4/, api_key: 你的 Key }不同工具的配置存放位置不同有的是配置文件有的是环境变量比如常见的 OPENAI_BASE_URL 和 OPENAI_API_KEY但“模型名 地址 Key”这个三元组是通用的。如果你在一个工具里填了模型名却报“model not exist”第一反应不应该是怀疑模型下架了而是检查这个工具走的是不是官方地址。很多人把工具默认地址指向某个海外服务商然后在那个服务商的模型列表里找 GLM那当然找不到。3. 单机异构部署把不同型号的 GPU 放在同一台机器里3.1 异构部署的第一原则别在不同型号的卡之间做张量并行先解释一下“单机异构”是什么意思。就是一台物理机上插了不同型号甚至不同架构的 GPU比如 2 张 A100 80G 加 4 张 RTX 4090 24G。这种配置在现实中非常常见因为 AI 显卡太贵很多团队是分期分批采购最后凑成一台“全家桶”。很多人第一次上手就会犯一个原则性错误把 6 张卡用 --tensor-parallel-size 6 直接捆成一个实例。原理上讲不通——张量并行在每一层计算时都要做卡间通信它默认所有卡的计算能力、显存、通信带宽是等价的。A100 和 4090 连架构世代都不同硬绑在一起通信要等最慢的那张卡更麻烦的是通信还依赖于卡间高速互联A100 之间走 NVLink4090 走 PCIe跨卡通信带宽差了一个数量级。用一个生活化类比解释张量并行就像四个人划一条龙舟要求四人的力量和节奏基本一致桨绑在同一根横杆上。现在你让一个专业运动员和三个业余爱好者共用一根桨结果不是整体变快而是整体被拖慢专业运动员的力气全浪费在“等”上面了。实际操作中vLLM 在检测到不同 GPU 计算能力时通常会直接报错或拒绝启动。即便有些场景能强行跑起来吞吐也会让你怀疑人生。异构卡的正确打开方式不是“物理绑定”而是“逻辑分组”。3.2 查看硬件拓扑分配卡组动手之前先摸清家底。用下面几个命令确认每张卡的型号、显存、驱动状态和卡间拓扑nvidia-smi nvidia-smi topo -mnvidia-smi 看的是每张卡的利用率、显存占用和驱动版本nvidia-smi topo -m 看的是卡间通信路径NVLink 连接的卡之间会有 NV 标记纯 PCIe 连接则显示 PIX 或 PXB。这张拓扑图直接决定了你能做什么规模的并行。拿到拓扑后再分组同一型号、有 NVLink 互联的卡分到一组组内可以做张量并行型号不同或只有 PCIe 互联的卡之间不要强行做张量并行而是各自起服务实例用上层路由把流量分开。以“2×A100 80G 4×RTX 4090 24G”为例我的分法是A100 组一个实例负责长上下文、高并发、复杂任务4090 组一个实例负责短上下文、低延迟、简单任务。两组对外暴露不同的模型名由上层网关按业务场景分流。3.3 软硬件环境准备这一步最容易翻车异构部署的环境问题比配置还多。驱动版本、CUDA 版本、容器工具链任何一个不匹配都可能让你在第一步就卡住。先确认宿主机驱动。4090 和 A100 虽然架构不同但同一个 NVIDIA 驱动可以同时支持两者只要驱动版本新于两者中较老型号的最低要求即可一般建议装当前较新的稳定分支驱动。装完以后用 nvidia-smi 确认两张卡都能被识别。容器环境建议直接用官方推理镜像不要自己从零搭 CUDA 环境。vLLM 官方镜像已经编译好对应版本的 CUDA kernel比自己手搓省心得多。如果是 Docker 环境还需要先装好 nvidia-container-toolkit并在启动时加上 GPU 参数。很多人第一次跑容器会碰见这个报错permission denied while trying to connect to the docker api at unix:///var/run/docker.sock原因几乎都是当前用户不在 docker 用户组里。解决方式是把用户加进 docker 组然后重新登录会话sudo usermod -aG docker $USER newgrp docker还有一类人是在 Windows 上用 Docker Desktop报错形态变成failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen这通常是 Docker Desktop 的 Linux 引擎没启动或者当前上下文还停在 Windows 容器模式。到 Docker Desktop 设置里把引擎切到 Linux containers等右下角图标变绿再重试就行。3.4 显存账要算清楚权重、KV cache 和余量启动 vLLM 之前必须算清楚显存分配否则不是 OOM 就是上下文长度不够。先看公式单卡可分配显存 单卡显存总量 × gpu_memory_utilization 每卡模型权重占用 ≈ 模型权重总大小 / tensor_parallel_size KV cache 可用显存 ≈ 单卡可分配显存 - 每卡权重占用 - 预留余量(1~2GB)权重总大小取决于模型参数量和精度。bf16 精度下每 10 亿参数大约占 2GB 显存如果是 4bit 量化每 10 亿参数大约占 GLM-5.3-Flash部署实战：API接入、单机异构与多卡生产
GLM-5.3-Flash 这名字刚出来的时候我其实没太当回事——Flash 后缀这些年见多了无非是快一点、便宜一点的 API 版本。直到我同时接到两个正经需求一个要把这个模型接进公司内部的 Agent 平台另一个要把开源权重部署到我们那批“东拼西凑”的 GPU 机器上我才意识到这个模型的部署路径比想象中更有讲究。先说结论GLM-5.3-Flash 是一条典型的三段式部署路径——最快的 API 接入、性价比最高的单机异构推理、以及真正意义上的多卡生产服务。绝大多数团队会先从 API 开始跑通业务逻辑再因为数据合规、调用成本或者并发压力把模型挪到自己的 GPU 上。这篇教程就沿着这条路一步步走覆盖我实际踩过的坑包括模型名配置错误、异构卡间通信失败、生产环境网关转发超时等能帮你省下至少两三天的排查时间。内容对三类读者最有用刚接触大模型部署、手里有几张卡但不知道怎么规划的新手有 API 调用经验、正打算把业务迁到私有化部署的工程师以及需要在多卡环境里做性能评估和容量规划的运维同学。下面直接开整。1. 部署路线怎么选先看场景再选方案1.1 三条路线分别解决什么问题GLM-5.3-Flash 最大的特点是“一条模型多条出路”官方开放平台可以直接调用社区也放出了开源权重。但很多人在这一步就开始纠结到底是调 API 还是自己部署我的建议是别凭感觉选先拿场景做匹配。API 接入适合业务还没定型、需要快速验证效果的阶段。你不需要管 GPU、驱动、显存只要有一个 Key 就能在十分钟内把模型接进代码。代价是单次调用计费、有并发上限、请求会出内网数据敏感的场景直接排除。单机异构部署适合预算有限但有存量 GPU 的团队。比如手里有两张 A100、四张 4090放在一台机器上想把这 6 张卡都用起来。这个场景最考验部署经验因为不同型号的卡混在一起处理不好性能还不如只开两张卡。多卡生产服务适合模型已经进入核心业务流程、需要稳定高并发响应的团队。这时候不是“能跑”就行而是要解决多副本负载、健康检查、扩容缩容、监控告警这一整套生产问题。我见过最典型的反面案例是API 还没跑通就先把 8 张卡买回来照着网上教程部署结果卡在驱动和框架版本上整整一周。正确顺序永远是 API 验证逻辑、单机验证性能、多卡验证容量层层递进。1.2 为什么我不建议“一步到位”上多卡“一步到位”的诱惑很大尤其当你看到别人晒出 8 卡并行的吞吐数据时。但多卡部署的复杂度是成倍增长的不是线性增长。单机单卡只需要管显存够不够单机多卡开始要管卡间通信拓扑多机多卡还要再加一层网络延迟和集群调度的问题。一个很现实的理由是排障范围。单卡部署出了问题99% 是权重路径、量化格式、显存这老三样多机多卡出现问题可能是 NCCL 超时、可能是 Ray 集群某个节点掉了、也可能是防火墙拦了通信端口排查面完全不在一个量级。我自己在写这篇教程前特意把三种形态都重新跑了一遍就是因为不同形态之间的问题其实很难互相覆盖。1.3 先分清开源权重和 API 的差异GLM-5.3-Flash 的开源权重和 API 是两个独立通道模型能力基本对齐但使用方式差别很大。API 通道有 glm-5.3-flash 和 glm-5.3-flash-1m 两个模型名后者支持百万级上下文窗口适合超长文档解析场景。开源权重则不具备这个“自动扩窗”能力你能用的上下文长度由部署时的 max-model-len 参数决定受显存约束。另一个差异在成本结构上。API 是“用多少付多少”适合低频或波动大、内网出得去的业务本地部署是“先砸硬件再摊薄”只有当请求量足够大、或对延迟和隐私有硬性要求时才划算。另外如果你打算商用务必先看权重仓库里的 LICENSE 和官方商用条款别等上线了才发现授权不允许这是很多人忽略的第一步。2. API 接入实操从 Key 申请到生产级调用2.1 申请 Key并且一定确认“模型名归谁管”第一个步骤没有任何技术含量去智谱开放平台注册账号创建一个 API Key保存下来。但这里有个特别容易翻车的细节——模型名不是通用的它是跟着网关走的。你的请求发到哪个平台就要用哪个平台注册的模型名。比如你用某个云厂商的 OpenAI 兼容端点或第三方聚合网关它的底层只认识它自己在平台上注册的那几个名字。网上有兄弟在 DeepSeek 的兼容端点上填了 glm-5.3-flash结果报错提示 the supported api model names are deepseek-v4-pro, deepseek-v4-flash, and so on这就是典型的模型名归属搞错了。你在 A 平台填 B 平台的模型名服务端根本没有这个模型自然报 model not exist。用官方端点就没有这个问题。智谱的 OpenAI 兼容地址是https://open.bigmodel.cn/api/paas/v4/在官方平台创建的 Key 可以直接用。先把环境变量准备好export ZHIPU_API_KEY你的 Key2.2 用 OpenAI SDK 完成第一次调用GLM-5.3-Flash 的接口兼容 OpenAI Chat Completions 协议所以不需要额外的专用 SDK直接装 openai 包就行。很多框架已经内置了 OpenAI 兼容调用能力这意味着你之前怎么写 GPT 或 DeepSeek现在就怎么写 GLM。pip install openaiimport os from openai import OpenAI client OpenAI( api_keyos.environ[ZHIPU_API_KEY], base_urlhttps://open.bigmodel.cn/api/paas/v4/, ) resp client.chat.completions.create( modelglm-5.3-flash, messages[ {role: system, content: 你是严谨的运维助手。}, {role: user, content: 用三句话总结这段部署日志里的问题。}, ], temperature0.3, max_tokens2048, streamTrue, ) for chunk in resp: if chunk.choices and chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end)streamTrue 是必须养成的习惯。大模型接口即使是在内网非流式也要等全部 token 生成完才返回一个 500 token 的回答可能让你等十几秒体验很差。流式模式下首字返回快用户能立刻看到内容在滚动业务侧的“感觉延迟”会大幅下降。2.3 thinking_budget 和 max_tokens别把扩展参数塞错位置如果 GLM-5.3-Flash 接了思考能力reasoning modeOpenAI 原生参数里并没有“思考预算”这个字段它属于平台扩展字段。常见报错是api error: 400 the thinking_budget parameter must be a positive integer这个报错的原因通常是三种传了 0 或负数、传了字符串或小数、放在了 messages 之外不正确的顶层字段。如果你的实现希望开启思考模式需要把它放到扩展字段或对应 SDK 的 extra 参数里而且必须是正整数。例如resp client.chat.completions.create( modelglm-5.3-flash, messages[ {role: user, content: 分析这份 Trace 日志的耗时瓶颈} ], extra_body{thinking_budget: 2048}, max_tokens4096, )我自己的经验是并不是所有任务都需要思考模式。像简单的关键词抽取、格式转换、意图分类这类任务关掉思考能省一半 token延迟也低很多。只有需要推理、排障、多步规划时才值得打开。产品上线前最好用代表性样本做一次对比不要想当然。这里还要提一个容易和 max_tokens 混淆的点max_tokens 限制的是最终回复的长度如果你同时开了思考模式思考内容也会占用 token 配额。如果你的回复经常被截断检查一下是不是思考 token 把预算吃光了。2.4 生产级调用超时、重试和 503 的处理姿势API 调用进入生产环境后最常遇到的就是限流和服务过载。GLM-5.3-Flash 本身定位是高吞吐低延迟但任何公共 API 在高峰期都可能出现下面这种报错api error: 503 server overloaded. this is a server-side issue, usually temporary503 是服务端过载的明确信号不是你的参数问题。健康的重试策略应该是指数退避加抖动第一次重试等 1 秒第二次等 2 秒第三次等 4 秒每次加上随机偏移避免所有请求像约好了一样同时撞上去。OpenAI SDK 内置了重试机制可以在初始化时直接控制client OpenAI( api_keyos.environ[ZHIPU_API_KEY], base_urlhttps://open.bigmodel.cn/api/paas/v4/, timeout60.0, # 单次请求总超时 max_retries3, # 自动处理连接错误和 5xx )另外团队内部一定要限制并发。很多“被限流”其实是自己客户端写了个 for 循环几百个线程同时打 API打到限流阈值后开始连环 429。靠谱的做法是在后端统一维护一个并发池或令牌桶控制峰值速率。这一层不做换什么模型都会出事。2.5 把 GLM-5.3-Flash 接进 Codex CLI 这类工具的通用思路现在很多开发工具都支持自定义模型端点比如有人问怎么在 Codex 里配置 glm-5.3-flash。原理很简单这些工具内部都是 OpenAI 兼容客户端只需要你告诉它三件事——模型名、API 地址、API Key。以 Codex CLI 为例核心配置无非是下面这些字段的变体{ model: glm-5.3-flash, base_url: https://open.bigmodel.cn/api/paas/v4/, api_key: 你的 Key }不同工具的配置存放位置不同有的是配置文件有的是环境变量比如常见的 OPENAI_BASE_URL 和 OPENAI_API_KEY但“模型名 地址 Key”这个三元组是通用的。如果你在一个工具里填了模型名却报“model not exist”第一反应不应该是怀疑模型下架了而是检查这个工具走的是不是官方地址。很多人把工具默认地址指向某个海外服务商然后在那个服务商的模型列表里找 GLM那当然找不到。3. 单机异构部署把不同型号的 GPU 放在同一台机器里3.1 异构部署的第一原则别在不同型号的卡之间做张量并行先解释一下“单机异构”是什么意思。就是一台物理机上插了不同型号甚至不同架构的 GPU比如 2 张 A100 80G 加 4 张 RTX 4090 24G。这种配置在现实中非常常见因为 AI 显卡太贵很多团队是分期分批采购最后凑成一台“全家桶”。很多人第一次上手就会犯一个原则性错误把 6 张卡用 --tensor-parallel-size 6 直接捆成一个实例。原理上讲不通——张量并行在每一层计算时都要做卡间通信它默认所有卡的计算能力、显存、通信带宽是等价的。A100 和 4090 连架构世代都不同硬绑在一起通信要等最慢的那张卡更麻烦的是通信还依赖于卡间高速互联A100 之间走 NVLink4090 走 PCIe跨卡通信带宽差了一个数量级。用一个生活化类比解释张量并行就像四个人划一条龙舟要求四人的力量和节奏基本一致桨绑在同一根横杆上。现在你让一个专业运动员和三个业余爱好者共用一根桨结果不是整体变快而是整体被拖慢专业运动员的力气全浪费在“等”上面了。实际操作中vLLM 在检测到不同 GPU 计算能力时通常会直接报错或拒绝启动。即便有些场景能强行跑起来吞吐也会让你怀疑人生。异构卡的正确打开方式不是“物理绑定”而是“逻辑分组”。3.2 查看硬件拓扑分配卡组动手之前先摸清家底。用下面几个命令确认每张卡的型号、显存、驱动状态和卡间拓扑nvidia-smi nvidia-smi topo -mnvidia-smi 看的是每张卡的利用率、显存占用和驱动版本nvidia-smi topo -m 看的是卡间通信路径NVLink 连接的卡之间会有 NV 标记纯 PCIe 连接则显示 PIX 或 PXB。这张拓扑图直接决定了你能做什么规模的并行。拿到拓扑后再分组同一型号、有 NVLink 互联的卡分到一组组内可以做张量并行型号不同或只有 PCIe 互联的卡之间不要强行做张量并行而是各自起服务实例用上层路由把流量分开。以“2×A100 80G 4×RTX 4090 24G”为例我的分法是A100 组一个实例负责长上下文、高并发、复杂任务4090 组一个实例负责短上下文、低延迟、简单任务。两组对外暴露不同的模型名由上层网关按业务场景分流。3.3 软硬件环境准备这一步最容易翻车异构部署的环境问题比配置还多。驱动版本、CUDA 版本、容器工具链任何一个不匹配都可能让你在第一步就卡住。先确认宿主机驱动。4090 和 A100 虽然架构不同但同一个 NVIDIA 驱动可以同时支持两者只要驱动版本新于两者中较老型号的最低要求即可一般建议装当前较新的稳定分支驱动。装完以后用 nvidia-smi 确认两张卡都能被识别。容器环境建议直接用官方推理镜像不要自己从零搭 CUDA 环境。vLLM 官方镜像已经编译好对应版本的 CUDA kernel比自己手搓省心得多。如果是 Docker 环境还需要先装好 nvidia-container-toolkit并在启动时加上 GPU 参数。很多人第一次跑容器会碰见这个报错permission denied while trying to connect to the docker api at unix:///var/run/docker.sock原因几乎都是当前用户不在 docker 用户组里。解决方式是把用户加进 docker 组然后重新登录会话sudo usermod -aG docker $USER newgrp docker还有一类人是在 Windows 上用 Docker Desktop报错形态变成failed to connect to the docker api at npipe:////./pipe/dockerdesktoplinuxen这通常是 Docker Desktop 的 Linux 引擎没启动或者当前上下文还停在 Windows 容器模式。到 Docker Desktop 设置里把引擎切到 Linux containers等右下角图标变绿再重试就行。3.4 显存账要算清楚权重、KV cache 和余量启动 vLLM 之前必须算清楚显存分配否则不是 OOM 就是上下文长度不够。先看公式单卡可分配显存 单卡显存总量 × gpu_memory_utilization 每卡模型权重占用 ≈ 模型权重总大小 / tensor_parallel_size KV cache 可用显存 ≈ 单卡可分配显存 - 每卡权重占用 - 预留余量(1~2GB)权重总大小取决于模型参数量和精度。bf16 精度下每 10 亿参数大约占 2GB 显存如果是 4bit 量化每 10 亿参数大约占