企业官网建设流程全解析

服务器上跑本地模型这件事，我是真被坑过才决定写这篇的。前阵子接到一台CentOS7系统，要求部署Ollama跑本地大模型，一开始以为就是个curl -sSfL https://ollama.com/install.sh | sh的事，结果连脚本都拉不下来，拉下来之后安装脚本又一堆兼容性报错，折腾到怀疑人生。后来把路趟顺了，发现CentOS7这个老系统上装Ollama，其实核心就三件事：搞定安装包来源、配好环境变量、写好服务管理。这篇就把我从零到一的过程完整拆开，包括国内网络环境下的下载加速办法、自定义端口和模型存储路径的配置方式、GPU和CPU场景的取舍，以及几个我实测遇到的坑和排查思路，给同样要在CentOS7上本地部署大模型的朋友一个可直接抄的作业。

1. 环境准备：CentOS7跑Ollama的硬性前提

1.1 为什么还有人在CentOS7上折腾Ollama

可能有人会问，CentOS7都EOL那么久了，为什么还要在这上面部署？我接触到的实际情况是：很多公司的存量服务器就是CentOS7，上面跑着业务系统，采购新机器要流程要预算，想先用闲置节点试水本地大模型，这是最现实的需求。另外CentOS7和RHEL7完全同源，很多企业内网镜像就是按RHEL7标准维护的，短期内不可能全部替换。

所以这篇不是劝你新装CentOS7，而是给那些手里只有CentOS7机器的朋友一条可行的路。Ollama官方其实没有声明支持CentOS7，最低要求写的是glibc 2.17以上，CentOS7的glibc版本是2.17，理论上是踩线达标。但问题就出在这个"踩线达标"上，后面我会详细说。

1.2 硬件要求与系统检查清单

在动手前，先把机器的底细摸清楚。Ollama跑起来之后的资源占用比想象中要高，尤其是内存，模型加载是整块整块吃内存的。

可以用下面这组命令快速摸底：

# 查看CPU信息 lscpu # 查看内存大小 free -h # 查看磁盘空间（模型文件体积不小） df -h # 查看显卡是否被系统识别 lspci | grep -i nvidia lspci | grep -i amd # 查看系统版本 cat /etc/redhat-release

我个人的建议配置如下，分三档参考：

磁盘这块要重点留意，Ollama的模型默认存储路径是/usr/share/ollama/.ollama/models，在root用户下则是/root/.ollama/models。7B模型一般是4~8GB，14B模型在8~16GB左右，多下几个模型磁盘就吃紧了。部署前一定要用df -h确认目标分区有足够空间，优先选容量大的分区做模型存储。

1.3 提前处理glibc和依赖问题

CentOS7上装Ollama最大的坑就是glibc。虽然理论上2.17能跑，但Ollama的二进制文件是用较新的Go版本交叉编译的，新版本可能会引用更高版本的glibc符号。如果你直接运行，会看到类似这样的报错：

./ollama: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./ollama)

这说明当前glibc版本不够。CentOS7默认的glibc是2.17，如果遇到这个报错，有几个选择：

1. 换用较早版本的Ollama，比如0.1.x或0.2.x版本，这些版本对glibc要求更低
2. 用strings /lib64/libc.so.6 | grep GLIBC查看系统最高支持的glibc版本
3. 升级glibc（有风险，生产环境强烈不建议）

我建议先安装最新版试试，如果报glibc错误再退回老版本。目前Ollama 0.3.x版本在glibc 2.17环境下实测是可以跑的，0.5.x版本在部分机器上会报错。也就是说，"最新版"不一定适合CentOS7，锁定版本才是关键。

2. 下载加速：安装包和模型的正确获取姿势

2.1 官方脚本卡住的原因与解决思路

