手里只有一张消费卡，想跑 DeepSeek 的 8B 或 14B，最常见的卡点是：下完模型起不来、起来了爆显存、跑起来慢得没法用。这篇不比较哪家模型更强，只给一条从「我这卡能跑哪个档」到「跑不顺怎么一步步降」的可执行路径，顺带把量化档位、上下文长度、并发这三个真正吃显存的变量讲清楚。
手里只有一张消费卡，想把 DeepSeek 的 8B 或 14B 跑在本地，真正的卡点往往不在下载，而在三步之后：模型下完了起不来，起来了爆显存，好不容易跑起来又慢得没法用。这篇只讲一件事——怎么从「我这卡能跑哪个档位」出发，一路走到「跑不顺时按什么顺序降级」，不比较谁家模型更强。
先记住三个真正吃显存的变量：量化档位、上下文长度、并发数。大多数人调不动，是因为一次把这些全改了，最后分不清是谁把显存吃满的。下面按选型、算显存、起服务、降级、止损五个环节拆开讲。
先分清 8B 和 14B 各自适合什么活
8B 和 14B 不是「大的更好」这么简单。8B 适合显存紧、要响应快、任务以对话润色、摘要、简单改写为主的场景；14B 适合需要更稳的指令跟随和拆解多步任务的场景，代价是显存占用和响应速度都上去了。选哪个，看你一天里跑得最多的那类问题。
| 你的典型任务 | 更合适的档位 | 理由 |
|---|---|---|
| 短问答、润色、摘要、改写 | 8B | 响应快，显存压力小，精度损失在这类任务上感知不明显 |
| 长文理解、多步流程拆解、结构化输出 | 14B | 指令跟随更稳，但显存和延迟都更高 |
| 要进自动化流程、被程序批量调用 | 先按响应时间定 | 答得再好，单条延迟吞掉吞吐就没意义 |
| 要塞大量文档进上下文 | 两个档都可能吃力 | 该考虑更大参数或直接走 API，别硬调 |
不适用的情况要说清楚：如果你的任务本身就要求长上下文、要一次塞进大量资料做理解，8B 和 14B 在消费卡上都很难同时兼顾长度和质量，这时候与其反复调参，不如先去看更大参数方案或直接调用接口。
按显存倒推量化档位，而不是反过来
正确的思考顺序是「我的卡有多少显存 → 能塞下哪个量化档 → 上下文最多能开多大」。先定档，再谈效果。反过来先挑一个量化档再看能不能跑，是导致反复重下的主要原因。量化越激进越省显存，但精度损失在长输出和结构化任务上更容易暴露，在短问答里往往感觉不到。
- 把上下文长度当成显存开销的一部分，开得越大占用越高，起服务时要留一截余量给 KV 缓存，别顶满
- 每档量化具体占多少、你的卡卡在哪一档，到 /models/deploy 用部署测算对一遍
- 再按自己的模型和卡的组合到 /compute/sizing 算一遍，看要不要降档或降上下文
- 同一台机器上其他占显存的进程也要算进去，不是只有模型在吃卡
从下载到跑通的最小检查清单
「下完起不来」九成不是硬件问题，而是文件或格式对不上。推理工具各有各支持的量化格式，格式错配最常见。另外别忽略推理工具的选型：单机随手用和接程序批量跑，对吞吐、并发、安装复杂度的要求完全不同。
- 确认文件完整比对模型仓库给出的文件清单，确认没有下载中断导致缺文件或半截文件。
- 对齐量化格式确认手里的量化格式和你选的推理工具支持的一致，不一致就换格式或换工具。
- 按场景选工具单机随手用优先装得省事，接程序批量跑优先吞吐和并发，差异可先到 /tools 用检测类工具量个基线。
- 一次只改一个变量先跑默认配置，再动上下文，最后动并发。一次全改，出问题分不清是谁的锅。
- 测一条基线接口通不通、首字延迟多少，用 /tools/speed-test 先记录一条基线，后面调优才有参照。
跑不动、跑得慢时的降级顺序
降级要有顺序，乱降会让质量掉得比性能快。推荐顺序是先降上下文，再降量化档，最后才换更小参数。这个顺序对回答质量的影响相对最小。速度慢还得分清是算力不足，还是显存不够导致部分层被放到了内存上——后者表现为首字特别慢，之后逐渐稳定，和纯算力不足的手感不一样。
| 症状 | 先查什么 | 再做什么 |
|---|---|---|
| 起服务直接报爆显存 | 上下文是否顶满、并发是否默认太高 | 降上下文，再考虑降量化档 |
| 首字很慢但后面变稳 | 是否有层跑在内存上 | 降上下文或降量化档，让模型回到显存里 |
| 单条还行、并发一来就崩 | 并发上限估计是否偏乐观 | 降到 /compute/sizing 按场景算出的上限以内 |
| 答得还行但偶尔跑偏 | 量化档是否太激进 | 结构化任务上适当放宽量化档，别只看显存 |
并发是把显存吃满的隐形杀手，一张卡同时来几个请求，占用不是简单相加。具体能扛多少，别凭感觉，到 /compute/sizing 按你的场景算一遍。另外，在你打算把本地服务对外提供之前，许可证和商用边界必须确认清楚，可参考 /ai-dict/category/safety 里的相关条目，别等做完才发现不能这么用。
什么时候不该在这两个档上折腾
本地部署不是越多越好。需要长上下文处理大量资料，或者要稳定做多轮复杂推理时，8B/14B 的本地收益很容易被调参时间吃掉，租卡或者调接口反而更省事。判断标准很简单：你是为了「数据不出内网」这个硬约束，还是只是想试试本地跑起来的感觉。
- 团队多人共用、要求响应稳定时，单张消费卡扛并发不划算
- 只是偶尔试用、没有数据不出内网的要求时，本地维护成本高于直接调用
- 任务本身要长上下文塞大量资料时，这两个档都不是好选择
- 一旦本地服务要对外提供，先确认许可证和商用边界，再决定要不要继续
两个档位到底能在你的卡上跑到什么程度，绕不开实测。跑之前到 /models/deploy 和 /compute/sizing 把档位和上下文估一遍，能省掉反复重下的时间。要不要考虑换成本地部署，也可以先看看 /sites 和 /rankings 里那些能直接调用的方案，把维护成本和调用成本摆在一起比。
下一步怎么走带上你的显卡型号、想跑的任务类型、能接受的首字延迟，到 /tools/speed-test 先测一条基线，再回 /compute/sizing 按场景核对档位和并发上限。→常见问题
一张消费级显卡到底能不能跑 14B？
能跑，但取决于量化档位、上下文长度和并发三个变量，不是一句能或不能。先确定显存上限，再去 /models/deploy 按量化档倒推，把上下文留出余量。如果你要同时开多个请求，实际能用的档位会比单请求时低一档，建议先用单请求跑通再逐步加并发观察。
8B 和 14B 的回答质量差多少，值不值得多占显存？
差距在任务类型上分布不均：短问答、改写、摘要这类 8B 通常够用；长文理解、多步流程拆解、要求严格按格式输出时 14B 更稳。判断方法是拿你自己最常问的十来个问题各跑一遍对比，而不是看通用榜单。质量差距明显但速度不能忍的话，就先留在 8B。
跑起来了但输出很慢，先改什么？
按顺序排：第一看是不是显存不足导致部分计算落到内存，第二看上下文开得是不是过大，第三才考虑降量化档或换更小参数。用 /tools/speed-test 测出基线，改一个变量测一次，别一次全改。如果基线本身就慢，说明卡的算力上限就在那，换档位只能小幅改善。
