实际上，我在过去一周多数次说到了Deepseek模型推理的问题。无论是部署的高门槛，“便宜”的错觉，还是效率。
这些分别在：
本地部署大模型，从开始到放弃只需一周
模型推理性能优化并不简单
Deepseek研究（2）：少数派报告
但是，突然同一天被问到了好几次同样的问题，所以，还是回答一下吧。
在大家已经都搞清楚了“蒸馏版”和原生版和满血版的区别后，满血的门槛就是变得很直接：671GB（模型文件大小）/80GB（GPU显存大小）=8.4。特别尴尬的数字，八块H100不够。所以最低配置就是一台八卡服务器+一台四卡服务器。一般就是两台八卡服务器了。
一个技术人员会说的问题：可以在四卡或者Mac Studio集群上部署“量化”版本，但是并发不行，得一个个排队。上两台服务器，装“满血版”就可以支持高并发了。然后，一直运行的服务器很容易当机，再配两台“热备份”就可以确保不影响业务了。
技术上，完全正确。
首先，先说“量化版本”和“满血版本”的区别：
1、“量化版本”模型文件较小，因为表达每个参数的精度比较低，比如4bit，就是用4位整型来表达每个参数（就是671B参数里的参数），而DeepSeek-R1（其实是底层V3）是bf8的，就是8位表达每个浮点参数。损失精度，但是占用资源的大小就是一半。目前，还有一种动态量化版本可以做到1.58bit，基本就是五分之一的大小了，四张H100可以应对；
2、量化的优点是，需要资源少，推理速度快，缺点就是精度下降，导致输出质量下降（其实绝大多数场景没太大问题，但是如果对话长度过长就容易导致幻觉率大幅提升，精度不够用了呗）；
3、量化版本在DeepSeek模型里还有一个更大的缺点，因为模型本身是MoE的（每个专家模型37B，然后一共24个），在“满血版”的推理优化里可以把24个专家模型分配到不同的GPU上，使得不同GPU负载相对均衡，提升并发输出，而量化后失去了MoE灵活部署的巨大优势。同时，因为量化某种程度上等于压缩，所以模型在运行时需要更大的计算量，导致了KV-Cache更多的占用，运行时实际需要的显存会显著大于模型文件大小，同时并发较多时，缓存占用也会大幅提升；
其次，来说并发问题，并发如何实现的？
如果只部署一个模型（前端没有负载均衡）的话，并发实现就是两种方式：
1、命中缓存，不需要再推理，直接从内存里读结果；
2、因为模型不同层是部署在不同的GPU或者设备上的，对于勉强部署一个模型的多卡而言，每块卡同一时间只能跑一个请求，但是四卡在最好的情况下就可以同时跑四个请求（恰好四个请求在计算的时候每次调用的层都在不同的GPU上）；
所以，严格意义上讲，卡的数量是能够同时应对并发量的理论上限。
在两台以上服务器部署“满血版”时，MoE附带一个好处，就是因为其实每次推理都是调用了一个37B的专家模型而已，能够支持的并发量就大幅增加了。但是这只针对V3而言，R1的情况就会复杂不少。
我想这大概也是Deepseek官方给出了V2的推理性能优化结果，但是并没有给V3 and R1的原因：首先V3必定要部署在多台机器上，瓶颈从内存带宽到了网络带宽，性能的优化也不再是单节点了，甚至可能需要一个集群整体做负载均衡；其次，R1的思考过程带来的专家模型的命中情况和routing可能DS自己都还需要不断的优化，github上有几个专门的issue讨论这些问题。
推理性能是个很复杂的问题，如果只够跑一个模型的资源，哪怕是四台8*H100的服务器，可能对于并发性能也不能有太乐观的预期，目前最快的应该是SGLang，但是性能优化还在不断的进行中。
SGLang部署Deepseek方法
https://github.com/sgl-project/sglang/tree/main/benchmark/deepseek_v3
作为兴趣研究，可以不断跟着上面的进度，跟大家讨论优化方法，作为企业部署，特别是上了服务器后……
到这里，我们基本可以得出两个结论了：
1、怎么算，提供“满血版”的模型在线推理服务都是亏钱的，那就意味着，只要不是敏感数据，就一定要“薅羊毛”；
2、本地部署，还有个天坑是“联网搜索功能”，所以，首先要优化的是业务流程，哪些联网“薅羊毛”，哪些本地批处理；
对了，还有一个结论，没有超大集群，没有强大生态支持，云的MaaS服务也没戏，做得越好，客户越多，亏的越多，“死”的越快。商业模式，是基本没有的。
时钟重回两年前，为什么要有生态的云？