这次我们不看概念直接看一套能落地的组合两台算力节点本地加载 DeepSeek 系列模型再压一轮并发请求看服务到底扛不扛得住。文章标题里的版本号“DeepSeek-V4-Flash-0731”我按它作为验证对象来处理但所有涉及权重文件、模型仓库 ID、发布状态的内容一律以官方渠道为准如果你本地还没有对应权重用同量级的 DeepSeek 开源模型走相同流程即可。先讲清楚标题里的 Spark。很多人第一反应是 Apache Spark 大数据引擎但在这个本地推理场景里把它理解成“两个算力节点/推理节点的代号”更合适。文章不会让你跑 MapReduce重点就两件事DeepSeek 本地推理服务能不能稳定启动以及并发压测下延迟、吞吐和显存表现如何。适合谁看想在内网私有化部署大模型的人想把 DeepSeek 接入自己业务系统做接口中转的人以及想给推理服务做容量评估的运维和开发。本文会按“环境准备 → 部署启动 → 功能测试 → 接口调用 → 并发压测 → 性能观察 → 问题排查 → 最佳实践”的顺序展开所有命令都是可直接复制的通用模板。有一点必须先说每个压测数字都要以你自己机器上的实测结果为准下面所有表格里的数值项也请你替换成自己跑出来的数据。1. 核心能力速览能力项说明方案类型DeepSeek 本地推理 双节点并发压测模型版本DeepSeek-V4-Flash-0731权重以官方仓库为准部署形态两台算力节点独立推理服务或网关统一接入启动方式vLLM / Ollama / llama.cpp 命令行启动接口能力OpenAI 兼容接口/v1/models、/v1/chat/completions批量任务通过并发脚本、消息队列或 nginx 负载均衡实现推荐硬件NVIDIA GPU 节点显存按模型量化等级匹配支持平台Linux 为主Windows 可用 WSL2 或 Docker显存占用取决于模型版本、量化精度、上下文长度和并发数适合场景内网私有化部署、API 中间层、容量评估与压测这个方案关注的重点不是模型有多少参数而是本地推理服务的三个硬指标能不能一键启动、API 是不是兼容 OpenAI 格式、并发上涨后延迟是否可控。两台节点过去最常被用来做“一个节点部署、另一个节点压测”但更实用的做法是两个节点都作为推理服务对外提供再在前面加一层网关分发流量。这样既解决了单点压力也为后面扩容留下了路子。2. 适用场景与使用边界2.1 适合谁这套流程最典型的场景是内网私有化部署。数据不出本机的团队比如金融、政务、企业内部知识库这类对数据外发敏感的环境可以用本地推理服务替代外部 API。开发人员也可以把它当成一个 OpenAI 兼容的后端先本地调通 Prompt再迁移到生产环境。运维人员则可以用压测脚本在发布前摸清服务的并发上限和显存阈值避免线上突然被打满。2.2 不适合什么如果你的机器只有一张 4GB 显存的显卡又想跑大参数模型这套流程会非常辛苦。大模型推理首先看显存显存不够就只能上 CPU 或小量化版本效果和速度都会打折扣。另外如果没有 Linux 操作基础、不熟悉命令行vLLM 这条路会有一定门槛建议先用 Ollama 降低启动成本。2.3 合规边界本地部署不等于可以随意使用。模型权重要确认是否有开源授权是否能商用压测数据不要使用真实用户隐私涉及人脸、声音、身份信息时必须确认已获得授权。服务如果开在局域网要加访问控制不要裸奔到公网。全文不涉及任何绕过安全限制、越狱提示词之类的内容请把能力用在合规且有明确授权的场景。3. 环境准备与前置条件3.1 硬件建议两台节点建议使用相同型号的 GPU避免性能基线不一致。显存选择看模型量化等级FP16 或 BF16 需要较高显存INT8、INT4 或 GGUF 量化可以在较小显存上运行。主板和电源要能支撑 GPU 满载运行温度过高会触发降频直接影响压测数据。3.2 软件环境系统层面推荐 Ubuntu 20.04 或 22.04官方对 CUDA 生态支持最完整。Windows 用户可以用 WSL2 或者 Docker 跑推理容器但 GPU 透传需要正确安装 Windows 侧驱动。软件清单如下NVIDIA 驱动使用nvidia-smi确认 GPU 可见CUDA Toolkit版本以推理框架要求为准Python 3.10 或 3.11推荐用 conda 或 venv 隔离环境推理框架vLLM、Ollama、llama.cpp 三选一3.3 网络与端口两节点之间内网必须互通压测机到推理节点的端口也要放行。常用的端口包括 vLLM 的 8000、Ollama 的 11434、llama.cpp 的 8080具体以配置为准。同一套方案内建议固定端口并在防火墙放行避免压测时出现连接被拒的问题。4. DeepSeek 本地部署与启动方式4.1 方案 AvLLM 启动 OpenAI 兼容服务vLLM 是目前本地推理性能较好的框架自带 OpenAI 兼容 API适合作为生产级服务使用。先安装依赖# 创建虚拟环境并安装 vLLM具体版本参考官方文档 python -m venv venv source venv/bin/activate pip install vllm启动命令是一个标准模板注意把模型仓库 ID 替换成官方实际提供的值# 启动 vLLM 推理服务监听所有网卡方便压测机访问 vllm serve MODEL_NAMESPACE/MODEL_NAME \ --host 0.0.0.0 \ --port 8000 \ --tensor-parallel-size 1 \ --max-model-len 8192参数含义--host 0.0.0.0表示允许其他机器访问--port 8000是服务端口--tensor-parallel-size 1表示单卡推理跨节点张量并行在没有高速互联时通信开销很大不建议轻易使用--max-model-len 8192是上下文长度上限按模型实际支持范围调整。启动后日志会显示模型加载进度和显存占用看到 “Starting vLLM server” 之类的输出就说明服务起来了。4.2 方案 BOllama 一键启动Ollama 更适合快速验证。安装后拉取模型再启动服务# 安装 Ollama 后拉取需要的模型标签 ollama pull MODEL_TAG # 启动服务默认监听 11434 端口 ollama serve启动后同样可以用 OpenAI 兼容接口调用这对只是想先跑通一次对话测试的同学来说最省事。Ollama 的优势是模型文件管理简单劣势是高级推理参数和并发调度能力不如 vLLM 灵活。4.3 方案 Cllama.cpp如果你的机器显存很紧或者需要 GGUF 量化模型用 llama.cpp 的服务器模式更合适llama-server -m 模型权重文件路径 \ --host 0.0.0.0 \ --port 8000 \ --n-gpu-layers 999--n-gpu-layers 999表示尽可能把所有层放到 GPU显存不够就减小这个值让部分层跑在 CPU 上。GGUF 模型文件通常从官方或可信渠道转换获得下载后建议先校验 SHA256避免文件损坏导致加载失败。4.4 双节点流量接入两个节点都启动推理服务之后最简单的方式是用 nginx 做 TCP 或 HTTP 负载均衡。下面的配置把流量轮询分发到两台推理节点upstream deepseek_backend { server 192.168.1.10:8000; server 192.168.1.11:8000; } server { listen 8001; location / { proxy_pass http://deepseek_backend; proxy_http_version 1.1; proxy_read_timeout 300s; proxy_set_header Host $host; } }压测机访问http://nginx_ip:8001即可不需要关心后端具体是哪台节点。这里要注意两个节点如果硬件不一致吞吐会受拖后腿的节点影响建议先用单节点压测摸清各自上限。5. 功能测试与效果验证5.1 检查服务是否启动成功服务起来后第一步不是直接压测而是确认 API 是否能正常响应。用 curl 请求模型列表curl http://127.0.0.1:8000/v1/models如果返回 JSON 里包含id和模型名称说明服务端加载成功。如果返回 404先看启动日志可能是模型没有加载完成也可能是请求打到了错误端口。5.2 单请求对话测试确认服务在线后发起一次对话请求curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: MODEL_ID, messages: [{role: user, content: 用一句话解释什么是大模型}], max_tokens: 128 }预期结果返回choices数组里包含完整的回复内容usage字段有prompt_tokens、completion_tokens、total_tokens三个数值。判断成功的标准是返回内容完整、无乱码、无截断报错。如果这一步都不通过不要继续压测先解决模型加载和输出异常问题。5.3 多轮对话与稳定性验证连续调用 3 到 5 次观察是否偶发超时或返回空内容。多轮对话场景建议在 messages 中携带历史记录import requests url http://127.0.0.1:8000/v1/chat/completions payload { model: MODEL_ID, messages: [ {role: system, content: 你是一个测试助手}, {role: user, content: 我会连续问你问题请简短回答}, {role: assistant, content: 好的请说}, {role: user, content: 第一问11等于几} ], max_tokens: 64, temperature: 0.7 } response requests.post(url, jsonpayload, timeout60) print(response.status_code) print(response.json())这一步的重点不是回答质量而是确认长上下文输入不会导致请求失败或显存异常飙升。5.4 判断功能测试是否通过整理一个验收清单v1/models返回正常单轮、多轮对话都能拿到非空输出连续 10 次请求无 5xx 错误显存占用没有持续无限上涨重启服务后能恢复到正常状态满足以上条件再进行并发压测。6. 接口 API 与批量任务6.1 接口能力说明vLLM 和 Ollama 都提供 OpenAI 兼容接口请求体主要字段如下参数类型说明modelstring模型 ID必须是服务端实际加载的模型messagesarray对话消息列表temperaturefloat采样温度范围 0 到 2max_tokensint最大生成 token 数streambool是否流式返回流式返回适合应用层按钮逐字输出场景但压测时建议关闭方便统计完整延迟。6.2 Python 批量调用模板写一个通用并发脚本先从小并发开始import json import threading import time import requests URL http://127.0.0.1:8000/v1/chat/completions MODEL_ID MODEL_ID def single_request(idx): payload { model: MODEL_ID, messages: [{role: user, content: f第 {idx} 个测试请求请返回 OK}], max_tokens: 32 } start time.time() try: r requests.post(URL, jsonpayload, timeout60) cost time.time() - start print(freq {idx}: status{r.status_code}, time{cost:.2f}s) if r.status_code ! 200: print(r.text[:500]) except Exception as e: print(freq {idx}: error{e}) threads [threading.Thread(targetsingle_request, args(i,)) for i in range(8)] for t in threads: t.start() for t in threads: t.join()首次先跑 8 并发观察成功率和服务端显存变化。如果全部成功再尝试 16、32、64 并发。注意不要一上来就跑 100 并发很多显存不足的问题都是并发测试阶段暴露的。6.3 批量任务与队列设计接口直接调用适合临时测试。正式批量任务建议在客户端做队列控制核心参数有并发数、单请求超时、失败重试次数。比较稳妥的做法任务写入本地队列Worker 数量固定避免突发流量打爆推理服务单请求超时设置为 60 到 120 秒超过就标记失败失败任务重试最多 2 次重试间隔按指数退避每次任务记录请求 ID、输入长度、输出长度、耗时和错误信息批量任务的目的不是把服务压垮而是找到稳定的吞吐区间。如果你在跑批量解析、批量生成、批量总结这类场景这套队列设计比直接并发循环可靠得多。6.4 压测结果记录指标无论用 JMeter、k6 还是 Python 脚本至少记录以下指标总请求数、成功数、失败数QPS即每秒请求数首 Token 延迟表示用户等待首个输出的时间生成速度每秒输出多少个 TokenP50 / P95 / P99 完整响应延迟GPU 显存峰值和均值把这些指标填进下面的表格就形成了你自己的基线数据指标单节点实测值双节点实测值并发 8 时 QPS以本机实测为准以本机实测为准P95 完整延迟以本机实测为准以本机实测为准显存峰值以本机实测为准以本机实测为准双节点之所以不等于两倍吞吐是因为负载均衡、网络开销和节点自身差异都会影响最终效果。只有实测数据才能回答“到底有多快”。7. 资源占用与性能观察7.1 显存观察方法压测过程中开一个独立终端实时观察nvidia-smi -l 1重点看四列GPU-Util、Memory-Usage、Temperature、Power Usage。GPU 利用率接近 100% 说明计算资源被有效使用显存接近上限说明增加并发可能触发 OOM温度过高说明散热不足需要先解决降频问题再做压测。7.2 CPU 推理与 GPU 推理差异CPU 推理的优势是安装简单、不挑显卡劣势是生成速度明显慢于 GPU。对 DeepSeek 这类大模型CPU 方案更适合用来跑通流程、验证接口不适合实际业务高并发。GPU 推理可以把更多层负载到显卡提升吞吐代价是显存占用更高。7.3 影响性能的关键因素以下因素对压测结果影响较大量化精度FP16 效果更好但显存更高INT4 能省显存但可能有精度损失上下文长度max_model_len越大显存占用越高并发数并发上涨会放大显存压力生成长度输出越长单请求占用的总时间越长是否开启流式输出流式输出对首 Token 延迟更友好如果压测发现延迟飙升优先排查是不是并发数超过了显存承受范围而不是急着换框架。7.4 降低显存占用的策略显存不足时按顺序尝试减小max_model_len降低并发数换 INT8 或 INT4 量化再不行就开--gpu-memory-utilization 0.9之类的参数约束显存使用上限。极端情况下可以让部分层跑 CPU但要以生成速度下降为代价。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后/v1/models返回 404模型加载失败或请求端口错误查看启动日志确认监听端口重启服务确认--port参数报 CUDA out of memory显存不足用nvidia-smi查看显存占用降低并发、缩短上下文、换量化模型端口被占用之前服务未完全退出lsof -i:8000查看占用进程换端口或清理残留进程API 调用超时并发过高或单次生成过长检查服务端日志和客户端超时设置降低并发调大timeout输出乱码或内容截断模板配置错误或上下文超限检查max_model_len和消息格式调整上下文长度检查模型模板批量任务全部失败队列无超时控制请求堆积查看失败日志中的错误类型增加超时、重试和退避策略双节点压测流量只走一台nginx upstream 配置未生效查看节点访问日志和连接数检查upstream配置并 reload模型文件缺失或校验失败下载不完整对比官方 SHA256重新下载并校验排查顺序建议从日志开始不要凭感觉改参数。vLLM 日志会直接打印每次请求的错误原因Ollama 的日志则会把模型加载阶段的问题暴露得更明显。9. 最佳实践与使用建议第一第一次测试先跑单节点、单并发、小max_tokens。把最小可运行配置固定下来比如记录“模型 ID、端口、上下文长度、量化等级”后续所有压测都基于这套配置展开。第二模型文件、输入素材、输出结果分目录管理。推荐结构如下~/deepseek-local/ ├── models/ # 权重文件和量化文件 ├── scripts/ # 启动脚本和压测脚本 ├── logs/ # 服务日志和请求日志 └── outputs/ # 批量任务结果第三压测前记录硬件基线压测后马上落盘。如果两次压测数据差异很大先检查是不是有别的任务占用了 GPU。第四接口服务不要裸奔。即使在内网也要在服务前面加访问控制或 API Key 校验至少限制来源 IP。涉及数据隐私的场景优先保证数据传输在可信网络内部完成。第五批量任务必须加日志和失败重试。单独跑一个请求失败无所谓批量 1000 个请求如果中途失败没有日志和重试策略后面的人只能重新跑一遍。第六任何输出发布或商用前都要复核。模型生成内容不代表事实本地部署也不代表内容一定正确需要接入业务系统时更要做质量抽检。10. 总结与下一步这套双节点本地部署方案最值得尝试的地方是把 DeepSeek 推理服务从“别人给的 API”变成了“自己能控制的本地服务”。启动方式、接口格式、压测手段都是通用工程能力换一个模型照样能用。最先要验证的功能是/v1/models和单轮对话最快踩到的坑通常是显存不足和端口冲突。建议下一步做三件事一是把压测脚本整理成固定工具形成单节点和双节点的性能基线二是接入监控组件比如 Prometheus 加 Grafana把显存、延迟和请求错误率变成可视化指标三是把 API 接入到现有系统比如 Dify 这类低代码平台或自己的业务后端验证真实业务场景下的稳定性。最后提醒一下任何时候都不要因为本地部署就放松授权审查和数据合规要求。模型权重、训练数据、输入输出内容该确认授权的确认授权该脱敏的脱敏该加访问控制的加访问控制。先在小并发下把流程跑稳再逐步增加压力这是本地大模型服务上线最稳妥的路径。