八卡机器刚买回来的时候，团队所有人都觉得自己随时可以拉起来跑模型。 大概第三天矛盾就开始了：有人占着四张卡跑微调任务不肯放，线上推理服务排队卡着上不去；还有同事启动容器直接爆显存，折腾半天才发现资源没规划。

本质不是同事之间不配合，是 GPU 资源的分配规则没提前定好。 CPU 服务器我们很习惯超卖，48 核分给上百个进程，感知不强；但 GPU 显存是硬资源，没有超售空间。同样一台机器，256GB 显存分给 10 个人，分配策略错一步，就会出现排队、OOM。

这篇文章就聊聊，我们在这台 8 卡 5090 上跑出来、可以直接落地的显存分配思路。

为什么八卡 5090 特别容易出现资源冲突？

先把硬件事实说清楚：单卡 32GB，8 张卡加起来 256GB，但它不是一块连续的 256GB 显存池，是 8 个独立的 32GB 显存池子。 想要把一个大模型拆到多张卡上跑张量并行，卡之间的数据交换只能走 PCIe 5.0。它不像 A/H 系列数据中心卡有 NVLink，跨卡通信的延迟和带宽差距非常明显，直接带来两个限制：

1. 张量并行规模越大，通信开销越高。拿 TP8 去跑一个小模型，并行带来的收益，很可能全部被 PCIe 通信吃掉；
2. 卡要成组使用，张量并行一般优先选择 2 的幂次，8 张卡只能拆成 8×1、4×2、2×4、1×8 这类组合，没法简单拆成 3+5 这种零散分组。

理解这点之后，能选的分配方案其实就清晰了。

一台八卡机，四种可用的分配模式

我们内部归纳了四种落地方式，怎么选，核心看你们团队是 “人多、任务杂、以小模型实验为主”，还是 “任务很重、少数大模型推理服务为主”。

我们自己团队长期在用的，就是最后这种混合方案：固定 4 张卡组成 TP4，专门跑对外的推理服务；剩下 4 张单卡开放给算法同学做实验、调模型。线上服务优先级最高，不会被临时实验任务挤垮，同时大家也有卡可以调试。

这里要划重点：消费版 5090没有 MIG 硬件切分能力，不能像专业卡那样，把一张卡切成两个硬件隔离的小 GPU。 如果要在同一张卡跑多个推理进程，只能用多推理服务共享或者 MPS。但 MPS 没有硬件显存隔离，显存泄漏很容易连带所有进程一起挂，生产推理服务我们不推荐这么干。

分配前，必须算清楚三笔显存账

很多人规划资源只看模型权重大小，上线之后一涨并发直接炸。显存占用一共三块：模型权重、KV Cache、运行时框架开销。其中 KV Cache 是变量最大的部分，直接决定你能承载多少并发。

1. 模型权重：70B 模型，FP16 大概 140GB，FP8 量化约 70GB，INT4 量化大概 35GB。这个是基础底。
2. KV Cache：这个是最容易踩坑的。它跟着上下文长度、并发请求数量线性上涨。同样 70B 模型，32K 上下文 50 并发，和 8K 上下文 200 并发，KV Cache 占用差距巨大。很多时候权重看着还剩很多，一上并发就 OOM，问题基本都在这里。
3. 运行预留开销：CUDA 上下文、框架缓冲区、通信缓存，我们一般习惯预留当前分组显存总量的 10%~15%。

所以我们内部提资源申请，不允许只说 “我要两张卡”，标准格式是：跑 XX 模型、上下文长度 XX、预期并发 XX。拿到这个参数，才可以评估显存够不够。

团队协作：三条硬规则，避免天天吵架

调度方案只是技术底座，没有使用规则，一周就乱掉。我们落地了三条简单但管用的制度：

1. 显存 / 卡资源记账：给项目分配固定卡资源和使用时段。比如算法业务组白天 9 点 - 19 点占用 4 卡 TP4 做线上推理；夜间没人访问的时候，释放出来给微调任务跑。看着土，但是十几个人共用一台机器，这是最稳定的办法。
2. 任务优先级固定：在线推理服务 > 批量离线推理 > 模型微调 > 个人调试实验。微调任务默认安排在夜间、周末错峰跑，避免白天把线上推理的延迟打高。
3. 容器环境隔离：整机驱动只有一套，但是不同项目依赖的 CUDA、推理框架版本不一样，全部用容器隔离。同时一定要设置NVIDIA_VISIBLE_DEVICES，只把分配给这个任务的显卡暴露进去。

