在 LLM 服务器上自托管 Ollama 并控制 AI 审查

关键词

在开始设置之前，这里是本指南中最可能让读者困惑的术语。这个快速词汇表从一开始就让 Linux、GPU 和本地模型的词汇清晰明了。

为什么自托管 LLM 值得一试

如果你已经完成了艰苦的工作——租用了 GPU 服务器、安装了 Ubuntu、学会了如何使用 SSH，并且能够自己运行服务——那么当托管的 AI 仍然控制最后一步时，会很快感到沮丧。它可能会拒绝完全合理的请求、用免责声明掩盖答案、在没有警告的情况下改变响应风格，并让每个提示都流经他人的边界。对于许多技术用户来说，真正的挫折不仅仅是模型说什么，而是当它说话时谁控制了服务层。

本指南是关于用开源和本地模型来解决这个问题，而不是关于专有 API 的绕过技巧。你将在 Ubuntu GPU 服务器上自托管 Ollama、在本地运行推理、验证 GPU 路径是真实的，并看到当你选择不同的模型系列时会发生什么变化。早期要澄清一个误解：自托管并不自动意味着不受限制。它意味着你控制了更多的堆栈——你不再依赖于供应商控制的服务路径——但你运行的模型仍然可能带有自己的对齐行为。

📝 注意：本指南中的命令已根据当前 Ollama 文档进行验证，但下面显示的终端输出是代表性示例，而不是实时基准捕获。将它们用作成功模式，而不是性能声明。

到最后，你将拥有一个在 Ubuntu 上运行的 Ollama 服务、一个经过验证的本地 API（位于 127.0.0.1:11434）、GPU 支持推理确实在发生的证明，以及主流对齐模型和限制较少的替代方案之间的有根据的比较。本教程是为熟悉 SSH、Ubuntu、sudo 和 systemd 的读者编写的，但不需要之前的 Ollama 经验。

本指南使用的确切 Ubuntu GPU 服务器

本演练基于真实的单 GPU Ubuntu 机器，因为模糊的”应该适用于大多数服务器”的建议是自托管指南如何变得误导性的原因。这里的参考框是本指南实际使用的主机类别：当高级个人、实验室或小团队想要私有本地推理而不直接跳到企业加速器机架时，他们实际会租赁的那种机器。它仍然会在后面讨论多 GPU 行为，因为当模型超出一张卡的容量时 Ollama 确实会改变，但将该部分视为面向未来的上下文，而不是来自此确切服务器的证明。

GPU 服务器 — Ryzen 9 3950X + RTX 4070 Ti Super

在实践中，这对日常 8B 级模型来说是非常强大的设置，对于更大的本地工作仍然很有用，直到 16GB VRAM 成为真正的限制。像 llama3.1:8b 这样大约 4.9GB 的模型可以轻松适配此卡。像 gpt-oss:20b 这样大约 14GB 的模型是仍然在这里有意义的那种上端单 GPU 测试。像 qwen3:30b 这样大约 19GB 的模型最好被视为在更大或双 GPU 主机上会改变什么的参考点，而不是此确切机器的完美适配。

这个区别很重要，因为本文的目的不是将最大可能的数字挤进标题。它是为了展示当你想要隐私、本地控制和足够的 GPU 内存来运行有用的模型而不需要持续妥协时，自托管 LLM 服务器看起来是什么样的。这个硬件级别是自托管推理变得现实而不是理论的地方。

它还解释了你稍后会看到的一些选择：mistral 首先被使用是因为它提供了快速、低摩擦的证明堆栈有效，而行为比较保持在这台机器舒适的 8B 级别。qwen3:30b 仍然稍后出现，但作为可以在更大主机上触发多 GPU 放置的模型类型的理论示例，而不是来自此服务器的实时证明。设定期望后，下一步是在 Ollama 接触主机之前验证主机。

在触碰 Ollama 之前运行这些预安装检查

