本地部署大模型哪个好用

很多人第一次本地跑模型，卡在「装哪个」这一步：看推荐列表个个都好，装完却发现显存爆了、速度慢到没法用，或者商用授权对不上。这篇不讲原理也不排座次，只给一套可执行的选型流程——先定用途和硬约束，再倒推量化档位、模型规模和并发余量，最后核对许可证和迁移成本，让你在几分钟内把候选缩到一两个。

第一次本地跑模型，最容易踩的坑不是技术难，而是顺序错：一上来先问「哪个模型最强」，然后照着推荐列表下载，装完发现显存爆了、生成慢到没法用，或者干脆授权对不上商用场景。这篇不排座次也不讲原理，只给一套能照着走的流程：先定用途和硬约束，再倒推量化档位、模型规模和并发余量，最后核对许可证和迁移成本，把候选缩到一两个。

整个过程的目标不是找到「最好」的模型，而是找到「在你的机器、你的任务、你的使用范围下最不别扭」的那一个。所以下面每一节都会附上判断标准，以及什么情况下这套标准不成立——选型最怕的就是拿别人的结论套自己的场景。

先定用途，别先看模型名

模型名字是最不应该作为起点的东西。同一个模型在闲聊时表现不错，放到长文档检索或代码补全上可能完全不是一回事。先把自己的用途归到具体类型里，硬约束才会浮出来，候选范围也就自然收窄了。

• 是否必须离线运行：涉及内部资料时，能不能出内网是第一条红线；
• 数据能不能离开内网：哪怕只是调试阶段，也要提前想清楚日志和提示词会不会外发；
• 是自用、团队内用还是要对外提供：这三种场景在并发、审计和授权上的要求完全不同；
• 写下三个你最常做的真实任务，后面所有测试都用这三条复现，不要拿通用闲聊当评测标准。

用硬件算上限，而不是用模型倒推

先量出你真正能用的显存，而不是看标称容量。系统占用、桌面环境、多屏输出、后台浏览器都会吃掉一部分，按满打满算的结果去选模型，基本都会在加载阶段就失败。量完再按「参数量加量化档位」估算权重占用，然后给上下文缓存和批处理留出余量。

1. 量可用显存用显卡监控工具看空闲状态下的真实剩余量，而不是规格表上的数字；
2. 估权重占用按模型库和部署测算页给的对照关系，把参数量和量化档位换算成显存占用；
3. 留运行余量上下文越长、并发越多，缓存占用越大，这部分要单独预留，不能算进权重里；
4. 算内存和磁盘加载过程需要内存中转，模型文件落盘占空间，离线环境还要给多版本共存留位置。

具体每种参数量在不同量化档位下对应多少占用，不要凭印象，直接到模型资料库页面核对当时的数字：/models。不同框架的实测值会有差异，以你要用的那个推理框架为准。

量化档位是先决条件，不是优化项

很多人把量化当成「跑顺了再优化」的选项，实际上它是决定你能不能跑起来的第一步。高精度档质量最接近原始权重，但占显存最多；低比特档能塞进小显存卡，代价是长链推理和指令遵循更容易掉链子。选档位的正确顺序是：先保住能跑起来，再回头提精度。

高精度档

质量最好、占用最大，适合显存充裕且任务对数值敏感的场景

中等比特档

占用和质量折中，多数日常任务的默认选择

低比特档

能塞进小显存，但长推理和格式遵循明显下滑

量化格式

不同框架支持的格式不一样，先确认框架认不认，再看文件体积

判断标准很简单：显存不够时，降量化档位通常比换一个更小的模型更划算，因为模型能力还在。但如果你的任务涉及严谨翻译、结构化抽取、代码修补这类对数值敏感的场景，低比特档的错误率会明显上升，这时候宁可换成更小的模型也别硬压精度。各档位的实际体积和兼容性对照，去 /tools 里的模型与工具页面核对当时的数据。

