一张RTX 5090跑125B编程模型：吞吐瓶颈与调优实录

用一张消费级显卡替代团队按席位订阅的AI编程服务，听起来很诱人。但真正决定体验的，不是跑分，而是「几个人同时用会卡」。本文基于 Strata（一个在消费级显卡上运行 Qwen3.8-Flash-Next 125B MoE 模型的开源引擎）的实测数据，拆解单卡多用户场景下的吞吐规律、两个隐蔽的性能陷阱，以及接入 Claude Code 的实际体验。

先看你会用到的那组数字

测试环境是一张租用的 RTX 5090（32GB 显存），加载 IST Austria DASLab 的 1-bit Coder 量化版本（58.4GB），上下文 256K。

1 个开发者：144 tokens/s，首 token 延迟低于 2 秒
4 人并发：每人 38 tokens/s，合计 125 tokens/s
8 人并发：每人 19 tokens/s，合计 130 tokens/s，首 token 延迟 2 到 8 秒

关键规律是：总吞吐基本不随人数增长，保持平稳。这张卡耗尽的是「并发席位」，而不是「token 产出能力」。理解这一点，才能正确规划团队使用方式。

RTX 5090 单卡运行 125B 编程模型的实测数据

为什么一个人比四个人快那么多

单人使用时，引擎启用了投机解码（speculative decoding）：一个小的草稿模型先猜 4 个 token，大模型一次性验证，实测约四分之三的草稿被接受。这是 144 tokens/s 的重要来源。

但 Strata 在多用户并发时采用并行槽位（parallel slots）机制，这些槽位不使用投机解码，每个 token 逐个生成并输出。于是从 1 人扩展到 4 人，单用户速度从 144 掉到 38，总吞吐也有所下滑——损失比单纯「分卡」要大。

实践结论很直接：如果团队成员的生成请求错峰、很少同时发生，单卡体验相当好；如果全天并行跑多个 agent，请按并发槽位的数字做容量规划，而不是按单人峰值。

投机解码（Speculative Decoding） 是一种加速大模型推理的推测式技术：先用一个参数量小得多的「草稿模型」快速连续猜出若干个 token，再让目标大模型在一次前向计算中并行验证这串草稿。凡是草稿与目标模型输出一致的部分直接被接受，只需从第一个不一致处重新采样。由于验证是并行的，一次大模型前向可产出多个 token，从而突破逐 token 自回归解码的速度上限。其收益取决于「接受率」——草稿越准，加速越明显；本文实测约四分之三的草稿被接受，正是单人 144 tokens/s 的主要来源。代价是需要额外加载草稿模型、占用显存，且在批量并发场景下难以与多请求调度兼得，这也是并行槽位不启用它的原因。

并行槽位（parallel slots） 是推理引擎处理多请求并发的调度方式：把显存中的 KV Cache 划分为若干个固定槽位，每个槽位承载一个独立会话，引擎以连续批处理（continuous batching）的方式把同一时刻各槽位的解码步骤合并成一次批计算。这样做的优点是多人同时使用时显存与算力被稳定共享、总吞吐不会因人数增加而崩塌；缺点是每个槽位走的都是标准的逐 token 解码路径，无法叠加投机解码这类单请求专用的加速手段。因此槽位数直接决定了「同时能服务几个人」，而单槽位速度则随并发数上升而下降——这正是总吞吐平稳、单用户速度骤降现象的机制根源。

那个并非 GPU 造成的 5 倍减速

第一次租用的主机只跑到约 30 tokens/s，而预期是 170 左右。GPU 本身没问题。问题在于容器暴露了宿主机全部 256 个线程，但通过 cgroup 配额把 CPU 限制在约 30 核。Strata 按「可见线程数」配置工作池，worker 空转后被内核节流，CPU 侧的工作（未缓存在显卡上的专家层）成为瓶颈。

在租用容器上做任何基准测试前，先检查：

cat /sys/fs/cgroup/cpu.max

如果显示配额限制，把 --pool-workers 设为允许核数略小的值，生成速度立刻恢复正常。

第二个坑在 8 槽位时出现：默认配置下 VRAM 剩余不足 400MiB，驱动开始对显存分页。加上 --vram-reserve-mib 1536 后问题解决。这两个问题都不是模型或显卡的锅，而是部署参数与运行环境不匹配。

cgroup（control group） 是 Linux 内核用于限制和隔离进程组资源使用的机制，容器（Docker、Kubernetes 等）正是靠它来约束 CPU、内存等配额。这里的关键差异在于：「可见线程数」由宿主机拓扑决定，容器内 nproc 或 /proc/cpuinfo 往往仍显示宿主机的全部核心；而「可用算力」由 cgroup 的 CPU 配额（cpu.max 中的 quota/period 比值）决定。当程序按可见线程数创建大量工作线程、而实际可用的 CPU 时间远小于此，线程会频繁空转后被内核强制节流（throttling），表现为整体性能断崖式下跌。判断方法就是读取 /sys/fs/cgroup/cpu.max：若第一列不是 max，说明存在配额限制，工作池规模应据此而非线程数来设定。

把 Claude Code 指向本地端点

Strata 暴露了 Anthropic 兼容端点，Claude Code 只需配置 base URL 和一个 token：

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export ANTHROPIC_AUTH_TOKEN=local

在单文件任务（一个带自动驾驶模式的贪吃蛇游戏）中，模型一次性写出 408 行代码，并自行修复了一个时序 bug。一个值得注意的怪癖：这类高度量化的模型有时会声称已完成，却没有实际调用 Write 工具。在 prompt 中明确点名 Write 工具后，问题消失。

这些数字的边界

需要如实说明局限：只有一张卡、一个主机、一个单文件任务（而非真实代码仓库）。质量指标 75.6%（SWE-bench Verified）来自模型卡，对比完整模型的 82.8%，并非本文实测。

对考虑用自控 GPU 替代按席位订阅的团队来说，这张卡的真实定位是：单人体验接近商用服务，多人并发则是一道容量算术题。先把 cgroup 配额和显存预留这两个参数调对，再谈性价比。

MoE（Mixture of Experts，混合专家） 架构把前馈层拆成多个「专家」子网络，每个 token 只被路由到其中少数几个专家计算。这使得模型总参数量可以做得很大，而单次推理实际激活的参数量远小于总参数——本文的 125B 模型正是如此，因而能在单张 32GB 消费级显卡上运行。但也带来一个部署特点：未被激活的专家权重仍需驻留显存或可快速换入，当并发槽位增多、KV Cache 挤占显存时，专家层可能被迫放在 CPU 侧计算或触发换页，从而显著拖慢速度。文中提到的 CPU 侧专家层瓶颈与显存分页问题，都与 MoE 的这种「参数总量大、激活量小」的特性直接相关。