在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 检查：

❗如果 Ubuntu 提示找不到 nvidia-smi，请不要就此认为服务器没有 GPU。在租用的 Ubuntu 机器上，一种常见的故障模式是显卡存在，但仍绑定到 nouveau 而非 NVIDIA 驱动程序。请先查阅”修复 Ubuntu 上的 Nvidia 驱动程序问题“章节。

在这类服务器上，正常的输出结果大致如下所示：

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

您需要确认的内容很简单：已安装的 GPU 可见，在此主机上报告的 VRAM 大约为 16GB，且驱动程序已干净加载。如果您使用的是多 GPU 服务器，同一命令应列出每张显卡。

❗ 重要：当前 Ollama GPU 支持文档将 NVIDIA driver 531+ 作为支持 NVIDIA 推理的实际最低要求。即使您看到过引用更低版本的旧社区说明，本指南也请以 531+ 作为要求。

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

最后，在开始下载模型之前检查可用磁盘空间。安装程序本身体积很小，但模型文件却不然。一旦超出小型测试的范围，一个 20B-30B 的模型库可能会迅速占用数十 GB 的空间，因此在进行认真的本地模型工作之前，保持 100GB+ 的可用空间是正确的思路。

如果这些检查均通过，您已经排除了主要的基础设施未知因素：GPU 存在，驱动程序基线正常，Ubuntu 已确认，磁盘有足够空间用于真实的模型拉取。到了这一步，安装 Ollama 才是清晰的下一步，而不再是一种猜测。

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

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

如果该输出显示了一张 NVIDIA 显卡以及类似 Kernel driver in use: nouveau 的行，请安装推荐的 Ubuntu 驱动程序包，而非单独安装 nvidia-utils。

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

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

然后安装推荐的驱动程序包。在我们的案例中，它是：nvidia-driver-595-open：

重启后，重新运行：

安装 Ollama 并确认服务运行正常

Ubuntu 支持的安装方式是使用官方 Ollama 安装程序，而非自定义 tarball 流程，也不是绕道 Docker。这一点很重要，因为本指南的目标是在 Linux 上获得一个具有可预测默认设置、systemd 集成和合理所有权行为的可靠本地服务。

严格按照文档运行安装程序：

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

脚本完成后，请验证服务状态，而非假设成功：

您需要在此确认三件事：单元文件已存在，服务已设置为开机启动，且 Active: active (running) 确认服务器确实已启动并运行。

首先以具体的方式确认 Linux 服务用户账户，然后再考虑模型存储的处理方式和位置。

这一行信息解释了大量后续行为。Linux 上的模型归属于该服务的所有权，如果您后来将模型移动到另一块磁盘而未修复 ollama 用户的权限，就会造成问题。

最后一项检查确认默认绑定情况：

⚠️ 警告：Ollama 默认在本地 API 上不需要身份验证。当它绑定到 127.0.0.1 时这没有问题，但将端口 11434 直接暴露在互联网上是不安全的，不能将其视为已加固的公共服务。

如果服务未能正常启动，请先查看日志，而非盲目重新安装：

这是发现权限问题、启动错误、驱动程序检测问题或绑定问题的最快方法。一旦服务在本地主机上正常运行，下一步需要了解的是运行时 GPU 分配的行为方式。

Ollama 实际上如何使用单个或多个 GPU

尽管本指南所使用的服务器只有一个 GPU，但多 GPU 的行为仍值得了解，因为许多用户可能使用更大的机器，或者将来可能会扩展。很多关于双 GPU 的困惑源于错误的预期：”我有两张显卡，所以两张应该一直都亮着。”Ollama 的工作方式并非如此。实际规则要简单得多：如果一个模型能放入一张 GPU，Ollama 通常会将其保留在一张 GPU 上。只有当模型无法舒适地放入单张显卡时，它才会跨多张 GPU 分配。

每当您想查看 GPU 性能时，请结合使用以下两个命令：

ollama ps 告诉您已加载的模型是如何被处理的。100% GPU 表示模型完全驻留在 GPU 显存中。100% CPU 表示未使用 GPU 加速。混合状态表明工作负载或驻留的某部分溢出到了 GPU 路径之外。watch -n 1 nvidia-smi 与之互补，在模型加载时实时显示每张显卡的 VRAM 使用情况。

区分这两个命令的最简便方法如下：

📝 注意：CUDA_VISIBLE_DEVICES 是一个可见性控制开关，而非”同时使用两张 GPU”的开关。如果您需要限制 GPU 访问，建议优先使用 nvidia-smi -L 中的 UUID，而非数字 ID，因为 GPU 排序在不同环境和重启后可能会发生变化。

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

