2026/9/11 1:45:05
FEATURED · 精选文章 
上周末帮朋友在一台闲置的Linux服务器上部署大模型从环境确认到把DeepSeek模型跑起来、再提供对外接口前后折腾了一整天。最有意思的是真正耗时间的不是装环境而是搞清楚这台机器到底该怎么选模型、怎么分配显存、怎么避免把自己埋进坑里。这篇文章就围绕Linux服务器部署大模型这条主线把我实际验证过的方案、算过的账、踩过的坑完整写下来希望帮你少走些弯路。适合谁看手里有一台Linux服务器、想在本地跑开源大模型的运维和后端开发以及准备做AI应用、但不想被各种教程绕晕的工程师。不需要你是算法出身Linux基础操作过关就行。下面的内容我尽量说人话该给命令给命令该算账算账。1. 先算账再动手显存、算力和模型选择的匹配逻辑1.1 显存与参数量的换算没那么玄乎很多人一上来就问我的机器能跑多大的模型这个问题其实可以拿一个公式先估算模型权重占用显存约等于参数量乘以每个参数需要的字节数。FP32每个参数4字节FP16/BF16每个参数2字节INT8每个参数1字节INT4每个参数约0.5字节所以一个7B模型FP16权重大约是7×214GB。但实际部署时显存占用一定比这个高因为还有KV Cache、CUDA context、激活值、推理框架自身的内存开销。我的经验是把权重占用再乘1.2到1.3当作这块显卡的最低显存线。按这个标准估算下来模型档位精度/量化权重大小实际建议显存常见可行的显卡7BFP1614GB17GB以上RTX 3090/4090 24GB7BINT4量化3.5GB6~8GBRTX 3060 12GB14BFP1628GB34GB以上双卡24GB或单卡48GB32BINT4量化16GB20~24GBRTX 4090 24GB紧70BINT4量化35GB42GB以上多卡或专业卡这里必须多提一句很多人把能不能跑理解成模型能不能加载其实跑起来只是一个开始。上下文窗口开多大、并发请求几个、对话历史有多长都会直接改变显存曲线。我见过8GB显存硬跑7B模型的情况量化成INT4确实能加载但输出速度只有几个token每秒体验非常差基本不具备实用价值。1.2 CPU、内存、磁盘的底线配置GPU是主角但CPU、内存、磁盘也不能太寒酸。内存至少要能放下模型权重加一些余量。7B模型跑起来我建议32GB内存起步16GB会很紧张。如果涉及CPU offload就是显存不够把部分层放到内存里内存需求直接翻倍因为那些层要常驻系统内存。CPU推理时CPU主要负责调度和预处理不是主要瓶颈。但如果你打算用纯CPU跑模型CPU的多通道内存带宽反而比核心数更重要大模型推理本质上是一个反复喂参数的过程大部分时间都卡在内存带宽上。磁盘模型权重文件动辄十几GB建议用NVMe SSD。7B模型文件大概15GB加上Python环境、依赖库、日志我一般至少预留50GB。如果还要下载压缩包再解压转换格式临时空间再留一份。这个环节很多人容易忽视的是GPU推理时系统内存不只是给操作系统用的。模型加载时需要先把权重从磁盘读入内存再搬到显存如果内存不足进程可能被系统直接杀掉连报错都看不到。1.3 开源模型怎么选先看任务再看显存选模型我的顺序是先定任务类型再定参数档位最后根据显存决定量化级别。通用聊天、中文场景我常用Qwen系列和DeepSeek系列中文效果好社区活跃。代码生成优先看Qwen2.5-Coder。通用英文场景可以看Llama系列。显存吃紧时优先考虑INT8/INT4量化而不是降低模型档位因为7B量化后的能力通常好于3B的原生精度。有一个容易忽略的点同一个模型在不同框架下的显存表现差异很大。Ollama默认对模型做了量化所以用起来显存占用比纯transformers加载FP16版本低不少。后面我详细说部署方案时还会涉及。2. 环境准备驱动、CUDA、Python和Docker的一次性配齐2.1 新机器到手第一步确认GPU和驱动状态拿到服务器先不要急着装模型用几个命令确认底层状态lspci | grep -i nvidia nvidia-smi如果lspci能查到NVIDIA显卡但nvidia-smi报错找不到驱动说明驱动没装。Ubuntu/Debian系统最简单的做法sudo apt update sudo apt install nvidia-driver-535 sudo reboot这个环节有个经验驱动版本别追新稳定即可。我遇到过为了体验新特性装了个最新驱动结果旧卡直接不支持的尴尬情况。装完驱动后执行nvidia-smi应该能看到类似下面的输出----------------------------------------------------------------------------- | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | -----------------------------------------------------------------------------注意这个CUDA Version它指的是当前驱动支持的最高CUDA版本不是说系统里已经装好了CUDA 12.2。很多教程没讲清楚这一点导致小白跟着去下载安装完整的CUDA Toolkit白白消耗好几个小时。2.2 CUDA到底要不要装很多人理解错了直接说结论绝大多数情况下你不需要手动安装CUDA ToolkitPyTorch和Ollama这类框架会自带运行时。为什么因为PyTorch的pip包捆绑了CUDA runtime只要用配套的pip命令安装内部就有完整的CUDA库不需要系统级CUDA。真正需要手动装CUDA Toolkit的场景是编译CUDA扩展、使用vLLM等对CUDA版本敏感的框架或者做底层性能分析。PyTorch的安装方式pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121装完验证GPU是否可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))输出True说明PyTorch能正常使用GPU。这里配套的CUDA toolkit版本不是越高越好要看你的驱动版本驱动太老的情况下装新版本PyTorch会报错。2.3 Python虚拟环境和Docker两条路线怎么选如果你要跑的是基于transformers的Python推理服务我强烈建议用虚拟环境避免把系统Python搞乱python3 -m venv llm-env source llm-env/bin/activate pip install transformers accelerate如果希望环境可复现、方便迁移或者多人共用一台机器Docker是更好的选择。Docker部署大模型的关键点在于GPU透传需要先装nvidia-container-toolkitsudo apt install nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker然后运行容器时加参数docker run --gpus all ...很多人在这一步翻车报错could not select device driver with capabilities: [[gpu]]基本就是nvidia-container-toolkit没装好或者没重启Docker。我自己踩过一次后现在每次都会用以下命令先验证Docker里的GPU是否可见docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi能看到显卡信息才敢继续往下走。3. 核心部署路径用Ollama把DeepSeek等模型跑起来3.1 为什么用Ollama而不是直接写transformers脚本我的原则是能用成熟工具就别重复造轮子。Ollama是当前社区里把模型管理加推理服务做得最轻量的工具之一。一条命令拉模型一条命令跑服务内置量化支持不需要自己转换模型格式提供OpenAI兼容API可以对接很多现有应用支持Modelfile自定义参数灵活度足够相比之下直接用transformers加FastAPI写推理服务虽然自由度更高但要处理的事情太多模型加载调度、并发控制、tokenizer处理、显存管理、服务优雅退出。对非算法背景的人来说这个成本不低。当然Ollama不是万能的。追求高吞吐、大规模并发、多副本推理时vLLM这类专业推理框架会更合适。但个人服务器、内部工具、产品原型Ollama就是目前最省心的选择。我在生产环境中也用过vLLM效果确实好但配置和学习成本也在那里。3.2 安装Ollama并拉取模型安装很简单官方一条命令curl -fsSL https://ollama.com/install.sh | sh装完启动服务并设为开机自启systemctl start ollama systemctl enable ollama拉取模型ollama pull deepseek-r1:7b如果拉Qwen系列ollama pull qwen2.5:7b拉完查看本地模型列表ollama list直接进入交互对话ollama run deepseek-r1:7b这里有个实用技巧Ollama默认拉取的是Q4_K_M量化版本所以显存要求比较低。想跑更高精度的FP16版本可以指定tag比如qwen2.5:7b-instruct-fp16但显存占用会明显上涨。首次下载会根据模型大小等待较长时间7B模型一般几个G网速正常的机器几分钟到十几分钟不等。3.3 本地跑通后的验证与显存观察模型跑起来后我习惯先看两个东西输出质量和资源占用。ollama ps这个命令显示当前加载了哪些模型、映射在哪些GPU上、显存占用和CPU占用情况。再配合nvidia-smi实时看GPU利用率和显存曲线。正常的7B量化模型跑起来显存占用通常在6到8GB左右。如果你看到显存占用高达十几GB大概率是加载了FP16版本。性能测试我一般不跑复杂的benchmark就用交互对话输入一段长文本让它续写感受响应速度。如果每秒只输出一两个token说明模型太大或者GPU算力跟不上果断换更小模型或量化版本。这个体感测试虽然不严谨但对个人使用来说足够直观。4. 从单机命令到对外服务API暴露、并发参数与安全防护4.1 开启OpenAI兼容API用curl和Python调用Ollama默认只监听本机11434端口。要让局域网其他机器能访问需要设置环境变量并重启服务export OLLAMA_HOST0.0.0.0:11434用Systemd管理服务时环境变量建议写到override文件里否则重启后会丢失mkdir -p /etc/systemd/system/ollama.service.d cat /etc/systemd/system/ollama.service.d/override.conf EOF [Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EOF systemctl daemon-reload systemctl restart ollama之后在同一局域网内可以用curl测试curl http://服务器IP:11434/api/chat -d { model: deepseek-r1:7b, messages: [ {role: user, content: 用一句话介绍Linux} ] }Ollama的API和OpenAI格式兼容Python里可以直接用openai库from openai import OpenAI client OpenAI( base_urlhttp://服务器IP:11434/v1, api_keyollama ) response client.chat.completions.create( modeldeepseek-r1:7b, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content)这里api_key随便填一个就行Ollama本地默认不做鉴权。这个兼容性意味着很多基于OpenAI SDK开发的应用只要改一下base_url就能切到本地模型非常省事。4.2 并发与上下文参数对显存的真实影响服务跑起来后很多人会忽略一个关键问题默认参数是为单用户设计的。Ollama有几个环境变量会影响并发与显存OLLAMA_NUM_PARALLEL同时处理几个请求数默认比较保守可根据显存余量调大OLLAMA_MAX_LOADED_MODELS同时加载几个模型默认是3模型多了显存会爆OLLAMA_KEEP_ALIVE模型在显存中的存活时间默认5分钟频繁调用建议调大举个例子一张24GB显卡跑7B量化模型单请求时显存可能只用了8GB此时把OLLAMA_NUM_PARALLEL调到2或者3可以在不明显影响单请求速度的情况下提升吞吐。但别贪心并发数一高KV Cache总和上去了照样OOM。我自己的调参顺序是先用nvidia-smi观察单请求显存算出可容纳的并发倍数然后逐步加并发每加一档就跑一轮模拟请求直到出现明显延迟增长或显存告警再回退一档。这个方法和性能压测的原理一样只是规模小但很管用。4.3 内网访问可以裸奔公网不行这里必须说一个安全底线Ollama默认没有鉴权如果直接把服务端口暴露到公网相当于把服务器算力敞开给全网用。网上已经有不少人被薅羊毛甚至被植入挖矿程序的案例这不是吓唬人。安全做法按场景分只在内网用监听内网IP用防火墙限定来源IP例如只允许公司网段访问跨网络访问优先考虑SSH隧道ssh -L 11434:127.0.0.1:11434 用户名服务器IP使用组网工具比如Tailscale建立私有网络不开放公网端口必须提供公网API时前面加一层带鉴权的反向代理。nginx配置Basic Auth是最简单的做法sudo apt install nginx apache2-utils htpasswd -c /etc/nginx/.htpasswd ai_user然后配置nginx将对应路径转发到11434端口并开启auth_basic认证。我在内网环境里不做公网暴露只用SSH隧道加防火墙基本满足需求。5. 部署路上最常见的坑我踩过的和你们会踩的5.1 OOM显存说爆就爆怎么定位和处理最常见的问题就是OOM。现象很直接请求要么被拒绝要么进程被杀。排查顺序建议这样看服务日志journalctl -u ollama -f有没有CUDA out of memory看系统日志dmesg | tail如果出现Out of memory: Killed process说明是系统内存不够不是显存不够用nvidia-smi确认显存占用是不是已经打满解决思路换更小模型或更低量化位宽减少OLLAMA_NUM_PARALLEL调低max tokens限制单次生成长度必要时换用vLLM等显存调度更精细的框架我实际部署中一个很深的体会是模型明明不跑的时候显存也可能不被释放。Ollama的keep-alive机制会在5分钟内把模型保留在显存里避免频繁加载。如果你看到空闲时显存仍然很高这是正常的不用慌。5.2 模型下载慢、中断换源是个技术活ollama pull一个7B模型要下载好几个GB甚至十几GB的文件网络差的时候体验非常糟。几个实测有效的方法用Ollama的断点续传pull中断后重新执行pull会从断点继续不需要重新下模型文件不一定从官方拉可以把Hugging Face上的GGUF格式文件下载好再通过Modelfile创建Ollama模型在国内网络环境下我习惯从ModelScope社区下载权重速度更稳从本地GGUF创建模型的流程FROM /path/to/local/model.gguf然后执行ollama create my-model -f Modelfile这样就把本地文件注册成了Ollama模型。注意GGUF格式要匹配别拿PyTorch格式权重直接喂给Ollama格式不对会直接报错。5.3 无GPU的旧服务器CPU推理的真实体验不是所有人都有带GPU的服务器。我也在纯CPU机器上跑过7B量化模型结论是能跑但体验完全取决于内存带宽。以一台双路Xeon服务器为例跑7B Q4量化模型输出速度大概在5到10 token每秒勉强能用于内部异步任务撑不住实时对话。想优化的话选更小的模型比如3B、1.5B档位确保内存是多通道配置频率别太低关掉其他吃内存的服务适当降低生成时的batch size如果业务对延迟敏感我的建议是别折磨自己加GPU或者直接用现成的API服务。CPU推理作为备用方案没问题作为主力方案会让你怀疑人生。5.4 模型部署成功不等于效果达标输出质量还得调部署完成只是第一步。很多人把模型跑起来后发现输出质量不如网页版就开始怀疑是不是部署错了。其实大概率不是是推理参数没对齐。需要重点关注的几个参数temperature控制随机性任务型对话建议设低一些比如0.3到0.7top_p控制采样范围默认0.9左右想稳定输出可以调低一点system prompt不同模型默认行为差异很大定制一个贴合业务场景的系统提示词有时比换模型更有效举一个实际例子之前用Qwen做客服问答默认输出总爱长篇大论把用户绕晕。后来我在系统提示词里明确要求直接回答不要解释控制在50字以内效果立刻改善。所以部署完不要急着声明过关先拿真实业务问题跑几轮把参数和提示词调到业务能接受为止。最后分享一个我自己的习惯任何新模型上线我都会先在开发机上用小模型把流程走通再迁移到正式服务器。不要一上来就在生产环境折腾环境变量、依赖版本、端口冲突这些问题会让你焦头烂额。部署这种事稳比快重要。等这条链路彻底跑顺了再去研究RAG接入、多模型编排那些进阶玩法也不迟。
Linux服务器部署大模型实战：显存估算、Ollama与API安全
上周末帮朋友在一台闲置的Linux服务器上部署大模型从环境确认到把DeepSeek模型跑起来、再提供对外接口前后折腾了一整天。最有意思的是真正耗时间的不是装环境而是搞清楚这台机器到底该怎么选模型、怎么分配显存、怎么避免把自己埋进坑里。这篇文章就围绕Linux服务器部署大模型这条主线把我实际验证过的方案、算过的账、踩过的坑完整写下来希望帮你少走些弯路。适合谁看手里有一台Linux服务器、想在本地跑开源大模型的运维和后端开发以及准备做AI应用、但不想被各种教程绕晕的工程师。不需要你是算法出身Linux基础操作过关就行。下面的内容我尽量说人话该给命令给命令该算账算账。1. 先算账再动手显存、算力和模型选择的匹配逻辑1.1 显存与参数量的换算没那么玄乎很多人一上来就问我的机器能跑多大的模型这个问题其实可以拿一个公式先估算模型权重占用显存约等于参数量乘以每个参数需要的字节数。FP32每个参数4字节FP16/BF16每个参数2字节INT8每个参数1字节INT4每个参数约0.5字节所以一个7B模型FP16权重大约是7×214GB。但实际部署时显存占用一定比这个高因为还有KV Cache、CUDA context、激活值、推理框架自身的内存开销。我的经验是把权重占用再乘1.2到1.3当作这块显卡的最低显存线。按这个标准估算下来模型档位精度/量化权重大小实际建议显存常见可行的显卡7BFP1614GB17GB以上RTX 3090/4090 24GB7BINT4量化3.5GB6~8GBRTX 3060 12GB14BFP1628GB34GB以上双卡24GB或单卡48GB32BINT4量化16GB20~24GBRTX 4090 24GB紧70BINT4量化35GB42GB以上多卡或专业卡这里必须多提一句很多人把能不能跑理解成模型能不能加载其实跑起来只是一个开始。上下文窗口开多大、并发请求几个、对话历史有多长都会直接改变显存曲线。我见过8GB显存硬跑7B模型的情况量化成INT4确实能加载但输出速度只有几个token每秒体验非常差基本不具备实用价值。1.2 CPU、内存、磁盘的底线配置GPU是主角但CPU、内存、磁盘也不能太寒酸。内存至少要能放下模型权重加一些余量。7B模型跑起来我建议32GB内存起步16GB会很紧张。如果涉及CPU offload就是显存不够把部分层放到内存里内存需求直接翻倍因为那些层要常驻系统内存。CPU推理时CPU主要负责调度和预处理不是主要瓶颈。但如果你打算用纯CPU跑模型CPU的多通道内存带宽反而比核心数更重要大模型推理本质上是一个反复喂参数的过程大部分时间都卡在内存带宽上。磁盘模型权重文件动辄十几GB建议用NVMe SSD。7B模型文件大概15GB加上Python环境、依赖库、日志我一般至少预留50GB。如果还要下载压缩包再解压转换格式临时空间再留一份。这个环节很多人容易忽视的是GPU推理时系统内存不只是给操作系统用的。模型加载时需要先把权重从磁盘读入内存再搬到显存如果内存不足进程可能被系统直接杀掉连报错都看不到。1.3 开源模型怎么选先看任务再看显存选模型我的顺序是先定任务类型再定参数档位最后根据显存决定量化级别。通用聊天、中文场景我常用Qwen系列和DeepSeek系列中文效果好社区活跃。代码生成优先看Qwen2.5-Coder。通用英文场景可以看Llama系列。显存吃紧时优先考虑INT8/INT4量化而不是降低模型档位因为7B量化后的能力通常好于3B的原生精度。有一个容易忽略的点同一个模型在不同框架下的显存表现差异很大。Ollama默认对模型做了量化所以用起来显存占用比纯transformers加载FP16版本低不少。后面我详细说部署方案时还会涉及。2. 环境准备驱动、CUDA、Python和Docker的一次性配齐2.1 新机器到手第一步确认GPU和驱动状态拿到服务器先不要急着装模型用几个命令确认底层状态lspci | grep -i nvidia nvidia-smi如果lspci能查到NVIDIA显卡但nvidia-smi报错找不到驱动说明驱动没装。Ubuntu/Debian系统最简单的做法sudo apt update sudo apt install nvidia-driver-535 sudo reboot这个环节有个经验驱动版本别追新稳定即可。我遇到过为了体验新特性装了个最新驱动结果旧卡直接不支持的尴尬情况。装完驱动后执行nvidia-smi应该能看到类似下面的输出----------------------------------------------------------------------------- | NVIDIA-SMI 535.104.05 Driver Version: 535.104.05 CUDA Version: 12.2 | -----------------------------------------------------------------------------注意这个CUDA Version它指的是当前驱动支持的最高CUDA版本不是说系统里已经装好了CUDA 12.2。很多教程没讲清楚这一点导致小白跟着去下载安装完整的CUDA Toolkit白白消耗好几个小时。2.2 CUDA到底要不要装很多人理解错了直接说结论绝大多数情况下你不需要手动安装CUDA ToolkitPyTorch和Ollama这类框架会自带运行时。为什么因为PyTorch的pip包捆绑了CUDA runtime只要用配套的pip命令安装内部就有完整的CUDA库不需要系统级CUDA。真正需要手动装CUDA Toolkit的场景是编译CUDA扩展、使用vLLM等对CUDA版本敏感的框架或者做底层性能分析。PyTorch的安装方式pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121装完验证GPU是否可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))输出True说明PyTorch能正常使用GPU。这里配套的CUDA toolkit版本不是越高越好要看你的驱动版本驱动太老的情况下装新版本PyTorch会报错。2.3 Python虚拟环境和Docker两条路线怎么选如果你要跑的是基于transformers的Python推理服务我强烈建议用虚拟环境避免把系统Python搞乱python3 -m venv llm-env source llm-env/bin/activate pip install transformers accelerate如果希望环境可复现、方便迁移或者多人共用一台机器Docker是更好的选择。Docker部署大模型的关键点在于GPU透传需要先装nvidia-container-toolkitsudo apt install nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker然后运行容器时加参数docker run --gpus all ...很多人在这一步翻车报错could not select device driver with capabilities: [[gpu]]基本就是nvidia-container-toolkit没装好或者没重启Docker。我自己踩过一次后现在每次都会用以下命令先验证Docker里的GPU是否可见docker run --rm --gpus all nvidia/cuda:12.2.0-base-ubuntu22.04 nvidia-smi能看到显卡信息才敢继续往下走。3. 核心部署路径用Ollama把DeepSeek等模型跑起来3.1 为什么用Ollama而不是直接写transformers脚本我的原则是能用成熟工具就别重复造轮子。Ollama是当前社区里把模型管理加推理服务做得最轻量的工具之一。一条命令拉模型一条命令跑服务内置量化支持不需要自己转换模型格式提供OpenAI兼容API可以对接很多现有应用支持Modelfile自定义参数灵活度足够相比之下直接用transformers加FastAPI写推理服务虽然自由度更高但要处理的事情太多模型加载调度、并发控制、tokenizer处理、显存管理、服务优雅退出。对非算法背景的人来说这个成本不低。当然Ollama不是万能的。追求高吞吐、大规模并发、多副本推理时vLLM这类专业推理框架会更合适。但个人服务器、内部工具、产品原型Ollama就是目前最省心的选择。我在生产环境中也用过vLLM效果确实好但配置和学习成本也在那里。3.2 安装Ollama并拉取模型安装很简单官方一条命令curl -fsSL https://ollama.com/install.sh | sh装完启动服务并设为开机自启systemctl start ollama systemctl enable ollama拉取模型ollama pull deepseek-r1:7b如果拉Qwen系列ollama pull qwen2.5:7b拉完查看本地模型列表ollama list直接进入交互对话ollama run deepseek-r1:7b这里有个实用技巧Ollama默认拉取的是Q4_K_M量化版本所以显存要求比较低。想跑更高精度的FP16版本可以指定tag比如qwen2.5:7b-instruct-fp16但显存占用会明显上涨。首次下载会根据模型大小等待较长时间7B模型一般几个G网速正常的机器几分钟到十几分钟不等。3.3 本地跑通后的验证与显存观察模型跑起来后我习惯先看两个东西输出质量和资源占用。ollama ps这个命令显示当前加载了哪些模型、映射在哪些GPU上、显存占用和CPU占用情况。再配合nvidia-smi实时看GPU利用率和显存曲线。正常的7B量化模型跑起来显存占用通常在6到8GB左右。如果你看到显存占用高达十几GB大概率是加载了FP16版本。性能测试我一般不跑复杂的benchmark就用交互对话输入一段长文本让它续写感受响应速度。如果每秒只输出一两个token说明模型太大或者GPU算力跟不上果断换更小模型或量化版本。这个体感测试虽然不严谨但对个人使用来说足够直观。4. 从单机命令到对外服务API暴露、并发参数与安全防护4.1 开启OpenAI兼容API用curl和Python调用Ollama默认只监听本机11434端口。要让局域网其他机器能访问需要设置环境变量并重启服务export OLLAMA_HOST0.0.0.0:11434用Systemd管理服务时环境变量建议写到override文件里否则重启后会丢失mkdir -p /etc/systemd/system/ollama.service.d cat /etc/systemd/system/ollama.service.d/override.conf EOF [Service] EnvironmentOLLAMA_HOST0.0.0.0:11434 EOF systemctl daemon-reload systemctl restart ollama之后在同一局域网内可以用curl测试curl http://服务器IP:11434/api/chat -d { model: deepseek-r1:7b, messages: [ {role: user, content: 用一句话介绍Linux} ] }Ollama的API和OpenAI格式兼容Python里可以直接用openai库from openai import OpenAI client OpenAI( base_urlhttp://服务器IP:11434/v1, api_keyollama ) response client.chat.completions.create( modeldeepseek-r1:7b, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content)这里api_key随便填一个就行Ollama本地默认不做鉴权。这个兼容性意味着很多基于OpenAI SDK开发的应用只要改一下base_url就能切到本地模型非常省事。4.2 并发与上下文参数对显存的真实影响服务跑起来后很多人会忽略一个关键问题默认参数是为单用户设计的。Ollama有几个环境变量会影响并发与显存OLLAMA_NUM_PARALLEL同时处理几个请求数默认比较保守可根据显存余量调大OLLAMA_MAX_LOADED_MODELS同时加载几个模型默认是3模型多了显存会爆OLLAMA_KEEP_ALIVE模型在显存中的存活时间默认5分钟频繁调用建议调大举个例子一张24GB显卡跑7B量化模型单请求时显存可能只用了8GB此时把OLLAMA_NUM_PARALLEL调到2或者3可以在不明显影响单请求速度的情况下提升吞吐。但别贪心并发数一高KV Cache总和上去了照样OOM。我自己的调参顺序是先用nvidia-smi观察单请求显存算出可容纳的并发倍数然后逐步加并发每加一档就跑一轮模拟请求直到出现明显延迟增长或显存告警再回退一档。这个方法和性能压测的原理一样只是规模小但很管用。4.3 内网访问可以裸奔公网不行这里必须说一个安全底线Ollama默认没有鉴权如果直接把服务端口暴露到公网相当于把服务器算力敞开给全网用。网上已经有不少人被薅羊毛甚至被植入挖矿程序的案例这不是吓唬人。安全做法按场景分只在内网用监听内网IP用防火墙限定来源IP例如只允许公司网段访问跨网络访问优先考虑SSH隧道ssh -L 11434:127.0.0.1:11434 用户名服务器IP使用组网工具比如Tailscale建立私有网络不开放公网端口必须提供公网API时前面加一层带鉴权的反向代理。nginx配置Basic Auth是最简单的做法sudo apt install nginx apache2-utils htpasswd -c /etc/nginx/.htpasswd ai_user然后配置nginx将对应路径转发到11434端口并开启auth_basic认证。我在内网环境里不做公网暴露只用SSH隧道加防火墙基本满足需求。5. 部署路上最常见的坑我踩过的和你们会踩的5.1 OOM显存说爆就爆怎么定位和处理最常见的问题就是OOM。现象很直接请求要么被拒绝要么进程被杀。排查顺序建议这样看服务日志journalctl -u ollama -f有没有CUDA out of memory看系统日志dmesg | tail如果出现Out of memory: Killed process说明是系统内存不够不是显存不够用nvidia-smi确认显存占用是不是已经打满解决思路换更小模型或更低量化位宽减少OLLAMA_NUM_PARALLEL调低max tokens限制单次生成长度必要时换用vLLM等显存调度更精细的框架我实际部署中一个很深的体会是模型明明不跑的时候显存也可能不被释放。Ollama的keep-alive机制会在5分钟内把模型保留在显存里避免频繁加载。如果你看到空闲时显存仍然很高这是正常的不用慌。5.2 模型下载慢、中断换源是个技术活ollama pull一个7B模型要下载好几个GB甚至十几GB的文件网络差的时候体验非常糟。几个实测有效的方法用Ollama的断点续传pull中断后重新执行pull会从断点继续不需要重新下模型文件不一定从官方拉可以把Hugging Face上的GGUF格式文件下载好再通过Modelfile创建Ollama模型在国内网络环境下我习惯从ModelScope社区下载权重速度更稳从本地GGUF创建模型的流程FROM /path/to/local/model.gguf然后执行ollama create my-model -f Modelfile这样就把本地文件注册成了Ollama模型。注意GGUF格式要匹配别拿PyTorch格式权重直接喂给Ollama格式不对会直接报错。5.3 无GPU的旧服务器CPU推理的真实体验不是所有人都有带GPU的服务器。我也在纯CPU机器上跑过7B量化模型结论是能跑但体验完全取决于内存带宽。以一台双路Xeon服务器为例跑7B Q4量化模型输出速度大概在5到10 token每秒勉强能用于内部异步任务撑不住实时对话。想优化的话选更小的模型比如3B、1.5B档位确保内存是多通道配置频率别太低关掉其他吃内存的服务适当降低生成时的batch size如果业务对延迟敏感我的建议是别折磨自己加GPU或者直接用现成的API服务。CPU推理作为备用方案没问题作为主力方案会让你怀疑人生。5.4 模型部署成功不等于效果达标输出质量还得调部署完成只是第一步。很多人把模型跑起来后发现输出质量不如网页版就开始怀疑是不是部署错了。其实大概率不是是推理参数没对齐。需要重点关注的几个参数temperature控制随机性任务型对话建议设低一些比如0.3到0.7top_p控制采样范围默认0.9左右想稳定输出可以调低一点system prompt不同模型默认行为差异很大定制一个贴合业务场景的系统提示词有时比换模型更有效举一个实际例子之前用Qwen做客服问答默认输出总爱长篇大论把用户绕晕。后来我在系统提示词里明确要求直接回答不要解释控制在50字以内效果立刻改善。所以部署完不要急着声明过关先拿真实业务问题跑几轮把参数和提示词调到业务能接受为止。最后分享一个我自己的习惯任何新模型上线我都会先在开发机上用小模型把流程走通再迁移到正式服务器。不要一上来就在生产环境折腾环境变量、依赖版本、端口冲突这些问题会让你焦头烂额。部署这种事稳比快重要。等这条链路彻底跑顺了再去研究RAG接入、多模型编排那些进阶玩法也不迟。 
