想在自己电脑或公司内网机器上跑通义千问 Qwen2.5，卡住的地方通常不是「下不下来」，而是下完发现显存爆了、量化档位选错、或者根本不知道该用哪个推理工具。这篇按「先算账、再装、后验证」的顺序给一套能照着做的流程，也写清哪些情况下本地跑并不划算，该掉头去调接口。
想在自己电脑或公司内网机器上跑通义千问 Qwen2.5，卡住的地方通常不是「下不下来」，而是下完发现显存爆了、量化档位选错、或者根本不知道该用哪个推理工具。这篇按「先算账、再装、后验证」的顺序给一套能照着做的流程，也写清哪些情况下本地跑并不划算，该掉头去调接口。
整条路线四步：算显存定版本、挑推理框架、搞定权重来源和格式、跑通后做验收。每一步都有明确的判断依据，不用凭感觉试。下面逐步展开，中间会穿插对照表和排查顺序，照着做基本能少走一大半弯路。
第一步：先算显存，再决定下哪个版本
权重占用的粗算是参数量乘以量化位宽，再换算成字节数。但这只是权重本身，实际加载还要加上 KV 缓存和框架自己的开销。经验做法是把估算值再留出一截余量，别按满打满算去选，否则加载能过、一对话就崩。
| 你的使用场景 | 显存余量建议 | 量化档位的取舍 |
|---|---|---|
| 单人自用、短对话为主 | 留出较宽余量，防止长上下文时临时爆 | 可以选省显存更多的档位，牺牲一点质量换稳定 |
| 单人自用、经常长文改写 | 余量要给 KV 缓存留够 | 量化别压太狠，长文上掉点更明显 |
| 多人并发或接应用 | 按并发数放大余量 | 优先选质量更好的档位，不够就升级硬件 |
| 只是尝鲜试效果 | 能加载就行 | 先跑起来，后面再按体验决定换不换 |
- 按参数量乘量化位宽粗估权重占用，再给 KV 缓存和框架开销留余量，别把显存占满
- 量化档位越激进省显存越多，但长文推理和代码任务上掉点更明显，先想清楚主要拿它干什么
- 同一台机器上「能加载」和「能舒服地连续对话」是两回事，单人自用和多人并发的余量标准不一样
- 拿不准就先去站内对照各家官方模型的规格说明，确认参数量对应的资源区间再动手
第二步：选推理工具，别一上来就装最重的
本地推理工具大致分两类：一类装完即用，模型拉取、端口管理都帮你处理好，适合桌面快速试效果；另一类是服务型框架，带批处理和 OpenAI 兼容接口，适合接自己应用、多人同时用。先判断自己属于哪类，再去挑具体工具。
- 确认用途是个人桌面试效果，还是要接应用、多人并发。这一步决定后面所有选择。
- 桌面自用路线选装完即用那类工具，重点看它支持哪些权重格式、你机器平台有没有对应算子。装完能跑通一次对话就算过。
- 服务型路线选带批处理和 OpenAI 兼容接口的框架，重点看并发能力、显存调度、有没有现成的部署说明。跑通后先用并发压一轮看稳不稳。
- 对照平台支持确认你的操作系统和显卡平台在工具的支持列表里，别装完发现缺算子。站内工具目录里有各框架的适用场景说明，先对一遍再决定。
选工具时最常见的坑是「装完发现缺你这个平台的算子」，尤其是非主流显卡或较老的驱动。判断标准很简单：工具的官方文档要能明确说出支持你的平台，含糊其辞的先跳过。
第三步：搞定权重来源和格式，别下错文件
权重格式和推理工具必须对得上，格式不匹配直接加载失败，这不是配置写错，是文件本身就用不了。下载前先在工具的文档里确认它吃哪种格式，再去挑对应的权重文件。
- 权重格式
- 不同推理工具支持的格式不一样，下之前先在工具文档里确认，别下完才发现加载不了
- 下载源
- 国内网络环境下优先挑下载稳定的镜像源，大文件断流重下很耗时间
- 量化文件版本
- 尽量用有人维护、有说明文档的那一版，来源不明的转换版容易出乱码和重复输出
- 校验
- 下载完对一下文件完整性，大文件下载中断是常见问题，别默认下完就是好的
- 确认拿到的权重格式和你的推理工具对得上，格式不匹配直接加载失败，不是配置问题
- 国内网络环境下优先挑下载稳定的镜像源，大文件断流重下很耗时间
- 量化文件尽量用有人维护、有说明文档的那一版，来源不明的转换版容易出乱码和重复输出
- 下完先做一次加载测试，能加载再往下走，别等全部配好才发现文件有问题
第四步：跑通不算完，做三项验收
能对话不等于能用。至少要测三类任务：中文长句改写、结构化输出（让它吐 JSON）、多轮上下文记忆。这三项各测一轮，看输出质量稳不稳、上下文有没有断，再决定要不要调参或换量化档位。
| 验收项 | 怎么测 | 不合格时先查什么 |
|---|---|---|
| 中文长句改写 | 给一段长句让它改写并保持原意 | 量化档位是不是压得太狠 |
| 结构化输出 | 让它按指定字段吐 JSON | 提示词写法，再看模型本身能力 |
| 多轮上下文 | 连续几轮引用前面的内容 | 上下文长度设置和 KV 缓存配置 |
| 性能基线 | 记录首字延迟和每秒出字速度 | 并发数、显存占用、量化档位 |
把测试用的提示词和结果都存下来。换版本或换参数时能横向比，别凭感觉说「好像变快了」。性能基线尤其重要，它是你后面调并发或换档位的参照。想看同类工具在你这套配置上的表现，可以到站内工具速度测试页跑一轮，拿当时的数字做对比。
下一步想对照几种推理框架和量化方案的适用场景，去工具目录和模型资料库核对当时的规格与说明，再决定装哪个。→这些情况下，本地部署不是好选择
本地部署不是默认最优解。有些场景下折腾本地反而是浪费时间，先判断自己是不是属于下面这几类，是的话直接掉头去调接口更划算。
- 只是在做原型验证、调用量还很小：直接调 API 更快也更省事，省下的时间比省下的卡钱值钱
- 需要顶配效果、不接受任何量化损失：本地消费级卡很难给到和线上旗舰一致的输出质量
- 团队里没人愿意维护驱动、CUDA 版本和模型更新：跑起来只是开始，后面每次升级都是活
- 对数据出境没有硬性要求、预算又有限：先算清楚调用成本和硬件投入，再决定要不要本地
- 只是想把模型当作生产力工具用、不打算做定制：直接调接口，把精力放在怎么用好它上
换句话说，本地部署真正划算的场景是：有数据不出内网的要求、调用量足够大、有人愿意持续维护。这三条缺一条，都要重新评估。判断的依据不是「别人都在本地跑」，而是你自己的实际约束。
先算账再动手，能加载不等于能用，能用不等于值得自己维护。
常见问题
我只有一张消费级显卡，Qwen2.5 能跑吗？
多数情况能跑，但要看参数规模和量化档位怎么配。先用站内的部署测算和显存估算页面按你的卡算一遍，得出可选的参数量区间，再挑对应量化版本。跑得动和跑得舒服是两回事，长期用建议给显存留出三分之一以上余量。
用 Ollama 还是 vLLM？
看用途。单人本地试用、要快装快跑，前者更省事；要对外提供接口、多人并发、想压吞吐，后者更合适。两者不是替代关系，很多团队是本地开发用轻量工具，上线服务换服务型框架。站内有两者的对比文章可以对着场景看。
本地跑出来的效果比线上差，正常吗？
常见。量化会带来精度损失，参数规模也可能比你平时用的线上模型小。想缩小差距，优先加大参数量、放宽量化档位，再考虑调温度和上下文长度。如果业务对输出质量要求高，评估一下是不是该直接调官方接口更省事。