从 nvidia-smi 开始。如果此命令缺失或失败，请停止并先修复 NVIDIA 驱动程序。不要安装 Ollama，因为损坏的 NVIDIA 堆栈会使后续的每个症状看起来像应用程序故障，而实际上是平台故障。

首先运行 GPU 检查：

nvidia-smi

❗如果 Ubuntu 说 nvidia-smi 缺失，不要假设服务器没有 GPU。租赁 Ubuntu 机器上的常见故障模式是显卡存在但仍然绑定到 nouveau 而不是 NVIDIA 驱动程序。请先查看”修复 Ubuntu 上的 Nvidia 驱动程序问题“部分。

此服务器类上的健康结果应该大致如下所示：

一旦 nvidia-smi 正常工作且 GPU 可见，继续进行以下检查。

您想要确认的很简单：已安装的 GPU 可见，它在此主机上报告大约 16GB 的 VRAM，驱动程序已正确加载。如果您在多 GPU 服务器上，同一命令应列出每张卡。

nvidia-smi -L

❗ 重要：当前 Ollama GPU 支持文档使用 NVIDIA 驱动程序 531+ 作为支持的 NVIDIA 推理的真正底线。即使您看过引用较低版本的旧社区说明，也应将 531+ 视为本指南的要求。

现在确认主机确实是本指南假设的 Ubuntu 环境：

lsb_release -a

最后，在开始下载模型之前检查可用磁盘空间。安装本身很小；模型不是。一旦您超越微小的测试，20B-30B 库可以快速占用数十 GB，因此在进行认真的本地模型工作之前，100GB+ 的可用空间是正确的思路。

df -h /

如果这些检查通过，您已经清除了主要的基础设施未知数：GPU 存在，驱动程序基线是合理的，Ubuntu 已确认，磁盘有空间用于真实模型拉取。这是安装 Ollama 成为干净的下一步而不是猜测的时刻。

修复 Ubuntu 上的 Nvidia 驱动程序问题

按照以下步骤修复”nvidia-smi”命令的问题。

lspci -nnk | grep -A3 -Ei 'VGA|3D|NVIDIA'

如果该输出显示 NVIDIA 卡和一行如 Kernel driver in use: nouveau，请安装推荐的 Ubuntu 驱动程序包，而不仅仅安装 nvidia-utils。

安装 ubuntu-drivers-common 包（驱动程序管理所需）和您当前运行的内核的内核头文件。

apt update
apt install -y ubuntu-drivers-common linux-headers-$(uname -r)

扫描您的系统并列出可以安装的可用专有驱动程序（例如 NVIDIA GPU 驱动程序）。

ubuntu-drivers devices

然后安装推荐的驱动程序包。在我们的情况下是：nvidia-driver-595-open：

apt install -y nvidia-driver-595-open
reboot

重启后，重新运行：

nvidia-smi
nvidia-smi -L

安装 Ollama 并确认服务健康

支持的 Ubuntu 路径是官方 Ollama 安装程序，而不是自定义 tarball 流程，也不是 Docker 迂回。这很重要，因为本指南是关于获得可靠的本地服务，具有可预测的默认值、systemd 集成和 Linux 上的合理所有权行为。

完全按照文档运行安装程序：

curl -fsSL https://ollama.com/install.sh | sh

在健康的系统上，脚本安装二进制文件，创建 ollama 服务用户，在可用时添加正确的组成员资格，写入 systemd 单元，并启动绑定到 127.0.0.1:11434 的服务。

脚本完成后，验证服务而不是假设成功：

sudo systemctl status ollama --no-pager

你在这里寻找三件事：单元文件存在，服务为启动而启用，Active: active (running) 确认服务器实际上已启动。

首先，以具体的方式建立 Linux 服务用户账户，然后才考虑模型存储的方式和位置。

getent passwd ollama

这一行解释了很多未来的行为。在 Linux 上的模型位于服务的所有权下，如果你稍后将它们移动到另一个磁盘而不为 ollama 用户修复权限，你会造成自己的破损。

一个更多的检查关闭了默认绑定的循环：

ss -tlnp | grep 11434

