欢迎来到我的小铺，今天继续聊本地大模型部署。
硬件有显存、带宽、算力三件套，软件有量化、MoE 这些偷懒办法。但知道这些和真正把模型跑起来，中间还差着部署这一步。
部署不是“下载、安装、运行”三步完事，而是一步一步试出来的——每一步都有可调的参数，每个参数都牵动着前面那些概念，没有一步是“填个正确答案就过”的。
网上那些部署教程，十有八九都停在同一句话上：
“它回你话了，成功！”
但真正部署过的人都知道，那只是起点。你照着教程走完，它确实回你话了，你以为搞定了——然后跑着跑着它崩了，或者两个人同时用就卡住了，或者重启之后就再也起不来。
这些教程没告诉你的部分，才是部署真正的工作量。这一篇，聊聊我在部署初期实际做了哪些事。
一、显存利用率：一个数字，牵动整个停车场
部署引擎开机时，第一个要设的参数叫显存利用率——告诉引擎：这块显存，你最多能用多少比例。
这个数字直接牵动着 KV Cache——对话的记忆区，可以理解成一个停车场，每多一轮对话就多停几辆车。
显存利用率设得高，停车场就大，能同时服务的对话越多、上下文越长；设得低，停车场就小，长对话容易撑不下。
那设高一点不就行了？
不行。
因为模型加载的那一瞬间，有个峰值——它先要临时占一块地，把货搬进来，搬完才松手。利用率卡得太高，峰值一冲，没有缓冲余量，就直接 OOM（显存爆掉）了。
以我的双机 DGX Spark 部署 V4 Flash（Q4 量化，vLLM 引擎）为例：
设 0.845，稳定运行；调到 0.86，开机当场崩。
就差 0.015。
所以这个数字的上限不是算出来的，是从低往高一点一点试出来的——每次加一点，跑到崩为止，然后退回安全线。
二、并发数与批大小：两个旋钮会“联动”
显存利用率定下来之后，还有两个参数要调：并发数（同时处理几个请求）和批大小（一次搬多少货一起算）。
软件篇讲过，并发不是简单除法——加并发买的是总处理量，不是每个人的速度。但部署时还有另一层：
并发数和批大小不是独立的，是联动的。
调并发，KV Cache 的分配会跟着变；调批大小，生成速度会跟着变。不能单独拧一个，得成对看、成对调。
我试过一组真实搭配：
把“并发 4 + 批大小 8192”这个组合一调，KV 池从 167 万 token 直接涨到 274 万，+64%。
意味着同样一台机器，长对话的承载能力几乎翻倍。但这个组合不是一次蒙对的，也是反复尝试出来的。
这步没什么捷径：
记下原值，一次只改一个，改完跑一遍对比。
最怕的就是“我改了五六个地方，现在也不知道是哪个起了作用”。
三、思考模式：什么场景该让它“想”，什么场景该直接说
现在很多模型是“推理型”的——回答问题前，会先在脑子里想一遍，生成一堆“思考”内容，再给答案。
这个“想一遍”是计时的，想得越多，等得越久。
这里呼应一下软件篇聊过的速度三兄弟——衡量模型速度有三个指标：首字延迟（等多久才开口）、单字速度（说得多快）、端到端速度（从问到答总共多久）。
思考时间主要加在首字延迟上——模型“想”完才开始“说”。所以思考模式开关，直接影响的是“开门慢不慢”。
我的做法是根据场景来配：
- 日常闲聊、简单问答：把思考关掉，速度立升。
- 复杂推理、写代码、做数学：再打开。
这个开关我在客户端做了可调配置，让使用的人自己根据任务类型切换，不写死在配置文件里。
四、多机部署：网络不是基础设施，是模型的一条神经
这是双机部署（比如我这套两台 DGX Spark 并联）才有的环节。单台机器装得下整个模型，这节可以跳过。
双机跑一个大模型，等于把一个脑子切成两半，每生成一个字，两半之间都要“通信握手”一次。
这时候，两台机器之间的网络，不再是“基础设施”，而是模型本体的一条神经——这跟硬件篇讲的“带宽决定速度”是同一个道理，只不过这次带宽的瓶颈不在显存和内存之间，而在两台机器之间。
神经一断，模型就瘫。
这条神经上要注意的方面不少，我举几个自己碰到的：
通信索引要对得上
两台机器用高速网卡直连，通信时要靠一个叫 GID 的索引来“认人”——可以理解成门牌号。
这个门牌号重启后可能会变，两台机器对不上，握手就失败。部署文档里一句轻飘飘的“默认填 0”，实际上两台机器可能各不相同，得手动查、手动配。
上电顺序
两台机器一个管调度（Head），一个管干活（Worker）。
同时上电最好；非要讲究先后，先开 Worker 再开 Head——因为 Head 上电后会主动去拉 Worker，Worker 已经在就一次成功。
软件层内部的启动顺序，部署脚本会自动保证，不用操心。
容器操作要小心
部署一般跑在 Docker 容器里——可以理解成一个隔离的“小盒子”。有些重置命令会直接把两机之间的神经连接掐断，重启后得重新建立。
这只是几个我碰到的。多机部署不是“配好就一劳永逸”的，更像一个持续微调的过程。
五、排查：出了问题，从哪查起
部署跑起来之后，各种各样的问题都会有。本地部署涉及的环节多——容器、引擎、网络、客户端，任何一环都可能出问题。
我遇到的典型情况大致分三类，排查思路也不一样：
第一类：服务自己挂了，但容器还活着
这是我遇到过最隐蔽的一种。引擎因为内部超时自己崩了，但容器状态显示 Up，监控面板一切正常，只有客户端在报“连接失败”。
排查方法： 先在本机直接 curl 一下服务端口，确认引擎本身还活着——如果本机都不通，问题在服务端，不用去查网络。
第二类：配置变了但没发现
比如多机部署重启后 GID 漂移，两台机器对不上。
排查方法： 看日志。引擎日志里通常会有连接超时或者握手失败的记录，顺着日志定位到具体哪台机器、哪个配置出了问题。
这类问题的特点是“昨天还好好的，今天突然不行”——先想最近改了什么、重启了什么。
第三类：运行久了才会冒出来的问题
比如显存碎片化（长时间运行后显存像碎了一地的玻璃，分配不出整块）、缓存污染（上一轮对话的残留数据干扰下一轮）、推理结果漂移（量化误差在长上下文中被放大，越聊越不靠谱）。
这类问题的特点是“刚部署好的时候一切正常，跑着跑着才出”——不是条件没配对，是运行过程中慢慢积累出来的。
这些不是每次必出，条件不到不触发，但一旦遇到就得查。解法因问题而异，没有统一药方。
三类问题的排查思路
先定位到哪一层出了问题（服务端/网络/资源/运行时），再往细了查。
一上来就到处翻日志、到处改配置，反而容易越改越乱。
六、自愈：最后一步不是“祈祷它稳定”，是让它出事后自己爬起来
前面五步都走完了，部署算成功了吗？
不算。
因为我知道它总会遇到问题——引擎会超时、网络会断、电源会跳闸。
最后一步不是“祈祷它稳定”，是给它装一套出事后能自己爬起来的机制：
- 开机自启：断电恢复后，服务能自己爬起来。我实测过，断电恢复后几分钟内全自动恢复，不用人碰。
- 运行时看门狗：定期给服务做“体检”，连续几次失败，就自动重启整套服务。
这两样装上之后，我才能安心睡觉。
判断一个部署算不算真正完成，不是“它能跑”，是：
“它出事了能自己爬起来。”
以上是我在部署初期实际做的一些事——相当于打个基础。
每一步都不是一开始就知道正确答案的：显存利用率要一点一点往高了试，并发和批大小要成对调着看，思考模式要根据场景切换，网络配置要重启后反复验证。这些事，光看教程是学不到的，得自己一步一步走过来才知道。
基础打好之后，真正的考验在实际使用中。显存碎片化、缓存污染、推理结果漂移——这些运行时问题不是每次必出，条件不到不触发，遇到了再查再解决。网上有不少真实案例可以参考，别人踩过的坑、试出来的参数组合，都能在社区里找到。但别人的参数是别人的机器上试出来的，到我这里不一定一样，最终还是得自己跑一遍。
哞小哞的杂货铺 · 2026 · 014