很多人是在这一步卡住的：Ollama 装好了，命令行也能跑，但一拉 DeepSeek 就卡在下载、跑起来慢得离谱、或者直接报显存不足。这篇不讲模型原理，只讲 Windows 上从零到能用的顺序：先确认硬件底子，再选量化档位，再让显卡真正接管，最后按现象排查。每一步都给判断标准和替代方案，数字一律以站内页面当天显示为准。
很多人是在这一步卡住的：Ollama 装好了，命令行也能跑，但一拉 DeepSeek 就卡在下载、跑起来慢得离谱，或者直接报显存不足。这篇不讲模型原理，只讲 Windows 上从零到能用的顺序：先确认硬件底子，再选量化档位，再让显卡真正接管，最后按现象排查。
全程有一个原则：数字别记在脑子里。显存占多少、下载多大、跑多快，都到站内对应页面看当天的实际口径，因为模型文件、驱动、量化方式一变，昨天的数就不作数了。你只需要记住判断顺序和退档规则，剩下的去 /models/deploy 核对当时的数字。
装之前先确认三件事：显卡、内存、磁盘
在 Windows 上跑本地模型，第一道门槛不是软件，是硬件能不能扛。先花五分钟把显卡型号、系统内存、可用磁盘看清，比装完再返工省事得多。这三项里任何一项不够，后面的步骤都会变成反复折腾。
- 显卡
- N 卡看显存容量，A 卡和核显走的是另一条支持路径，先去 /compute/gpus 对照自己的卡属于哪一档
- 系统内存
- 模型加载和 KV 缓存都会吃内存，内存太小会出现「能加载但一提问就卡死」的现象
- 磁盘余量
- 模型文件是实打实的体积，别等其他盘符只剩几 G 才动手，具体占用规律见 /models/deploy 的测算口径
安装与验证：先把服务跑通，再谈模型
装 Ollama 本身不复杂，复杂的是把「安装对不对」和「模型跑不跑得动」这两件事分开验证。很多人一上来就拉最大的模型，失败之后根本分不清是安装问题还是硬件问题。
- 走标准安装包从官方安装包安装，不要用第三方打包的版本。装完在 PowerShell 里敲版本命令，能返回版本号，说明服务和路径都已就绪。
- 确认服务在监听确认服务监听在本地回环地址，用浏览器或 curl 能打通基础接口，说明常驻进程正常。接口地址与端口口径见 /models/deploy。
- 先用小模型跑通一轮第一件事不是拉大模型，而是先拉一个体积很小的模型跑通一轮问答，把服务链路验完，再换 DeepSeek。
- 出问题先看日志多数 Windows 问题出在服务没起、端口被占、代理拦截下载，而不是安装包坏了。先看服务日志再决定要不要重装。
拉哪个 DeepSeek：按显存选量化档位，别按名字选
DeepSeek 在本地通常以不同参数量与量化档位的形式提供。选型的正确顺序是「显存 → 量化档位 → 参数量」，反过来选必然翻车：先看名字挑大的，装完发现跑不动，再回头降档，白折腾一小时。
| 现象 | 大概率原因 | 该往哪调 |
|---|---|---|
| 能加载但每次回答都明显卡顿 | 档位偏高，部分计算回退到 CPU 或内存 | 往下降一档量化 |
| 加载阶段就报显存不足 | 档位超出可用显存 | 降档或换更小参数量 |
| 回答短问题还行，长问题崩 | 上下文长度吃掉显存 | 减少上下文长度或降档 |
| 换个问题就重新加载很慢 | 模型未被常驻 | 固定常用模型，避免频繁加载 |
- 量化档位越激进，显存占用越低、速度越快，但长推理和细节准确度会打折，取舍逻辑参考站内量化相关条目，不要在这里记死数字。
- 判断标准是「能加载 ≠ 能用」：加载进去后如果每次回答都明显卡顿或频繁换页，就该往下降一档，而不是硬扛。
- 不适用情况：如果你要做的是长文档解析、代码库级理解这类吃上下文的任务，小档位本地模型大概率不如直接调用官方接口，这种情况别硬上本地。
让显卡真正接管：Windows 上的加速开关与常见坑
Ollama 能在 CPU 上跑，但那就是「能跑不好用」的状态。判断显卡有没有真正接管，最直接的办法是打开任务管理器，在推理时看 GPU 占用；占用长期为零，说明还在拿 CPU 硬扛。
- 多显卡或多卡机器需要显式指定用哪张卡，不指定时可能选到核显或错误的卡，指定方式与环境变量口径见 /models/deploy。
- 驱动版本过旧会导致识别不到独显，或直接回退 CPU 计算，升级驱动是成本最低的一次尝试。
- 集成显卡、AMD 卡、Intel 卡各有自己的支持路径，不要照搬 N 卡的教程；不确定时先到 /ai-dict/category/hardware 把名词对上。
- 如果你用的是笔记本双显卡，插电和不插电的表现会不一样，排查慢的问题前先确认供电状态。
慢、卡、报显存不足：按现象排查的顺序
这类问题的坑在于，现象看起来一样，原因差很远。定一个固定排查顺序，比每次凭感觉调参靠谱：先看是加载阶段失败还是推理阶段变慢，再看 GPU 占用率，最后才怀疑模型本身。
| 排查顺序 | 看什么 | 结论方向 |
|---|---|---|
| 第一步 | 失败发生在加载还是推理阶段 | 加载失败多为显存或文件问题 |
| 第二步 | 推理时 GPU 占用是否明显 | 占用为零说明没接管，走加速排查 |
| 第三步 | 占用高但输出慢 | 档位或上下文设置偏重，考虑降档 |
| 第四步 | 并发请求下的表现 | 单人够用不等于能对外提供服务 |
显存不足的解法有优先级：降量化档位 > 减少上下文长度 > 换更小参数量。调参类操作往往治标不治本，真正有效的是降档。并发场景要特别注意，同时多个请求会叠加显存和上下文占用，单人测试通过的配置不代表能对外服务，测算口径见 /models/deploy。
下载慢、下不动、要搬到内网怎么办
下载卡住先分清是网络问题还是镜像源问题。换网络、清代理、重试，通常比反复重装有效。国内网络环境下，代理设置残留是下载失败的常见原因，装之前先把环境变量里的代理配置清一遍。
- 分清卡在哪一步是连接不上，还是连上了但速度极慢。前者查代理和 DNS，后者考虑换时间段或换源。
- 需要搬到内网时走文件迁移不要在没有外网的机器上重新拉，走模型文件迁移，流程与坑见 /models/deploy 相关说明。
- 先确认真实存储目录模型存放位置会随版本和安装方式变化，找不到文件时先确认当前实际存储目录，再谈迁移。
- 算清体积再决定搬哪些如果目标机器完全隔离且磁盘紧张，先算清体积再决定搬哪几个档位，不要整目录全搬。
跑起来之后的验收清单与日常维护
能回答一个问题不等于部署完成。真正跑起来之后，还有几件事决定这套东西能不能长期用下去：服务能不能自启、常用模型会不会每次都重新加载、磁盘会不会被旧档位塞满。
- 验收四条：能稳定返回答案、GPU 确实在工作、重复提问不崩、重启机器后服务能自己起来。
- 把常用模型固定下来，避免每次都重新加载；常驻与卸载策略会影响首次响应速度。
- 定期清理不再用的档位释放磁盘，避免盘满导致新模型拉不下来。
- 想做知识库、联网、接前端界面，属于下一层的事，先保证本地推理这一层是稳的。
- 如果模型效果长期达不到预期，不要无限调参，回过头比较一下本地档位与官方接口的差距，判断是不是该换路线。
常见问题
Windows 上用 Ollama 跑 DeepSeek，一定要独立显卡吗？
不一定，但没有独显时基本只能跑很小的档位，速度体验会很差。有独显的机器优先让显卡接管，核显和 AMD、Intel 卡各有支持路径，能不能用取决于具体型号和驱动。先到 /compute/gpus 对照自己的卡属于哪一档，再决定选哪个量化档位。
模型拉下来了，但回答特别慢，是模型不行还是配置不对？
先看推理时 GPU 占用。占用很低说明没走显卡，属于配置问题；占用很高但还是慢，多半是量化档位和参数量对这台机器来说偏大。处理顺序是先解决显卡接管，再往下调档位，最后才考虑换更小的模型。具体卡数对应关系以站内测算页当天口径为准。
显存不够会直接报错吗？
不一定。有时是直接报错退出，有时是部分层被卸载到内存后勉强跑起来，表现成又慢又卡。两种情况都指向同一件事：当前档位超出这台机器的承受范围。优先降量化档位，其次缩短上下文，最后才换更小的参数量。
部署完之后，能不能给同事一起用？
技术上可以，但单人够用的配置往往扛不住多人并发。并发会同时叠加显存和上下文占用，还涉及把服务从本机回环地址改成局域网可访问。真要共用，先按并发量重新做一遍测算，再谈开放访问。
本地部署的 DeepSeek 和直接用官方接口，效果一样吗？
不完全一样。本地跑的是量化后的版本，档位越激进和原版差距越明显，长推理和细节任务上更容易暴露。什么时候该自建、什么时候该调接口，站内已有专门讨论，本文只负责把本机这一层跑通跑稳。