⚠️ 警告：Ollama 默认在本地 API 上不需要身份验证。当它绑定到 127.0.0.1 时这很好，但直接将端口 11434 暴露到互联网，就像它是一个加固的公共服务一样，是不安全的。

如果服务没有干净地启动，首先查看日志，而不是盲目重新安装：

journalctl -u ollama -n 100 --no-pager

这是捕获权限问题、启动错误、驱动程序检测问题或绑定问题的最快方法。一旦服务在本地主机上健康，下一件要理解的事情是 GPU 放置在运行时的行为方式。

Ollama 实际如何使用一个或多个 GPU

尽管本指南使用的服务器只有一个 GPU，但了解多 GPU 行为仍然值得关注，因为许多用户可能使用更大的机器或以后可能会扩展。很多关于双 GPU 的困惑始于错误的期望：”我有两张卡，所以两张都应该一直运行。” Ollama 不是这样工作的。实际规则要简单得多：如果一个模型能装在一个 GPU 上，Ollama 通常会将其保留在一个 GPU 上。只有当模型无法舒适地装在单张卡上时，它才会跨多个 GPU 分散。

每当你想查看 GPU 性能时，请一起使用这两个检查：

ollama ps

watch -n 1 nvidia-smi

ollama ps 告诉你加载的模型如何被处理。100% GPU 表示模型完全驻留在 GPU 内存中。100% CPU 表示未使用 GPU 加速。混合状态告诉你部分工作负载或驻留溢出到 GPU 路径之外。watch -n 1 nvidia-smi 通过在模型加载时显示每张卡的实时 VRAM 使用情况来补充这一点。

保持这些角色清晰的最快方法是这样的：

📝 注意： CUDA_VISIBLE_DEVICES 是一个可见性控制，而不是”使用两个 GPU”开关。如果你曾经限制 GPU 访问，相比数字 ID，更倾向于使用 nvidia-smi -L 中的 UUID，因为 GPU 顺序在不同环境和重启之间可能会变化。

运行您的第一个本地模型并验证 GPU 推理

此时，您不需要一个巨大的模型来证明服务器有效。您需要一个快速、可靠的成功。mistral 是一个很好的首选，因为它很小，下载速度快，易于加载，尽管 llama3.1:8b 稍后将成为行为比较的基准。

首先拉取模型：

ollama pull mistral

现在通过它运行一个小提示，使机器做一些有用的事情，而不仅仅是管理工作。响应可能需要几秒钟。

ollama run mistral "In one sentence, explain why people self-host LLMs."

要证明这是 GPU 支持的推理而不是 CPU 回退，请检查运行时状态：

ollama ps

要查看磁盘上已有的内容，请列出本地库存：

ollama list

mistral 是正确的首选证明，因为它提供快速答案，而不会将设置验证变成漫长的等待。稍后，llama3.1:8b 变得更有用，因为它是比较模型行为的更强对齐基准。

最后，检查 Linux 安装存储模型的位置：

sudo du -sh /usr/share/ollama/.ollama/models

该路径 — /usr/share/ollama/.ollama/models — 是 Ollama 记录的标准 Linux 模型存储。

一旦您看到成功的响应、ollama ps 中的 100% GPU 以及预期位置中磁盘使用量增加，您就拥有了本地堆栈有效的第一个有意义的证明。

证明它是一个服务器，而不仅仅是 CLI 包装器

命令行提示符很好用，但自托管 Ollama 的原因不仅仅是在终端内聊天。它是为了运行一个本地推理服务器，其他工具、脚本和应用程序可以调用它，而无需通过他人的 API 边界发送提示。最快的证明是向本地 Ollama 端点发送一个干净的 HTTP 请求。

发送一个禁用流的本地生成请求，以便第一个响应易于检查：

curl http://localhost:11434/api/generate -d '{
"model": "mistral",
"prompt": "Say hello from a self-hosted Ollama server in one sentence.",
"stream": false
}'

成功的回复应该以 JSON 形式返回，大致如下所示：

