企业官网建设流程全解析

简介：这份PDF面向希望在本地或服务器上运行DeepSeek-R1 70B大模型的开发者与AI爱好者，聚焦Ollama推理框架的完整部署流程，帮助解决从模型下载、量化选择到远程访问验证的实操问题。资源为1个PDF文件，约430KB，内容涵盖GGUF格式模型获取、Q5_K_M量化说明、Modelfile模板与参数配置、模型实例创建及服务验证等关键环节，并附有命令示例与界面截图辅助理解。目前已有2508人学习下载，适合具备一定Linux与命令行基础、希望低成本本地部署大模型的中高级用户参考。读者可从中获得量化级别与精度体积的权衡思路、Ollama环境变量与远程访问配置方法、对话终止符与上下文窗口等参数设置技巧，以及部署过程中常见问题的排查方向，便于快速搭建可交互的DeepSeek-R1 70B推理服务。

1. 本地跑 70B 这件事，卡点从来不在模型本身

ollama 部署 deepseek-r1 70B 模型完整指南，这个标题背后其实藏着一个很具体的诉求：手里有一台还算像样的机器，想在不依赖外部接口的前提下，把 70B 级别的推理模型跑起来，并且能稳定地对外提供问答能力。真正动手过的人都知道，模型权重下载只是第一步，后面显存怎么分、量化选哪档、上下文开多大、并发上来之后会不会直接 OOM，才是决定这套东西能不能用的关键。这篇笔记按我自己的落地顺序拆开讲：先讲清楚 70B 在本地意味着什么量级的资源，再给一套能照着敲的部署流程，然后把量化档位、上下文长度、并发这几个必调参数摊开说，最后把我在实际环境里踩过的坑列出来。适合已经用过 ollama 跑小模型、现在想往 70B 这个量级推一步的开发者，也适合评估「本地 70B 到底值不值得投入」的团队做参考。

2. 先算清楚 70B 的账：显存、量化与硬件底线

2.1 70B 参数到底吃掉多少显存

很多人对 70B 的显存占用没有概念，以为和 7B 差十倍就完事了。实际不是线性关系。推理阶段的显存主要分三块：模型权重、KV Cache、运行时开销。权重部分按量化精度算，FP16 下 70B 大约需要 140GB 左右，这个数字直接把单卡消费级方案排除掉了。INT8 大约 70GB，INT4 大约 35GB 到 40GB，再往下还有更激进的低比特量化，但质量损失会明显起来。

KV Cache 是第二个大头，它和上下文长度、批大小成正比。上下文开到 32K、并发给到 4 的时候，KV Cache 本身就能吃掉十几 GB。所以你不能只看权重能不能塞进去，得把 KV Cache 的峰值也算上。我一般的做法是：先按「权重 + 预留 30% 给 KV Cache 和运行时」来估总显存需求，这样留出的余量在实际跑起来之后不容易翻车。

运行时开销这块容易被忽略。ollama 底层依赖推理引擎，加载模型、做图优化、维护中间张量都要占显存，通常留 2GB 到 4GB 比较稳妥。综合下来，INT4 量化跑 70B，单卡 48GB 是比较舒服的起点，24GB 卡要靠 CPU 卸载硬撑，速度会掉得很难看。

2.2 量化档位怎么选：Q4_K_M 是默认答案但不是唯一答案

ollama 支持的量化档位里，和 70B 搭配最常见的是 Q4_K_M、Q4_K_S、Q5_K_M、Q8_0 这几档。选哪档不是拍脑袋，要看你更在意质量还是更在意能不能跑起来。

Q4_K_M 之所以成为默认答案，是因为它在质量和体积之间取得了比较好的平衡，绝大多数任务上和更高精度的差距不容易被肉眼感知。但如果你的任务对细节敏感，比如长文档摘要、代码生成，Q5_K_M 会明显更稳。代价就是显存需求往上跳一档，单卡 48GB 就比较勉强了。

提示：不要一上来就冲 Q8_0。先跑通 Q4_K_M，确认整条链路没问题，再根据质量反馈决定要不要升档。直接上高精度，很可能卡在加载阶段就动不了。

2.3 硬件底线：单卡、双卡还是 CPU 卸载

硬件这块我给三条线。第一条线是单卡 48GB，跑 Q4_K_M 比较从容，上下文开到 16K、并发 2 到 4 没问题。第二条线是双卡 24GB，靠张量并行把权重摊开，能跑 Q4_K_M，但卡间通信会带来额外延迟，实际吞吐不如单卡 48GB。第三条线是单卡 24GB 加 CPU 卸载，能加载起来，但推理速度会掉到每秒几个 token，只适合验证功能，不适合对外服务。

