前段时间跟多个客户，客户是某金融机构。
他们采购了一台规格不低的一体机，8 卡、总显存 1TB、上一代二线厂商 AI 加速卡。采购时的判断也很自然：32B 模型都能装下了，吞吐应该差不到哪去。
结果很快遇到现实问题。Demo 能跑，单次问答也能出字，但一到真实业务流量，吞吐就是起不来。知识问答一多，审查辅助一上，排队就开始变长。平台团队的困惑很典型：卡看起来不少，显存看起来也够，为什么业务体感还是慢？
这个问题其实很有代表性。
一体机的吞吐，本质上不是"能不能把模型放进去"，而是"能不能把每一个 token 变成稳定、顺滑、低损耗的流水线"。
换个角度看，很多一体机项目卡住的，不是"算力总量"，而是下面这 四层漏斗。
第一层：装得下，不等于跑得快
很多人先看参数量和显存，觉得只要模型能完整放进去，问题就解决了一大半。其实不是。
模型"装进去"，只说明仓库够大；吞吐"跑起来"，还取决于装卸效率、搬运路径和作业节奏。
举个例子，32B 模型能放进 1TB 显存，不代表每一步推理都高效。实际运行时，还会受到这些因素影响：
- 推理引擎是不是成熟，底层算子有没有针对这类卡吃满。
- 精度、量化和缓存策略是不是合适。
- 模型结构和这套硬件、这套软件栈是不是匹配。
所以很多项目表面上是"卡不够强"，本质上是软件栈没有把硬件潜力变成稳定产能。
这就像一家厨房，灶台很多，但备菜、传菜、出餐都不顺，顾客不会因为你后厨面积大，就自动吃得更快。
第二层：多卡，不等于线性叠加
继续追问，为什么 8 张卡也不够？
因为多卡推理不是简单的"8 台机器一起干活"。很多时候，它更像 8 个人协作搬一件大件货物。只要其中几个环节对不上，整体速度就会被最慢的那一步拖住。
尤其是上一代、生态相对弱一些的加速卡，常见问题不是单卡完全不能跑，而是：
- 卡与卡之间协同开销偏大。
- 通信链路和运行时调度不够成熟。
- 多卡拆分后，收益被同步和等待吃掉。
最后就会出现一种很容易误判的现象：看起来总算力很大，但真正能变成业务吞吐的那部分并不高。
这也是为什么很多用户会觉得"一体机参数很好看，真实吞吐却不惊艳"。
第三层：有显存，不等于有并发
一体机吞吐还有一个经常被低估的问题：显存不是只装模型，它还要装上下文和缓存。
如果把模型权重理解成固定货架，那么推理时不断增长的上下文缓存，更像是在仓库里临时堆起来的周转箱。箱子越多，可同时进来的车就越少。
这也是为什么很多项目一旦开始支持长上下文、复杂问答、多用户同时在线，吞吐就迅速掉下来。不是模型突然变慢了，而是：
- 每个请求占用的缓存变大了。
- 能同时排进去的请求数变少了。
- GPU 看似在忙，但整体产出并不高。
PagedAttention 和同类优化之所以重要，本质上不是"炫技"，而是把这类缓存占用整理得更规整，减少内存浪费，把本来装不进来的并发重新装进去。
第四层：上线服务，不是跑一个 benchmark
很多采购和 PoC 阶段看的，是单次速度，或者比较理想的压测曲线。
但企业真正上线后，流量不是整整齐齐来的。
有的请求很短，有的请求很长；有的重在首字快，有的重在总吞吐高；有的还在读长文档，有的已经进入连续出字阶段。这些请求混在一起时，服务调度方式往往比"单卡峰值算力"更决定结果。
真正影响吞吐的，往往是下面几件看起来没那么"硬件味"的事：
- 能不能做连续批处理，而不是凑一整批再发车。
- 能不能把长输入和持续出字更平滑地混合调度。
- 能不能把首字时间和总吞吐分开看，而不是只盯一个指标。
- 能不能在真实线上流量下持续维持稳定，而不是只跑实验室曲线。
所以回到那个金融机构案例，问题并不是"32B 跑不动"，而是32B 在真实服务流量下，没被组织成高吞吐流水线。
为什么 MoE 模型更容易"看着很强，吞吐却不稳"
如果再往前一步，用的是 MoE 模型，这个问题会更明显。
MoE 的直观理解，不是"所有专家一起干活"，而是来了一个请求，先做分诊，再把它送去最合适的几个专家那里处理。
这个机制的好处是，模型总容量可以很大，但每次真正激活的部分没那么大，理论上更省算力。
但问题也跟着来了。
1. 请求不是平均分给所有专家的
现实业务里，用户问题的分布往往很不均匀。
这就像银行里并不是每个窗口人都一样多。总会有几个窗口特别忙，几个窗口比较闲。于是你会看到一种很典型的现象：有些卡很忙，有些卡没那么忙，整体吞吐却被最忙的那几个点卡住。
2. EP 并行，本质上是在把"专家窗口"分开放
很多非专业读者一听 EP 并行会觉得很玄。其实可以把它理解成：
不要让每张卡都摆一小份所有专家，而是把不同专家像不同柜台一样分散开，让请求直接去对应柜台。
这样做的目的很简单：
- 让每个专家拿到更成规模的请求，效率更高。
- 减少重复摆放，给系统留出更多有效空间。
- 让多卡分工更清楚，而不是大家都沾一点，但谁都不饱和。
3. 热门专家要"加窗口"
MoE 模型还有一个很关键、但很容易被忽略的优化方向：热点专家冗余。
还是拿银行打比方。如果你发现企业开户窗口永远排长队，最直接的办法不是要求所有窗口更努力，而是再开几个同类窗口。
MoE 也是一样。对于高负载专家，业界已经有一类成熟思路，就是：
- 在线观察哪些专家最忙。
- 给高负载专家增加副本。
- 周期性调整，让不同卡上的负载尽量均衡。
这件事不解决，MoE 很容易出现"总参数量很漂亮，但线上吞吐忽高忽低"的体验。
4. MoE 更依赖调度，不只是依赖算力
Dense 模型更像一个大厨房，大家围着同一套工序做饭。
MoE 更像一个专科医院。分诊、转诊、排队、热门科室加号，这些组织动作做不好，再好的医生也会被堵在流程里。
所以 MoE 的吞吐优化，往往不是先去追更大的卡，而是先把专家并行、专家负载均衡和热点专家冗余做好。
一体机吞吐上不去，优先看哪几件事
如果你现在就在做一体机选型、验收或者优化，建议按下面这个顺序看。
先看第一件事：目标到底是"演示能跑"，还是"线上能扛"
如果目标只是内部验证、固定人群、固定上下文长度，一体机通常够用。
但如果目标是：
- 多部门共享。
- 线上请求长短不一。
- 对吞吐、稳定性和排队时延都有要求。
那你要看的就不是"模型能不能装下"，而是服务能不能长时间稳定出产能。
再看第二件事：先抢显存空间，再谈并发
很多吞吐问题，第一步不是继续加卡，而是先把显存用法理顺：
- 不要默认给所有业务都开最长上下文。
- 让缓存管理更规整，减少碎片和浪费。
- 用合适的量化和部署方式，把显存从"摆着占位"变成"能换并发"。
第三件事：把服务调度做好
在线推理不是短跑，是流水线。
所以要优先考虑：
- 连续批处理。
- 长输入和持续出字的平滑混排。
- 首字时间和总吞吐的平衡。
- 用真实业务流量做压测，而不是只看理想实验室数据。
第四件事：MoE 要单独设计，不要按 Dense 的思路硬套
如果用的是 MoE 模型，至少要额外检查三件事：
- 专家有没有合理分散，也就是 EP 并行有没有做好。
- 专家负载是不是明显失衡。
- 热点专家有没有做副本或动态调整。
很多 MoE 项目不是败在模型本身，而是败在把"专家路由问题"当成"普通并行问题"处理。
回到最初的问题
为什么大模型一体机吞吐上不去？
因为企业买到的，往往只是一台能放下模型的机器；而真正决定体验的，是显存管理、卡间协同、服务调度和模型路由能不能被组织成一条顺滑流水线。
对 Dense 模型来说，核心是把显存、调度和多卡协同理顺。
对 MoE 模型来说，还要再加一层判断：专家有没有被合理分散，热门专家有没有被及时分流。
回到最初的问题，本质上企业买的不是"更大的参数容量"，而是稳定把 token 变成吞吐的能力。