此时，您不需要一个庞大的模型来证明服务器可以正常工作。您需要的是一次快速、真实的成功。mistral 是一个不错的首次拉取选择，因为它体积小、下载快、易于加载，尽管 llama3.1:8b 将在后续作为行为对比的基准模型。

首先拉取模型：

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

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

要查看磁盘上已有的内容，请列出本地模型清单：

mistral 是正确的首次验证选择，因为它能快速给出答案，而不会让配置验证变成漫长的等待。之后，llama3.1:8b 会更加有用，因为它是比较模型行为时更强的对齐基准。

最后，检查 Linux 安装将模型存储在何处：

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

一旦您看到成功的响应、ollama ps 中显示 100% GPU，以及磁盘使用量在预期位置增加，就获得了本地技术栈正常工作的第一个有意义的证明。

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

命令行提示词固然不错，但自托管 Ollama 的原因不仅仅是在终端中聊天。而是为了运行一个本地推理服务器，让其他工具、脚本和应用程序无需通过他人的 API 边界发送提示词即可进行调用。最快的证明方式是向原生 Ollama 端点发送一次干净的 HTTP 请求。

禁用流式传输发送一个本地生成请求，以便于检查首次响应：

成功的响应应以 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 端点：

📝 注意：“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 生态系统这一部分中最可能看到的三个名称的实用说明：

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

GPU 性能

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

在这台服务器上，更好的高端运行时测试是 gpt-oss:20b。它足够大，具有研究价值，同时在单张 16GB 显卡上仍然合理。

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

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

如果您稍后在双 GPU 主机上运行 Ollama，像 qwen3:30b 这样的模型就成为能够演示多 GPU 分配的工作负载类型。工作流程是相同的——观察 nvidia-smi，运行模型，检查 ollama ps——但重点不是为了让两张显卡都亮起而去这样做。重点是确认 Ollama 只有在模型无法干净地放入单张显卡时，才会将其分布在多个 GPU 上。

关于绕过内容审查的注意事项

进行行为对比时，请保持条件受控，以便更多地测试模型本身而非随机性。使用相同的端点、相同的提示词、stream: false、较低的 temperature 和固定的 seed：

然后用 “model”: “dolphin3” 重复相同的请求。固定的 seed 不能消除所有变量，但它能减少足够多的随机性，使语气和合规性差异更易于观察。

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 边界归您所有，模型选单归您所有，您的提示词/运行时默认值也归您自己调整。

仍然需要您自行判断的，是任何安装程序都无法替您解决的部分：选择符合您使用场景的模型、用合理的默认值引导它们，以及在准备好超出本地主机范围时安全地开放访问。这才是自托管控制权的真实面貌。不是从所有限制中获得神奇的自由，而是拥有决定推理如何发生、在哪里发生以及使用哪个模型的技术栈所有权。如果您想迈出最佳的下一步，可以从创建自定义 Modelfile 开始，或者在准备好时为本地 API 配置安全的远程访问。

基础配置完成后的下一步

此时，核心承诺已经兑现。服务器正常运行，API 正常运行，GPU 路径是真实的，模型行为差异也不再是抽象的概念。下一步不是”盲目地安装更多东西”，而是调整现在属于您的技术栈中的各个部分。

使用 Modelfile 自定义模型行为

Modelfile 是在不触及模型权重的情况下更改本地提示词默认值的最简洁方式。首先检查模型的当前定义，以便了解您将要扩展的内容：

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

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

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

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

加固配置安全性

本地主机绑定是一个良好的默认设置，但这并非安全故事的终点。首先重新检查当前的监听地址：

如果目标是将 Ollama 保持为仅本地访问，请通过 systemd 覆盖明确锁定该行为：

添加以下内容：

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

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

如果您以后需要远程访问，请勿直接发布 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 网关。

适合此硬件的推荐模型

基础安装完成后，最有价值的改进是选择真正适合这台机器的模型，而非追逐最大的数字。对于本指南使用的单 RTX 4070 Ti SUPER 服务器，实用的模型菜单如下：

自动启动与日常维护

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

对于日常模型操作，以下是您最常用的命令：

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

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

故障排除参考

当出现问题时，最快的解决路径通常是将症状与正确的层面对应起来，而非尝试随机重装循环。请将此表格作为第一步排查手段：

如果您只记住本节中的一条操作规则，请记住这条：将 Ollama 视为真正的服务，而非一次性的 CLI 工具。日志、所有权、绑定地址和存储路径与提示词窗口同等重要。