官方安装脚本的做法是下载一个二进制包然后解压到/usr/local/bin，再创建systemd服务和ollama用户。整个过程在海外服务器上很流畅，但在国内网络环境下，最慢的环节往往是访问GitHub Releases下载二进制包，速度忽快忽慢，经常超时中断。

我一开始用官方脚本装到一半就断了，curl走了差不多一分钟没动静，Ctrl+C之后再试还是一样。后来发现官方脚本里有一段curl -fsSL -o ollama-linux-amd64.tgz的操作，这个东西的下载源就是GitHub Releases，网速不好时基本走不动。

解决思路很简单：不用官方脚本，直接从国内能稳定访问的镜像站下载二进制包，手动完成安装。这样既能控制下载速度，又能避开脚本执行过程中的各种网络坑。

2.2 使用国内镜像源加速安装

我实测最稳定的方式是使用国内的GitHub加速代理来下载Ollama的Linux压缩包。以ollama-linux-amd64.tgz为例，可以这样操作：

# 下载Ollama压缩包，将URL替换为可用的加速地址 curl -L -o ollama-linux-amd64.tgz "https://gh-proxy.com/https://github.com/ollama/ollama/releases/download/v0.3.13/ollama-linux-amd64.tgz" # 解压到临时目录 mkdir -p ollama-temp tar -xzf ollama-linux-amd64.tgz -C ollama-temp # 将ollama可执行文件放入/usr/local/bin cp ollama-temp/bin/ollama /usr/local/bin/ollama chmod +x /usr/local/bin/ollama # 验证安装结果 ollama --version

如果你的网络环境连加速代理也访问不了，还有一个办法：找一台网络好的机器下载好压缩包，然后通过scp、U盘或者公司内部文件服务器传到目标机器上。离线部署在服务器场景下其实是最稳妥的，不依赖目标机器的外网环境。

提示：安装之后可以顺便确认一下ollama命令是否在PATH中。如果运行ollama提示找不到命令，检查/usr/local/bin是否在PATH里，或者直接把二进制放到/usr/bin下面。

2.3 模型下载慢的应对方案

安装包搞定之后，更大的坑在模型下载。ollama pull默认从registry.ollama.ai拉模型，国内访问这个源同样慢，一个几GB的模型经常下到一半就断。

这里分享两个我自己用过的方案：

方案一：从Hugging Face镜像站下载GGUF文件再本地导入

Ollama支持从GGUF格式的模型文件导入到本地模型库。如果pull太慢，可以先去Hugging Face官方镜像站找到需要的模型文件（比如Qwen2.5、Llama3等都有GGUF版本），下载后用Modelfile导入：

# 在镜像站下载好qwen2.5-7b-instruct-q4_k_m.gguf之后，创建Modelfile cat > Modelfile << 'EOF' FROM ./qwen2.5-7b-instruct-q4_k_m.gguf EOF # 导入到ollama，名字自己定义 ollama create qwen2.5-7b -f Modelfile # 验证 ollama list

这种方法对带宽有限的环境特别友好，因为Hugging Face镜像站有CDN加速，下载速度比Ollama官方源快得多。而且GGUF文件下载可以断点续传，用wget -c反复重试也能推进。

方案二：手动把模型文件放进模型目录

如果你手头已经有其他方式获取到的模型目录（比如从另一台机器上拷贝的.ollama/models目录），可以直接把它放到Ollama的模型路径下，重启服务后ollama list就能识别。这个做法适合内网多台机器共享模型文件的场景，省去每台机器都下载一遍的重复劳动。

3. 自定义端口与存储路径：三个环境变量搞定一切

3.1 为什么要改端口和存储路径

默认情况下，Ollama的API服务监听127.0.0.1:11434，模型存储在/usr/share/ollama/.ollama/models。但实际使用中这两个默认值经常不够用：