最恐怖的坑就是：容器能看见全部 8 张卡，一条脚本直接占满整机显存，前面的配额全部作废。

怎么判断当前分配方案合不合理？五条观测阈值

我们会定期看监控看板，用这几个指标判断要不要调整调度策略：

1. GPU 卡时利用率：长期低于 30%，说明资源拆得太碎，或者任务很少，可以考虑合并分组；稳定高于 85%，并且任务排队越来越多，说明算力不够，该加机器或者优化推理量化方案。
2. 任务排队时长：平均排队超过 30 分钟，研发同学的体验会明显变差。
3. 显存水位：单卡显存长期跑到 90% 以上，属于高危水位，新请求进来极易 OOM，至少留 10% 余量。
4. 张量并行通信占比：如果 TP 组里面，通信耗时占总耗时超过 25%，说明 TP 开太大了，要么缩小并行规模，要么换单卡更大或者带 NVLink 的机型。
5. 故障统计：一个月内，因为显存抢占、资源冲突导致的 OOM 超过 3 次，说明配额规则没有落地执行。

我们踩过的七个高频坑

1. 两个人共用一张卡跑满负载，互相挤压显存，双双 OOM，花很久排查，最后才发现是没有做卡级独占隔离。
2. 微调训练任务和线上推理混跑，训练一启动，推理首字延迟直接抖动，用户投诉。生产池必须固定分卡隔离。
3. 只按模型权重估算显存，完全忽略 KV Cache，上线初期流量低没事，业务量上涨直接崩。
4. TP 参数盲目开大：8 张卡跑一个 8B 小模型，通信开销吃掉大部分算力收益，还不如 TP2 跑。
5. 容器可见显卡没有限制，进程能看到整机所有 GPU，配额形同虚设。
6. 生产推理环境强行上 MPS 共享，显存没有硬隔离，一个内存泄漏直接一锅端，故障排查难度极高。
7. 没有基础监控：不采集显存、卡温、功耗、延迟曲线，出问题只能靠猜，分配方案永远没办法迭代优化。

常见问题整理

Q1：8 卡机器能不能同时跑 8 个独立模型？ A：可以。前提是每个模型量化之后，能塞进单张 32GB 显存，7B~30B 的 INT4/FP8 模型大多满足，一人一卡互不干扰。但 70B 级别就必须张量并行分组，最多只能拆两组 TP4。

Q2：两个人能不能共用一张卡？ A：技术上可以，用 MPS 或者多推理服务实例。工程上我们生产环境不推荐。没有硬件显存边界，一个进程显存泄漏，另外一个跟着挂。稳妥做法是合并到同一个推理服务里面，做租户、模型层面的逻辑隔离。

Q3：5090 无 NVLink，张量并行 TP 开多大最合适？ A：我们实测甜点是 TP2、TP4。TP8 一般只有模型实在塞不下的时候才会启用。PCIe 带宽限制下，并行规模拉太高，通信开销会抵消并行带来的加速收益。

Q4：微调任务和线上推理能不能放同一台机器？ A：可以，但必须分卡隔离，或者严格错峰。混跑会带来延迟抖动、显存抢占。我们的做法就是固定 4 卡给线上生产，剩下 4 张白天实验、夜间跑微调。

Q5：团队成员怎么快速看有没有空闲卡？ A：最简单低成本方案：搭一个简单看板，把每张卡的显存、利用率推到企业微信群里，大家申请资源之前先看状态。如果团队任务量很大，再上一套任务排队调度系统。很多小团队，一张看板就能解决 80% 的冲突。

小结

多人共享 8 卡 5090 服务器，核心共识只有一句：显存是硬上限，不能像 CPU 那样随便超卖。 先根据业务的模型大小、上下文、并发，算出真实显存需求，再选择分组模式，最后靠配额、优先级、容器隔离三条规则兜底。 给十人左右团队一个可以直接抄的起步方案：4 卡 TP4 固定给线上推理，剩下 4 卡单卡轮转给实验，容器限定可见 GPU，微调全部错峰夜间跑。这套方案，只要业务规模不爆发式增长，稳定跑半年没问题。

免责声明：本文为一线团队内部落地经验总结，仅做技术交流。RTX5090 为消费级显卡，无企业级 ECC、NVLink，不具备数据中心卡的原厂 SLA 保障，生产业务上线前务必充分压测评估风险。