本地部署满血版deepseek-r1

很多人搜「满血版」是想在本机或公司服务器上跑到没被裁过的权重，但真开机才发现卡在显存、带宽、许可证和推理框架这几道坎上，跑起来和跑得动是两件事。这篇不给你一个「买什么卡」的结论，而是按参数量、量化档位、并发需求把门槛拆开，告诉你哪些环节能省、哪些省不了，以及每一步该到哪里去核对当时的数据。

很多人搜「本地部署满血版deepseek-r1」，心里想的是在本机或者公司服务器上跑到没被裁过的原始权重。但真开机才发现，卡住你的往往不是算力不够，而是显存装不下、带宽跟不上、许可证看不懂、推理框架报错这四件事。跑起来和跑得动，是两件完全不同的事。

这篇不给你一个「买什么卡」的结论，因为硬件行情和模型规格一直在变。我按参数量、量化档位、并发需求把门槛拆开，告诉你哪些环节能省、哪些根本省不了，以及每一步该到哪个站内页面去核对当时的数字。

先把「满血版」这件事说准

「满血版」指的是未经小参数量裁剪的原始权重。你平时在网页端用到的、或者下载到的小参数蒸馏版，是另外一套东西。蒸馏版能在你的笔记本上跑起来，不代表原版也能跑，两者对硬件的要求差着量级，别把跑通蒸馏版的经验直接套过来。

还有一笔账要分清：权重本身的体量，和推理运行时的开销。同一份权重，换个框架、换个量化方式，显存占用可以差出很多。所以别只盯着「模型多大」，要按「权重体量 + 运行时开销」两笔账一起算。

• 权重体积决定下限，运行时开销决定你的实际余量，两笔分开算
• 不同推理框架对同一权重的显存管理策略不一样，框架选型也是变量
• 如果只是日常问答、写文案，用蒸馏版或直接调 API 更省事，没必要为了「满血」两个字上硬件
• 真正需要原版的场景通常是：长链推理、对答案稳定性要求高、或者数据不能出内网

显存和带宽：真正的两道门槛

显存容量决定权重能不能装下，这是第一道门槛，装不下就直接出局。显存带宽和卡间互联决定输出快不快，这是第二道门槛，装得下但带宽不够，你等一个回答要等很久。两个指标要分开看，别混在一起说「我这卡行不行」。

粗算权重体积的方法是：参数量乘以每参数字节数，再给 KV 缓存、框架开销留出余量。实际上不同框架的运行时开销差别不小，所以别把显存按权重体积顶格配，至少留出能装下上下文的那部分空间。具体到当时的模型规格和卡型，到 /models/deploy 按现行数据算一遍，比记一个固定数字靠谱得多。

选卡之前，建议先到 /compute/sizing 把参数量、精度、上下文长度三个输入填进去，得到一个量级判断。这一步花几分钟，能省掉后面买错卡的麻烦。

量化档位怎么选：省显存要付什么代价

量化是绕不开的取舍。精度逐级往下调，权重体积变小、显存压力变小，但输出质量也会跟着变。没有哪一档是免费的午餐，你要做的不是找最优解，而是找一个你的任务能接受的平衡点。

长链推理任务对精度更敏感。量化过狠之后，容易出现推理链断裂、答案中途跑偏这类问题——它不会报错，但给出的答案悄悄变差了，这种问题最难发现。如果你的任务需要多步推理、代码生成或者严谨的数学推导，优先保精度。

1. 第一步：保守起步先用一档偏保守的量化把整个流程跑通，确认模型能加载、能回答、显存有余量。这一步的目标是「通」，不是「快」。
2. 第二步：准备对照集挑一批你自己的真实难题，覆盖长链推理、多轮追问、长上下文这几类，作为后续对比的基准。
3. 第三步：逐档降级降一档量化，用同一批难题跑一遍，对比答案稳定性和响应速度。重点看有没有出现推理链断裂。
4. 第四步：回退或定档一旦发现答案质量明显下滑，就回退到上一档。宁可多占一点显存，也别让输出质量悄悄变差。

量化相关的术语如果看着眼晕，可以到 /ai-dict/category/tech 对照一下，把名词先搞明白再动手。

装不下怎么办：卸载到内存还是上多卡