尺寸与能力：小模型够用的场景比想象中多

参数规模不是唯一变量。短指令、分类打标、摘要改写这类任务，中小尺寸往往够用；长链推理、多步代码修改、跨文件理解才更吃参数。同一尺寸下不同训练取向的模型，在中文、代码、长文本上的差距可能比跨尺寸的差距还大，所以必须用你自己的任务实测，而不是看别人说哪个好。

• 实测时统一条件：同一提示词、同一量化档位、同一上下文长度，只换模型，否则结论没有意义；
• 每次至少跑三条真实任务，记录答对没有、格式对不对、速度能不能接受；
• 把结果写下来，别凭记忆比较，模型之间的差距往往体现在细节上；
• 候选别超过三个，测太多反而记混，一轮结论出来再换下一批。

并发与延迟：从「能跑」到「能给人用」

单人慢慢用，本地跑基本没问题；只要有人同时用，就必须按并发来算显存和吞吐，否则排队排到没人愿意用。多并发下显存占用不是线性叠加，但也不会凭空消失，得实测。三个观察指标：首字延迟、生成速度、并发增加时的速度衰减。

1. 量基线用接口测速工具在单请求下跑出首字延迟和生成速度，记下来；
2. 压并发同时发多个请求，看速度衰减到什么程度、显存有没有顶到上限；
3. 调参数按降量化档位、缩上下文、限最大输出长度、换更小模型的顺序逐条试；
4. 才考虑加卡前面四步基本不花钱，都试过还不够再谈硬件。

测速别用感觉判断，直接用站内的测速页跑同一组提示词，把不同配置下的数字放一起比：/tools/speed-test。如果你需要毫秒级首字、长时间高并发，本地单机通常不是合适选择，该考虑的是托管推理或者多卡并行，这一点要提前想清楚。

许可证与使用范围，先看再装

很多标着「开源」的模型只开放了权重，能不能改、能不能商用是另外两回事。自用、团队内部使用、对外提供产品，这三种场景踩到的条款完全不同，别用自用的心态去做对外服务。有专利或商标附加条款的，更不要直接嵌进面向客户的产品里。

具体某个模型的授权范围，以官方模型卡和站内核对的版本为准，别只看社区转述：/models。如果只是纯个人学习、不外发、不商用，许可证通常不构成障碍，但二次分发的限制仍然要留意。

部署方式与工具链：顺手比强更重要

跑得起来和跑得舒服是两件事。只想快速试一下，选封装好的命令行工具最省事；要做成服务、撑多并发、跑批处理，就得选面向推理服务的框架。选工具时看四件事：量化格式支持、显卡适配（包括国产卡）、接口兼容性、升级和回滚方不方便。

• 量化格式支持：框架不认你的模型文件，等于白下；
• 显卡适配：换机器或加卡时会不会重来一遍；
• 接口兼容性：能不能走标准接口，决定了以后换后端要改多少代码；
• 升级回滚：新版本出问题时能不能快速退回上一个可用状态。

一页选型清单与验证顺序

把前面几节的判断收敛成一条可复现的路径，避免每次换模型都从头纠结。顺序很重要：先定边界，再定档位，最后才挑名字。

1. 第一步：写清楚需求三条真实任务加大致并发人数，越具体越好；
2. 第二步：算硬件上限查出可用的显存区间，定出能跑的量化档位；
3. 第三步：小范围实测同档位下挑两三个候选，跑同一组任务，记录答对没有、速度能不能接受；
4. 第四步：核对许可证确认授权覆盖你的使用场景，尤其是商用和对外服务；
5. 第五步：写一句话结论包含模型类型、量化档位、上下文上限和部署工具，方便日后复现和迁移。

如果需求还在变，别过早锁定某一个模型。保留一个能快速替换的接口层，比选对某一个模型更有价值。想知道现在大家都在用哪些部署方案、各方案的适配情况，去工具目录页面看当时整理的信息：/tools。