这段时间总有朋友来问我手里有一台Linux服务器能不能把大模型跑起来注意这里说的“跑起来”不是玩一下Demo而是真的能在上面搭服务、接应用、给团队用。我自己前后在几台不同配置的服务器上折腾过从最开始的Ollama一行命令到后来配合Dify做问答应用再到多卡环境和参数调优踩过的坑不少。这篇就把大模型在Linux服务器上部署的完整链路拆开讲适合手里有服务器、想本地部署大模型又不想被各种文档淹没的读者可以直接照着做。这篇文章解决的核心问题很明确在一台Linux服务器上把一个开源大模型跑成可调用的服务并且尽量不依赖外部API。适合两类人一是公司或实验室负责基础设施、需要内网部署模型的工程师二是自己买了GPU服务器、想跑通本地大模型的技术爱好者。整个过程会涉及Ollama、Docker、GPU驱动、模型下载、API调用等环节我会把每一步背后的原理和取舍也讲清楚而不只是丢出几条命令。1. 部署方案选型先把思路理清楚1.1 为什么建议从Ollama入手第一次做Linux服务器部署大模型的人十有八九会被vLLM、llama.cpp、Transformers、Text Generation Inference这些名词吓住。我的建议是别一上来就上重型框架先用Ollama把整条链路跑通。Ollama本质上是一个自带模型管理能力的推理服务一条命令就能拉模型再一条命令就能启动一个OpenAI风格兼容的API服务几乎不写代码。对绝大多数内部应用场景来说Ollama的性能已经够用而且后面真要换高并发框架也不会白折腾因为你已经把模型、数据、调用方式都梳理清楚了。有人会说Ollama只适合个人玩生产环境得上vLLM。这话一半对一半错。我自己实测Ollama在单卡或双卡环境下普通问答场景的吞吐完全可以接受而vLLM的强项是极高的并发吞吐和PagedAttention这样的显存优化适合大流量对外服务。如果你只是给团队几十个人做内部工具Ollama的复杂度、维护成本更低出问题的概率也小得多。先把简单方案跑起来再根据压测结果决定要不要换这才是工程上最合理的路径。那什么时候需要直接上其他方案呢如果你明确知道自己要做高并发的开放接口或者要在一个请求里同时跑多个模型做复杂编排那就直接上vLLM加多卡Tensor Parallel。如果服务器根本没有GPU纯CPU环境跑大模型我更推荐llama.cpp。选型的核心逻辑是先确认自己的约束是什么显存大小、并发需求、团队维护能力再决定用哪个框架而不是追求“最火”的部署工具。1.2 硬件配置先算清手里的牌部署大模型的硬件约束核心就一句话模型权重要常驻显存显存不够就是跑不起来。以7B参数模型为例如果以FP16精度加载权重文件大约14GB加上推理时的KV Cache和激活值一块24GB显存的显卡比如RTX 3090、4090可以轻松跑但大概率放不下满载下的超大上下文。如果是70B模型FP16要140GB单卡就完全没戏必须用多卡并行或者选择量化版本把体积压到50GB以内。给你一个我常用的估算表方便选模型时直接用模型参数量常用量化权重大小推荐显存典型卡型1.5B~3BQ4_K_M1~2GB4GB纯CPU也能跑7B~8BQ4_K_M4~6GB8GB3060 12GB7B~8BFP1614GB16GB3090/409014BQ4_K_M9~11GB12~16GB309014BFP1628GB32GBA100 40G32BQ4_K_M18~22GB24GB3090/409070BQ4_K_M40~45GB48GB双卡3090/4090或A6000注意这里的“推荐显存”是保守值实际还要把系统桌面、其他进程、上下文长度占用算进去。上下文越长KV Cache越大128K上下文的KV Cache占用可能超过20GB所以别只看模型权重大小就下结论。如果一台机器上只有内存没有独立显卡也别直接放弃。用Ollama跑GGUF量化的3B、7B小模型在性能还行的CPU上也能有每秒几个token的速度做内部研究、文档摘要够用了。我的经验是没有GPU就别碰14B以上的模型纯CPU跑大模型体验会很痛苦。另外磁盘一定要用SSD模型的加载速度、首次推理延迟都跟磁盘随机读性能强相关机械盘加载一个7B模型可能要等一分钟以上。1.3 部署架构单机还是容器安装Ollama有两种常见方式直接装二进制包或者用Docker跑容器。我刚上手时图省事直接装二进制后来发现不同服务器环境差异大还是Docker更可控。容器方案的好处是环境隔离升级版本、清理模型都方便也不会污染宿主机换机器迁移时一条docker run命令搬走。最简单的生产可用架构是客户端 → Ollama API11434端口 → GPU。如果后面要做知识库、工作流可以在Ollama前面加一层Dify形成用户 → Dify → Ollama → GPU。不需要一开始就引入Nginx和网关等真正有复杂路由需求再补。这里我想强调一下不要在部署第一步就追求完美架构先让数据流跑通再逐步加固这是我自己踩过不少坑后总结出来的经验。2. 环境准备与基础依赖2.1 先检查服务器基础信息不管用什么方式部署第一件事不是急着装软件而是先摸清服务器底子。登录服务器后建议按下面几条命令把信息看一遍# CPU和内存 lscpu | grep -E Model name|Socket|Core|Thread free -h # GPU和驱动 nvidia-smi # 磁盘情况 df -hnvidia-smi最需要重点看。如果执行后提示command not found说明驱动没装或没进PATH如果显示一张类似表格的GPU信息说明驱动已就绪。注意看右上角的CUDA Version这是当前驱动支持的最大CUDA版本容器里的运行时版本低于它就行不需要完全一致。这个细节很多新手会理解错以为一定要装上与模型框架完全一致的CUDA toolkit其实只要驱动够新剩下交给容器镜像就行。2.2 安装Docker与GPU容器支持Docker安装可以走官方脚本也可以走apt。我这里给的是Ubuntu/Debian系系统下的常见做法# 安装依赖 sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release # 添加Docker官方GPG key与仓库Ubuntu示例 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # 把当前用户加入docker组免sudo执行docker sudo usermod -aG docker $USER装完Docker后还要装NVIDIA Container Toolkit否则容器里看不到GPU。命令如下# 配置NVIDIA容器工具包仓库Ubuntu示例 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \ | sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g \ | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker验证容器能不能看到GPU跑一条最简单的命令就可以docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果能看到和宿主机一样的GPU信息说明容器GPU支持已经打通。这里补充一个我在生产和开发中频繁试错后的体会别攒一个很大的自定义镜像官方基础镜像够用。Ollama官方镜像本身就是优化过的能少装一层中间件就少装一层排障的时候会省去大量时间。2.3 安装Ollama二进制方式还是容器方式如果服务器上没有Docker或者你更偏好systemd管理服务可以直接装Ollama二进制版curl -fsSL https://ollama.com/install.sh | sh装完后服务会用systemd托管启动命令是systemctl start ollama。对于容器派我更推荐用下面的方式起一个带数据持久化的Ollama# 创建模型存储目录建议放到空间充足的磁盘 mkdir -p /data/ollama/models export OLLAMA_MODELS/data/ollama/models docker run -d --name ollama \ --gpus all \ -v /data/ollama/models:/root/.ollama \ -p 11434:11434 \ -e OLLAMA_HOST0.0.0.0 \ -e OLLAMA_NUM_PARALLEL2 \ -e OLLAMA_KEEP_ALIVE5m \ ollama/ollama解释一下这里的几个细节。OLLAMA_HOST设置成0.0.0.0是为了让局域网其他机器能访问到API如果只是本机用保持默认127.0.0.1更安全。OLLAMA_MODELS决定模型文件存哪儿我习惯放到单独的数据盘避免系统盘被大模型文件塞满。OLLAMA_NUM_PARALLEL表示每个模型最多并行处理几个请求调太大会吃显存先设2比较稳。OLLAMA_KEEP_ALIVE表示模型在空闲后驻留内存多久5分钟比较折中频繁调用不重复加载长时间空闲又会自动释放显存。3. 模型下载与部署实操3.1 拉取模型官方仓库与离线导入Ollama最大的便利是模型名即命令。比如要跑阿里的Qwen2.5 7B或者DeepSeek-R1的7B量化版直接执行# 查看有哪些模型可用 ollama list # 拉取一个模型 ollama pull qwen2.5:7b # 拉取DeepSeek R1 7B量化版 ollama pull deepseek-r1:7b拉取完成后用ollama run qwen2.5:7b就能进入交互式对话界面。这一步能跑通说明环境没问题后面再谈对外服务。很多内网服务器连不上官方模型仓库或者下载慢。这时候我的做法是先从可访问的渠道把模型文件下载好再在服务器上用Modelfile导入。Ollama支持通过Modelfile引用一个GGUF格式或Safetensors格式的模型文件自己定义一个标签就可以。# Modelfile示例 FROM ./qwen2.5-7b-instruct-q4_k_m.gguf # 设置上下文窗口长度 PARAMETER num_ctx 8192 # 设置温度 PARAMETER temperature 0.7 # 设置提示模板 TEMPLATE {{- if .System }} |im_start|system {{ .System }}|im_end| {{- end }} |im_start|user {{ .Prompt }}|im_end| |im_start|assistant 文件放好后在同一目录下执行ollama create my-model -f Modelfile就会生成一个名为my-model的本地模型。之后ollama list里就能看到。这种离线导入方式在网络受限的部署现场特别管用。另外要注意Modelfile里FROM的路径写相对路径时必须基于当前工作目录不要写成绝对路径也不要在文件里写引号否则会报找不到文件。我自己第一次离线导入时就卡在这个细节上。3.2 模型选择不是参数越大越好模型怎么选是部署时我回答最多的一个问题。很多人的第一反应是“越大越聪明”然后拿着24G显存的显卡硬跑32B甚至70B的模型结果速度慢到没法用。我的建议是先明确业务场景。做代码补全、结构化输出7B到14B的优秀中文模型已经能扛住大部分内部使用场景做长篇文档分析、复杂推理才需要考虑32B以上。这里也给一个我实测下来的参考组合单张24G显卡我首选qwen2.5:14b-instruct-q4_K_M约9G配合8192的上下文窗口既能保持不错的推理质量又能留出足够的KV Cache余量。如果机器是16G显存就退到qwen2.5:7b或者deepseek-r1:7b的Q4量化。如果追求速度和并发3B模型其实大部分内部工具都够用。模型部署跟买车一样只有偶尔满载的场景别按满载需求去配长期跑的硬件。3.3 验证部署成功的三个方法模型拉下来之后不要急着接入业务先做三个基本验证。第一个方法是看模型列表ollama list能看到刚拉取的模型说明模型文件完整。第二个方法是看当前加载状态ollama ps这个命令能显示当前驻留在显存里的模型、大小和上下文长度是判断显存占用最直接的入口。第三个方法是直接调APIcurl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好用一句话介绍你自己}], stream: false }如果curl能返回一段JSON里面有choices和message字段说明模型服务已经完全打通。到这一步你其实已经把一个大模型服务器点亮了。下面要解决的问题是怎么让业务系统稳定地调用它。这里我想再多说一句验证这一步千万别跳过很多人觉得“ollama run能聊就是好了”结果对接API的时候才发现端口不通或者模型标签不对白折腾半天。4. 模型对外服务与API调用4.1 打开OpenAI兼容接口Ollama从0.1.24版本开始支持OpenAI兼容API路径是/v1所以很多现有代码可以无缝切换地址就完成接入。比如原来调用OpenAI接口的Python脚本只需要把base_url改成http://你的服务器IP:11434/v1把api_key改成任意字符串Ollama默认不校验但要求这个字段不能为空就能直接用大模型的本地服务。# 用OpenAI SDK调用本地Ollama from openai import OpenAI client OpenAI( base_urlhttp://192.168.1.100:11434/v1, api_keyollama, # Ollama默认不校验但不能为空 ) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 用一句话解释什么是RAG}], streamFalse, ) print(resp.choices[0].message.content)如果你是纯命令行环境也可以用curl直接测试。要注意的是当OLLAMA_HOST设置为0.0.0.0后服务器防火墙、云安全组都要放行11434端口否则局域网其他机器访问不到。如果是暴露在不完全可信的网络环境我建议至少放一层Nginx做IP白名单或者干脆把Ollama绑在内网专用地址上不要直接暴露公网。Ollama本身默认没有鉴权机制这一点很多刚上手的人会忽略。4.2 配合Dify快速搭建可用的问答应用只想调API测功能上面的步骤已经够用。但要做成一个给别人用的应用比如内部知识库问答、文档总结我推荐在Ollama前面加一个Dify。Dify支持一键docker compose启动图形化界面里配置模型供应商选择Ollama类型填上API地址就能在Web界面里直接对话、调试工作流、配置知识库。Dify的docker compose部署官方有完整文档大体流程是先下载docker-compose.yaml文件然后执行docker compose up -d等容器都起来后访问80端口完成初始化配置。配置Ollama时API地址要填http://ollama:11434如果Dify和Ollama在同一个小网络里或者http://宿主机IP:11434。这里注意Dify容器和Ollama容器不能用localhost互访必须用容器名或宿主机的实际IP。这个坑我见过很多次配置半天连不上其实只是网络没通。Dify接上Ollama之后可以做的事比单纯聊天多得多比如把内部文档上传到知识库通过Embedding模型做向量化再让大模型基于检索结果回答又比如搭建一个多轮对话工作流先让模型判断意图再决定调用哪个子流程。这些能力对很多团队来说已经远超“在本机跑一个聊天机器人”的需求。所以我的建议是如果你最终目标是把模型用起来Dify几乎是必装的配套工具。4.3 并发与会话参数怎么调当Ollama开始真正对外服务后最明显的直接感受就是并发高了以后变慢、卡顿甚至报错。这时候先别急着加机器试着看三个参数OLLAMA_NUM_PARALLEL控制的是同一个模型接受多少个并发请求OLLAMA_MAX_LOADED_MODELS控制同时常驻多少个模型OLLAMA_KEEP_ALIVE控制模型空闲驻留时间。这三个参数要配合显存调整不是越大越好。比如我有一台24G显存的机器常驻一个7B模型OLLAMA_NUM_PARALLEL设4是没问题的因为两个并发请求共用一个模型参数主要增加的是KV Cache显存但如果同时还要常驻一个14B模型OLLAMA_MAX_LOADED_MODELS设2就很容易把显存挤爆。更稳妥的做法是用ollama ps观察显存占用从2到4慢慢上调找到一个吞吐和显存的平衡点。关于上下文长度单次请求里参数num_ctx默认值通常是2048或者按模型内置值如果要做长文档总结要通过API把num_ctx传大一些但代价是显存占用线性增长。5. 性能调优与资源监控5.1 影响吞吐的3个关键参数先放一张我常用的参数速查表后面逐个讲参数作用建议值说明OLLAMA_NUM_PARALLEL单模型并行请求数2~4受显存和KV Cache限制OLLAMA_MAX_LOADED_MODELS常驻模型数量1~2多模型分别占显存OLLAMA_KEEP_ALIVE模型空闲驻留时间5m~30m太长会占显存太短频繁加载num_ctx上下文窗口长度4096~32768越长越占显存num_gpu卸载到GPU的层数-1自动显存不足时强制部分CPU这几个参数里最容易被忽视的是num_ctx。很多人都知道模型权重占显存但不知道上下文长度也占显存。以7B模型为例KV Cache的大小大约等于层数、头数、维度、上下文长度的乘积粗略估算可以理解为每增加1024个上下文额外增加约1GB显存不同模型结构差异较大。如果上下文从2048提到32768显存占用可能多出几十GB。所以如果你的应用场景并不需要太长上下文一定要在API请求里显式控制num_ctx而不是依赖默认值。5.2 监控GPU和模型状态的实用工具部署上线后我最常用的监控命令不是写脚本而是下面几个现成工具# 实时看GPU利用率每2秒刷新 nvidia-smi dmon -s pucvmet -d 2 # 或者用nvtop界面更直观 apt install -y nvtop nvtop # 看Ollama当前加载的模型和上下文占用 ollama ps # 看进程和内存占用 ps aux | grep ollama日常排查时我一般先看ollama ps如果模型不在列表里说明刚才的请求触发了重新加载这会带来好几秒的冷启动延迟。如果请求很频繁、吞吐又上不去就用nvidia-smi dmon看GPU的利用率看看是不是模型太小时GPU一直在 Linux服务器大模型部署实战：从Ollama到Docker与API调用
这段时间总有朋友来问我手里有一台Linux服务器能不能把大模型跑起来注意这里说的“跑起来”不是玩一下Demo而是真的能在上面搭服务、接应用、给团队用。我自己前后在几台不同配置的服务器上折腾过从最开始的Ollama一行命令到后来配合Dify做问答应用再到多卡环境和参数调优踩过的坑不少。这篇就把大模型在Linux服务器上部署的完整链路拆开讲适合手里有服务器、想本地部署大模型又不想被各种文档淹没的读者可以直接照着做。这篇文章解决的核心问题很明确在一台Linux服务器上把一个开源大模型跑成可调用的服务并且尽量不依赖外部API。适合两类人一是公司或实验室负责基础设施、需要内网部署模型的工程师二是自己买了GPU服务器、想跑通本地大模型的技术爱好者。整个过程会涉及Ollama、Docker、GPU驱动、模型下载、API调用等环节我会把每一步背后的原理和取舍也讲清楚而不只是丢出几条命令。1. 部署方案选型先把思路理清楚1.1 为什么建议从Ollama入手第一次做Linux服务器部署大模型的人十有八九会被vLLM、llama.cpp、Transformers、Text Generation Inference这些名词吓住。我的建议是别一上来就上重型框架先用Ollama把整条链路跑通。Ollama本质上是一个自带模型管理能力的推理服务一条命令就能拉模型再一条命令就能启动一个OpenAI风格兼容的API服务几乎不写代码。对绝大多数内部应用场景来说Ollama的性能已经够用而且后面真要换高并发框架也不会白折腾因为你已经把模型、数据、调用方式都梳理清楚了。有人会说Ollama只适合个人玩生产环境得上vLLM。这话一半对一半错。我自己实测Ollama在单卡或双卡环境下普通问答场景的吞吐完全可以接受而vLLM的强项是极高的并发吞吐和PagedAttention这样的显存优化适合大流量对外服务。如果你只是给团队几十个人做内部工具Ollama的复杂度、维护成本更低出问题的概率也小得多。先把简单方案跑起来再根据压测结果决定要不要换这才是工程上最合理的路径。那什么时候需要直接上其他方案呢如果你明确知道自己要做高并发的开放接口或者要在一个请求里同时跑多个模型做复杂编排那就直接上vLLM加多卡Tensor Parallel。如果服务器根本没有GPU纯CPU环境跑大模型我更推荐llama.cpp。选型的核心逻辑是先确认自己的约束是什么显存大小、并发需求、团队维护能力再决定用哪个框架而不是追求“最火”的部署工具。1.2 硬件配置先算清手里的牌部署大模型的硬件约束核心就一句话模型权重要常驻显存显存不够就是跑不起来。以7B参数模型为例如果以FP16精度加载权重文件大约14GB加上推理时的KV Cache和激活值一块24GB显存的显卡比如RTX 3090、4090可以轻松跑但大概率放不下满载下的超大上下文。如果是70B模型FP16要140GB单卡就完全没戏必须用多卡并行或者选择量化版本把体积压到50GB以内。给你一个我常用的估算表方便选模型时直接用模型参数量常用量化权重大小推荐显存典型卡型1.5B~3BQ4_K_M1~2GB4GB纯CPU也能跑7B~8BQ4_K_M4~6GB8GB3060 12GB7B~8BFP1614GB16GB3090/409014BQ4_K_M9~11GB12~16GB309014BFP1628GB32GBA100 40G32BQ4_K_M18~22GB24GB3090/409070BQ4_K_M40~45GB48GB双卡3090/4090或A6000注意这里的“推荐显存”是保守值实际还要把系统桌面、其他进程、上下文长度占用算进去。上下文越长KV Cache越大128K上下文的KV Cache占用可能超过20GB所以别只看模型权重大小就下结论。如果一台机器上只有内存没有独立显卡也别直接放弃。用Ollama跑GGUF量化的3B、7B小模型在性能还行的CPU上也能有每秒几个token的速度做内部研究、文档摘要够用了。我的经验是没有GPU就别碰14B以上的模型纯CPU跑大模型体验会很痛苦。另外磁盘一定要用SSD模型的加载速度、首次推理延迟都跟磁盘随机读性能强相关机械盘加载一个7B模型可能要等一分钟以上。1.3 部署架构单机还是容器安装Ollama有两种常见方式直接装二进制包或者用Docker跑容器。我刚上手时图省事直接装二进制后来发现不同服务器环境差异大还是Docker更可控。容器方案的好处是环境隔离升级版本、清理模型都方便也不会污染宿主机换机器迁移时一条docker run命令搬走。最简单的生产可用架构是客户端 → Ollama API11434端口 → GPU。如果后面要做知识库、工作流可以在Ollama前面加一层Dify形成用户 → Dify → Ollama → GPU。不需要一开始就引入Nginx和网关等真正有复杂路由需求再补。这里我想强调一下不要在部署第一步就追求完美架构先让数据流跑通再逐步加固这是我自己踩过不少坑后总结出来的经验。2. 环境准备与基础依赖2.1 先检查服务器基础信息不管用什么方式部署第一件事不是急着装软件而是先摸清服务器底子。登录服务器后建议按下面几条命令把信息看一遍# CPU和内存 lscpu | grep -E Model name|Socket|Core|Thread free -h # GPU和驱动 nvidia-smi # 磁盘情况 df -hnvidia-smi最需要重点看。如果执行后提示command not found说明驱动没装或没进PATH如果显示一张类似表格的GPU信息说明驱动已就绪。注意看右上角的CUDA Version这是当前驱动支持的最大CUDA版本容器里的运行时版本低于它就行不需要完全一致。这个细节很多新手会理解错以为一定要装上与模型框架完全一致的CUDA toolkit其实只要驱动够新剩下交给容器镜像就行。2.2 安装Docker与GPU容器支持Docker安装可以走官方脚本也可以走apt。我这里给的是Ubuntu/Debian系系统下的常见做法# 安装依赖 sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release # 添加Docker官方GPG key与仓库Ubuntu示例 sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # 把当前用户加入docker组免sudo执行docker sudo usermod -aG docker $USER装完Docker后还要装NVIDIA Container Toolkit否则容器里看不到GPU。命令如下# 配置NVIDIA容器工具包仓库Ubuntu示例 curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey \ | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list \ | sed s#deb https://#deb [signed-by/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g \ | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list sudo apt update sudo apt install -y nvidia-container-toolkit sudo nvidia-ctk runtime configure --runtimedocker sudo systemctl restart docker验证容器能不能看到GPU跑一条最简单的命令就可以docker run --rm --gpus all nvidia/cuda:12.4.0-base-ubuntu22.04 nvidia-smi如果能看到和宿主机一样的GPU信息说明容器GPU支持已经打通。这里补充一个我在生产和开发中频繁试错后的体会别攒一个很大的自定义镜像官方基础镜像够用。Ollama官方镜像本身就是优化过的能少装一层中间件就少装一层排障的时候会省去大量时间。2.3 安装Ollama二进制方式还是容器方式如果服务器上没有Docker或者你更偏好systemd管理服务可以直接装Ollama二进制版curl -fsSL https://ollama.com/install.sh | sh装完后服务会用systemd托管启动命令是systemctl start ollama。对于容器派我更推荐用下面的方式起一个带数据持久化的Ollama# 创建模型存储目录建议放到空间充足的磁盘 mkdir -p /data/ollama/models export OLLAMA_MODELS/data/ollama/models docker run -d --name ollama \ --gpus all \ -v /data/ollama/models:/root/.ollama \ -p 11434:11434 \ -e OLLAMA_HOST0.0.0.0 \ -e OLLAMA_NUM_PARALLEL2 \ -e OLLAMA_KEEP_ALIVE5m \ ollama/ollama解释一下这里的几个细节。OLLAMA_HOST设置成0.0.0.0是为了让局域网其他机器能访问到API如果只是本机用保持默认127.0.0.1更安全。OLLAMA_MODELS决定模型文件存哪儿我习惯放到单独的数据盘避免系统盘被大模型文件塞满。OLLAMA_NUM_PARALLEL表示每个模型最多并行处理几个请求调太大会吃显存先设2比较稳。OLLAMA_KEEP_ALIVE表示模型在空闲后驻留内存多久5分钟比较折中频繁调用不重复加载长时间空闲又会自动释放显存。3. 模型下载与部署实操3.1 拉取模型官方仓库与离线导入Ollama最大的便利是模型名即命令。比如要跑阿里的Qwen2.5 7B或者DeepSeek-R1的7B量化版直接执行# 查看有哪些模型可用 ollama list # 拉取一个模型 ollama pull qwen2.5:7b # 拉取DeepSeek R1 7B量化版 ollama pull deepseek-r1:7b拉取完成后用ollama run qwen2.5:7b就能进入交互式对话界面。这一步能跑通说明环境没问题后面再谈对外服务。很多内网服务器连不上官方模型仓库或者下载慢。这时候我的做法是先从可访问的渠道把模型文件下载好再在服务器上用Modelfile导入。Ollama支持通过Modelfile引用一个GGUF格式或Safetensors格式的模型文件自己定义一个标签就可以。# Modelfile示例 FROM ./qwen2.5-7b-instruct-q4_k_m.gguf # 设置上下文窗口长度 PARAMETER num_ctx 8192 # 设置温度 PARAMETER temperature 0.7 # 设置提示模板 TEMPLATE {{- if .System }} |im_start|system {{ .System }}|im_end| {{- end }} |im_start|user {{ .Prompt }}|im_end| |im_start|assistant 文件放好后在同一目录下执行ollama create my-model -f Modelfile就会生成一个名为my-model的本地模型。之后ollama list里就能看到。这种离线导入方式在网络受限的部署现场特别管用。另外要注意Modelfile里FROM的路径写相对路径时必须基于当前工作目录不要写成绝对路径也不要在文件里写引号否则会报找不到文件。我自己第一次离线导入时就卡在这个细节上。3.2 模型选择不是参数越大越好模型怎么选是部署时我回答最多的一个问题。很多人的第一反应是“越大越聪明”然后拿着24G显存的显卡硬跑32B甚至70B的模型结果速度慢到没法用。我的建议是先明确业务场景。做代码补全、结构化输出7B到14B的优秀中文模型已经能扛住大部分内部使用场景做长篇文档分析、复杂推理才需要考虑32B以上。这里也给一个我实测下来的参考组合单张24G显卡我首选qwen2.5:14b-instruct-q4_K_M约9G配合8192的上下文窗口既能保持不错的推理质量又能留出足够的KV Cache余量。如果机器是16G显存就退到qwen2.5:7b或者deepseek-r1:7b的Q4量化。如果追求速度和并发3B模型其实大部分内部工具都够用。模型部署跟买车一样只有偶尔满载的场景别按满载需求去配长期跑的硬件。3.3 验证部署成功的三个方法模型拉下来之后不要急着接入业务先做三个基本验证。第一个方法是看模型列表ollama list能看到刚拉取的模型说明模型文件完整。第二个方法是看当前加载状态ollama ps这个命令能显示当前驻留在显存里的模型、大小和上下文长度是判断显存占用最直接的入口。第三个方法是直接调APIcurl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d { model: qwen2.5:7b, messages: [{role: user, content: 你好用一句话介绍你自己}], stream: false }如果curl能返回一段JSON里面有choices和message字段说明模型服务已经完全打通。到这一步你其实已经把一个大模型服务器点亮了。下面要解决的问题是怎么让业务系统稳定地调用它。这里我想再多说一句验证这一步千万别跳过很多人觉得“ollama run能聊就是好了”结果对接API的时候才发现端口不通或者模型标签不对白折腾半天。4. 模型对外服务与API调用4.1 打开OpenAI兼容接口Ollama从0.1.24版本开始支持OpenAI兼容API路径是/v1所以很多现有代码可以无缝切换地址就完成接入。比如原来调用OpenAI接口的Python脚本只需要把base_url改成http://你的服务器IP:11434/v1把api_key改成任意字符串Ollama默认不校验但要求这个字段不能为空就能直接用大模型的本地服务。# 用OpenAI SDK调用本地Ollama from openai import OpenAI client OpenAI( base_urlhttp://192.168.1.100:11434/v1, api_keyollama, # Ollama默认不校验但不能为空 ) resp client.chat.completions.create( modelqwen2.5:7b, messages[{role: user, content: 用一句话解释什么是RAG}], streamFalse, ) print(resp.choices[0].message.content)如果你是纯命令行环境也可以用curl直接测试。要注意的是当OLLAMA_HOST设置为0.0.0.0后服务器防火墙、云安全组都要放行11434端口否则局域网其他机器访问不到。如果是暴露在不完全可信的网络环境我建议至少放一层Nginx做IP白名单或者干脆把Ollama绑在内网专用地址上不要直接暴露公网。Ollama本身默认没有鉴权机制这一点很多刚上手的人会忽略。4.2 配合Dify快速搭建可用的问答应用只想调API测功能上面的步骤已经够用。但要做成一个给别人用的应用比如内部知识库问答、文档总结我推荐在Ollama前面加一个Dify。Dify支持一键docker compose启动图形化界面里配置模型供应商选择Ollama类型填上API地址就能在Web界面里直接对话、调试工作流、配置知识库。Dify的docker compose部署官方有完整文档大体流程是先下载docker-compose.yaml文件然后执行docker compose up -d等容器都起来后访问80端口完成初始化配置。配置Ollama时API地址要填http://ollama:11434如果Dify和Ollama在同一个小网络里或者http://宿主机IP:11434。这里注意Dify容器和Ollama容器不能用localhost互访必须用容器名或宿主机的实际IP。这个坑我见过很多次配置半天连不上其实只是网络没通。Dify接上Ollama之后可以做的事比单纯聊天多得多比如把内部文档上传到知识库通过Embedding模型做向量化再让大模型基于检索结果回答又比如搭建一个多轮对话工作流先让模型判断意图再决定调用哪个子流程。这些能力对很多团队来说已经远超“在本机跑一个聊天机器人”的需求。所以我的建议是如果你最终目标是把模型用起来Dify几乎是必装的配套工具。4.3 并发与会话参数怎么调当Ollama开始真正对外服务后最明显的直接感受就是并发高了以后变慢、卡顿甚至报错。这时候先别急着加机器试着看三个参数OLLAMA_NUM_PARALLEL控制的是同一个模型接受多少个并发请求OLLAMA_MAX_LOADED_MODELS控制同时常驻多少个模型OLLAMA_KEEP_ALIVE控制模型空闲驻留时间。这三个参数要配合显存调整不是越大越好。比如我有一台24G显存的机器常驻一个7B模型OLLAMA_NUM_PARALLEL设4是没问题的因为两个并发请求共用一个模型参数主要增加的是KV Cache显存但如果同时还要常驻一个14B模型OLLAMA_MAX_LOADED_MODELS设2就很容易把显存挤爆。更稳妥的做法是用ollama ps观察显存占用从2到4慢慢上调找到一个吞吐和显存的平衡点。关于上下文长度单次请求里参数num_ctx默认值通常是2048或者按模型内置值如果要做长文档总结要通过API把num_ctx传大一些但代价是显存占用线性增长。5. 性能调优与资源监控5.1 影响吞吐的3个关键参数先放一张我常用的参数速查表后面逐个讲参数作用建议值说明OLLAMA_NUM_PARALLEL单模型并行请求数2~4受显存和KV Cache限制OLLAMA_MAX_LOADED_MODELS常驻模型数量1~2多模型分别占显存OLLAMA_KEEP_ALIVE模型空闲驻留时间5m~30m太长会占显存太短频繁加载num_ctx上下文窗口长度4096~32768越长越占显存num_gpu卸载到GPU的层数-1自动显存不足时强制部分CPU这几个参数里最容易被忽视的是num_ctx。很多人都知道模型权重占显存但不知道上下文长度也占显存。以7B模型为例KV Cache的大小大约等于层数、头数、维度、上下文长度的乘积粗略估算可以理解为每增加1024个上下文额外增加约1GB显存不同模型结构差异较大。如果上下文从2048提到32768显存占用可能多出几十GB。所以如果你的应用场景并不需要太长上下文一定要在API请求里显式控制num_ctx而不是依赖默认值。5.2 监控GPU和模型状态的实用工具部署上线后我最常用的监控命令不是写脚本而是下面几个现成工具# 实时看GPU利用率每2秒刷新 nvidia-smi dmon -s pucvmet -d 2 # 或者用nvtop界面更直观 apt install -y nvtop nvtop # 看Ollama当前加载的模型和上下文占用 ollama ps # 看进程和内存占用 ps aux | grep ollama日常排查时我一般先看ollama ps如果模型不在列表里说明刚才的请求触发了重新加载这会带来好几秒的冷启动延迟。如果请求很频繁、吞吐又上不去就用nvidia-smi dmon看GPU的利用率看看是不是模型太小时GPU一直在