显存装不下的时候，有两条路：把部分权重卸载到内存，或者上多卡。这两条路都能让你跑起来，但代价不一样，适用场景也不一样。

部分卸载到内存适合验证和低频使用——你偶尔跑一次长任务，等一下能接受。但如果要多人共用，token 生成速度掉下来之后，排队等待会变成常态，体验很差。

多卡这条路，关键在卡间互联。简单堆两张卡不等于速度翻倍，如果互联带宽不够，跨卡通信会成为新瓶颈，实际加速比远低于你的预期。上多卡之前，先确认你的推理框架支持什么样的并行策略。

部署路径：从单机试跑到对外服务

部署不是一步到位的事，分两个阶段看：单机验证和对外服务。单机阶段的目标是确认权重、量化、显存这三件事对得上；服务阶段的目标是扛住并发、提供稳定接口。两阶段的工具选型可以完全不同。

单机验证建议用轻量工具，加载快、配置简单，出错也容易定位。确认没问题之后，再考虑换成面向服务的推理框架，那类框架在吞吐和并发调度上更强，但配置项也更多，出问题的排查成本更高。

单机验证

目标是跑通，用轻量工具快速确认权重、量化、显存三件事对得上

服务化框架

目标是扛并发，支持批处理、显存分片、容器化部署

容器化

把环境固化下来，换机器时不用重新折腾依赖

显存分片

多卡场景下把权重切开分布到各卡，需要框架支持

遇到加载失败或者推理报错，先别急着改配置，到 /ai-status 确认一下是不是服务侧本身的问题。很多时候你折腾半天，其实是上游在抖。

并发与吞吐：能不能给团队用

单卡能扛多少并发，不是卡本身决定的，而是显存余量、上下文长度和批处理策略三者共同决定的。上下文越长，占用的 KV 缓存越多，可用并发就越低。这一点很多人一开始没意识到，等到团队用起来才发现响应越来越慢。

量化并发能力之前，先量出你这条链路的延迟基线：在单人使用、固定上下文长度的情况下，从发出请求到收到完整回答要多久。有了这个基线，才能推算多人并发时的表现。

1. 量基线单人、固定上下文长度，记录响应延迟。到 /tools/speed-test 做一次对照，别凭感觉说「够用」。
2. 列需求把峰值并发、平均上下文长度、可接受的响应时间写成一张表，这是你反推卡数的依据。
3. 压测验证按峰值并发模拟一次，看延迟是否还在可接受范围内。这是唯一能验证「够不够用」的方法。
4. 留余量按实测结果再留一部分余量，别把卡跑到满载，满载时的稳定性谁都不敢保证。

许可证与使用边界：跑起来不等于能商用

权重开源不等于随便用。商用范围、署名要求、衍生模型的分发限制，这些都要逐条看许可证原文。很多人跑通之后直接拿去接客户，这一步的风险其实比技术风险更大。

公司内部使用和对外提供服务，适用的条款可能不一样。个人玩通了不代表团队能上，这个判断要做在部署之前，不是之后。

• 先确认你的使用场景属于哪一类：内部使用、对外服务、还是分发衍生模型
• 逐条核对许可证里的商用范围、署名要求、分发限制
• 拿不准就查原始许可证文本，别只看二手解读
• 把判断结论写下来留档，后面团队扩大使用时有据可依

一份可执行的决策清单

下面这份清单按顺序走一遍，能帮你把「要不要自建」这件事想清楚。顺序很重要，别倒着来。

1. 先定任务类型写清楚你要解决的问题属于哪一类：日常问答、长链推理、还是批量处理。这一步决定了后面所有取舍的方向。
2. 反推最小可用配置按任务选定最小可接受的量化档位，再算显存和卡数。不要反过来先买卡再找活干。
3. 单机验证用轻量工具把流程跑通，确认权重、量化、显存三件事对得上。
4. 评估许可证确认你的使用场景在许可证允许范围内，拿不准就查原文。
5. 再谈服务化单机验证通过之后，才考虑换服务化框架、扛并发、上容器化。
6. 留回退方案每一步都留一次回退的空间，量化降档不满意能退回，服务化出问题能退回单机。

选型阶段如果拿不准从哪个模型或哪个卡型起步，可以到 /models 看当时的模型资料和规格对比，把参数量、上下文长度这些基础参数先摸清楚，再进下一步。