本地部署免费大模型常见问题，常见问题和做法

本地部署免费大模型，多数人不是卡在「不会装」，而是卡在装完之后：模型下不下来、下了跑不动、跑起来答得不对、机器一变又全废。这篇按这四类问题拆开，每类给一个判断口径和一套动手排查的先后顺序，还标了哪些情况这套做法不适用，省得你一条条试。

本地跑免费大模型，大多数人不是卡在「不会装」。教程照着走一遍，框架能起来，界面能打开，真正让人抓狂的是装完之后那一串事：模型文件半天拉不下来，下完了显存爆掉，好不容易跑起来答得又不对，某天重启一下全没了。这篇就把这些最常卡住的地方摊开讲，每个类别给一个判断口径和一套动手顺序，省得你一条条盲试。

先说清楚一件事：下面这些做法大多是针对个人机或者小团队自用场景的，目标是「能稳定跑起来、知道哪里出问题」。如果你是要给多人提供稳定服务，或者数据有硬性合规要求，那思路得换成容量规划那一套，文末会单独说哪些情况不适用。

先把「常见问题」分成四类，别混着查

很多人排查效率低，是因为把不同层的问题搅在一起。一个「慢」字，可能是显卡不够，也可能是量化档位配错导致大量计算落到内存上，还可能是上下文开太大。不先定位类别，你就会在显卡、框架、提示词之间来回跳，越调越乱。

排查原则只有一条：先确认现象落在哪一类，再动手。同一现象可能由两类原因叠着造成，比如「慢」既可能是卡不行，也可能是层卸载策略配错。所以每次只改一个变量，改完记下结果，别一次动三处。

获取类：下不动、拉不下来、格式不对怎么处理

这一类问题的共同点是：你还没进入「跑」的阶段，先把文件弄对再说。先搞清楚你要的是哪种文件——量化打包格式、原始权重格式、还是某个框架自己的仓库打包，这三类的加载方式完全不同，装错了等于白下几百 G。

• 下载慢优先换源或走镜像，别对着同一个源反复重试，重试不会变快，只会浪费时间
• 内网机器或断网机器，要把模型文件搬过去再本地导入，指望它在目标机器上在线拉基本行不通
• 授权报错不等于模型坏了，多半是仓库访问权限没给或者授权条款没接受，去看模型卡片里的授权说明，别直接跳过
• 文件名和目录结构要能对上框架文档里的示例，对不上就先别往下走

判断标准很直接：能稳定拿到完整文件、目录结构能对上框架说明，才进入下一步。拿不到文件的时候去折腾显卡是纯浪费，先把获取这关过了。

资源类：跑不动，按「显存→内存→速度」的顺序查

资源问题要按顺序查，顺序错了会白忙。第一步先算账：参数规模乘上量化后每参的大致字节数，再加上下文缓存和运行开销，得出一个粗估占用，拿这个数跟你的显存比。别凭感觉觉得「这个模型应该能跑」，估算口径可以去站内按当时的数字核一遍。

1. 算占用用参数量乘量化字节数，再加上上下文缓存开销，得出粗估显存需求，和实际显存比对
2. 看有没有卸载很多框架默认会把一部分层卸载到内存或 CPU，看起来能跑但慢得离谱，先确认有多少层真正进了显存
3. 最后再调速度上下文开太大、并发开太高、模型没常驻显存，都会让体感速度断崖式下跌，这三项最后调

有一点要特别注意：如果显存明显够、层也确实都进了显存，但还是慢，那问题往往不在模型大小，而在驱动版本、推理后端没启用，或者这张卡本身的算力就弱。这种情况下换小模型解决不了根本问题。

想对照不同量化档位和配置大概是什么量级，可以去 /models/deploy 和 /compute/sizing 按当时的数据核对，别照抄别人机器上的配置。

效果类：能跑但答得不对，先分清是能力问题还是配置问题

「答得不好」是最容易被误判的一类。多数时候不是模型不行，而是配置没对。先排除配置：上下文长度设小了会截断，温度设高了回答会飘，系统提示没写清楚会跑偏。这三项加起来，能解释掉一大半「答非所问」。

• 先排除配置：上下文长度、温度、系统提示，三项逐个核对
• 再排除量化：同一模型不同量化档位的表现有差距，遇到明显退化先换一档验证
• 最后才看能力边界：免费开源模型在特定语言、特定专业领域就是有短板，换提示词救不回来
• 判断标准：用官方示例配置跑同一个问题，还是不行，才认定是模型能力问题

要不要加重排、要不要换嵌入模型，这类决定别拍脑袋。可以先去 /embeddings 看当期对照，再决定是加检索还是直接换模型。加检索能缓解知识类问题，但救不了推理能力本身的短板，这点要分清。

运维类：装完能跑，但一重启就出问题

这一类最气人：昨天还好好的，今天开机就不行了。常见翻车点就三条——服务没注册开机自启、模型路径写的是某个用户目录下的默认值、改完端口忘了在防火墙上放行。每一条都不难，但三条叠在一起就很难查。

做法是把三件事固定下来：模型存储目录写进配置文件，不靠默认值；服务注册成开机自启；监听地址和端口显式写清楚。改配置之前，先把当前能跑的状态记一笔，改坏了能退回去。本地部署最怕的不是出错，是越调越乱，最后连原来能跑的状态都回不去了。

这套做法在个人机上够用，但多人共用的机器不一样：要考虑权限隔离和资源抢占，个人机上「谁先启动谁占着」的做法直接搬过去，几个人会互相踩。

一份可以直接照着走的排查清单

下面这份清单按顺序走，遇到问题先看自己停在哪一步。不要跳步，跳步是排查效率低的主要原因。

1. 先定任务再选模型写清楚你要它干什么活，是问答、写作还是写代码，再按任务选模型，别反过来先下个大模型再想用途
2. 确认文件拿到的是哪种格式、对应哪个加载方式、授权能不能用，三项都过了再往下
3. 估算占用显存、内存、上下文三项都算进去，对照站内口径核一遍
4. 起服务后量基线记下首个 token 的等待时间、每秒出字速度、显存剩余，这三个数是以后判断「变慢了没有」的基准
5. 效果不达标逐项排除按提示词→上下文→量化档位→换模型的顺序，一次只改一项
6. 上线前固定三件事自启、模型目录、监听地址固定下来，再考虑接知识库或对外提供接口

哪些情况这套做法不适用

前面讲的都是个人机或小团队自用的思路，下面这几种情况照搬会走弯路，提前说清楚。

• 数据必须完全不出内网、又要多人并发的场景，个人机的排查思路不够用，要按服务端的容量规划重来
• 只是偶尔用一下、没有固定任务的，本地部署的维护成本通常高过直接用现成接口，动手前先想清楚
• 要求很高的专业领域问答，免费开源模型加提示词能到的上限有限，别把时间都耗在调参上
• 机器配置本身就在及格线边缘的，与其反复调参，不如先承认这台机器跑不动这个档位的模型，换目标比换参数有效

还有一种情况：你要的是「稳定对外提供服务」，那这套排查清单只能帮你定位问题，不能帮你做容量规划。并发一上来，单机自用的经验会集体失效，得按服务端的思路重新算。