简介一份文档系统梳理了 DeepSeek 平台的部署全流程适合具备一定服务器操作经验的运维人员、开发者和技术爱好者参考。内容从硬件、网络、操作系统、数据库与 Python 环境等前期准备讲起逐步覆盖安装包下载、数据库连接配置、依赖安装、初始化、Web 服务器反向代理与 SSL 证书设置、服务启动测试以及后续的用户权限管理、数据导入、性能调优、安全加固和日志监控等环节能够帮助读者避开常见部署误区快速完成从零搭建到上线运行。资源为单个 Word 文档格式为 doc整体仅 35KB内容紧凑且便于按章节查阅。这份资料已被 1539 人学习下载尤其适合初次接触 DeepSeek 或希望系统梳理部署步骤的读者按文档顺序操作即可获得一套完整、可落地的部署方案。1. 先泼盆冷水你要部署的 DeepSeek 和你以为的可能不一样如果你以为把 DeepSeek 部署起来等于在本地装了一个开箱即用的数据分析平台先停一下。所谓部署本质是把 DeepSeek 的开源模型权重下载到你自己的机器上跑成本地服务再通过 API 和周边组件组合出搜索与分析能力。一台 16G 显存显卡能跑吗能但跑的是蒸馏小模型不是官方 671B 参数的完整版两者在效果和资源占用上差了不止一个量级。这篇文章的目标读者想把数据留在本地、不想按 token 付费、需要离线服务的开发者或小团队。我会从选型讲到最小可复现的部署命令再到避坑和接入业务场景一条路走完。2. 部署前定方案模型版本、显存算法与推理引擎选型2.1 从完整版到蒸馏版先认清模型家族再动手DeepSeek 的开源模型大致分两类。一类是官方完整版671B 参数、MoE 架构完整部署需要企业级多卡集群显存堆到数百 GB 才谈得上稳定服务这不是大多数团队的第一选择。另一类是蒸馏版用完整模型生成的高质量数据训练出来的小模型常见档位从 1.5B、7B、8B、14B 一直到 32B、70B。蒸馏版保留了解题、推理、对话的基本能力但体积小一两个数量级16G 显存就能跑最小的几个档位。部署前第一件事不是装环境而是回答一个问题你的场景到底需要多大的模型纯知识库问答、文本分类、信息抽取7B 档位已经能打过不少在线服务复杂逻辑推理、长文档分析、代码生成建议 14B 或 32B70B 以上通常意味着你已经有明确的业务营收支撑且准备好了多卡服务器。模型档位选错后面所有调优都是白费这是我见过最多的返工原因。选档位前先把家底盘清楚# 查看有几块 GPU、每块多少显存、还剩多少可用 nvidia-smi --query-gpuname,memory.total,memory.free --formatcsv这段命令输出三列显卡型号、总显存、当前可用显存。注意看 memory.free 而不是只看 total因为可能有其他进程占着显存。我见过有同事盯着 total 32G 兴冲冲拉 32B 模型结果 free 只有 12G启动直接 OOM。先记下这个数字后面 2.2 的估算全靠它。2.2 显存怎么算权重、KV Cache 与量化档位显存占用由三部分组成模型权重、KV Cache、运行时激活值。权重最容易算参数量乘以单个参数需要的字节数BF16/FP16 精度下每个参数 2 字节INT8 是 1 字节INT4 是 0.5 字节。所以 7B 模型在 BF16 下权重约 14GBINT4 下约 3.5GB。KV Cache 与上下文长度强相关上下文越长、并发越高占用越大在长上下文场景下甚至可以占到总显存的 30% 以上。激活值在推理时动态变化量级小但不可忽略一般留 10% 余量。量化是用精度换体积的手段。Ollama 和 llama.cpp 生态里常见 GGUF 量化档位 Q4_K_M、Q5_K_M、Q8_0vLLM 生态里常见 AWQ 和 GPTQ 的 4bit 量化。Q4_K_M 是体积和质量的平衡点也是我默认首选的档位Q8_0 质量几乎无损但体积大一倍低于 Q4 的档位比如 Q2 不推荐输出质量崩坏的概率明显上升看上去省了显存实际省下的钱不够弥补返工。下面这段脚本可以帮你快速建立直觉# 估算不同档位模型在两种精度下的权重显存GB不含 KV Cache 和激活 models {1.5B: 1.5, 7B: 7, 14B: 14, 32B: 32, 70B: 70} for name, b in models.items(): bf16 b * 2 int4 b * 0.5 print(f{name}: BF16 ≈ {bf16:.0f}GB, INT4 ≈ {int4:.0f}GB)输出结果能直接对到显存档位7B 的 BF16 版本要求单卡 24G还得给 KV Cache 留空间INT4 版本 8G 卡就能跑。我通常用这个表快速筛掉不现实的组合然后再查具体模型的量化文件大小误差基本在 1-2GB 内。2.3 推理引擎对比Ollama、vLLM、LMDeploy 怎么选同一个模型不同推理引擎的部署体验和性能差异很大。我按实际使用的优先级介绍。Ollama 适合单机、开发测试和小并发场景安装一条命令模型管理也是命令行搞定它的底层是 llama.cpp 的推理实现CPU、GPU 都能跑。vLLM 适合生产环境和对外 API 服务核心优势是 PagedAttention 显存管理和 continuous batching并发吞吐比 Ollama 高一个量级OpenAI 兼容接口做得最完整。LMDeploy 在量化模型的推理效率上有独到之处和 AWQ 搭配很好但社区资料和周边生态不如前两者。如果你完全没有 GPUllama.cpp 可以纯 CPU 跑速度慢但能用。选型其实没有银弹。我的习惯是本地验证、内部演示用 Ollama要对外提供 API、要支持高并发、要多卡并行直接上 vLLM对显存抠得紧、要跑 4bit 量化模型对比一下 LMDeploy 和 vLLM 的实测吞吐再定。不要一上来就搭 vLLM它的启动参数、日志和显存报错对新手都不友好先用 Ollama 把模型跑通再迁移到 vLLM 也不迟。3. 用 Ollama 在单机跑通 DeepSeek最小命令到 OpenAI 兼容接口3.1 安装与检查环境确认显存再动手Ollama 的安装是整个过程里最没技术含量的一步但环境检查不能省。先跑下面这段确认驱动和 CUDA 环境正常再装 Ollama# 检查显卡驱动是否被系统识别 nvidia-smi # Linux 一键安装 Ollama官方脚本自动注册系统服务 curl -fsSL https://ollama.com/install.sh | sh # 确认安装成功并记录版本号 ollama --version说明一下环境变量curl 管道到 sh 的方式要求你能访问官方安装脚本如果是在内网离线环境去官网下载对应安装包或直接复制二进制到 /usr/local/bin 也行本质是一样的。装完后 Linux 下会自动启动一个 systemd 服务并监听 11434 端口不需要手动后台运行。macOS 和 Windows 有桌面安装包装完在终端里执行 ollama 命令即可。无论哪个系统安装完成后先用 ollama --version 确认不要急着拉模型。3.2 拉取模型与配置服务四个环境变量决定并发和上下文把 DeepSeek 蒸馏模型拉下来Ollama 一行命令# 拉取 7B 蒸馏模型默认 Q4_K_M 量化约 4.7GB ollama pull deepseek-r1:7b # 直接进入交互式对话验证模型可用 ollama run deepseek-r1:7b模型名里的 tag 决定了量化和档位deepseek-r1:7b 是 7B 档位 Q4_K_M 量化版想更强推理能力可以换 14b、32b、70b 等 tag。第一次 pull 会从远程仓库下载分片几 GB 到几十 GB 不等取决于模型档位。下载完成后 ollama run 会加载模型并进入对话输入 /bye 退出。这一步如果卡住参考第 5 章的“模型拉不下来”避坑条目。交互验证通过后把服务正式跑起来。Ollama 默认只监听本机且并发数很低需要用环境变量调整# 监听所有网卡局域网内其他机器也能访问 export OLLAMA_HOST0.0.0.0:11434 # 单请求上下文长度token数值越大模型能记住的对话越长 export OLLAMA_CONTEXT_LENGTH8192 # 同时处理的请求数默认 1调高提升并发但增加显存压力 export OLLAMA_NUM_PARALLEL4 # 启动服务与 run 不同serve 是常驻服务 ollama serve注意OLLAMA_CONTEXT_LENGTH 和 OLLAMA_NUM_PARALLEL 都会扩大 KV Cache 显存占用。16G 显存跑 7B 模型时8192 上下文和 4 并发是比较稳的组合换 14B 模型建议退回 4096 上下文和 2 并发否则启动阶段就可能 OOM。环境变量只对当前终端生效改成常驻配置要写到系统服务的环境变量文件里重启服务后才生效。提示OLLAMA_NUM_PARALLEL 调高后如果出现响应变慢不一定是并发不够可能是 KV Cache 被挤占导致每请求可用显存变小观察 nvidia-smi 再做增减。3.3 用 OpenAI 兼容接口做一次真实调用Ollama 提供 /v1 接口兼容 OpenAI 的 Chat Completions 规范。这意味着你手头现有基于 OpenAI SDK 写的代码只需要把 base_url 和 api_key 换掉就能指向本地 DeepSeek。先 curl 一把验证curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: deepseek-r1:7b, messages: [ {role: user, content: 用一句话解释数据搜索和数据清洗的区别} ], stream: false }返回的 JSON 里重点看三个字段choices 里是模型生成的回答正文usage 里有 prompt_tokens 和 completion_tokens 两个计数做成本核算和配额限制时依赖这两个数字model 字段确认响应的模型名。stream 参数如果改成 true会返回 SSE 流式响应适合做打字机效果但调试时建议先关掉流式方便看完整 JSON。Python 侧更简单直接用 OpenAI 官方 SDKfrom openai import OpenAI # base_url 指向 Ollama 的 /v1 端点api_key 填任意非空字符串 client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, ) resp client.chat.completions.create( modeldeepseek-r1:7b, messages[{role: user, content: 一个 7B 模型能处理多长的文档}], temperature0.7, max_tokens512, ) print(resp.choices[0].message.content)temperature 是采样温度数值越高回答越发散知识问答建议 0.3 以下闲聊可以到 0.7-0.9。max_tokens 限制单次生成的最大 token 数设太大响应会慢设太小回答会被截断。api_key 在本地服务下不参与鉴权随便填一个非空字符串让 SDK 通过校验即可。到这一步你的 DeepSeek 已经是一个标准的本地 API 服务可以接进任何业务系统了。4. 用 vLLM 部署生产级服务吞吐、多卡并行与压测4.1 安装 vLLM 并启动第一个模型服务如果 Ollama 满足不了并发了下一个选择是 vLLM。它的部署不复杂但参数比 Ollama 多理解每个参数比抄命令更重要。先装环境# 准备 Python 3.9 环境强烈建议用虚拟环境隔离 python -m venv .venv source .venv/bin/activate # 安装 vLLM包含推理引擎和 serve 命令 pip install vllmvLLM 在启动时会自动从模型仓库拉取权重前提是这台机器能访问。内网环境可以先把权重文件下载好再用本地路径替换下面的模型名。启动一个 7B 蒸馏模型的最小命令# 启动 vLLM 服务deepseek-r1-7b 是暴露给客户端的模型名 vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek-r1-7b \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.85 \ --max-model-len 8192 \ --dtype bfloat16逐项说明第一段模型名是模型仓库上的权重路径客户端不可见--served-model-name 才是客户端调用时用的模型 ID很多线上事故就是这里没设客户端拿默认路径请求导致 404--gpu-memory-utilization 控制显存利用率上限默认 0.9 太激进新环境先用 0.85--max-model-len 是最大上下文长度它直接决定 KV Cache 预留量--dtype bfloat16 是权重加载精度7B、14B 档位没问题显存紧可以改 AWQ 量化版。启动日志里看到类似 “Starting vLLM server” 和 “Application startup complete” 才算成功。4.2 多卡张量并行与 AWQ 量化加载模型档位升到 14B 以上单卡 24G 就吃力了多卡是常态。vLLM 的张量并行把一张大模型拆到多张卡上每张卡持有模型的一部分权重推理时协同计算。32B 模型在 4 张 16G 卡上可以跑 BF16 精度但显存会非常紧# 先限定可用 GPU再指定并行度避免 vLLM 捡到不应使用的卡 CUDA_VISIBLE_DEVICES0,1,2,3 vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-32B \ --served-model-name deepseek-r1-32b \ --tensor-parallel-size 4 \ --gpu-memory-utilization 0.85 \ --max-model-len 16384tensor-parallel-size 必须不大于 CUDA_VISIBLE_DEVICES 中指定的卡数且多卡型号、显存尽量一致系统按最小那块卡的可用显存来评估能否加载。混插卡比如一张 24G 加三张 16G跑张量并行很容易在启动时收到显存不足的报错因为权重按最小卡切分。显存不够又必须跑大模型时换量化版# 用 AWQ 4bit 量化模型替代 BF1614B 权重从 28GB 降到约 10GB vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-14B-AWQ \ --served-model-name deepseek-r1-14b-awq \ --quantization awq \ --max-model-len 8192AWQ 是 vLLM 支持较好的 4bit 量化方案模型仓库名里带 AWQ 后缀时--quantization awq 要显式声明否则 vLLM 可能按原始精度加载轻则显存翻倍重则直接报错。量化版本的推理质量比 BF16 略降但在知识问答、检索增强这类任务上差别不大如果你要做的是深度推理或代码生成建议用 BF16 并接受更高的硬件成本。4.3 压测脚本与显存观测上线前先看这两个数字服务启动后不要急着接业务先跑一轮压测。压测的目的不是跑出一个漂亮的数字而是确认两件事并发上来后延迟是否还在可接受范围显存是否会在长时间运行后缓慢增长即是否存在泄漏。下面这个脚本用 AsyncOpenAI 并发打 20 个请求import asyncio import time from openai import AsyncOpenAI # 指向 vLLM 的 OpenAI 兼容端点 client AsyncOpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) async def one_call(prompt: str) - float: start time.time() await client.chat.completions.create( modeldeepseek-r1-7b, messages[{role: user, content: prompt}], max_tokens128, ) return time.time() - start async def main(): prompts [讲一个技术冷笑话] * 20 start time.time() latencies await asyncio.gather(*[one_call(p) for p in prompts]) total time.time() - start avg_latency sum(latencies) / len(latencies) print(f平均单请求延迟: {avg_latency:.2f}s) print(f20 请求总耗时: {total:.2f}s吞吐约 {20 / total:.2f} req/s) asyncio.run(main())这个脚本刻意不加超时重试目的是暴露问题而不是掩盖问题。读结果时注意区分两个数平均单请求延迟反映的是每个用户的体感总耗时和吞吐反映的是服务整体能力。如果平均延迟很短但总耗时很长说明请求在排队并发处理能力见底这时该调大 --max-num-seqs 或升级硬件。如果平均延迟本身就高问题可能在单请求的 max_tokens 过长或 GPU 计算瓶颈。压测同时开一个终端盯显存# 每秒刷新一次显存占用 nvidia-smi -l 1重点看 GPU-Util 和 Memory-Used 两列。显存打满但 GPU-Util 长期低于 50%瓶颈大概率不在 GPU 计算而在数据预处理或 CPU 传输此时换更快的 CPU、调大 batch 比加显卡管用。显存随时间缓慢但持续上涨十有八九是服务有内存泄漏先查 vLLM 的日志里是否有 OOM 重试记录。5. DeepSeek 部署避坑指南五个高频翻车现场5.1 模型拉不下来卡在 pulling 进度条怎么办现象是 ollama pull 之后进度条长时间不动或者速度只有几十 KB/s有时还会失败回退重传。原因通常在网络链路Ollama 的模型仓库走海外对象存储网络环境下的连接质量不稳定分片多时会反复超时。解决思路不是反复重试而是换一条路找一个网络稳定的机器先下载 GGUF 格式的量化模型文件再通过 Ollama 的导入功能本地封装。先在当前目录写好 Modelfile# Modelfile指定本地 GGUF 文件路径 FROM ./deepseek-r1-7b.Q4_K_M.gguf然后执行# 用 Modelfile 创建本地模型deepseek-r1-local 是自定义模型名 ollama create deepseek-r1-local -f Modelfile # 验证导入成功并能正常对话 ollama run deepseek-r1-local导入的关键是 Modelfile 里 FROM 的路径必须指向真实存在的 .gguf 文件且路径不能带空格。ollama create 只是做封装不会重新下载所以导入几乎瞬时完成。这条路的代价是你得自己找 GGUF 文件的下载渠道并校验文件完整性但比起卡在 pull 上干等更可控。5.2 启动即 OOMCUDA out of memory 的三个原因现象是 vllm serve 启动几秒后直接报 CUDA out of memory连带一段 torch 的显存分配栈信息。最常见原因是 --gpu-memory-utilization 设过高比如默认的 0.9第二常见是机器上有其他进程比如另一个模型、浏览器、桌面环境在抢显存第三是 --max-model-len 过大KV Cache 预留超出了剩余显存。解决顺序先查剩余显存再降参数最后换量化。# 查看真实可用的显存而不是总显存 nvidia-smi --query-gpumemory.total,memory.free --formatcsv拿到 memory.free 之后把 --gpu-memory-utilization 调到 0.8--max-model-len 从 8192 降到 4096 再试。如果还是 OOM基本可以判断是模型档位超出了硬件上限要么换更小档位要么换 AWQ 量化版。注意 OOM 报错不一定出现在启动瞬间也可能在第一次请求时出现这通常是 KV Cache 按请求动态分配导致调小 max-model-len 和并发限制即可。5.3 并发一高就假死排队、超时与队列参数现象是单个请求正常并发一上来响应越来越慢最后连接超时服务看起来像假死。Ollama 默认每个模型实例只能串行处理请求并发请求全部排队而 vLLM 虽然支持 continuous batching但如果 --max-num-seqs 设置过小请求一样会堆积。先分清是哪一种Ollama 就调环境变量 OLLAMA_NUM_PARALLEL 和 OLLAMA_MAX_LOADED_MODELS前者控制单模型并发后者控制同时加载几个模型vLLM 就调 --max-num-seqs它限制推理引擎中同时处理的序列数。我一般把 Ollama 的并发调到 4 就不再往上再高就迁移 vLLM硬调 Ollama 的并发只会换来更频繁的 OOM。还有一种假死原因请求的输入上下文过长每个请求的 prefill 阶段占满 GPU后续请求全部排队。这种情况用压测脚本复现时把 max_tokens 调大、prompt 调长观察延迟曲线是否从某一点起剧烈上升。是的话除了限制并发还要在接入层限制单请求的最大输入长度。5.4 中文输出乱码与重复采样参数和量化惹的祸现象是回答里出现整段重复、句子循环、莫名多出半个字符。如果所有请求都这样先怀疑量化档位Q2 一类的过度量化会明显破坏输出质量换回 Q4_K_M 或 BF16 再测如果只是部分请求这样问题在采样参数。DeepSeek 的蒸馏模型对 temperature 和 repetition_penalty 比较敏感temperature 太高容易发散和重复太低容易输出平淡常见有效区间是 0.6-0.7配合 repetition_penalty 1.05-1.1 使用。vLLM 可以通过启动参数直接固定# 用 vLLM 固定采样参数避免客户端乱传参数导致输出失控 vllm serve deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek-r1-7b \ --temperature 0.7 \ --repetition-penalty 1.1 \ --max-model-len 8192还有一种“乱码”其实是截断max_tokens 设成 128回答写到一半被强行掐断看起来像故障。服务端把 max_tokens 设到 512 以上客户端确认没有覆盖这个值。排查时先用 curl 不带 stream 请求一次把完整 JSON 打出来看 finish_reason——如果是 length说明是截断不是生成异常。5.5 长对话失忆上下文长度设置不当的表现与修正现象是对话进行到十几轮之后模型开始忘记用户早期提供的信息比如前面说过“数据源是 MySQL”后面问它数据源是什么它答不上来。原因通常是上下文长度被截断Ollama 默认 OLLAMA_CONTEXT_LENGTH 只有 2048长对话早把最早的 token 挤出上下文窗口。vLLM 侧则是 --max-model-len 设置过小或过大导致的分配问题。排查方法Ollama 的日志会打印每次请求的上下文 token 数看它是不是步步逼近上限vLLM 可以在响应里对比 prompt_tokens 和 max-model-len 的关系。解决分两层。第一层是调大上下文Ollama 设 OLLAMA_CONTEXT_LENGTH8192 或更高vLLM 调 --max-model-len注意显存代价。第二层是改产品设计与其依赖模型硬记长对话不如把关键信息通过 RAG 注入到每一轮的系统提示词里。很多所谓的“模型失忆”其实是产品设计把不该交给模型记忆的事情强行塞给了上下文窗口。部署层面调参只能延迟失忆出现的位置根治要靠检索增强第 6 章给的例子就是干这件事的。6. 部署完不止会聊天把 DeepSeek 接成数据搜索分析后端6.1 最小 RAG 闭环Embedding 检索 DeepSeek 生成DeepSeek 部署完你拿到的只是一个会对话的模型离“数据搜索分析”还差一个检索层。最常见的落地方式是 RAG先把你业务里的文档、表结构说明、指标口径切块做向量化查询时先用向量检索找出最相关的几段拼进 prompt 交给 DeepSeek 生成回答。这样做有两个好处模型不需要记住你的全部业务知识更新知识只需要刷新向量库不需要重新训练模型。下面是一个最小闭环Embedding 走 Ollama 的 bge-m3对话生成走 vLLM 或 Ollama 都行from openai import OpenAI import faiss import numpy as np # 两个不同的 base_urlembedding 用 Ollamachat 用 vLLM或两者都用 Ollama embed_client OpenAI(base_urlhttp://localhost:11434/v1, api_keyollama) chat_client OpenAI(base_urlhttp://localhost:8000/v1, api_keyEMPTY) def embed(texts): resp embed_client.embeddings.create(modelbge-m3, inputtexts) return np.array([d.embedding for d in resp.data], dtypefloat32) # 三份业务切片的简化示例生产环境替换成真实文档分块 chunks [ 数据血缘描述数据在加工链路中的来源与去向用于排查问题, 指标口径不一致是数据质量问题最常见的根因之一, 数据搜索将自然语言问题转换为结构化查询并返回结果, ] vec embed(chunks) index faiss.IndexFlatIP(vec.shape[1]) index.add(vec) def search(question, top_k2): q_vec embed([question]) scores, ids index.search(q_vec, top_k) return [chunks[i] for i in ids[0]] def ask(question): snippets search(question) context \n\n.join(f[{i1}] {s} for i, s in enumerate(snippets)) resp chat_client.chat.completions.create( modeldeepseek-r1-7b, messages[{role: user, content: f只根据以下资料回答问题不要使用资料之外的知识。\n资料\n{context}\n\n问题{question}}], temperature0.3, ) return resp.choices[0].message.content print(ask(数据质量问题的常见根因是什么))这段代码演示了 RAG 的最小骨架embed 负责把文本向量化faiss.IndexFlatIP 用内积做相似度检索search 返回最相关的切片ask 把切片拼进 prompt 后交给 DeepSeek 生成。temperature 设到 0.3 是为了让回答尽量贴近资料原文这是知识问答和闲聊最大的区别。提示词里“只根据资料回答问题”这句不能省否则模型会用自身常识脑补产生看似合理实则错误的幻觉。生产环境要补的还有文档切片策略、向量库持久化、增量更新和权限控制但骨架就是这几行。RAG 上线后要盯一个指标检索召回率。如果查出来的 Top-1 切片本身不对模型再聪明也答不对这是 RAG 项目里的普遍教训。切片太长会把无关内容带进来太短会丢失上下文通常先按 200-500 字切再看效果微调。6.2 部署验收清单六项检查跑完再交付接完业务逻辑最后用这张清单做一次上线前验收。我每次部署新模型都跑一遍耗时大约半小时能挡住九成线上问题。检查项操作方法通过标准接口连通性curl http://localhost:8000/v1/models返回 200 且模型名正确单请求延迟压测脚本单并发max_tokens128平均延迟不超过 5 秒并发吞吐20 并发观察失败率和超时无超时吞吐不低于 2 req/s显存稳定性nvidia-smi -l 1 连续观察 1 小时显存占用平稳无 OOM回答质量准备 20 道领域问题人工打分可接受率不低于 80%长对话稳定性连续 50 轮包含固定信息的对话固定信息仍能被正确引用回答质量这一项最容易敷衍也最值得认真做。挑 20 道题时不要只选模型擅长的把边界 case 放进去比如数据缺失、问题含歧义、检索结果为空——这些场景在线上每天都在发生。跑完清单如果并发这项没通过回头调 --max-num-seqs 和 --gpu-memory-utilization别硬上。最后说一个我的习惯所有配置变更都留档。当前用哪个模型、哪个量化档位、上下文多长、压测数据是多少写在一个 Markdown 文件里。你会在三个月后回来改模型配置如果那时已经忘了当初为什么选 Q4_K_M 而不用 Q8_0你只能重新做一轮选型这是最贵的时间成本。把 nvidia-smi 的输出和压测结果存下来对比着看比任何口头交接都可靠。部署 DeepSeek 这件事卡住你的从来不是命令不够多而是没想清楚边界硬件边界、模型边界、并发边界。先把这一次部署的目标定小一点——跑通最小闭环记录一组基线数据再去优化。我见过太多团队第一步就想着全套生产架构结果卡在显存上一个月没进展。希望帮到你。本文还有配套的精品资源点击获取