CPU 卸载的原理是把部分层放在内存里，需要的时候再搬到显存算。这个搬运过程走 PCIe，带宽远低于显存内部，所以速度瓶颈非常明显。如果你的场景对延迟有要求，CPU 卸载只能当临时方案。我一般会建议：要么把显存堆够，要么就退到 32B 这个量级，不要硬上 70B 再靠卸载续命。

3. 从零跑通：ollama 拉取、加载与最小验证

3.1 安装 ollama 并确认运行环境

第一步是把 ollama 装好。Linux 下用官方脚本最省事，装完确认服务在跑。

# 安装 ollama curl -fsSL https://ollama.com/install.sh | sh # 确认服务状态 systemctl status ollama # 查看版本，确认安装成功 ollama --version

装完之后不要急着拉模型，先确认两件事：一是 GPU 驱动和容器运行时是否正常，二是 ollama 有没有识别到你的显卡。用ollama ps看当前加载的模型，用nvidia-smi看显存占用。如果 ollama 没识别到 GPU，后面加载 70B 会直接走 CPU，速度会让你怀疑人生。

# 确认 ollama 是否识别到 GPU ollama ps # 查看显存占用和 GPU 状态 nvidia-smi

逻辑说明：ollama ps列出当前已加载的模型及其资源占用，如果 GPU 一栏显示的是 CPU，说明推理引擎没拿到显卡。nvidia-smi用来交叉验证显存是否被正确占用。参数上没什么可调的，这一步纯粹是环境体检。

3.2 拉取 deepseek-r1 70B 并做最小推理

模型拉取这一步，网络和磁盘是主要变量。70B 的 Q4_K_M 大概 40GB 上下，磁盘要留够空间，网络不稳的话建议挂后台拉。

# 拉取 70B 量化版本，具体 tag 以本地可用为准 ollama pull deepseek-r1:70b # 拉完之后确认模型在列表里 ollama list # 做一次最小推理，验证模型能正常加载和输出 ollama run deepseek-r1:70b "用一句话解释什么是量化"

逻辑说明：ollama pull会把权重下载到本地模型目录，默认在/usr/share/ollama/.ollama/models或者用户目录下的.ollama/models。ollama list确认模型已经注册。ollama run会触发加载，第一次加载会慢一些，因为要把权重读进显存并做图优化。如果这一步卡住或者报显存不足，先别怀疑模型，去看显存占用和量化档位是否匹配。

参数说明：deepseek-r1:70b这个 tag 对应的具体量化档位取决于仓库里的默认配置，如果你需要指定 Q4_K_M 或 Q5_K_M，可以用对应的完整 tag。拉取之前建议先确认本地磁盘剩余空间，40GB 只是权重，加上缓存和临时文件，留 60GB 比较稳。

3.3 用 API 方式对外提供服务

命令行验证通过之后，下一步是把它变成可调用的服务。ollama 默认在 11434 端口提供 HTTP 接口，直接用 curl 就能测。

# 启动服务（如果没在跑） ollama serve # 用 API 发一次请求 curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:70b", "prompt": "解释一下 KV Cache 的作用", "stream": false }'

逻辑说明：/api/generate是 ollama 的生成接口，stream设为 false 会等生成完一次性返回，方便调试。生产环境一般用stream: true做流式输出，降低首 token 延迟。model字段要和ollama list里的名字一致，写错了会直接报模型不存在。

参数说明：这个接口还支持options字段，可以覆盖温度、上下文长度、最大生成 token 等。比如"options": {"num_ctx": 16384, "temperature": 0.6}。这些参数在下一章会展开讲，这里先跑通链路。

4. 必调参数：上下文、并发与显存的三方博弈

4.1 num_ctx 开多大才不炸

num_ctx是 ollama 里最容易被低估的参数。它决定上下文窗口大小，直接吃 KV Cache。默认值通常比较保守，但很多人为了处理长文档会直接拉到 32K 甚至 128K，结果就是显存爆掉或者速度骤降。

KV Cache 的占用和num_ctx近似线性。以 70B 为例，上下文从 4K 拉到 32K，KV Cache 可能从 2GB 涨到 16GB 以上。如果你只有单卡 48GB，权重占了 40GB，留给 KV Cache 的空间本来就不多，这时候开大上下文就是自找麻烦。

我的做法是分场景设：日常问答 4K 到 8K 够用，长文档处理 16K 到 32K，再往上就要考虑是不是该换方案了。设置方式是在 API 请求的options里指定，或者用 Modelfile 固化。

# 在请求里覆盖上下文长度 curl http://localhost:11434/api/generate -d '{ "model": "deepseek-r1:70b", "prompt": "总结下面这段文字", "options": { "num_ctx": 16384, "temperature": 0.6 }, "stream": false }'