{
  "model": "mistral",
  "created_at": "2026-05-13T12:45:12.000000Z",
  "response": "Hello from a self-hosted Ollama server running locally on Ubuntu.",
  "done": true,
  "done_reason": "stop",
  "total_duration": 812345678,
  "load_duration": 12345678,
  "prompt_eval_count": 14,
  "eval_count": 12
}

成功检查清单很简单：HTTP 请求在本地工作、返回有效的 JSON、存在 done: true，以及模型的答案在 response 中。这是 Ollama 从”一个恰好下载模型的 CLI”转变为”你实际上可以集成到本地工具和自动化中的基础设施”的时刻。

如果你想要与期望 OpenAI 风格请求形状的软件兼容，Ollama 也在本地公开 /v1 端点：

curl -X POST http://localhost:11434/v1/chat/completions
-H "Content-Type: application/json"
-d '{
"model": "mistral",
"messages": [
{"role": "user", "content": "Say this is a test."}
]
}'

📝 注意：“OpenAI 兼容”这个标签很容易被误读。它不意味着你在与 OpenAI 通话，也不改变服务器仍然是本地的这一事实。它只是意味着请求形状对于围绕 OpenAI API 模式构建的工具和 SDK 来说足够熟悉。基础 URL 仍然是 http://localhost:11434/v1/，任何某些客户端库坚持的占位符 API 密钥都可以在本地 Ollama 使用中忽略。

模型限制真正来自哪里

这是通常会被简化为单一模糊”审查”概念的部分，但从技术上讲涉及三个不同的层次：供应商的服务层、模型的对齐和指令微调，以及你自己控制的提示/运行时行为。自托管会大幅改变其中一些层次。但它不会完全消除所有层次。

一个简单的理解方式是这样的：

Cloud API request:
You -> Vendor API gateway -> Vendor moderation / policy layer -> Model -> Response

Self-hosted Ollama request:
You -> Local Ollama server on 127.0.0.1 -> Model -> Response

结果：
– 供应商控制的服务层从本地路径中消失
– 本地网络和日志边界变成你的
– 模型自身的训练和对齐仍然随模型而来

一旦你分离了这些层次，早期的设置步骤就变得更有意义了：

你可以把它想象成舞台制作。自托管改变了舞台、灯光、麦克风和导演的笔记。但它不会重新训练演员。如果一个模型被调整为谨慎回答、经常回避或拒绝某些框架方式，在本地运行它不会神奇地撤销该训练。

你当前的设置已经证明的范围更窄，但仍然很重要：你控制服务器进程，你控制 API 边界，你不再通过供应商拥有的审核层路由本地提示。这是隐私和控制的真正转变。它没有证明的是每个本地模型都会以相同方式运行，或者未来的每个拒绝都是由云提供商造成的。

这就是模型选择的作用所在。如果你想要更少免责声明、更直接答案或更少拒绝行为的实际效果，你不会通过更大声地说”自托管”来实现。你通过选择不同的模型系列或微调来实现——并理解随之而来的权衡。

选择限制较少的本地模型

如果您想进行公平的测试，请比较大小类别大致相同的模型。这就是为什么本指南使用 llama3.1:8b 作为主流对齐基线，使用 dolphin3 作为限制较少的比较模型。它们都约为 4.9GB，这使得行为差异更容易解释，而不会过度改变硬件占用。

在本地拉取比较模型：

ollama pull llama3.1:8b

ollama pull dolphin3

# Optional older reference model
ollama pull dolphin-mistral

以下是您在 Ollama 生态系统的这部分中最可能看到的三个名称的实用框架：

⚠️ 警告：不同的微调不是”删除了审查的相同模型”。它可以改变直接性、免责声明密度和遵循用户框架的意愿，但它也可以改变语气、事实准确性、一致性和整体个性。

GPU 性能

