你想在本地把 DeepSeek Flash 系列跑起来，多半卡在这几步：不知道自己的卡够不够、量化档位选哪个、用 Ollama 还是 vLLM、权重下下来加载失败。这篇不吹参数，按「先算显存、再定框架、后做验证」的顺序给一套可执行的流程，每一步都告诉你什么情况下要换方案。
你想在本地把 DeepSeek Flash 系列跑起来，卡点通常不在「模型好不好」，而在几个很具体的地方：不知道自己那张卡够不够、量化档位选哪个、用 Ollama 还是 vLLM、权重下下来加载直接报错。这几个问题一个没解决，后面全是白忙。
这篇按「先确认版本、再算显存、后定框架、最后做验证」的顺序给一套能照着走的流程，每一步都告诉你什么情况下该换方案。不背数字，要看数字的地方都指到站内对应的换算和资料页去核对当时的情况。
先确认你手上到底是哪版权重
同名模型经常有多个版本别名与快照，权重结构、上下文长度上限、是否带视觉塔都可能不一样。动手之前先去站内资料库把这一版的实际规格核清楚，别拿一篇旧文里的参数直接开跑，大概率对不上。
- 先去 /models 核对该版本的实际规格：参数量、层数、上下文长度、是否有额外模态分支
- 确认你要的是开放权重还是接口版。Flash 系列一般同时存在官方托管接口和开放权重两份，本地部署只能拿开放权重那一份
- 许可证范围要提前看清，商用、二次分发、蒸馏限制都可能不一样，可参考 /ai-dict/category/safety 里的合规说明
- 如果翻遍资料页只找到接口文档、没有权重下载入口，说明这版没开源权重，本地部署这条路直接不适用，转去比价页面看按量调用的成本
这一步的判断标准很简单：能不能拿到权重文件。拿不到就别在部署工具上浪费时间，方案要换，不是流程要优化。
按量化档位算你需要多少显存
显存够不够，是本地部署唯一真正的硬门槛，算不清楚就会反复经历「下完了、加载一半、爆了」。粗算分成三块，权重、KV 缓存、框架自身开销，三块加起来再留一截余量。
- 权重体积
- 参数量乘每参数字节数，低比特量化约每参数半个字节，中等量化约一个字节，半精度约两个字节
- KV 缓存
- 随上下文长度和并发数增长，长上下文场景这一项可能比权重还占地方
- 框架开销
- 运行时、图捕获、临时缓冲区，通常占几个 GB 量级，小卡上这一项不能忽略
上下文长度是隐形吃显存的大头。很多人只按权重体积拍板，结果一开长上下文就爆。具体数值别背，去 /models/deploy 和 /compute/sizing 按你的卡型、目标上下文和并发数算一遍，拿不准就看 /tools 里有没有现成的换算工具。
量化档位怎么选：不是越低越好
量化档位选错的代价很直观：低到一定程度，指令跟随开始飘、长文写作开始漏要求，而你的显存其实本来够用。判断顺序是先满足显存能装下，再在装得下的档位里挑质量最高的那个，而不是一上来就追最低比特。
| 你的任务类型 | 量化档位倾向 | 原因 |
|---|---|---|
| 指令跟随、长文写作、结构化输出 | 偏保守，往上抬一档 | 对数值精度更敏感，掉档容易表现为不听话 |
| 代码补全、短问答、分类打标 | 可以更激进 | 任务容错高，格式约束强，轻微损失可接受 |
| 离线批处理、对延迟不敏感 | 可以退到更低档位 | 用质量换并发或换更长的上下文更划算 |
什么情况下不适用：如果你跑的是评测型任务、结果要横向对比，那量化档位就必须每次保持一致，不能这次用一档下次换一档，否则数字之间没有可比性。
框架选型：Ollama、llama.cpp 还是 vLLM
这几种框架不是谁更高级的问题，是场景不同。选错会出现两种典型症状：单人调试时启动慢得离谱，或者多并发一上来就排队超时。
- 单人本地调试、想要一条命令起服务，用 Ollama 这类封装好的方案，环境依赖它帮你处理
- 已经在用某个轻量框架且能跑通，别为了追新折腾迁移，收益通常不抵迁移成本
- 要压测吞吐、要跑多并发、要吃到张量并行，走 vLLM 这类服务化框架，具体差异对照站内框架选型文章
- 权重格式和框架要匹配，加载报错优先怀疑格式不对，而不是模型文件坏了
什么情况下不适用：消费级卡加小显存场景下，服务化框架自身的显存占用就可能把模型挤出去，这时轻量方案反而更快、更稳。选型之前先看你的卡有多余空间。具体框架版本和权重格式的兼容关系，到站内框架选型文章和 /models/deploy 页核对。
最小可跑通的部署步骤
- 先用小模型验环境拉一个同族的小尺寸模型跑通，验证驱动、CUDA 或 NPU 运行时、框架版本三件套没问题，再上大权重，能省下大量重复下载时间
- 指定权重目录与端口起服务用配置文件或命令行显式指定权重路径和监听端口，本地先只监听回环地址，自己确认没问题再考虑开放对外
- 做一次冒烟测试用一条固定提示词跑一次，记录首 token 延迟和逐 token 生成速度，作为后面所有调参的基线，没有基线就没法判断改动是快了还是慢了
- 显存不够时的降级顺序先减上下文长度，再考虑降量化档位，最后才是换卡；前两步都是软件层面能立刻回退的，换卡不是
这套流程里最容易跳过的是第一步。很多人直接上大权重，加载失败之后分不清是环境问题还是模型问题，排查成本翻倍。
起服务后的参数与性能调优
服务起来之后，调优的核心是把「慢」拆开看。并发和显存是直接换算关系，卡数、批大小、上下文三者通常只能同时满足两个，先定死你最重要的那一个，另外两个让路。
| 现象 | 先怀疑什么 | 怎么验证 |
|---|---|---|
| 首 token 很慢 | 权重加载、缓存未命中、磁盘 IO | 看加载日志耗时，重复请求看第二次是否变快 |
| 逐 token 很慢 | 算力或显存带宽瓶颈 | 降并发或降上下文，看单 token 时间是否改善 |
| 并发一上来就超时 | 批大小或并发上限设太高 | 逐步压并发，找到出现错误的那条线 |
| 偶发 OOM | 残留进程或显存碎片 | 先清进程和缓存，再降配置 |
把每次改动的延迟数字记下来，别靠感觉。感觉会说「好像快了点」，记录会告诉你到底是快在哪一段。
上线前的验证清单与回退方案
在本地跑通不等于能用。上线前至少验证三件事，并且在动手之前就把回退路径定好，不要等出事再临时决定。
- 同一提示词多次输出是否稳定，有没有随机崩掉或截断
- 长输入是否触发截断，实际可用上下文和文档标称是否一致
- 并发上来后是否出现超时或报错，错误是稳定复现还是随机
- 准备回退路径：本地跑不动时，是退回接口按量调用，还是租卡跑同一份权重，这个决定要在上线前定
- 记录权重快照、量化档位、框架版本三样，下次复现或升级直接照抄这套组合
本地部署最容易踩的几个坑
下面这几个问题占了本地部署报错的大多数，遇到时按顺序排查，别一上来就重装环境。
| 坑 | 排查顺序 |
|---|---|
| 磁盘空间不够 | 权重文件体积通常是显存需求的数倍，下载前先看剩余空间 |
| 加载失败 | 先查驱动与运行时版本矩阵，再查权重文件完整性 |
| 显存占满 | 先杀残留进程和清缓存，再考虑降配置或降量化 |
| 速度不达预期 | 先分清首 token 慢还是逐 token 慢，再对症改参数 |
驱动与运行时版本错配是报错率最高的一类，很多看着像「模型坏了」的问题，本质是环境不匹配。遇到加载失败先查版本，再查权重。
下一步先拿你的卡型和目标上下文去算一遍显存，再看框架选型的差异，最后决定要不要本地跑；数字对齐了再动手，比反复重装环境省事得多。→常见问题
我的显卡只有 8G 显存，能跑 DeepSeek Flash 系列吗？
要看具体版本和量化档位，不能一概而论。做法是先查该版本的参数量，按 INT4 粗算权重体积，再留出 KV 缓存和框架开销。如果算下来超过显存，可以退到更低的量化档位、缩短上下文，或者干脆换成同族更小的模型；具体卡型对应的可跑范围去站内部署测算页面按你的卡算一遍。
Ollama 和 vLLM 部署同一个模型，结果会不一样吗？
输出结果通常接近，差别主要在吞吐、并发和显存占用上。轻量封装的方案上手快、单请求简单，服务化框架在多人并发和压测场景更占优，但对显存的要求也更高。选哪个取决于你是自己调试还是要对外提供服务，而不是哪个更「先进」。
权重下载下来加载失败，一般是哪里的问题？
按顺序排查：先确认权重格式和框架要求是否匹配，再确认权重是否下载完整，最后看驱动和运行时版本是否落在框架要求的范围内。这三步能覆盖大部分加载报错。如果是刚发布的新版本模型跑不起来，多半是框架还没适配，去站内查对应模型的适配情况。
本地部署和直接用官方接口，什么情况下该选本地？
数据不能出内网、调用量大到按量计费不划算、或者需要离线环境时，本地部署更合适。反过来，如果调用量不稳定、只是想试试效果，直接走接口更省事。这笔账要把卡的成本、电费和你自己的运维时间一起算进去，别只比单次调用价格。
部署完怎么判断性能是否正常？
先看两个指标：首 token 延迟和每秒生成 token 数。跟同卡型、同量化档位的公开参考值比一比，差得太多就是配置有问题，而不是模型本身慢。另外注意上下文变长后延迟会自然上升，测的时候要保持输入长度一致才有可比性。
