这两年开源大模型铺得遍地都是很多团队的第一反应不是去训练而是先把一个能用的模型部署到自己服务器上。我经手过不少Linux服务器部署大模型的项目从几台办公用的旧机器到带双卡的GPU工作站都有今天这篇就把完整流程摊开讲一遍硬件怎么评估、工具怎么选、命令怎么敲、坑怎么躲。先说个背景。不是只有互联网大厂才需要本地大模型很多场景——比如企业内部知识库问答、文档摘要、代码辅助、会议纪要整理——都适合在本地部署开源权重模型。相比于按小时租云端GPULinux服务器加开源模型的路线更可控数据不出内网长期算下来也划算。如果你手头有一台带NVIDIA显卡的Linux机器或者准备租一台云服务器甚至只是想在虚拟机里先跑个小模型试试水都可以按这篇文章走一遍。1. 部署前的硬件与系统评估1.1 先摸清机器家底显卡、内存、磁盘很多人拿到服务器第一句话就问“用什么框架部署”实际上框架是最后一步。部署大模型的核心瓶颈只有一个显存。模型权重在推理时要全部加载到显存里显存不够再好的CPU、再大的内存都白搭。所以在动手之前我建议你先花十分钟把机器摸清楚。登录服务器后先跑三条命令nvidia-smi free -h df -hnvidia-smi看显卡型号和显存大小free -h看内存df -h看磁盘剩余空间。如果nvidia-smi提示命令不存在说明驱动没装或者这台机器根本没有NVIDIA显卡。这时候可以再用lspci | grep -i nvidia看一眼硬件层面有没有识别到显卡如果 lspci 也查不到那基本可以确认是无GPU机器。显存和模型参数量的关系新手最容易懵。我通常用一个粗算公式帮大家建立感觉10亿参数在FP16精度下大约需要2GB显存在4bit量化下大约只需要0.6GB左右。举例来说一个70亿参数的Qwen2.5-7B模型FP16精度需要约14GB显存但换成Q4_K_M量化版本只需要5到6GB就能跑。所以同样是“7B模型”你用不同的精度加载对显存的需求可以差出三倍。这也是为什么很多人的显卡看起来“够大”跑量化模型却仍然卡顿。内存方面32GB起步比较稳。虽然推理时权重主要吃显存但操作系统、加载过程中的临时缓存、以及如果你要跑多个模型切换都需要内存兜底。如果机器只有16GB内存跑7B量化模型勉强可以但别指望同时开一堆服务。磁盘则要大模型文件动辄几个GB到几十个GB本地知识库、向量库也会持续占空间。我习惯给模型单独分一个目录比如/opt/models至少预留50到200GB磁盘用NVMe SSD体验最好机械硬盘加载大模型真的会等到怀疑人生。1.2 操作系统的选择与基础环境操作系统层面我的建议非常直接新手无脑选Ubuntu Server 22.04 LTS。原因很简单NVIDIA驱动、CUDA生态、Docker、Ollama这些工具链对Ubuntu的适配最顺畅出了问题也最容易搜到解决方案。如果你身在Red Hat系环境或者公司运维统一用Rocky Linux那Rocky Linux 9也能跑只是个别驱动安装步骤要多折腾一下。如果是自己学习用又实在不习惯纯命令行装Ubuntu Desktop版带图形界面也可以。我遇到过不少朋友第一台试验机装了带桌面的Ubuntu用浏览器和文件管理器操作心理压力小很多。线上生产环境当然还是纯Server版更干净但学习阶段没必要为难自己。选好系统后先把基础工具补齐sudo apt update sudo apt install -y curl git vim htop ncdu net-tools这几个命令分别用来下载文件、拉代码、编辑配置、看系统负载、看磁盘占用、看网络端口。你不需要成为Linux运维专家但ssh、df -h、free -h、nvidia-smi、systemctl这五组命令最好烂熟于心。后面所有部署操作基本都是围绕这些命令展开的。还有一个小细节确保SSH服务是开着的并且你在服务器上做的所有操作都尽量在screen或tmux会话里执行。尤其是拉取几十GB模型文件的时候网络一抖动SSH断了前台进程就跟着没了模型下载到一半白等。用tmux挂后台断了还能重新连回去这是运维老手都懂的保命习惯。2. 部署工具选型用什么把模型跑起来2.1 为什么建议先用 Ollama 起步大模型部署的工具链现在已经很成熟但选择太多反而让人不知道从哪下手。我见过的组合五花八门有人直接编译llama.cpp有人硬上vLLM有人用FastAPI自己封装一套推理服务。我的意见很明确第一次部署先用Ollama。为什么是Ollama因为它把llama.cpp那套推理引擎封装成了一个开箱即用的服务。你不需要理解量化算法、不需要手动编译、不需要写Python调度逻辑只需要两行命令就能下载模型并启动一个完整的API服务curl -fsSL https://ollama.com/install.sh | sh ollama run qwen2.5:7b第一条命令安装Ollama第二条命令下载并运行Qwen2.5-7B模型。就这么简单。这种“一条命令解决一个事”的设计极大降低了普通人接触大模型的门槛。很多人以为部署大模型需要会写CUDA代码实际上Ollama把这层全部隐藏掉了。我不建议新手一上来就自己编译llama.cpp不是因为llama.cpp不好而是因为编译过程中的坑实在太多。依赖版本不匹配、CUDA路径不对、量化工具链不熟任何一个环节都能卡你一下午。这些经历对老手来说是成长对新手来说是劝退。先用Ollama跑通全流程、建立体感再回头去研究底层实现学习曲线会平滑很多。那Ollama适合什么场景以我的经验适合三类个人学习体验、小团队内部使用、需要频繁切换模型的场景。它内置了模型管理ollama list看已下载的模型ollama pull拉新模型ollama rm删旧模型跟包管理器一样顺手。如果你想试不同厂商的开源模型Ollama是切换成本最低的方案。2.2 什么时候换 vLLMDify 又是什么角色Ollama虽然好用但不是万能的。如果你要面向几十上百个用户提供高并发服务Ollama的调度能力就不够看了。这时候vLLM是更合适的选择。vLLM的核心优势是PagedAttention显存管理技术可以把显存利用率提到很高吞吐量比朴素推理方案大好几倍。代价是它对CUDA环境更挑剔部署复杂度也更高第一次启动还会预分配大量显存小显存机器根本玩不转。所以我的判断标准很简单几个人用选Ollama几十人并发再考虑vLLM。还有一个容易混淆的角色是Dify。Dify不是推理引擎它更像是一个应用编排平台负责把模型API串成实际功能。比如你要做一个企业知识库问答系统需要“上传文档-切分-向量化-检索-丢给大模型生成回答”这条完整链路Dify干的就是这个活。它本身不跑模型而是对接你已经部署好的模型服务无论是Ollama、vLLM还是各家云API都能接。这三者的关系可以用一个分层来理解Linux和驱动是地基Ollama或vLLM是发动机Open WebUI或Dify是车身和方向盘。新手只要先把发动机点着也就是用Ollama把模型跑起来就已经成功了80%。3. 完整部署实操从装驱动到跑通服务3.1 安装 GPU 驱动与 Ollama我假设你现在拿到了一台带NVIDIA显卡、装好Ubuntu Server 22.04的机器。第一步是确认驱动状态。很多云服务器镜像默认不带NVIDIA驱动或者带的版本很旧。直接执行nvidia-smi如果可以显示显卡信息比如显卡型号、驱动版本、显存大小那驱动这关就过了。如果提示错误需要安装驱动。最简单的方式是用Ubuntu自带的驱动管理器sudo apt update sudo apt install -y nvidia-driver-545 sudo reboot安装完重启再执行nvidia-smi确认能看到显卡信息。这一步出了岔子不要急着往下走驱动不识别后面所有GPU相关的部署都会退化成CPU运行速度惨不忍睹。驱动就绪后安装Ollama。官方给了一条极简安装命令curl -fsSL https://ollama.com/install.sh | sh这条脚本会自动检测系统架构、安装依赖、注册systemd服务。安装完成后检查一下服务状态systemctl status ollama正常情况下Ollama服务已经自动启动并监听127.0.0.1:11434。默认只监听本机意味着只有服务器自己可以访问这个设计是安全的但局域网内其他电脑访问不了后面我会讲怎么开放。顺便说一句如果你拿到的机器没有NVIDIA显卡也不用灰心。Ollama会自动退回到CPU推理模式跑1.5B、3B这种小模型完全没问题只是速度慢一些。对学习流程来说这反而是个很好的起点。3.2 下载模型与显存估算Ollama装好之后最激动人心的时刻来了——下载模型。模型选择上我个人推荐从国内团队或社区生态比较好的开源模型入手比如Qwen2.5系列、Llama 3.1系列、DeepSeek-R1的蒸馏版本这些在Ollama的模型库里都能直接拉取。以Qwen2.5-7B为例执行ollama pull qwen2.5:7bOllama会自动下载模型文件并做好格式转换。下载速度和你的网络带宽有关一般几个GB到十几个GB不等用tmux挂着慢慢下就行。模型下载完成后用ollama list查看已安装列表。接下来是显存估算的关键环节。我整理了一张常用模型的显存参考表基于Q4_K_M量化模型参数量量化格式显存占用预估适合显卡1.5BQ4_K_M约1.2GB4GB以上7B-8BQ4_K_M约5-6GB8GB以上14BQ4_K_M约9-10GB12GB以上32BQ4_K_M约20GB24GB以上70BQ4_K_M约40GB48GB以上如果你不知道什么是“量化”我用一个生活化的类比解释模型权重原本是32位或16位的浮点数精度高但体积大量化就是把小数点后面不太重要的位数砍掉用8位甚至4位来存。好处是体积和显存需求大幅下降坏处是模型智商会有轻微下降。对于大多数对话、总结、问答场景Q4量化后的质量损失几乎感觉不到。跑一个试试。执行ollama run qwen2.5:7b在交互式对话窗口里输入“你好介绍一下你自己”如果模型能流畅回复恭喜你这次部署的核心环节已经通了。这时候再开一个终端窗口看nvidia-smi你会看到显存被Ollama进程占用GPU利用率跳动说明推理确实发生在显卡上。3.3 用 systemd 托管 Ollama 服务并开放局域网Ollama默认只允许本机访问但实际使用中团队其他同事的电脑也要连过来用。这时候要改一下Ollama的启动参数让它监听所有网络接口并且调整并发和自动卸载策略。先创建systemd的override目录sudo mkdir -p /etc/systemd/system/ollama.service.d sudo vim /etc/systemd/system/ollama.service.d/override.conf写入以下内容[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE5m这几个参数分别表示监听所有网卡的11434端口最多并行处理4个请求同时只保留一个模型在显存里模型空闲5分钟后自动卸载。OLLAMA_NUM_PARALLEL可以根据显卡显存大小调整显存紧张就改成2否则并发请求会把显存挤爆。保存后重载systemd并重启服务sudo systemctl daemon-reload sudo systemctl restart ollama再验证一下。本机执行curl http://127.0.0.1:11434/api/tags有JSON输出说明服务正常。然后找到服务器的局域网IP比如192.168.1.100在另一台电脑上执行curl http://192.168.1.100:11434/api/tags如果也能返回JSON说明局域网已经能访问了。这一步是很多人容易忽略的因为Ollama的安装脚本默认不开放外部监听不改配置就算关了防火墙也连不上。安全提醒千万不要直接把11434端口裸奔到公网。Ollama本身没有复杂的认证机制暴露到公网等于把你的模型和算力交给全世界。如果是生产环境建议用防火墙只允许内网IP访问或者在前面加一层带认证的反向代理。sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp4. 配一个浏览器入口Open WebUI 与 Dify 对接4.1 用 Docker 快速部署 Open WebUI命令行跑通之后下一步就是给团队配一个像ChatGPT那样好用的网页界面。我推荐Open WebUI它自带聊天界面、多用户管理、文件上传、对话历史、收藏夹还支持自定义模型参数基本能满足小团队日常使用。Open WebUI推荐用Docker部署这也是目前最省心的方式。先装Dockercurl -fsSL https://get.docker.com | sh sudo systemctl start docker sudo systemctl enable docker装好后一条命令启动Open WebUIdocker run -d \ --name open-webui \ --add-hosthost.docker.internal:host-gateway \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main这里有几个地方要特别注意。OLLAMA_BASE_URL必须是Open WebUI容器能访问到的Ollama地址如果Ollama装在宿主机上容器内直接写localhost是连不通的。我用的host.docker.internal是Docker提供的一个特殊域名指向宿主机配合--add-hosthost.docker.internal:host-gateway参数才能生效。如果你习惯用网络驱动也可以改用network_mode: host那OLLAMA_BASE_URL直接写http://127.0.0.1:11434就行。启动完成后浏览器访问http://服务器IP:3000。第一次打开会让你注册用户这个注册出来的第一个账号会自动成为管理员。管理员登录后在后台把“允许注册”关掉否则任何访问到3000端口的人都能随意注册账号。进入聊天界面后左上角模型选择器里如果没看到模型点一下刷新按钮Ollama里已有的模型就会同步过来。选一个模型开始对话整个部署链路就真正跑通了。4.2 把模型接到 Dify 工作流里如果你不只是想聊天而是想搭一个知识库问答系统或者自动化工作流那就需要Dify出场了。Dify同样支持Docker部署官方提供了完整的docker-compose文件按文档执行即可。安装完成后在Dify后台的“设置-模型供应商”里选择Ollama填写Ollama服务地址http://host.docker.internal:11434模型ID那一栏填你在Ollama里的模型标签比如qwen2.5:7b。保存并点击“测试”按钮如果提示连接成功就可以在Dify的“知识库”里上传文档创建一个基于本地模型的应用了。整个流程大概需要半小时之后一个企业内部文档问答机器人就能跑起来。我的建议是先跑通Open WebUI体验一轮完整对话后再去折腾Dify。不要第一天就把Ollama、Open WebUI、Dify、向量库全装上。每一层都先独立验通再往下走出了问题才知道去哪排查。5. 常见问题与排查技巧实录5.1 显卡不工作、Ollama全部跑在CPU上这是我被问得最多的问题。现象很典型nvidia-smi能正常显示显卡但模型响应极慢一看nvidia-smi里的GPU利用率几乎为0反而是CPU飙到100%。这种情况基本可以断定Ollama没把推理任务放到GPU上。排查步骤很简单。先用ollama ps查看当前加载的模型它会显示模型运行在GPU还是CPU上。然后看Ollama日志journalctl -u ollama -f --no-pager启动模型时日志里会明确写“inference compute id: GPU”还是“inference compute id: CPU”。如果是CPU先检查驱动和CUDA版本是否匹配很多时候是因为Ollama安装时没检测到CUDA库或者安装完驱动后没重启系统。还有一个容易踩的坑是用Docker部署Ollama但忘记传GPU参数。在Docker里跑Ollama必须在docker run命令里加--gpus all否则容器根本访问不到宿主机显卡。这个坑我见过太多次现象就是容器里一切正常但速度奇慢无比。5.2 显存溢出、并发排队与日志分析显存溢出是最硬性的问题报错通常是“CUDA out of memory”。遇到这种情况第一反应不是优化代码而是重新审视模型和硬件是否匹配。比如你只有8GB显存硬跑14B模型无论怎么调都会爆。解决办法无非是几条路换更小参数的模型、使用量化更狠的格式、关掉其他占用显存的进程。如果你需要多个人同时使用显存又很紧张可以调小OLLAMA_NUM_PARALLEL比如改成2。这个参数控制的是并行请求数数值越大同时处理的请求越多但显存占用也越大。很多人在一台24GB显卡的机器上开8并行结果两三个人一用就OOM调回2就一切正常了。记住并行度和显存是直接交换关系没有免费的午餐。日常监控显存用nvidia-smi -l 1可以每秒刷新一次。配合htop看内存和CPU基本能定位80%以上的性能问题。5.3 常见问题速查表我把这些年踩过的坑整理成一张速查表方便你对照排查问题现象可能原因处理方式局域网无法访问11434端口OLLAMA_HOST未修改 / 系统防火墙拦截修改systemd override并重启放行防火墙内网IPOpen WebUI连不上OllamaOLLAMA_BASE_URL写错 / 容器内访问宿主机网络不通使用host.docker.internal并加--add-host参数Open WebUI模型列表为空模型未下载 / 标签名写错检查ollama list在页面刷新模型列表模型响应很慢无GPU / 驱动不匹配 / 并发参数过高看ollama ps确认推理设备检查nvidia-smi利用率重启后Ollama未自启systemd服务未启用执行systemctl enable --now ollama显存直接爆掉模型太大 / 并行度太高 / 精度选太高换小模型或用更低量化降低OLLAMA_NUM_PARALLEL拉取模型一直中断网络不稳定 / 磁盘空间不足用tmux挂后台重试检查df -h磁盘余量最后说一个我的个人经验部署完成以后给这个文件夹和服务写一份简单的文档记录你用的什么系统、什么驱动、什么Ollama版本、下载了哪些模型、改了哪些配置。别高估自己的记忆力三个月后你再回来升级驱动或者加新模型这份文档能帮你省下半天时间。这几年经手的大模型部署环境踩过最多次的坑其实不是显卡而是系统和工具版本。别小看版本这两个字NVIDIA驱动、CUDA、Ollama、Docker四者之间稍微错一个版本就可能出现“明明按照教程做的却怎么都不对”的尴尬局面。所以你在搜索任何部署问题的时候第一件事就是确认你的版本号和教程里是不是同一个。给新人一个最实在的建议第一次部署不要一上来就追求70B大模型先从7B或8B的小模型跑通。看到模型第一次给出回复的那一刻这个正反馈比任何教程都有效。等这条链路烂熟于心再去折腾量化、并发、性能调优你心里就有底了。
Linux服务器部署开源大模型：从硬件评估到Ollama实战
这两年开源大模型铺得遍地都是很多团队的第一反应不是去训练而是先把一个能用的模型部署到自己服务器上。我经手过不少Linux服务器部署大模型的项目从几台办公用的旧机器到带双卡的GPU工作站都有今天这篇就把完整流程摊开讲一遍硬件怎么评估、工具怎么选、命令怎么敲、坑怎么躲。先说个背景。不是只有互联网大厂才需要本地大模型很多场景——比如企业内部知识库问答、文档摘要、代码辅助、会议纪要整理——都适合在本地部署开源权重模型。相比于按小时租云端GPULinux服务器加开源模型的路线更可控数据不出内网长期算下来也划算。如果你手头有一台带NVIDIA显卡的Linux机器或者准备租一台云服务器甚至只是想在虚拟机里先跑个小模型试试水都可以按这篇文章走一遍。1. 部署前的硬件与系统评估1.1 先摸清机器家底显卡、内存、磁盘很多人拿到服务器第一句话就问“用什么框架部署”实际上框架是最后一步。部署大模型的核心瓶颈只有一个显存。模型权重在推理时要全部加载到显存里显存不够再好的CPU、再大的内存都白搭。所以在动手之前我建议你先花十分钟把机器摸清楚。登录服务器后先跑三条命令nvidia-smi free -h df -hnvidia-smi看显卡型号和显存大小free -h看内存df -h看磁盘剩余空间。如果nvidia-smi提示命令不存在说明驱动没装或者这台机器根本没有NVIDIA显卡。这时候可以再用lspci | grep -i nvidia看一眼硬件层面有没有识别到显卡如果 lspci 也查不到那基本可以确认是无GPU机器。显存和模型参数量的关系新手最容易懵。我通常用一个粗算公式帮大家建立感觉10亿参数在FP16精度下大约需要2GB显存在4bit量化下大约只需要0.6GB左右。举例来说一个70亿参数的Qwen2.5-7B模型FP16精度需要约14GB显存但换成Q4_K_M量化版本只需要5到6GB就能跑。所以同样是“7B模型”你用不同的精度加载对显存的需求可以差出三倍。这也是为什么很多人的显卡看起来“够大”跑量化模型却仍然卡顿。内存方面32GB起步比较稳。虽然推理时权重主要吃显存但操作系统、加载过程中的临时缓存、以及如果你要跑多个模型切换都需要内存兜底。如果机器只有16GB内存跑7B量化模型勉强可以但别指望同时开一堆服务。磁盘则要大模型文件动辄几个GB到几十个GB本地知识库、向量库也会持续占空间。我习惯给模型单独分一个目录比如/opt/models至少预留50到200GB磁盘用NVMe SSD体验最好机械硬盘加载大模型真的会等到怀疑人生。1.2 操作系统的选择与基础环境操作系统层面我的建议非常直接新手无脑选Ubuntu Server 22.04 LTS。原因很简单NVIDIA驱动、CUDA生态、Docker、Ollama这些工具链对Ubuntu的适配最顺畅出了问题也最容易搜到解决方案。如果你身在Red Hat系环境或者公司运维统一用Rocky Linux那Rocky Linux 9也能跑只是个别驱动安装步骤要多折腾一下。如果是自己学习用又实在不习惯纯命令行装Ubuntu Desktop版带图形界面也可以。我遇到过不少朋友第一台试验机装了带桌面的Ubuntu用浏览器和文件管理器操作心理压力小很多。线上生产环境当然还是纯Server版更干净但学习阶段没必要为难自己。选好系统后先把基础工具补齐sudo apt update sudo apt install -y curl git vim htop ncdu net-tools这几个命令分别用来下载文件、拉代码、编辑配置、看系统负载、看磁盘占用、看网络端口。你不需要成为Linux运维专家但ssh、df -h、free -h、nvidia-smi、systemctl这五组命令最好烂熟于心。后面所有部署操作基本都是围绕这些命令展开的。还有一个小细节确保SSH服务是开着的并且你在服务器上做的所有操作都尽量在screen或tmux会话里执行。尤其是拉取几十GB模型文件的时候网络一抖动SSH断了前台进程就跟着没了模型下载到一半白等。用tmux挂后台断了还能重新连回去这是运维老手都懂的保命习惯。2. 部署工具选型用什么把模型跑起来2.1 为什么建议先用 Ollama 起步大模型部署的工具链现在已经很成熟但选择太多反而让人不知道从哪下手。我见过的组合五花八门有人直接编译llama.cpp有人硬上vLLM有人用FastAPI自己封装一套推理服务。我的意见很明确第一次部署先用Ollama。为什么是Ollama因为它把llama.cpp那套推理引擎封装成了一个开箱即用的服务。你不需要理解量化算法、不需要手动编译、不需要写Python调度逻辑只需要两行命令就能下载模型并启动一个完整的API服务curl -fsSL https://ollama.com/install.sh | sh ollama run qwen2.5:7b第一条命令安装Ollama第二条命令下载并运行Qwen2.5-7B模型。就这么简单。这种“一条命令解决一个事”的设计极大降低了普通人接触大模型的门槛。很多人以为部署大模型需要会写CUDA代码实际上Ollama把这层全部隐藏掉了。我不建议新手一上来就自己编译llama.cpp不是因为llama.cpp不好而是因为编译过程中的坑实在太多。依赖版本不匹配、CUDA路径不对、量化工具链不熟任何一个环节都能卡你一下午。这些经历对老手来说是成长对新手来说是劝退。先用Ollama跑通全流程、建立体感再回头去研究底层实现学习曲线会平滑很多。那Ollama适合什么场景以我的经验适合三类个人学习体验、小团队内部使用、需要频繁切换模型的场景。它内置了模型管理ollama list看已下载的模型ollama pull拉新模型ollama rm删旧模型跟包管理器一样顺手。如果你想试不同厂商的开源模型Ollama是切换成本最低的方案。2.2 什么时候换 vLLMDify 又是什么角色Ollama虽然好用但不是万能的。如果你要面向几十上百个用户提供高并发服务Ollama的调度能力就不够看了。这时候vLLM是更合适的选择。vLLM的核心优势是PagedAttention显存管理技术可以把显存利用率提到很高吞吐量比朴素推理方案大好几倍。代价是它对CUDA环境更挑剔部署复杂度也更高第一次启动还会预分配大量显存小显存机器根本玩不转。所以我的判断标准很简单几个人用选Ollama几十人并发再考虑vLLM。还有一个容易混淆的角色是Dify。Dify不是推理引擎它更像是一个应用编排平台负责把模型API串成实际功能。比如你要做一个企业知识库问答系统需要“上传文档-切分-向量化-检索-丢给大模型生成回答”这条完整链路Dify干的就是这个活。它本身不跑模型而是对接你已经部署好的模型服务无论是Ollama、vLLM还是各家云API都能接。这三者的关系可以用一个分层来理解Linux和驱动是地基Ollama或vLLM是发动机Open WebUI或Dify是车身和方向盘。新手只要先把发动机点着也就是用Ollama把模型跑起来就已经成功了80%。3. 完整部署实操从装驱动到跑通服务3.1 安装 GPU 驱动与 Ollama我假设你现在拿到了一台带NVIDIA显卡、装好Ubuntu Server 22.04的机器。第一步是确认驱动状态。很多云服务器镜像默认不带NVIDIA驱动或者带的版本很旧。直接执行nvidia-smi如果可以显示显卡信息比如显卡型号、驱动版本、显存大小那驱动这关就过了。如果提示错误需要安装驱动。最简单的方式是用Ubuntu自带的驱动管理器sudo apt update sudo apt install -y nvidia-driver-545 sudo reboot安装完重启再执行nvidia-smi确认能看到显卡信息。这一步出了岔子不要急着往下走驱动不识别后面所有GPU相关的部署都会退化成CPU运行速度惨不忍睹。驱动就绪后安装Ollama。官方给了一条极简安装命令curl -fsSL https://ollama.com/install.sh | sh这条脚本会自动检测系统架构、安装依赖、注册systemd服务。安装完成后检查一下服务状态systemctl status ollama正常情况下Ollama服务已经自动启动并监听127.0.0.1:11434。默认只监听本机意味着只有服务器自己可以访问这个设计是安全的但局域网内其他电脑访问不了后面我会讲怎么开放。顺便说一句如果你拿到的机器没有NVIDIA显卡也不用灰心。Ollama会自动退回到CPU推理模式跑1.5B、3B这种小模型完全没问题只是速度慢一些。对学习流程来说这反而是个很好的起点。3.2 下载模型与显存估算Ollama装好之后最激动人心的时刻来了——下载模型。模型选择上我个人推荐从国内团队或社区生态比较好的开源模型入手比如Qwen2.5系列、Llama 3.1系列、DeepSeek-R1的蒸馏版本这些在Ollama的模型库里都能直接拉取。以Qwen2.5-7B为例执行ollama pull qwen2.5:7bOllama会自动下载模型文件并做好格式转换。下载速度和你的网络带宽有关一般几个GB到十几个GB不等用tmux挂着慢慢下就行。模型下载完成后用ollama list查看已安装列表。接下来是显存估算的关键环节。我整理了一张常用模型的显存参考表基于Q4_K_M量化模型参数量量化格式显存占用预估适合显卡1.5BQ4_K_M约1.2GB4GB以上7B-8BQ4_K_M约5-6GB8GB以上14BQ4_K_M约9-10GB12GB以上32BQ4_K_M约20GB24GB以上70BQ4_K_M约40GB48GB以上如果你不知道什么是“量化”我用一个生活化的类比解释模型权重原本是32位或16位的浮点数精度高但体积大量化就是把小数点后面不太重要的位数砍掉用8位甚至4位来存。好处是体积和显存需求大幅下降坏处是模型智商会有轻微下降。对于大多数对话、总结、问答场景Q4量化后的质量损失几乎感觉不到。跑一个试试。执行ollama run qwen2.5:7b在交互式对话窗口里输入“你好介绍一下你自己”如果模型能流畅回复恭喜你这次部署的核心环节已经通了。这时候再开一个终端窗口看nvidia-smi你会看到显存被Ollama进程占用GPU利用率跳动说明推理确实发生在显卡上。3.3 用 systemd 托管 Ollama 服务并开放局域网Ollama默认只允许本机访问但实际使用中团队其他同事的电脑也要连过来用。这时候要改一下Ollama的启动参数让它监听所有网络接口并且调整并发和自动卸载策略。先创建systemd的override目录sudo mkdir -p /etc/systemd/system/ollama.service.d sudo vim /etc/systemd/system/ollama.service.d/override.conf写入以下内容[Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EnvironmentOLLAMA_NUM_PARALLEL4 EnvironmentOLLAMA_MAX_LOADED_MODELS1 EnvironmentOLLAMA_KEEP_ALIVE5m这几个参数分别表示监听所有网卡的11434端口最多并行处理4个请求同时只保留一个模型在显存里模型空闲5分钟后自动卸载。OLLAMA_NUM_PARALLEL可以根据显卡显存大小调整显存紧张就改成2否则并发请求会把显存挤爆。保存后重载systemd并重启服务sudo systemctl daemon-reload sudo systemctl restart ollama再验证一下。本机执行curl http://127.0.0.1:11434/api/tags有JSON输出说明服务正常。然后找到服务器的局域网IP比如192.168.1.100在另一台电脑上执行curl http://192.168.1.100:11434/api/tags如果也能返回JSON说明局域网已经能访问了。这一步是很多人容易忽略的因为Ollama的安装脚本默认不开放外部监听不改配置就算关了防火墙也连不上。安全提醒千万不要直接把11434端口裸奔到公网。Ollama本身没有复杂的认证机制暴露到公网等于把你的模型和算力交给全世界。如果是生产环境建议用防火墙只允许内网IP访问或者在前面加一层带认证的反向代理。sudo ufw allow from 192.168.1.0/24 to any port 11434 proto tcp4. 配一个浏览器入口Open WebUI 与 Dify 对接4.1 用 Docker 快速部署 Open WebUI命令行跑通之后下一步就是给团队配一个像ChatGPT那样好用的网页界面。我推荐Open WebUI它自带聊天界面、多用户管理、文件上传、对话历史、收藏夹还支持自定义模型参数基本能满足小团队日常使用。Open WebUI推荐用Docker部署这也是目前最省心的方式。先装Dockercurl -fsSL https://get.docker.com | sh sudo systemctl start docker sudo systemctl enable docker装好后一条命令启动Open WebUIdocker run -d \ --name open-webui \ --add-hosthost.docker.internal:host-gateway \ -p 3000:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main这里有几个地方要特别注意。OLLAMA_BASE_URL必须是Open WebUI容器能访问到的Ollama地址如果Ollama装在宿主机上容器内直接写localhost是连不通的。我用的host.docker.internal是Docker提供的一个特殊域名指向宿主机配合--add-hosthost.docker.internal:host-gateway参数才能生效。如果你习惯用网络驱动也可以改用network_mode: host那OLLAMA_BASE_URL直接写http://127.0.0.1:11434就行。启动完成后浏览器访问http://服务器IP:3000。第一次打开会让你注册用户这个注册出来的第一个账号会自动成为管理员。管理员登录后在后台把“允许注册”关掉否则任何访问到3000端口的人都能随意注册账号。进入聊天界面后左上角模型选择器里如果没看到模型点一下刷新按钮Ollama里已有的模型就会同步过来。选一个模型开始对话整个部署链路就真正跑通了。4.2 把模型接到 Dify 工作流里如果你不只是想聊天而是想搭一个知识库问答系统或者自动化工作流那就需要Dify出场了。Dify同样支持Docker部署官方提供了完整的docker-compose文件按文档执行即可。安装完成后在Dify后台的“设置-模型供应商”里选择Ollama填写Ollama服务地址http://host.docker.internal:11434模型ID那一栏填你在Ollama里的模型标签比如qwen2.5:7b。保存并点击“测试”按钮如果提示连接成功就可以在Dify的“知识库”里上传文档创建一个基于本地模型的应用了。整个流程大概需要半小时之后一个企业内部文档问答机器人就能跑起来。我的建议是先跑通Open WebUI体验一轮完整对话后再去折腾Dify。不要第一天就把Ollama、Open WebUI、Dify、向量库全装上。每一层都先独立验通再往下走出了问题才知道去哪排查。5. 常见问题与排查技巧实录5.1 显卡不工作、Ollama全部跑在CPU上这是我被问得最多的问题。现象很典型nvidia-smi能正常显示显卡但模型响应极慢一看nvidia-smi里的GPU利用率几乎为0反而是CPU飙到100%。这种情况基本可以断定Ollama没把推理任务放到GPU上。排查步骤很简单。先用ollama ps查看当前加载的模型它会显示模型运行在GPU还是CPU上。然后看Ollama日志journalctl -u ollama -f --no-pager启动模型时日志里会明确写“inference compute id: GPU”还是“inference compute id: CPU”。如果是CPU先检查驱动和CUDA版本是否匹配很多时候是因为Ollama安装时没检测到CUDA库或者安装完驱动后没重启系统。还有一个容易踩的坑是用Docker部署Ollama但忘记传GPU参数。在Docker里跑Ollama必须在docker run命令里加--gpus all否则容器根本访问不到宿主机显卡。这个坑我见过太多次现象就是容器里一切正常但速度奇慢无比。5.2 显存溢出、并发排队与日志分析显存溢出是最硬性的问题报错通常是“CUDA out of memory”。遇到这种情况第一反应不是优化代码而是重新审视模型和硬件是否匹配。比如你只有8GB显存硬跑14B模型无论怎么调都会爆。解决办法无非是几条路换更小参数的模型、使用量化更狠的格式、关掉其他占用显存的进程。如果你需要多个人同时使用显存又很紧张可以调小OLLAMA_NUM_PARALLEL比如改成2。这个参数控制的是并行请求数数值越大同时处理的请求越多但显存占用也越大。很多人在一台24GB显卡的机器上开8并行结果两三个人一用就OOM调回2就一切正常了。记住并行度和显存是直接交换关系没有免费的午餐。日常监控显存用nvidia-smi -l 1可以每秒刷新一次。配合htop看内存和CPU基本能定位80%以上的性能问题。5.3 常见问题速查表我把这些年踩过的坑整理成一张速查表方便你对照排查问题现象可能原因处理方式局域网无法访问11434端口OLLAMA_HOST未修改 / 系统防火墙拦截修改systemd override并重启放行防火墙内网IPOpen WebUI连不上OllamaOLLAMA_BASE_URL写错 / 容器内访问宿主机网络不通使用host.docker.internal并加--add-host参数Open WebUI模型列表为空模型未下载 / 标签名写错检查ollama list在页面刷新模型列表模型响应很慢无GPU / 驱动不匹配 / 并发参数过高看ollama ps确认推理设备检查nvidia-smi利用率重启后Ollama未自启systemd服务未启用执行systemctl enable --now ollama显存直接爆掉模型太大 / 并行度太高 / 精度选太高换小模型或用更低量化降低OLLAMA_NUM_PARALLEL拉取模型一直中断网络不稳定 / 磁盘空间不足用tmux挂后台重试检查df -h磁盘余量最后说一个我的个人经验部署完成以后给这个文件夹和服务写一份简单的文档记录你用的什么系统、什么驱动、什么Ollama版本、下载了哪些模型、改了哪些配置。别高估自己的记忆力三个月后你再回来升级驱动或者加新模型这份文档能帮你省下半天时间。这几年经手的大模型部署环境踩过最多次的坑其实不是显卡而是系统和工具版本。别小看版本这两个字NVIDIA驱动、CUDA、Ollama、Docker四者之间稍微错一个版本就可能出现“明明按照教程做的却怎么都不对”的尴尬局面。所以你在搜索任何部署问题的时候第一件事就是确认你的版本号和教程里是不是同一个。给新人一个最实在的建议第一次部署不要一上来就追求70B大模型先从7B或8B的小模型跑通。看到模型第一次给出回复的那一刻这个正反馈比任何教程都有效。等这条链路烂熟于心再去折腾量化、并发、性能调优你心里就有底了。