逻辑说明：num_ctx设成 16384 表示上下文窗口 16K，KV Cache 会按这个上限预分配。temperature控制随机性，deepseek-r1 这类推理模型一般建议 0.5 到 0.7 之间，太低会死板，太高会跑偏。

参数说明：如果你不确定显存能不能撑住，可以从小到大试，每次翻倍，同时用nvidia-smi盯显存峰值。一旦接近上限就回退一档。不要一次性拉到最大再往回找，那样很容易在加载阶段就失败。

4.2 并发数怎么定：OLLAMA_NUM_PARALLEL 的取舍

并发是第二个吃显存的变量。ollama 用OLLAMA_NUM_PARALLEL控制同时处理的请求数，默认值通常比较低。调高并发能提升吞吐，但每个并发实例都要独立的 KV Cache，显存占用会成倍增长。

假设单请求 16K 上下文占 8GB KV Cache，并发开到 4 就是 32GB，加上 40GB 权重，直接超过 48GB。所以并发和上下文要一起算，不能分开调。

# 设置并发数，重启服务生效 export OLLAMA_NUM_PARALLEL=2 systemctl restart ollama # 确认环境变量生效 systemctl show ollama | grep Environment

逻辑说明：OLLAMA_NUM_PARALLEL是进程级环境变量，改完要重启服务。设成 2 表示同时处理两个请求，第三个请求会排队。这个值不是越大越好，超过显存承受范围会触发 OOM 或者频繁换页，反而拖慢整体响应。

参数说明：单卡 48GB 跑 Q4_K_M，我一般把并发控制在 2 到 4，上下文不超过 16K。如果是双卡，可以适当放宽，但要考虑卡间通信开销。实际压测的时候用ab或者自己写脚本打并发，观察 P99 延迟和显存峰值，找到拐点再定。

4.3 显存不够时的三个降级路径

显存不够是 70B 部署里最常见的翻车点。真遇到了，有三条路可以走，按优先级排。

第一条是降量化档位，从 Q4_K_M 换到 Q4_K_S，体积能省几个 GB，质量损失在可接受范围内。第二条是降上下文，把num_ctx从 16K 砍到 8K，KV Cache 直接减半。第三条是降并发，把OLLAMA_NUM_PARALLEL设成 1，牺牲吞吐保稳定。

这三条可以组合用。我的习惯是先降上下文，因为对大多数问答场景来说 8K 已经够用，降下来对体验影响最小。如果还不够，再考虑量化档位。并发是最后动的，因为它直接影响服务能力。

注意：不要用 CPU 卸载来「解决」显存不够。它只是把问题从显存转移到速度上，实际体验会更差。宁可降配置，也不要让模型跑在 PCIe 带宽上。

5. 避坑与排查：70B 部署里最容易翻车的五件事

5.1 模型加载卡住不动，日志里没有明显报错

现象：执行ollama run之后长时间没反应，nvidia-smi显示显存占用在涨但很慢，最后可能超时或者直接退出。

原因：多数情况是磁盘 IO 瓶颈。70B 权重 40GB 上下，如果模型目录在机械盘或者网络存储上，读取速度跟不上，加载时间会被拉得很长。另一个可能是显存碎片，之前跑过其他模型没释放干净。

解决：把模型目录放到本地 SSD 上，确认df -h里模型所在分区有足够空间和正常读写速度。如果是显存碎片，重启 ollama 服务再试。加载期间用iostat看磁盘读带宽，如果一直跑不满，基本就是存储的问题。

5.2 推理速度只有每秒几个 token

现象：模型能加载，也能出结果，但速度慢到没法用，nvidia-smi显示 GPU 利用率很低。

原因：最常见的是部分层被卸载到了 CPU。ollama 在显存不够的时候会自动做部分卸载，但这个行为不一定在日志里显眼地提示。另一个原因是量化档位选得太高，权重体积超过了显存实际上限，引擎被迫走内存。

解决：先确认ollama ps里 GPU 占用比例，如果显示的是部分 CPU，说明发生了卸载。这时候要么降量化档位，要么降上下文和并发，把显存需求压到显卡能完全容纳的范围。用nvidia-smi dmon观察推理过程中的 GPU 利用率，正常应该在 80% 以上，如果长期低于 50%，基本可以确定有卸载。

5.3 并发一上来就 OOM

现象：单请求正常，压测到并发 3 或 4 的时候服务崩溃，日志里出现显存分配失败。

原因：KV Cache 是按并发数成倍增长的，很多人只算了权重的显存，没算并发带来的 KV Cache 增量。另外 ollama 的并发模型是每个请求独立分配 KV Cache，不是共享的。

