前四篇解决单机可用性本篇转向多人并发。vLLM 通过连续批处理与 PagedAttention 提升吞吐并直接提供 OpenAI 兼容服务。一、痛点从可验收约束看主题风险本地部署最容易犯的错是先复制一条启动命令失败后才猜是驱动、内存、模型格式还是参数问题。可复用的方法是把系统拆成四层硬件资源、模型制品、推理运行时、应用入口。每层都保存版本和边界故障才有明确归属。传统静态批处理会让短请求等待长请求连续批处理在请求完成后立即补位。PagedAttention 把 KV Cache 分块管理减少碎片并提高可服务并发。还要先定义目标负载是一个人交互聊天还是多人 API输入通常多长输出上限多大允许多少秒出现首 token数据能否离开机器。没有这些约束“能运行”与“可使用”会被混为一谈。建议写一张实验卡包含模型仓库与修订号、量化格式、启动参数、驱动和运行时版本、并发、提示长度、输出长度、峰值内存与失败原因。它既是复现材料也是后续优化的对照组。二、原理资源、接口与质量如何联动传统静态批处理会让短请求等待长请求连续批处理在请求完成后立即补位。PagedAttention 把 KV Cache 分块管理减少碎片并提高可服务并发。 推理不是单一指标竞赛。容量决定能否装下模型和缓存带宽影响每秒能搬运多少权重算力影响矩阵计算软件内核决定硬件是否真正被利用。应用侧还受排队、分词、网络和流式传输影响所以端到端延迟不能简单归因于显卡。下面用一个独立 Python 程序演示“预算内择优”。真实项目可把三组样本替换成压测结果。筛选必须先满足硬约束再比较质量与延迟否则很容易选出质量最高却必然 OOM 的配置。代码只依赖标准库可直接保存运行。fromdataclassesimportdataclassdataclass(frozenTrue)classCandidate:name:strvalue:floatcandidates[Candidate(concurrency-1,420),Candidate(concurrency-4,770),Candidate(concurrency-8,1680),]threshold1000eligible[]foritemincandidates:accepteditem.valuethresholdifaccepted:eligible.append(item)print(f{item.name}: ttft_p95_ms{item.value:g}accepted{accepted})ifnoteligible:raiseSystemExit(no eligible candidate)selectedeligible[-1]marginthreshold-selected.valueprint(fselected{selected.name})print(fmargin{margin:.1f})运行输出concurrency-1: ttft_p95_ms420 acceptedTrue concurrency-4: ttft_p95_ms770 acceptedTrue concurrency-8: ttft_p95_ms1680 acceptedFalse selectedconcurrency-4 margin230.0这个小程序体现三条工程规则原始样本不可只保存最终结论预算要预留安全余量选择函数必须确定输入相同就得到相同配置。进入生产后可增加能耗、首 token 延迟、p95 和错误率但不要把不同硬件或不同长度的样本混在一起平均。三、实现建立可复现的主题实验先固定模型、输入输出长度和显存利用率再逐级增加并发观察首 token 延迟与吞吐。 以下脚本不下载大文件也不假定读者已经安装某个框架它先创建本篇的实验清单。随后执行具体模型命令时把清单、控制台日志和模型摘要放在同一目录。这样换机器、换后端或数周后回看仍知道数字是怎样产生的。mkdir-p$PWD/local-llm-195cd$PWD/local-llm-195printf%s\nexperimentvLLMexperiment.envprintf%s\nmodelqwen2.5:3bexperiment.envprintf%s\ncontext4096experiment.envprintf%s\nconcurrency1experiment.envprintf%s\ntemperature0experiment.envprintf%s\nseed42experiment.envprintf%s\ntimeout_seconds120experiment.envprintf%s\nwarmup_requests3experiment.envprintf%s\nsample_requests10experiment.envprintf%s\nrecord_versionstrueexperiment.envprintf%s\nrecord_hardwaretrueexperiment.envprintf%s\nrecord_failurestrueexperiment.envprintf%s\nredact_promptstrueexperiment.envprintf%s\nbind_address127.0.0.1experiment.envprintf%s\nauth_requiredtrueexperiment.envprintf%s\nbackup_requiredtrueexperiment.envprintf%s\nstatusreadyexperiment.envwc-lexperiment.env sha256sum experiment.env脚本会输出 17 行配置以及文件的 SHA-256。校验和不是安全签名但能发现实验清单被无意修改。真正部署时还应记录可执行文件版本、容器镜像 digest 和模型文件校验值仅写“最新版本”无法复现也无法在回归时快速回退。实施顺序建议固定为先检查磁盘和内存再验证模型制品完整性启动后先做健康检查再发一个短请求接着用固定输入做三次预热最后才采集正式数据。每次只调整一个参数例如上下文、批量或线程数。若同时改三个变量即便性能改善也无法知道因果关系。四、踩坑吞吐高不代表单请求更快。过高的显存利用率会让突发长上下文触发 OOM模型许可、远程代码和多卡通信也必须单独审查。吞吐高不代表单请求更快。过高的显存利用率会让突发长上下文触发 OOM模型许可、远程代码和多卡通信也必须单独审查。 另一个隐蔽问题是把成功响应当成正确响应。服务返回 200 只说明协议链路通了不能证明模板、停止词、字符编码和上下文截断正确。至少准备三类探针固定事实问答检查模板长输入检查截断边界结构化输出检查格式稳定性。升级模型或运行时后重复执行并比较差异。安全方面本地并不天然安全。监听0.0.0.0会扩大攻击面模型下载可能包含许可限制或不受信任代码聊天记录、日志和崩溃转储也可能泄露提示。默认只绑定回环地址跨机器访问通过带 TLS 和鉴权的网关模型来源、哈希与许可证进入资产清单日志对密钥、个人信息和完整提示做脱敏。资源不足时先降并发或上下文再考虑更激进量化因为前两者通常不改变模型权重质量。出现 OOM 要保留失败时的输入长度、并发、缓存设置与峰值不要只重启。出现变慢则分别观察 CPU、GPU、内存带宽、磁盘读取和排队时间避免“升级显卡”式盲目处理。五、验证用证据决定是否进入下一篇本篇验收不是截图而是一组可重复事实冷启动与热启动都成功固定请求得到非空且可解析的响应达到目标上下文时没有 OOM连续请求无资源持续增长重启后配置仍在端口、鉴权和日志符合边界实验卡能够解释模型、硬件、软件和参数。任何一项失败都先回到对应层修复不用应用层重试掩盖基础问题。完成后把基线文件纳入版本控制但不要提交密钥、真实对话或受许可证限制的模型。对性能数字同时标注日期和环境给结果设置有效期。驱动、内核、模型修订或运行时变化后应重新验证而不是沿用旧结论。这套“约束—实验—记录—比较”的闭环会贯穿整个系列。下一篇将推进到GGUF 量化与精度取舍继续沿用本篇的预算和实验卡把新的组件放进同一套可复现流程。参考来源docs.vllm.ai官方资料docs.vllm.ai官方资料arxiv.org官方资料 觉得有用就点个赞 收藏方便回头查阅有疑问直接在评论区留言我看到都会回。 本文属于《本地大模型部署实战》系列持续更新关注不迷路。 文章里的代码都能直接跑。想要可直接 clone 的完整工程 配套部署脚本 / 踩坑清单评论一声或发邮件到cj2664qq.com我免费发你。如果你正好在做类似系统、或有工程化难题想找人做也欢迎邮件聊一句——我按实际情况评估能落地的就接单或出方案。评论和邮件都能直接找到我不用跳别的平台。