最近不少朋友问我大模型到底怎么在自己机器上跑起来尤其是那种没有显卡、纯 CPU 的 Linux 服务器能不能也凑个热闹。我把话说在前面能而且比你想象的简单。现在开源社区的部署工具已经成熟到几条命令就能拉起一个 7B 模型的地步真正花时间的反而是环境检查和模型选型。这篇文章就基于我自己的实操经验把 Linux 服务器部署大模型这条路从头到尾捋一遍从硬件评估、环境准备、模型下载到对外提供 API 服务全部给到可直接抄作业的命令和参数。这套东西适合谁想给团队内部搞一个私有化 AI 助手的技术同学学生党想在宿舍工作站上跑通推理流程或者搞应用开发但不想被云厂商 API 费用绑死的朋友。看完你至少能回答三个问题服务器要什么配置、用哪个框架部署最省心、模型怎么选才不爆显存。1. 部署前的硬件与软件评估1.1 服务器到底要什么配置大模型部署最核心的资源就是显存。如果服务器有 NVIDIA 显卡先跑一下nvidia-smi看显存大小。以常见的 7B/8B 参数模型为例FP16 半精度加载大概需要 14~16GB 显存如果用 4-bit 量化直接砍到 4~6GB。也就是说一张 8GB 显存的消费级显卡比如 RTX 3060 Ti也能跑 7B 模型只是上下文长度要控制一下。如果没有 GPU纯 CPU 也不是不能跑但要做好心理准备。7B 量化模型在纯 CPU 上推理速度大概每秒 5~10 个 token看内存带宽和数据格式。同价位下内存通道数越多、频率越高CPU 推理越快。服务器内存建议至少 16GB推荐 32GB 以上因为除了放模型权重还得给系统和其他服务留余量。硬盘方面建议预留模型参数大小 2~3 倍的空间。量化后的 7B 模型只有 4~5GB但原生 FP16 版本要 14GB 左右如果你想多下载几个模型轮着用500GB 的 NVMe 固态是比较稳的起步配置。注意模型文件大部分是顺序读固态硬盘的随机性能反而没那么关键不过现在新服务器基本都标配 NVMe不用太纠结。1.2 Linux 发行版与内核选择部署大模型Ubuntu Server 22.04 LTS 或 24.04 LTS 是最省心的选择社区资料最多驱动兼容性问题最少。CentOS Stream、Rocky Linux 或国产的 openAnolis 也能跑只是遇到问题能查到的资料相对少一些。内核版本建议 5.15 以上太老的内核可能跟新驱动有兼容性问题。需要特别提醒的是如果你的服务器是虚拟机想直通 GPU 给容器用得看虚拟化平台是否支持 PCIe Passthrough。没用过 GPU 直通的朋友第一次部署建议直接用物理机或带 GPU 的裸金属云服务器不然光排查驱动穿透问题就能耗掉一整天。我先前踩过这个坑VMware 里配完驱动后nvidia-smi始终空白最后发现是直通配置里漏了 IOMMU 分组。2. 模型选型与下载策略2.1 从参数规模倒推显存需求选模型之前先根据显存大小画一条线参考这个表模型参数规模FP16 显存需求4-bit 量化显存需求CPU 推理建议内存1~3B2~6GB1~2GB8GB 起步7~8B14~16GB4~6GB16GB 起步13~14B26~28GB8~10GB32GB 起步32B64GB18~20GB64GB 更稳70B140GB40GB128GB 以上这张表是理论值实际还会有 KV Cache 和推理框架的额外开销。比如跑 7B 模型时上下文长度设为 8192KV Cache 可能要额外吃 1~2GB。所以我建议选模型时按下限往上留 20% 余量宁可模型小一号也别刚启动就 OOM。2.2 开源模型怎么下、从哪里下目前主流的开源模型国内下载比较方便的是 ModelScope魔搭海外则是 Hugging Face。如果你是国内服务器优先走 ModelScope速度基本可以跑满带宽。常见的部署目标模型我实测下来不错的有这几个Qwen2.5 系列7B/14B/72B中文能力强指令跟随稳定适合做通用助手和知识库问答DeepSeek-R1 系列蒸馏版 1.5B/7B/8B/14B/32B/70B推理能力强适合数学、代码生成场景Llama 3.1/3.2 系列英文生态好工具调用能力完善但中文表现略逊于 QwenPhi-3 系列3.8B/14B微软出品小模型性能惊人适合资源有限的场景下载模型时需要注意文件格式。如果你用 Ollama不需要手动下载权重文件直接执行ollama pull命令即可它会自动拉取并转成专用格式。如果你打算用 vLLM、Transformers 这类框架就需要从 Hugging Face 或 ModelScope 下载完整的 PyTorch 权重或 GGUF 量化文件。GGUF 是 llama.cpp 生态的量化格式Ollama 内部也是基于 GGUF 的理解这个概念对后面选量化等级有帮助。3. 基于 Ollama 的一步到位部署3.1 安装 Ollama 与模型拉取Ollama 目前是 Linux 本地部署大模型最省事的方式一条命令安装curl -fsSL https://ollama.com/install.sh | sh安装完会自动注册为 systemd 服务状态可以用systemctl status ollama查看。如果你的网络访问官方安装脚本比较慢可以直接从 GitHub Release 页下载二进制包或者用代理加速这都不是问题。拉取模型也简单ollama pull qwen2.5:7b ollama pull deepseek-r1:7b跑起来更简单ollama run qwen2.5:7b3.2 修改模型存储路径与远程访问配置默认情况下模型存储在/root/.ollama/models如果根分区空间不够需要改到数据盘。推荐用 systemd 的 override 配置避免直接改主配置文件在升级时被覆盖sudo systemctl edit ollama写入下面内容[Service] EnvironmentOLLAMA_MODELS/data/ollama/models EnvironmentOLLAMA_HOST0.0.0.0:11434保存后重启 ollama 服务sudo systemctl daemon-reload sudo systemctl restart ollama这里的OLLAMA_HOST0.0.0.0:11434是让 Ollama 监听所有网卡允许局域网内其他机器访问。如果你只想让本机访问就不要加这个环境变量保持默认的127.0.0.1。注意生产环境暴露0.0.0.0一定要有安全防护。至少要在云安全组或防火墙里限制 11434 端口的来源 IP不然别人可以直接往你的模型服务发请求。更稳妥的做法是前面套一层 API 网关做认证后面我会讲到。4. 基于 Docker 的部署与 API 服务4.1 用 Docker 跑 Ollama 服务如果你的服务器上已经跑了很多容器或者不想在宿主机上直接装 Ollama用 Docker 部署是更好的选择。一条命令拉起服务docker run -d \ --name ollama \ --gpusall \ -v /data/ollama:/root/.ollama \ -p 11434:11434 \ --restart always \ ollama/ollama--gpusall是让容器使用所有 GPU如果没有 N 卡环境去掉这个参数即可。-v挂载的目录是模型存储位置跟宿主机共享。这样你可以在宿主机上直接执行ollama run拉模型容器内也会同步看到。在容器里拉模型和运行模型docker exec -it ollama ollama run deepseek-r1:7b4.2 提供标准 OpenAI 兼容接口给业务系统Ollama 自带 OpenAI 兼容接口这是它作为企业内部 AI 服务的最大优势。很多系统对接 OpenAI API 的代码不需要任何改动只要把base_url换成 Ollama 的地址就能切换。比如一个典型的 Python 请求from openai import OpenAI client OpenAI( base_urlhttp://your-server-ip:11434/v1, api_keyollama ) response client.chat.completions.create( modelqwen2.5:7b, messages[ {role: user, content: 用一句话介绍一下 Linux} ] ) print(response.choices[0].message.content)这里api_key随便填一个非空字符串就行Ollama 不会校验。如果你的业务系统已经接入了 GPT 接口切到内部模型只需要改配置业务代码零改动这在实际落地中能省大量工时。如果你想跑多个模型做负载均衡可以在 Ollama 上一层挂 Nginx 反向代理或者直接用 Open WebUI 这种带界面和用户管理的工具。Open WebUI 部署命令docker run -d \ --name open-webui \ -p 3000:8080 \ --add-hosthost.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main启动后浏览器访问http://服务器IP:3000注册一个管理员账号然后在设置里把 Ollama 的地址填上默认是http://host.docker.internal:11434就能像 ChatGPT 一样在网页里对话了。5. 性能调优与实战参数解析5.1 吞吐与并发的核心参数很多朋友把模型跑起来就完事了实际使用中发现并发一高就卡死。问题往往出在 Ollama 的默认参数上。Ollama 支持通过环境变量调整并发和上下文长度在/etc/systemd/system/ollama.service.d/下创建 override 文件或者在容器启动时通过-e参数传入。关键的几个变量OLLAMA_NUM_PARALLEL4 OLLAMA_MAX_LOADED_MODELS2 OLLAMA_CONTEXT_LENGTH8192 OLLAMA_KEEP_ALIVE30mOLLAMA_NUM_PARALLEL表示同时处理的请求数。默认值是 1意味着同一时刻只能处理一个请求其他请求排队等待。对于 7B 模型和 24GB 显存的服务器设成 2~4 是合理的如果设太高显存会不够用频繁换入换出反而更慢。OLLAMA_CONTEXT_LENGTH控制模型上下文的最大长度。设得越大能处理的长文本越多但 KV Cache 占用的显存也线性增长。比如 7B 模型8K 上下文大约多占 2GB 显存16K 就是 4GB。这个值要跟ollama run时的--num-ctx参数配合实际上OLLAMA_CONTEXT_LENGTH是全局默认值。5.2 推理参数调整与安装 vLLM 进阶方案除了环境变量推理时的采样参数也很关键。以下是 Ollama 中常用参数的推荐值参数推荐值说明temperature0.7值越低回复越保守越高越有创造性top_p0.9核采样控制候选词范围num_ctx4096~8192上下文长度repeat_penalty1.0~1.3重复惩罚处理中文长文本时适当调高在调这些参数之前先用默认值跑一次看效果然后一次只调一个变量不要同时调好几个不然到时候不知道是哪个参数起的作用。如果 Ollama 的性能满足不了需求比如要做高并发的线上推理服务可以考虑 vLLM。vLLM 在显存管理和 Continuous Batching 上做得更好吞吐量比 Ollama 高不少但配置也更复杂。vLLM 部署一个 Qwen2.5-7B-Instruct 的命令大致是pip install vllm vllm serve Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9--tensor-parallel-size多卡时设为卡数单卡就是 1。--gpu-memory-utilization表示最多使用多少比例的显存默认 0.9如果你还需要在 GPU 上跑其他任务设小一点比如 0.5。6. 常见故障排查手册与避坑经验6.1 推理超时、显存溢出的判断技巧故障归类是非常重要的能力。我下面把这些年遇到的最高频问题列成速查表方便你对照处理现象可能原因排查方法加载模型时提示找不到文件模型未下载完成执行ollama list查看本地模型状态重新ollama pullCUDA out of memory显存不足换更小量化模型、减小上下文、关闭其他占用显存的服务CPU 推理极慢内存带宽不足或未正确配置检查内存是否插满通道GGUF 量化层级是否过高局域网无法访问 API监听地址未改检查OLLAMA_HOST是否为0.0.0.0开放防火墙端口部署到云端后 API 一直超时安全组/防火墙限制检查云控制台入站规则与云服务器内部 firewalld拉取模型时网络很慢源在海外配置镜像源或从 ModelScope 手动下载后导入6.2 显存不够时的降级方案显存不足是最常见的问题一个非常实用的降级思路是从 7B 降到 3B/4B 量化模型。比如原本用qwen2.5:7b可以改成qwen2.5:3b或者原版改量化版ollama pull qwen2.5:7b-q4_K_Mq4_K_M是 GGUF 量化的一种4-bit 量化带中间级精度是质量和体积的平衡点。比它更小的有q3_K_M更大的有q5_K_M、q8_0。实测下来7B 模型从 FP16 换成 q4_K_M显存占用直接减到三分之一左右推理速度反而更快因为显存带宽瓶颈降低了量化后的权重读取量更小。质量损失在日常对话场景几乎感知不到只有做严格的数学推理或代码生成时能感受到一点点下降。6.3 踩坑总结Ollama 日常运维注意事项维护过程中有几个容易忽略的细节。第一个是版本更新ollama pull旧模型不会主动更新需要先ollama rm删掉旧版本再重新拉。不过删除前记得确认当前没有容器在引用这个模型否则会导致推理中断。第二个是磁盘空间。Ollama 下载大模型时如果磁盘满会留下不完整的临时文件这时候重新拉取会一直报 checksum 不匹配。解决办法是先执行ollama rm清理模型再删除/root/.ollama/models/blobs下的残留文件最后重新 pull。第三个是中文乱码问题。有些模型中文训练数据不够回答会出现繁体或 Unicode 乱码这跟部署环境没关系就是选型问题。换用 Qwen 或 DeepSeek 这类国产中文强模型基本能解决。7. 部署完成后的验收与扩展思路模型跑通之后建议先做一轮功能验收别急着对接业务。我自己习惯用一组固定的测试用例中文理解、代码生成、数学推理、长文本总结每个用例跑两遍看结果稳定不稳定。顺便记一下首 token 延迟和生成速度用ollama ps可以看当前加载的模型和显存占用。关于扩展根据团队实际需求可以走三个方向。第一个是接知识库用 LangChain 或 LlamaIndex 配合向量数据库把内部文档切块、向量化、存起来再通过 RAG 让模型基于文档回答问题。第二个是微调如果想让模型掌握特定的领域术语或风格可以基于开源模型做 LoRA 微调成本远低于全量微调。第三个是接入企业微信、飞书或钉钉机器人等于给整个团队发了一个 7x24 小时的 AI 助手。我个人实际测试下来7B 级别的量化模型已经能覆盖大部分企业内部问答和辅助编码场景没必要一上来就追求 70B 大模型。先把流程跑通再根据响应质量决定要不要升级模型规模这是最务实的路线。部署过程中遇到的具体问题欢迎在评论区交流我看到都会回复。