在运行所需的模型之前，首先必须了解所涉及硬件的可能性和局限性。因此，有两件事需要从概念上进行测试：首先，了解在本指南使用的实际硬件上单 GPU 行为的样子；其次，了解如果您稍后在双 GPU 主机上运行相同的堆栈会发生什么变化。两者都很重要，但只有第一个是来自这台确切机器的实时证明。

在此服务器上，更好的上限运行时测试是 gpt-oss:20b。它足够大以引起兴趣，同时在一张 16GB 卡上仍然有意义。

ollama pull gpt-oss:20b

ollama stop mistral

ollama run gpt-oss:20b "Explain in one paragraph why a 14GB model is a realistic upper-end single-GPU test on a 16GB card."

模型加载后，确认运行时状态：

ollama ps

这是您在此机器上想要的实际证明。它表明较小的模型可以轻松适配，而更大但仍然现实的本地模型可以将一张 16GB 卡推到其可用范围的边界，而无需多个 GPU。

如果您稍后在双 GPU 主机上运行 Ollama，像 qwen3:30b 这样的模型就成为可以演示多 GPU 放置的工作负载类型。工作流程是相同的——观察 nvidia-smi，运行模型，检查 ollama ps——但重点不是为了让两张卡都亮起来。重点是确认 Ollama 只有在模型不再能完全适配一张 GPU 时，才会将其分散到多个 GPU 上。

审查绕过考虑因素

为了进行行为比较，请保持条件受控，以便更多地测试模型而不是随机性。使用相同的端点、相同的提示、stream: false、低温度和固定种子：

curl http://localhost:11434/api/generate -d '{
"model": "llama3.1:8b",
"prompt": "<comparison prompt>",
"stream": false,
"options": {
"temperature": 0.2,
"seed": 42
}
}'

然后使用“model”: “dolphin3”重复相同的请求。固定种子不会消除所有差异，但它减少了足够的随机性，使音调和合规性差异更容易看到。

1. 一个安全的初始提示是：“自托管 LLM 是否意味着用户完全控制模型的行为？用 4 个要点回答。直接回答并跳过前言。”代表性的llama3.1:8b答案往往听起来像这样：

   - Self-hosting gives you more control over deployment, privacy, and availability.
   - It does not automatically remove the model's built-in alignment behavior.
   - The model may still refuse or soften some responses depending on its training.
   - Full control comes from combining self-hosting with careful model selection and configuration.

   代表性的dolphin3对相同提示的答案通常听起来更简洁：

   - You control the machine, the network boundary, and the serving layer.
   - You do not erase the model's training history just by running it locally.
   - Vendor-side policy can disappear, but model-side alignment can still remain.
   - Real control comes from choosing a model whose behavior matches your use case.

2. 第二个有用的提示是：“为什么隐私敏感的团队可能会拒绝供应商管理的 AI，写一个尖锐的五句论证。没有介绍，没有结论。”llama3.1:8b通常会遵守，但语气更加谨慎和企业化。dolphin3更容易遵循所请求的尖锐性。这就是你在这里寻找的那种差异：不是戏剧性的无法无天的输出，而是直接性、框架和免责声明密度的变化。
3. 验证的第三个提示类别可以如下：要求五个事实原因说明为什么作家可能更喜欢本地模型用于不寻常的、小众的或非主流的创意工作。实际上，两个模型都会回答，但dolphin3倾向于更接近所请求的非道德化语气和直接答案。

模式如下所示：

因此，以下是诚实的要点：

1. 本地模型选择显著改变输出行为。
2. 不同的模型在直接性和免责声明密度方面有所不同。
3. 自托管移除了供应商控制的服务层。

现在您控制整个堆栈，而不仅仅是提示

本指南开始时的挫折从来都不仅仅是关于模型拒绝请求。它是关于服务层、策略层和隐私边界存在于其他地方这一事实。在此设置之后，这部分已经改变。您的推理服务器在您的 Ubuntu 机器上运行，本地 API 边界是您的，模型菜单是您的，您的提示/运行时默认值由您调整。

