deepseek本地部署指南:在linux服务器部署

本地跑 DeepSeek 的教程大多停在「一条命令拉起来」，真搬到 Linux 服务器上，先卡住的往往是驱动与 CUDA 版本对不对、模型权重从哪来、用哪个推理框架、端口怎么开、显存被谁吃了。这篇按运维视角走一遍完整流程：先做上线前自检，再选框架和量化档位，然后起服务、验通、排错、留维护入口。显存、并发、价格这类会变的数字，统一给站内页面让你按当时的数去核。

很多人写本地部署，写到「一条命令拉起来」就结束了，真搬到 Linux 服务器上，卡住的往往不是命令，是前面那几件事：驱动和 CUDA 版本对不对、权重从哪来、用哪个推理框架、端口开给谁、显存被谁吃了。这篇按运维和开发者的视角走一遍完整流程，从自检到上线后的维护入口，每一步都给判断标准和可执行动作。

显存要多少、单卡能扛多少并发、不同算力大概什么价位，这些会变的数字本文一个都不写死，统一给站内页面，你按当时的数去核。下面的步骤你可以照着顺序做，也可以只挑自己卡住的那一段看。

上线前自检：别在装到一半才发现卡不对

先把「装」和「跑」分开。装之前确认的是硬件与运行环境，跑之前确认的是模型与显存。两件事混在一起做，出问题时你会分不清是环境没配好还是模型放不下。自检这一步花不了多少时间，但能省掉后面反复重装。

• 显卡与驱动：确认卡被系统认到、驱动版本能用，nvidia-smi 能正常输出；驱动太旧会导致后面容器运行时直接起不来
• 容器运行时：如果用容器路线，先确认能成功跑一个最小的带 GPU 的镜像，这一步不过，后面全是白忙
• 磁盘空间：系统盘和模型盘分开看，权重目录别默认落在系统盘，盘写满是最容易被忽略的停机原因
• 网络出口：需要在线拉权重的机器，确认能出网；纯内网环境要提前把权重和依赖准备好，不要等装到一半才发现拉不动

自检完还要想清楚这台机器的定位。是单人调试、团队内部接口，还是给知识库当后端？三种定位对并发、端口暴露面和常驻内存的要求完全不同。单人调试可以随便一点，给业务用的就要按长期服务来规划。显存与模型规格的对应关系不要凭记忆，到 /compute/sizing 和 /models/deploy 按当时的模型与量化档位核一遍，再决定用哪张卡。

推理框架怎么定：Ollama、vLLM、llama.cpp 的分工

框架选型不是选「最好的」，是选「和你场景匹配的」。判断依据放在四条上：要不要高并发、要不要多卡并行、有没有现成的 OpenAI 兼容接口需求、团队愿不愿意维护 Python 环境和编译依赖。四条里有一条不满足，选项就会收窄。

选之前先到 /inference 看这个模型规格有没有现成的支持记录，避免选完才发现权重加载不上。另外，如果你们已经有统一的推理平台或网关，框架选型应该服从平台，不要为单个模型另开一套，后期没人维护是常态而不是意外。

权重从哪来、量化档位怎么定

权重来源分三种：官方或镜像站直拉、内网离线拷贝、从别的机器迁移已有模型目录。三种路线对目录结构和环境变量的要求不一样，离线环境最容易在这里翻车——装的时候看着都对，起服务才发现路径读不到。

1. 先定权重目录在独立数据盘上规划一个固定路径，把环境变量指过去；不要把权重放在用户家目录或系统盘默认位置。
2. 再按显存定量化档位先按满精度估算一遍需要多少显存，超了就往下调一档。每调一档都要在真实业务问句上抽测几条，确认输出质量还能接受，而不是只看能不能跑起来。
3. 最后做一次路径验证用最小命令加载模型，确认进程能读到全部文件、没有缺分片报错，再进入起服务阶段。

量化档位的取舍本质是「显存够不够 × 质量能不能接受」两个维度。对输出质量极敏感、且显存本来就宽裕的场景，没必要为了省显存强行压量化，那会白白损失效果。反过来，只是为了内部试用，压一两档通常也能接受。

起服务：容器还是裸机，端口与鉴权怎么配

容器路线的优势是依赖打包、回滚方便；裸机路线的优势是能直接调驱动、做性能剖析。团队没有容器运维能力就老老实实选裸机，别硬上。这不是技术先进与否的问题，是出问题时谁能收拾的问题。

监听地址

默认绑定到所有网卡之前，先想清楚哪些网段能访问

对外端口

端口一旦暴露到公网，被扫到只是时间问题，内网服务也建议走一层代理

鉴权

即便内网也要加令牌或反向代理，跨网段或经跳板机访问时尤其不能省

启动参数

上下文长度、并发上限、显存占用比例三项先保守设小，压测后再往上放

端口规划的核心不是「开哪个端口」，是「谁能访问到」。内网服务也建议统一走反向代理，好处是鉴权、限流、日志都在一层做掉，换后端实例时不用改调用方配置。

验通与压测：怎么证明它真的能用

验通分三层：进程是否活着、接口是否能返回完整回答、流式输出是否正常且不中断。三层都要过，只看第一层就交给业务，后面大概率会被投诉「时好时坏」。

• 单请求首字延迟：决定用户第一眼的体感
• 整体生成速度：决定长回答的总耗时
• 并发上来后的延迟劣化幅度：决定能不能对外服务
• 显存有没有缓慢增长：决定会不会跑几小时后自己挂掉

特别留意长上下文请求，它往往才是把显存打满的真正原因，而不是并发数。压测时多测几条长输入，比只压短问题更有参考价值。只给自己一个人用的开发机，压测意义不大，跑几条真实问句即可。

报错排查顺序：从显存到驱动的固定套路

排查顺序固定下来，比每次对着报错猜要快得多。顺序是：先看显存是不是真不够，再看驱动与运行时版本是否匹配，然后看权重文件是否完整、路径是否被正确读到，最后才怀疑框架本身的参数。

日志要看三层：框架自身日志、容器或 systemd 日志、系统内核日志。显卡相关的硬件级报错经常只出现在最后一层，只看应用日志会一直找不到原因。排查时先在最小配置下复现，再逐项加回并发和上下文长度，这个做法看着笨，但比对着报错猜有效得多。

上线之后：升级、监控与迁移要留的入口

能跑起来只是开始，真正省事的是提前留好三个入口：一份能重现当前可用配置的启动脚本、一份模型与框架版本记录、一条明确的回滚路径。这三样东西不需要多复杂，一条脚本加一个记录文件就能起步。

1. 升级前先起旁路实例在新端口起一个新实例，用同样的验通方法测一遍，通过后再切流量，不要在原实例上直接替换。
2. 监控只盯三个指标显存占用、请求延迟、错误率。异常时先看显存曲线再看日志，多数问题在曲线上就有征兆。
3. 迁移按固定顺序搬驱动→运行时→权重路径→启动参数→接口验通，别只拷权重目录，环境差异才是翻车点。

监控不用一上来就上全套，先把显存和延迟两项跑起来，已经能覆盖大部分故障预警。单次实验性部署、明显跑完就删的环境，不值得投入监控和回滚建设，直接记一条「曾经这样跑过」就够了。