解决：把OLLAMA_NUM_PARALLEL降下来，同时把num_ctx也降一档，两个参数一起调。压测的时候逐步加并发，每加一档观察显存峰值，找到安全上限。不要直接按理论值设，实际开销总比算出来的多。

5.4 输出质量明显下降，答非所问

现象：模型能跑，速度也正常，但回答质量比预期差很多，经常跑题或者重复。

原因：量化档位太低是主因。Q4_K_S 在 70B 上虽然能跑，但质量损失比 Q4_K_M 明显。另一个可能是temperature设得不对，太高会导致输出发散，太低会陷入重复。

解决：先换回 Q4_K_M 对比，如果质量明显回升，说明是量化的问题。然后调temperature，推理类任务建议 0.5 到 0.7，事实性问答可以降到 0.3 到 0.5。如果换了量化档位还是不行，检查 prompt 模板是否匹配 deepseek-r1 的格式要求，格式不对也会导致质量下降。

5.5 服务跑一段时间后变慢，重启才恢复

现象：刚启动的时候速度正常，跑几个小时后响应越来越慢，重启 ollama 就恢复。

原因：长时间运行会积累显存碎片，尤其是频繁加载卸载或者并发波动大的时候。另一个可能是 KV Cache 没有及时释放，导致可用显存越来越少。

解决：设置定期重启策略，比如每天凌晨重启一次 ollama 服务。如果业务不允许中断，可以用两个实例做轮换。另外检查是不是有请求超时后没正确释放资源，在客户端加超时和重试逻辑，避免僵死请求占着 KV Cache。

6. 把 70B 用稳的几个进阶习惯

跑通 70B 只是起点，真正决定这套东西能不能长期用的是几个日常习惯。第一个习惯是给模型目录单独挂一块 SSD，不要和系统盘或者数据盘混用。70B 的权重读取是重 IO 操作，存储拖后腿的话，再好的显卡也白搭。我一般会留一块至少 200GB 的 NVMe 专门放模型，换模型、升量化档位都不用担心空间。

第二个习惯是压测先行。任何参数调整之前，先用固定的一组 prompt 打一遍基线，记录首 token 延迟、每秒 token 数和显存峰值。调完参数再打一遍，对比数据决定是否保留。凭感觉调参是玄学，有基线数据才是工程。压测脚本不用复杂，一个循环发请求、记录时间戳的 Python 脚本就够。

import requests import time # 基线压测：固定 prompt，记录首 token 和总耗时 prompts = ["解释量化", "什么是 KV Cache", "总结注意力机制"] * 3 url = "http://localhost:11434/api/generate" for p in prompts: start = time.time() resp = requests.post(url, json={ "model": "deepseek-r1:70b", "prompt": p, "stream": False, "options": {"num_ctx": 8192, "temperature": 0.6} }) elapsed = time.time() - start tokens = resp.json().get("eval_count", 0) print(f"耗时 {elapsed:.2f}s, 输出 {tokens} tokens, 速度 {tokens/elapsed:.1f} tok/s")

逻辑说明：这段脚本对同一组 prompt 循环请求，记录每次的总耗时和输出 token 数，算出每秒 token 数。eval_count是 ollama 返回的生成 token 数，用它除以耗时就是实际速度。跑之前确认服务在运行，跑的时候用nvidia-smi dmon同步观察显存和 GPU 利用率。

参数说明：num_ctx和temperature要和实际服务配置一致，否则基线没有参考价值。prompt 数量建议 10 条以上，覆盖不同长度和类型，单条太短的话首 token 延迟占比过高，数据会失真。

第三个习惯是给服务加一层健康检查。ollama 本身没有复杂的健康检查接口，但可以用一个轻量 prompt 定期探测，比如每隔 30 秒发一次「回复 OK」，如果连续失败或者延迟超过阈值就触发告警。这样能在用户感知之前发现服务退化。

第四个习惯是记录每次变更。量化档位、上下文、并发、环境变量，任何一项改动都记下来，附上压测数据。70B 这套东西参数多，过两周回头看很容易忘了当时为什么这么设。有记录才能复盘，才能在下一次调整的时候不重复踩坑。

最后一个习惯是留好退路。70B 不是所有场景都值得上，如果压测下来延迟和吞吐达不到业务要求，果断退到 32B 或者更小的模型。本地部署的价值在于可控和隐私，不在于参数规模。我见过太多为了「跑 70B」而跑 70B 的情况，最后服务体验还不如一个小模型加好的 prompt 工程。选型的时候先问清楚业务到底需要什么，再决定要不要为 70B 投入这些硬件和调参成本。希望帮到你。

本文还有配套的精品资源，点击获取