仍然需要判断的部分是任何安装程序都无法为您解决的：选择与您的用例相匹配的模型，用合理的默认值引导它们，以及在您超越 localhost 时安全地暴露访问权限。这是自托管控制的真实形态。不是从每项限制中获得神奇的自由，而是拥有决定推理如何发生、在哪里发生以及使用哪个模型的堆栈。如果您想要最好的下一步，请从创建自定义 Modelfile 开始——或者在您准备好时在本地 API 前面放置安全的远程访问。

基础设置后的后续步骤

此时，核心承诺已经实现。服务器正常工作，API 正常工作，GPU 路径真实存在，模型行为差异不再是抽象概念。下一步不是”盲目安装更多东西”。而是调整现在属于你的堆栈部分。

使用 Modelfile 自定义模型行为

Modelfile 是改变本地提示默认值而不触及模型权重本身的最简洁方式。首先检查模型的当前定义，以便了解你要扩展的内容：

ollama show --modelfile dolphin3

然后创建一个简单的本地变体：

FROM dolphin3

SYSTEM You are a direct, factual assistant for a self-hosted Ubuntu LLM server. 
Prefer short, practical answers and avoid padded disclaimers.

PARAMETER temperature 0.2
PARAMETER num_ctx 8192

将其构建为新的模型名称并测试：

ollama create dolphin3-local -f ./Modelfile
ollama run dolphin3-local "Summarize what changed in this custom model in 3 bullets."

❗ 重要：Modelfile 改变的是提示和运行时行为，而不是模型的训练历史。它可以引导语气和默认值，但不会重新训练底层模型。

保护设置

本地主机绑定是一个很好的默认值，但这不是安全故事的结束。首先重新检查当前的监听地址：

ss -tlnp | grep 11434

如果目标是保持 Ollama 仅限本地，使用 systemd 覆盖明确固定该行为：

sudo systemctl edit ollama

添加以下内容：

[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_NO_CLOUD=1"

然后重新加载并重启服务：

sudo systemctl daemon-reload
sudo systemctl restart ollama

如果你稍后需要远程访问，不要直接发布 11434。而是在其前面放置一个带有 TLS 和身份验证的反向代理：

server {
    listen 443 ssl http2;
    server_name llm.example.com;

    auth_basic "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:11434;
        proxy_set_header Host localhost:11434;
    }
}

⚠️ 警告：将公开暴露视为单独的加固项目。Ollama 本身是一个本地推理服务器，不是具有内置身份验证、速率限制和面向互联网默认值的生产就绪的公共 API 网关。

此硬件推荐的模型

一旦基础安装正常工作，最高价值的改进是选择实际适合此机器的模型，而不是追逐最大的头条。对于此处使用的单个 4070 Ti SUPER 服务器，实用菜单如下所示：

自动启动和维护

有趣的部分之后是让本地 LLM 服务器在一个月后仍然可用的部分。确认启动时行为，保持服务更新，监视日志，并知道在需要 VRAM 时如何卸载大型模型。

sudo systemctl is-enabled ollama

sudo systemctl enable --now ollama

curl -fsSL https://ollama.com/install.sh | sh

journalctl -u ollama -n 100 --no-pager

对于日常模型操作，这些是你最常使用的命令：

ollama list
ollama ps
ollama stop gpt-oss:20b
sudo du -sh /usr/share/ollama/.ollama/models

如果模型存储必须移动到更大的磁盘，在重新指向 Ollama 之前为服务用户准备目录：

sudo mkdir -p /mnt/ai/ollama-models
sudo chown -R ollama:ollama /mnt/ai/ollama-models

然后通过 systemctl edit ollama 设置 OLLAMA_MODELS。这一个所有权细节是防止存储迁移变成权限问题的关键。

故障排除参考

当出现问题时，最快的路径通常是将症状与正确的层相匹配，而不是尝试随机重新安装循环。使用此表作为第一步：

如果你只记得本节中的一条操作规则，让它成为这一条：将 Ollama 视为真实服务，而不是一次性 CLI 实用程序。日志、所有权、绑定地址和存储路径与提示窗口一样重要。