在Linux服务器上部署大模型正在变成越来越多后端工程师和运维团队的基础技能。最近我帮几个朋友在自己的Linux服务器上跑通了DeepSeek和Ollama整个过程有点波折但真跑通以后后续加模型、加接口、接应用都非常顺。这篇东西的定位就是一份可复现的部署笔记从硬件选型、方案对比到具体安装命令、服务化、故障排查再到Dify、微调这类延伸玩法尽量把关键点一次讲透让你少走我走过的弯路。1. 动手部署前先解决三个核心问题模型、硬件与系统很多人拿到一台服务器第一反应就是敲命令装Ollama然后发现模型拉下来跑不动或者跑起来巨慢最后全卡在环境上。我现在的习惯是在真正动手之前先把模型规模、硬件条件、操作系统三件事对清楚这一步花不了半小时但能省下后面两三天。1.1 模型参数量与显存内存的估算法则要估算一个模型需要多大显存其实有个很粗暴的公式权重占用 参数量 × 每个权重字节数然后再加上推理过程中必须留出的KV Cache和激活值空间。以7B模型为例如果用FP16精度每个参数占2字节那就是14GB权重如果换成4-bit量化每个参数约0.5到0.6字节权重就被压到4GB出头。不同规模模型在常见精度下的显存需求我整理了一个参考表模型规模FP16/BF164-bit量化适合的单卡条件7B约14GB约4.5GBRTX 3060 12GB起步13B/14B约28GB约8GBRTX 4090 24GB较稳32B约64GB约20GB4090勉强A100更舒服70B约140GB约40GB需要两张24GB卡或多卡这个表只是权重占用的粗算实际操作里还要看上下文长度。上下文开得越长KV Cache占用越大比如一个7B模型的32K上下文KV Cache可能额外吃掉几GB显存。所以我给朋友的建议通常是第一批模型先用量化版本跑流程通了再谈升级精度。内存这边也容易被忽略。如果显存不够系统会用内存顶推理速度会断崖式下降。考虑到进程加载、数据交换和系统本身的占用内存至少应该是模型权重的两倍。硬盘则直接决定模型加载速度同样的一个7B模型机械硬盘和NVMe固态的启动时间能差出几分钟预算允许的情况下优先NVMe。1.2 服务器硬件与Linux发行版怎么选硬件选型上NVIDIA显卡依然是部署大模型的最省心选择因为CUDA生态太完整了Pytorch、各种推理框架、容器工具链都是优先支持NVIDIA。消费级显卡里RTX 4090 24GB是目前单机自用的甜点卡能跑7B、14B甚至量化后的32B预算更低就选RTX 3060 12GB跑7B量化模型完全够用。企业级场景则看A100、H100这类显存大、带宽高但价格也高不少。Linux发行版我推荐Ubuntu Server 22.04 LTS原因是它的内核版本和驱动兼容性都很稳遇到问题时网上的资料也最多。Debian 12、Rocky Linux 9也可以但没有特殊理由的话没必要在发行版选择上给自己增加难度。拿到系统后第一件事就是确认GPU驱动是否正常终端里执行nvidia-smi能看到类似下面的输出就说明驱动和显卡都被识别了--------------------------------------------------------------------------------------- | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | ---------------------------------------------------------------------------------------如果提示command not found说明驱动还没有装好需要先解决驱动问题再继续。这里有一个常见的误区很多人以为必须要手动装CUDA Toolkit才能部署大模型其实Ollama这类工具会自带运行依赖只要驱动版本别太老一般都能正常工作。1.3 你需要在服务器上准备的驱动与基础环境驱动是基础但还有几个环境变量和基础工具值得提前准备。一个是检查curl、wget是否装上很多精简版Linux发行版默认不带这些工具。另一个是确保系统的glibc版本够新如果你的服务器是特别老旧的发行版后面装Ollama可能会报GLIBC版本过低的错误升级到较新的Ubuntu或Debian版本通常能直接避开。Docker不是必须的但如果你打算用Docker部署就得提前装好NVIDIA Container Toolkit否则容器里识别不到GPU。我一般会在系统装好后执行一遍完整检查nvidia-smi、docker --version、curl --version、free -h、df -h把硬件、工具、磁盘、内存全部过一遍确认没有明显短板再继续。2. 四类主流部署方案对比别一上来就闷头装“Linux服务器部署大模型”这个事很容易一搜教程就直接开干。但部署方案的选型其实比安装命令本身重要得多方案选错了后面可能整个推倒重来。目前互联网上讨论最多的是Ollama、vLLM、llama.cpp和Text Generation Inference各有各的主场。2.1 Ollama、vLLM、llama.cpp、TGI的适用场景方案安装难度硬件要求核心优势适合场景Ollama极低有GPU更好CPU也能跑模型管理简单API开箱即用个人开发、内网小并发vLLM中等强烈建议GPUPagedAttention吞吐高在线API服务、高并发llama.cpp中等CPU/GPU通吃轻量GGUF量化成熟嵌入式、纯CPU环境TGI中等偏高GPUHuggingFace生态完整企业级推理服务Ollama是我个人最常用的入门方案一条命令就能装好拉模型、换模型版本、起服务都很简单而且它默认暴露的接口和OpenAI的Chat Completions格式兼容后面接Dify、FastGPT这类应用非常方便。它的内部调度在低并发场景下足够用但扛不住每秒几十个请求的压力。vLLM是冲着性能和吞吐去的核心是PagedAttention技术显存利用率比朴素推理高很多。如果你的目标是做一个对外服务的API前期就能预期有比较大的并发量建议直接用vLLM。但它对模型格式有要求也不是所有模型都能一把梭。llama.cpp是纯C实现的推理引擎最突出的能力是GGUF量化模型没有NVIDIA显卡、只有纯CPU的服务器也能跑。很多嵌入式设备和低成本服务器会选它。TGI则是HuggingFace官方出的推理服务和HuggingFace生态结合最紧密功能全但部署和调优的学习成本高一些。2.2 选择Ollama作为入门路线的三个理由我之所以推荐先试Ollama核心原因有三个。第一它把模型下载、文件管理、进程守护、API服务全都封装好了对刚接触大模型部署的人来说这是最节省时间的路径。第二它使用起来接近于“Docker之于容器”的体验ollama pull、ollama run、ollama list几个命令就能完成日常操作。第三它跨平台且支持GPU加速一台老的CPU服务器也能跑只是慢一点不会完全不可用。2.3 什么时候应该换掉OllamaOllama毕竟是面向个人和小团队的轻量工具当你遇到下面这些情况就该考虑换vLLM或TGI一是并发请求持续超过两位数二是需要对显存做更细粒度的控制三是需要多模型多副本的自动扩缩容。识别这个信号主要看延迟和失败率如果模型明明没OOM但请求经常排队或超时那就说明Ollama的调度已经到瓶颈了。3. 实操在Linux服务器上用Ollama部署DeepSeek接下来是全文最核心的部分我以Ollama和DeepSeek-R1系列为例演示从零开始在Linux服务器上跑通一个本地大模型。这个流程我在Ubuntu Server 22.04和Debian 12上都验证过可以照着敲。3.1 安装Ollama的两种方式第一种方式是用官方脚本安装也是最推荐的方式curl -fsSL https://ollama.com/install.sh | sh脚本会自动检测操作系统、下载二进制、配置systemd服务。安装完成后执行ollama --version确认版本号正常会打印类似ollama version 0.x.x的内容。第二种方式是手动安装适合服务器无法直接用脚本或者你想固定某个特定版本的情况。去官方GitHub Release页面下载对应架构的二进制包解压后把ollama可执行文件放到/usr/local/bin/再把模型目录和用户权限设置好。这种方式能让你精确控制版本但需要手动处理systemd和权限新手还是建议直接用脚本。3.2 环境变量与GPU可见性确认安装完成后先别急着拉模型先确认Ollama能不能看到GPU。执行下面这个命令如果返回的是GPU available相关的信息说明加速已经生效如果返回的是CPU推理也不用慌继续往下走只是速度慢一些。ollama serveOllama默认只监听本机的127.0.0.1也就是说只能在这台服务器上访问。如果你想从其他机器调用这个API需要设置环境变量OLLAMA_HOST0.0.0.0:11434。这个变量可以在启动Ollama前用export设置也可以写到systemd服务配置文件里。如果是用官方脚本安装的Ollama已经注册成systemd服务稍后我会讲怎么改配置。3.3 拉取模型并完成首次对话DeepSeek-R1系列发布以后热度很高它有几个规格可以选。我拿deepseek-r1:7b举例这是7B规模、默认4-bit量化的版本显存需求比较友好。ollama pull deepseek-r1:7b这个命令会从模型仓库拉取所有文件模型体积在4GB到6GB之间具体取决于网络链路和镜像源。下载中断也没关系再次执行ollama pull会断点续传。下载完成后直接运行ollama run deepseek-r1:7b看到 Send a message (/? for help)这样的提示符就说明模型已经加载成功可以直接输入问题。比如输入“你好简单介绍一下你自己”模型会正常回话。这一步如果通过说明模型本身、硬件加速、系统环境全都没问题接下来要做的是把它变成一个能对外提供服务的接口。3.4 把模型封装成HTTP APIOllama自带REST API最常用的是生成接口和OpenAI兼容接口。先测试原生的生成接口curl http://127.0.0.1:11434/api/generate -d { model: deepseek-r1:7b, prompt: 介绍一下Linux系统, stream: false }如果返回内容里包含response字段接口就通了。官方还兼容了OpenAI的格式接口路径是/v1/chat/completions这样绝大多数现成的OpenAI SDK可以无缝切换只需要把base_url改成http://你的服务器IP:11434/v1。Python调用示例也贴一下方便做自动化脚本import requests url http://127.0.0.1:11434/v1/chat/completions payload { model: deepseek-r1:7b, messages: [ {role: user, content: 写一段Python快速排序代码} ] } resp requests.post(url, jsonpayload) print(resp.json()[choices][0][message][content])3.5 使用Docker运行Ollama的补充方案如果你更习惯容器化也可以用Docker运行Ollama。第一步确保宿主机已经装好NVIDIA Container Toolkit然后用下面的命令启动docker run -d --gpus all \ -v /data/ollama:/root/.ollama \ -p 11434:11434 \ ollama/ollama-v /data/ollama:/root/.ollama是把模型存储目录挂载到宿主机的/data/ollama这个很关键否则容器一旦删除模型文件就全丢了。--gpus all让容器使用宿主机全部GPU。容器启动后再执行docker exec -it 容器ID ollama pull deepseek-r1:7b拉取模型。容器化方案的好处是环境隔离换机器迁移时直接把数据目录拷走即可缺点是排查问题时多一层容器网络要处理。4. 从临时进程到正式服务systemd、Nginx与模型数据管理跑通模型只是第一步真正能在生产环境或者团队内部使用还需要把Ollama托管成系统服务、加上访问入口和权限控制并且考虑模型文件的备份迁移。这一节讲的就是怎么把一个临时进程变成正经服务。4.1 用systemd托管并支持远程访问官方脚本安装Ollama时已经自动创建了一个systemd服务文件通常在/etc/systemd/system/ollama.service。查看当前监听地址systemctl status ollama如果只监听了127.0.0.1需要编辑服务文件加入或修改Environment配置[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434然后执行sudo systemctl daemon-reload sudo systemctl restart ollama sudo systemctl enable ollamaenable是设置开机自启restart是让新配置立即生效。这种场景下不推荐直接export OLLAMA_HOST因为重启后就丢了写在systemd里才是一劳永逸。4.2 用Nginx转发并增加访问控制监听0.0.0.0之后局域网内其他机器的确能访问了但同时也意味着任何能扫到这个端口的人都能调用你的API白嫖算力还是小事被恶意灌请求把服务器打挂就麻烦了。我的做法是在前面加一层Nginx只暴露Nginx的端口同时加一道最简单的HTTP Basic认证。先安装Nginx并生成用户密码文件sudo apt install nginx apache2-utils sudo mkdir -p /etc/nginx/conf.d sudo htpasswd -c /etc/nginx/.ollama_htpasswd aiuser然后在Nginx配置里加一个server块将/路径转发到Ollama的11434端口并开启认证。配置核心写法server { listen 8080; server_name _; auth_basic ollama; auth_basic_user_file /etc/nginx/.ollama_htpasswd; location / { proxy_pass http://127.0.0.1:11434; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }这样外部访问就变成了http://服务器IP:8080而且必须先通过用户名密码认证。如果团队有统一的认证系统再往后可以接更复杂的SSO或Token机制但基础版已经能挡住绝大多数扫描和误用。4.3 模型目录位置与迁移备份Ollama的模型文件默认存储在~/.ollama/models也就是当前用户的Home目录。查看当前模型列表用ollama list如果你用非root用户运行Ollama要特别小心权限问题。我之前遇到过把模型目录放在/root/.ollama下然后用另一个用户启动服务结果完全读取不到模型的情况。解决办法是把模型目录设置为环境变量OLLAMA_MODELS指向一个共享目录再统一交给负责运行Ollama的用户管理。备份模型也很简单直接压缩模型目录即可tar -czf ollama_models_backup.tar.gz ~/.ollama/models恢复时解压到新机器的对应目录再启动Ollama就能看到原来的模型。多个大模型并存时磁盘空间增长很快我建议先跑ollama list看看都有哪些模型占了多大空间长期不用的直接ollama rm 模型名清理掉免得磁盘被撑爆。5. 部署过程中最常见的坑与排查实录这部分是整篇博客里我最想写给后来人的内容。我见过太多人在部署时遇到问题就盲目重装其实绝大多数问题都有迹可循关键是通过日志和命令先定位再做针对性处理。5.1 问题排查速查表现象常见原因排查方式CUDA error: no kernel image available显卡驱动版本过旧与容器/推理框架不匹配升级驱动或降低镜像版本模型加载直接OOM上下文太长或并发请求太多缩短上下文换更小量化模型下载到一半总断网络链路不稳定重新pull等待断点续传GPU利用率一直很低模型没有走GPU或请求并发低nvidia-smi查看进程API请求超时推理时间过长客户端等待时间短调大HTTP超时时间Nginx 502 Bad GatewayOllama没启动或端口不对systemctl status ollamacurl 127.0.0.1:11434这张表只是速查下面挑几个我实际踩过、修复过程也比较有代表性的展开说。5.2 GPU没有被利用怎么处理部署完以后发现推理慢得离谱第一件事永远是打开一个新终端执行nvidia-smi。如果输出里完全没有Python或ollama进程说明推理根本没有用上GPU。最常见的原因是没有安装好NVIDIA Container ToolkitDocker部署时或者CUDA_VISIBLE_DEVICES被意外设置成了空值。检查Ollama日志也很重要journalctl -u ollama -f日志里如果出现no GPU found或者using CPU就顺着这个线索去查驱动和容器工具链。还有一种情况是模型本身是纯CPU版本或GGUF的CPU量化版本如果是为了省事用CPU跑的那也不算错误只是性能天花板有限。5.3 并发请求与性能调优经验Ollama默认同一时间只在显存里保留一个模型并且单模型默认并发有限。如果团队多人同时访问可以通过环境变量提升并发能力EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_MAX_LOADED_MODELS2OLLAMA_NUM_PARALLEL表示同一个模型允许同时处理的请求数适当地提高可以让单张GPU利用率更充分。但并发不是越高越好显存有限时并发过高的直接后果就是OOM。我的经验是7B量化模型在24GB显存的卡上开4并发比较稳开8并发就随时可能爆显存。如果真到了需要两位数并发的阶段建议把Ollama换掉直接用vLLM。vLLM的PagedAttention机制会把显存调度得更精细吞吐量比特意调优的Ollama高不少。切换成本也没有想象中高因为vLLM也提供OpenAI兼容接口模型参数格式上稍微调整就能接上。6. 模型跑起来只是开始知识库、Dify与微调当模型在Linux服务器上稳定运行API也能被外部调用了下一步一般就是想让它真正解决业务问题。大部分人不会只满足于在终端里聊天而是会往知识库问答、智能体、业务系统集成这些方向走。这里我主要聊三条延伸路径Dify应用层、模型微调、同机其他AI任务的资源规划。6.1 通过Dify快速搭建应用层Dify是目前很火的开源LLM应用开发平台能可视化编排Prompt、管理知识库、接入多个模型并且完全支持对接本地部署的Ollama。部署Dify本身也走Docker Compose在服务器上安装好Docker和Compose后拉取官方部署仓库执行docker compose up -d就能起一套Web控制台。在Dify的“设置-模型供应商”里找到Ollama填上服务地址http://你的服务器IP:11434模型名称填deepseek-r1:7b类型选择“LLM”保存后就能在应用编排界面里用了。比较实用的一个场景是先在Dify里建一个知识库应用把企业内部的文档传上去Dify负责做文档分段、向量化再借助本地大模型完成语义检索和回答生成。整个过程数据不出内网既能控制成本也照顾了数据隐私需求。6.2 LoRA微调与数据准备如果你手里的模型在专用领域的表现不够好可以考虑微调。对于大多数中小团队和个人开发者我不建议从零预训练那是成本深渊推荐用LoRA或QLoRA在已有模型基础上做参数高效微调。常用方案是LLaMA-Factory或Unsloth前者功能全面后者显存友好、速度更快。数据是微调的重中之重。很多人误以为样本越多越好实际上几百到上千条高质量、格式规范的问答对往往就能看到明显效果。数据准备好后在服务器上通过LLaMA-Factory的脚本指定基础模型、数据文件和输出目录就能开始训练。需要提醒的是微调对显存的要求比单纯推理高不少7B模型做LoRA微调建议至少配16GB以上显存用QLoRA则可以把门槛降到12GB左右。6.3 同机运行其他AI应用时的资源规划很多人的Linux服务器不只是跑大模型还会跑ComfyUI、语音识别、向量数据库等。我的经验是如果这些任务都要共享同一块GPU一定要做好显存预算否则就会出现“跑图的时候模型加载失败跑模型的时候图像生成直接OOM”的情况。一个简单的策略是错峰运行把需要大显存的任务按时间段隔离例如大模型推理服务在白天给业务用图像生成任务放到晚上批量执行。另一个策略是显存不够时限制推理并发用OLLAMA_NUM_PARALLEL控制住大模型对显存占用的上限给其他任务留出空间。最后一点是始终关注磁盘微调中间产物和模型快照都非常吃空间建议定期清理。我在实际部署中的体会是Linux服务器上跑大模型真正花时间的地方往往不是模型本身而是环境、资源和服务化这些“周边工作”。先把一个小模型完整跑通再做性能优化和应用扩展是性价比最高的路径。最后再说个小技巧遇到任何部署问题先看日志再用最小化方式验证不要一上来就重装这是我在无数坑里摔出来的经验。