• 端口要改：如果11434已经被其他服务占了，或者你需要让局域网内其他机器访问这个Ollama服务，就必须改监听地址和端口。默认只监听127.0.0.1意味着其他机器根本访问不到。
• 路径要改：默认模型盘可能在根分区，而根分区往往空间不大。如果数据盘挂在/data下，就需要把模型存储改过去。

Ollama的设计比较人性化，所有关键配置都通过环境变量控制，不需要改配置文件。

3.2 环境变量详解

我实际使用中涉及的三个核心环境变量如下：

OLLAMA_HOST设置为0.0.0.0:8080表示监听所有网卡接口的8080端口。这样局域网内的其他机器可以通过http://服务器IP:8080访问API。如果只有本机需要访问，保持127.0.0.1就是更安全的。

OLLAMA_MODELS是模型存储路径，这个必须提前想好。我踩过的坑是：装好之后下了两个模型，根分区满了，才想起来要改路径。结果要把几十GB的模型文件搬到新路径，既浪费时间又折腾。建议第一步就把路径定好。

OLLAMA_KEEP_ALIVE控制模型在显存/内存中的保留时间。默认5分钟，如果使用频率高，设成30分钟能减少重复加载模型的等待时间。如果内存紧张，可以设短一点，比如2m。

3.3 写一个干净的systemd服务文件

用官方脚本安装会自动创建systemd服务，但手动安装就需要自己写。这里给出一份我实测可用的服务文件：

[Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="PATH=/usr/local/bin:/usr/bin:/bin" Environment="OLLAMA_HOST=0.0.0.0:8080" Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_KEEP_ALIVE=30m" Environment="HOME=/home/ollama" [Install] WantedBy=multi-user.target

有几个细节值得注意：

• User和Group设为ollama，不要用root运行服务，这是基本的安全意识
• Environment="HOME=/home/ollama"很重要，Ollama运行时会读取HOME环境变量来确定用户配置目录
• Restart=always让服务在异常退出后自动拉起

同时需要创建对应的用户和目录：

# 创建服务用户 useradd -r -s /bin/false -d /home/ollama ollama # 创建模型存储目录（根据你设置的OLLAMA_MODELS调整） mkdir -p /data/ollama/models # 修改目录归属 chown -R ollama:ollama /data/ollama # 将服务文件放到系统目录并启动 cp ollama.service /etc/systemd/system/ollama.service systemctl daemon-reload systemctl enable --now ollama # 检查服务状态 systemctl status ollama

这里再补充一个常见误区：如果你直接用root用户执行ollama serve跑起来过，再去启动systemd服务，会出现两个进程抢同一个端口的情况。解决方法是先把root下的ollama进程停掉，再启动服务：

pkill -f "ollama serve" systemctl start ollama

4. GPU与CPU场景：让Ollama跑得更快的取舍

4.1 显卡驱动与CUDA检查

如果你有NVIDIA显卡，先确认驱动和CUDA是否就绪：

# 查看显卡驱动 nvidia-smi # 查看CUDA版本 nvcc --version

Ollama在NVIDIA GPU上是自动检测的，只要nvidia-smi能正常输出，它就会优先用GPU推理，不需要额外配置。驱动版本建议450以上，CUDA 11.0以上，老驱动可能会出现"incompatible driver"的报错。

如果机器上有GPU但Ollama没用上，运行ollama run qwen2.5时观察输出，有GPU信息说明调用成功。如果显示只有CPU，检查一下nvidia-smi是否正常，以及安装Ollama时是否在正确的环境下。

AMD显卡在CentOS7上可能稍微麻烦，因为AMD的ROCm驱动对RHEL7的支持版本有限。我在这块没有太深入，如果踩过的朋友可以在评论区补充。

4.2 纯CPU模式下的线程调整

很多服务器其实没有GPU，纯CPU跑小模型也不是不行，但速度确实感人。7B模型在纯CPU下每秒大概只能生成2~5个token，而GPU可以到30~80个token，体感差距很大。

CPU模式下有一个优化技巧：通过OLLAMA_NUM_THREADS环境变量控制线程数。不设置时Ollama会根据CPU核心数自动决定，但有时自动检测并不理想。比如一台16核的机器，跑7B量化模型时，线程数设成8或12可能比默认值更快。

# 在service文件里增加 Environment="OLLAMA_NUM_THREADS=8"

注意，这个值不是越大越好。线程太多会导致CPU上下文切换开销变大，实测在8~12之间往往是最优区间。具体可以逐个试一下，对比ollama run的响应速度。

另外纯CPU模式对内存带宽很敏感，内存频率高的机器比频率低的快不少，这个属于硬件层面的限制，软件上没法改变。

4.3 量化版本的选择

模型量化（Quantization）对资源占用影响很大。Ollama官方模型库默认提供多个量化级别，常见的有：

• q4_0、q4_k_m：4-bit量化，体积小，速度较快，精度损失可接受
• q5_k_m：5-bit量化，体积和精度比较均衡
• q8_0：8-bit量化，体积大但精度接近原始模型

对于CentOS7上常见的16GB内存机器，7B模型建议用q4_k_m，14B模型用q4_0，这样内存能撑住。如果你内存只有8GB，建议考虑3B~4B规模的小模型，或者用更激进的q2_k量化。

这里给一个我实测的组合示例：

# 拉取7B模型q4量化版本 ollama pull qwen2.5:7b-q4_k_m # 如果磁盘空间有限，可以查看模型大小 ollama list

选择合适量化版本的好处是双重的：既减少磁盘占用，也降低加载后占据的内存/显存，推理速度也会有改善。

5. 踩坑实录：从安装到启动的典型问题

5.1 防火墙导致局域网访问不通

Ollama服务起来了，curl http://localhost:8080在本机通，但从另一台机器访问就是超时。这种问题十有八九是防火墙。

CentOS7默认使用firewalld，放行端口的命令如下：

# 永久放行8080端口 firewall-cmd --permanent --add-port=8080/tcp firewall-cmd --reload # 验证端口是否放行 firewall-cmd --list-ports

如果还是有云安全组的概念，记得也去云控制台把安全组规则配好，这个和本机防火墙是两套体系，很容易漏掉。

5.2 curl拉取安装脚本失败或超时

这个前面提过。官方脚本频繁超时的根因就是访问不到GitHub Releases。解决方案就是在能访问的机器上直接把安装包下载好，然后传入内网。如果一定要直接用脚本，可以先手动把脚本下载下来，然后修改脚本内的下载地址指向国内镜像，再执行本地脚本。我个人更推荐纯手动安装，因为脚本里面还涉及创建用户、写systemd服务等操作，手动的每一步都看得见，出了问题容易排查。

5.3 模型加载时OOM（内存不足）

内存不足是CPU部署最常见的故障。现象就是ollama run之后，模型加载到一半进程直接被杀，dmesg里能看到Out of memory相关的记录。

排查思路：

# 查看OOM记录 dmesg | grep -i "killed process" # 查看当前内存 free -h

应对方案有几个：

1. 换更小的模型或更低的量化等级
2. 加swap，虽然推理会变慢，但至少不会进程崩溃
3. 调整OLLAMA_KEEP_ALIVE，让模型闲置后更快释放内存
4. 降低OLLAMA_NUM_THREADS，减少运行时内存占用

加swap的快捷方式：

# 创建4GB swap文件 dd if=/dev/zero of=/swapfile bs=1M count=4096 chmod 600 /swapfile mkswap /swapfile swapon /swapfile # 写入fstab使其永久生效 echo "/swapfile swap swap defaults 0 0" >> /etc/fstab

这个方法对OOM有立竿见影的效果，但推理速度会下降。swap本质是用磁盘换内存，在SSD上表现还能接受，在机械硬盘上就比较痛苦了。

5.4 升级和卸载的正确姿势

Ollama更新比较频繁，CentOS7上升级时建议先停服务再替换二进制：

systemctl stop ollama # 备份旧版本 mv /usr/local/bin/ollama /usr/local/bin/ollama.bak # 下载并替换新版本 curl -L -o ollama-linux-amd64.tgz "https://gh-proxy.com/https://github.com/ollama/ollama/releases/download/v0.3.13/ollama-linux-amd64.tgz" tar -xzf ollama-linux-amd64.tgz -C /tmp cp /tmp/bin/ollama /usr/local/bin/ollama chmod +x /usr/local/bin/ollama # 重启服务 systemctl start ollama # 验证版本 ollama --version

版本选择上，我建议跟踪官方Release，但不要盲目追新。大版本跳跃时先在测试机过一遍，确认glibc兼容性再上生产。像0.3.x到0.4.x、0.5.x这几次大版本升级，CentOS7上都出现过不兼容反馈。

卸载相对简单：

systemctl stop ollama systemctl disable ollama rm -f /etc/systemd/system/ollama.service rm -f /usr/local/bin/ollama # 删除模型目录（确认已备份） rm -rf /data/ollama # 删除用户 userdel ollama systemctl daemon-reload

6. 验证与日常运维：让Ollama真正可用起来

6.1 API验证与远程访问

装好之后一定要验证API是否正确响应。下面这条命令测试的是Ollama的根路径：

curl http://localhost:8080

正常情况下会返回一个JSON字符串。进一步测试模型对话接口：

curl http://localhost:8080/api/generate -d '{ "model": "qwen2.5:7b-q4_k_m", "prompt": "你好，请简单介绍一下你自己" }'

局域网访问时，把localhost换成服务器实际的IP地址。如果通了，说明端口和防火墙配置都正常。

6.2 模型管理与日常使用技巧

日常使用中，有几个命令我几乎每天都会用到：

# 查看本地模型列表 ollama list # 查看正在运行的模型 ollama ps # 删除不用的模型 ollama rm qwen2.5:7b-q4_k_m

ollama ps特别有用，可以直观地看到当前模型占用了多少显存或内存。如果发现内存占用异常高，可以用OLLAMA_KEEP_ALIVE调整模型释放策略。

在多台服务器之间同步模型，直接拷贝OLLAMA_MODELS目录是最省事的方式。前提是每台机器的Ollama版本尽量一致，避免模型格式不兼容的问题。

6.3 日志排查与健康监控

服务出问题的时候，日志是第一条线索：

# 查看Ollama服务日志 journalctl -u ollama -f # 只看最近50条 journalctl -u ollama -n 50

日志里常见的几类信息：

• 模型加载失败：一般会提示是磁盘空间不足还是文件损坏
• GPU调用失败：会提示CUDA相关错误
• 端口冲突：会明确提示address already in use

建议写一个简单的健康检查脚本，配合crontab定时探测API是否存活：

#!/bin/bash if curl -s http://localhost:8080 > /dev/null 2>&1; then echo "$(date): ollama is alive" else echo "$(date): ollama is down, restarting..." systemctl restart ollama fi

配合crontab每个5分钟跑一次，能有效避免服务挂掉后无人处理的尴尬。

最后再分享一个实用技巧：CentOS7的yum源维护问题。因为系统比较老，yum install某些依赖时可能会失败，但只要不涉及Ollama的核心依赖，一般不需要折腾。我在部署时遇到过/lib64/libstdc++.so.6: version CXXABI_1.3.11 not found的报错，这是gcc版本过旧导致的，安装devtoolset-7可以解决：

yum install -y centos-release-scl yum install -y devtoolset-7 scl enable devtoolset-7 bash

不过这属于少数情况，大部分CentOS7机器都自带符合要求的运行库，遇到再用这个办法不迟。希望这篇能把你在CentOS7上部署Ollama的路铺得平一些，少走几个我走过的弯路。