成本、计费与运维2026年10月26日Flatkey Team

Ollama Cloud GPU：运行安全的远程 API 服务器

一套安全的 Docker 与 HTTPS 代理工作流，可在云 GPU 上运行 Ollama，并提供远程 /api 或兼容 OpenAI 的 /v1 端点。

Ollama Cloud GPU：运行安全的远程 API 服务器

运行 Ollama cloud GPU 服务器可让您直接控制模型、量化、运行时和数据路径。同时，这也带来了一项笔记本电脑安装环境中不易察觉的运维责任：本地 Ollama API 并不是面向公网的身份验证边界。安全的远程设置应将 Ollama 保持在私有回环端口上，并在边缘代理处部署 TLS 和调用方身份验证。

本指南展示了一个实用的 NVIDIA/Docker 部署方案，用于运行 Ollama cloud GPU 服务器；还包括一个接受 OpenAI 风格 Bearer 令牌的 Caddy HTTPS 边缘，以及远程客户端配置。其面向独立开发者和小型 AI 团队：他们希望在租用的 GPU 资源上运行开放权重模型，同时不将端口 11434 发布到互联网。

简要版本：运行 Ollama 时，将其主机端口绑定到 127.0.0.1；在云防火墙中阻止对端口 11434 的公网访问；仅在端口 80/443 上暴露 HTTPS 反向代理。让该代理在将流量转发给 Ollama 之前验证令牌。

Ollama 将 127.0.0.1:11434 记录为其默认绑定地址，并说明本地服务器的 API 请求无需授权。这对本地开发很方便，但也意味着可从远程访问的裸端点并不是正确的安全边界。在部署期间，建议始终参考 Ollama 的 FAQ 和 API 简介。

此 Ollama cloud GPU 架构保护的内容

该架构包含四个边界，每个边界都有明确的职责：

远程客户端 / OpenAI SDK
        |
        | HTTPS + Bearer 令牌
        v
公网边缘代理（Caddy，仅端口 80/443）
        |
        | localhost HTTP
        v
Ollama API (127.0.0.1:11434)
        |
        v
GPU 运行时和模型卷

边缘代理是唯一接受互联网流量的组件。Ollama 仅可由同一主机访问。这样可以防止云防火墙配置错误、意外开放的 Docker 映射或未经身份验证的调用方，直接访问您的模型服务器。

层	必需职责	不要这样做
云防火墙 / 安全组	仅允许您有意暴露的端口；将 SSH 限制为您的 IP 或私有网络。	向 `0.0.0.0/0` 开放 TCP 11434。
Docker 端口映射	使用 `127.0.0.1:11434:11434` 将 Ollama 绑定到回环地址。	除非已有私有网络边界提供保护，否则不要使用公网主机映射。
HTTPS 代理	终止 TLS、验证调用方令牌并转发到回环地址。	不要将 Ollama 的本地端点视为能够验证远程调用方身份的端点。
客户端	将令牌发送给代理，并使用特定的模型标签。	不要假设每个 OpenAI 端点或参数都无需测试即可使用。

对于拥有多个用户的生产系统，请使用私有覆盖网络或具备身份感知能力的代理，并提供独立身份和撤销机制。下面的单一 Bearer 令牌示例是实用的服务器到服务器起点，不能替代 SSO、按用户划分的审计记录、速率限制或策略执行。

租用 GPU 之前：评估工作负载，而不是下载量

当您需要控制模型文件、特定量化方式、私有运行时，或需要持续使用某个模型系列时，Ollama cloud GPU 是合理的选择。对于流量突发或频繁更换模型的产品，它并不一定是成本更低的选择。

从实际的模型标签、量化方式、上下文窗口和同时请求数开始。模型权重只是内存预算的一部分：上下文和并行请求会消耗额外的 VRAM。Ollama 文档指出，并行请求处理会增加有效上下文分配；其 ollama ps 输出会显示模型是完全位于 GPU、完全位于 CPU，还是分布在两者之间。在确定 GPU 规格之前，请参阅 Ollama 70B 模型 VRAM 要求和 LLM GPU 内存要求指南。

您的目标	首选部署方案	扩展前需衡量的指标
单用户开发或评估	选择一张可轻松容纳量化模型及上下文余量的 GPU。	GPU 驻留情况、首个 token 延迟、峰值 VRAM，以及在真实提示词上的质量。
小型团队的内部 API	一台私有服务器，加上 HTTPS 边缘和明确的队列策略。	并发请求数、尾延迟、503 错误，以及令牌轮换工作流。
共享产品端点	多个副本或托管 API 备用方案，并配备可观测性和身份控制。	队列深度、错误率、可接受输出率和恢复时间。

2026 年如何为 Ollama 选择低成本 GPU 云

对于“best cheap gpu cloud for ollama 2026”这一查询，并不存在一个持久不变的答案。一块价格低廉但会迫使您使用 CPU 卸载、缺少上下文余量，或一天中大部分时间处于空闲状态的按小时计费 GPU，在实际使用中并不便宜。请使用相同的模型标签和提示词集比较候选方案，然后记录：

计费的 GPU 时间、存储、出站流量和设置时间；
来自 ollama ps 的模型加载时间和 GPU 驻留情况；
首个令牌生成时间、端到端延迟和失败请求；
实际支持的上下文窗口和并发量；以及
每个被接受输出的成本，而不只是每 GPU 小时的成本。

使用 Flatkey 的GPU 云服务对比来评估供应商是否适合，并参考其GPU 租赁价格指南，避免忽略实例本身之外的成本项目。在预留容量之前，先进行一次简短且可重复的试点。

第 1 步：准备 NVIDIA 主机

本演练假定您使用的是受支持的 Linux GPU 主机、Docker、NVIDIA 驱动程序以及 NVIDIA Container Toolkit。首先确认主机能够识别其 GPU：

nvidia-smi

然后配置 Docker 的 NVIDIA 运行时，并验证容器能够识别同一设备：

sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

# CUDA 镜像示例；请使用与主机驱动程序和操作系统兼容的标签。
docker run --rm --gpus all \
  nvidia/cuda:12.6.0-base-ubuntu22.04 nvidia-smi

Ollama 的Docker 文档针对基于 NVIDIA 的容器使用 NVIDIA Container Toolkit 和 --gpus=all。如果此验证命令失败，请在此停止并修复驱动程序/运行时层；模型故障排除只会掩盖根本原因。

启动容器之前，请配置云防火墙或安全组：

仅允许来自获批准的源地址范围、堡垒机或私有网络的 SSH。
只有当此服务器将使用公共 HTTPS 主机名时，才允许 TCP 80 和 443。
不要允许来自公共互联网的 TCP 11434。
如果您使用 UFW 等主机防火墙，请使其规则与云防火墙保持一致，而不是仅依赖其中一层。

第 2 步：在 GPU 主机上私有运行 Ollama

使用命名卷，以便模型文件在重新创建容器后仍能保留。-p 左侧的回环地址是有意设置的：它允许同一台机器上的 Caddy 访问 Ollama，同时阻止与该服务建立直接的外部连接。

docker pull ollama/ollama:<verified-ollama-tag>

docker run -d \
  --name ollama \
  --restart unless-stopped \
  --gpus all \
  -v ollama:/root/.ollama \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama:<verified-ollama-tag>

请将 <verified-ollama-tag> 替换为您的团队已测试的发布标签；不要在重启时拉取未经审查的镜像，从而在不知不觉中升级生产服务。Ollama 也支持原生 Linux 安装和 systemd 服务，但同样的边界原则仍然适用：保留回环绑定，并将远程访问置于经过身份验证的代理之后。官方Linux 指南记录了服务工作流及其环境变量覆盖机制。

拉取一个适合所选 GPU 的小型测试模型。本示例使用 Ollama 的 OpenAI 兼容性示例中的当前标签；请替换为您打算提供服务的确切模型和量化版本。

docker exec ollama ollama pull qwen3:8b

curl -sS http://127.0.0.1:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "qwen3:8b",
    "messages": [{"role": "user", "content": "Reply with a three-word GPU health check."}],
    "stream": false
  }'

docker exec ollama ollama ps

ollama ps 是对 Ollama 云 GPU部署进行验收检查的有用工具。100% GPU 处理器指示表示已加载的模型完全位于 GPU 上；对于测试而言，CPU/GPU 混合使用可能可以接受，但在投入生产前，应衡量其延迟和内存方面的权衡。

第 3 步：添加带 Bearer 令牌的 HTTPS API 边缘层

Ollama 可以通过代理公开其 API，并同时提供原生的 /api 接口和本地 OpenAI 兼容的 /v1 接口。其本地 OpenAI 客户端示例使用的 API 密钥值会被 Ollama 忽略，这正是以下代理会在转发流量前执行授权检查的原因。Ollama 的 OpenAI 兼容性文档也明确指出，兼容性只是一个子集，因此应规划实际的集成测试，而不是作出笼统假设。

此 Caddy 模式使 OpenAI 风格的客户端能够使用 Authorization: Bearer <token>。Caddy 会验证该请求头，在请求到达本地服务之前将其移除，并通过回环地址代理该请求。

首先生成一个高熵令牌，并将其保存到团队的密钥管理器中。不要将它放入源代码控制系统或您无法控制的 shell 历史记录中。

openssl rand -hex 32

为 Caddy 创建 systemd 覆盖配置，并将生成的值设为 OLLAMA_API_TOKEN：

# sudo systemctl edit caddy
[Service]
Environment="OLLAMA_API_TOKEN=replace-with-your-secret-manager-value"

然后使用 DNS 指向该服务器的主机名配置 /etc/caddy/Caddyfile：

ollama.example.com {
    @authorized {
        header Authorization "Bearer {$OLLAMA_API_TOKEN}"
    }

    handle @authorized {
        reverse_proxy 127.0.0.1:11434 {
            # The edge checked this header; Ollama does not need the token.
            header_up -Authorization
        }
    }

    handle {
        respond "Unauthorized" 401
    }
}

使用实际的 DNS 名称替换 ollama.example.com。Caddy 会将域名站点地址视为使用托管证书的 HTTPS 站点；重新加载前，请确保 DNS 和所需的入站端口已准备就绪。Caddy 请求匹配器、互斥的 handle 块和反向代理请求头控制文档介绍了上面使用的指令。

验证并重新加载配置：

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl daemon-reload
sudo systemctl reload caddy

测试边界两侧的访问。第一个请求必须能够从主机成功发出。第二个请求只有在令牌正确时才能通过 TLS 成功完成。第三个不带令牌的请求应返回 401。

# Host-local health check
curl -sS http://127.0.0.1:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"health check"}],"stream":false}'

# Remote request through the edge
curl -sS https://ollama.example.com/api/chat \
  -H "Authorization: Bearer $OLLAMA_API_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"model":"qwen3:8b","messages":[{"role":"user","content":"health check"}],"stream":false}'

# Expected: HTTP 401
curl -i https://ollama.example.com/api/chat

如果不修改客户端设计，请勿在这种特定的客户端模式中改用基本认证。HTTP Basic 和 OpenAI SDK 都使用 Authorization 请求头。上述边缘层的 Bearer 令牌方案保留了常见的 OpenAI SDK 调用方式，同时使本地 Ollama 端点保持私有。

第 4 步：从 OpenAI 客户端调用远程 Ollama API

Ollama 文档将 http://localhost:11434/v1 指定为其本地兼容 OpenAI 的基础 URL。配置好 HTTPS 边缘层后，只需更改主机地址，并将代理令牌用作客户端 API 密钥：

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://ollama.example.com/v1/",
    api_key=os.environ["OLLAMA_API_TOKEN"],
)

response = client.chat.completions.create(
    model="qwen3:8b",
    messages=[
        {"role": "user", "content": "Give me a concise deployment checklist."}
    ],
)

print(response.choices[0].message.content)

这是一个远程 Ollama 云 GPU API，但它并不能自动成为所有 OpenAI 功能的即插即用替代方案。在迁移生产流量之前，请测试应用实际使用的端点和行为：流式输出、工具调用、结构化输出、嵌入、视觉输入、错误处理、上下文限制和客户端超时。哪些功能有意义或受到支持，也取决于模型本身。

第 5 步：有计划地调整并发和模型驻留

不要因为服务器在单次 curl 测试期间负载较低就提高并行度。Ollama 文档介绍了默认的 4096 token 上下文窗口、请求队列设置，以及取决于内存的模型并行处理能力。每增加一个并行请求，实际分配的上下文容量都会增加，因此，即使 Ollama 云 GPU 能够处理单个请求，也可能在并发流量下出现故障。

按以下受控顺序逐步部署：

以计划使用的量化级别加载一个模型，并运行一组具有代表性的提示词。
使用 nvidia-smi 和 ollama ps 记录显存、延迟和 GPU 驻留情况。
每次只增加上下文长度或并行请求数中的一项。
制定明确的过载策略：排队、拒绝或路由至备用方案。
每次更改模型、驱动程序、运行时或上下文窗口后，重复上述步骤。

Ollama 的常见问题文档介绍了 OLLAMA_CONTEXT_LENGTH、OLLAMA_NUM_PARALLEL、OLLAMA_MAX_QUEUE 和 OLLAMA_KEEP_ALIVE。文档还指出，503 响应可能表示队列过载。应为这些信号准备运维手册，而不是将其视为随机的 API 故障。

信号	可能原因	首要响应措施
`ollama ps` 显示 CPU/GPU 分配	模型无法完全装入可用 VRAM。	减小模型规模或上下文，选择不同的量化方式，或迁移到更大的 GPU。
远程请求返回 401	边缘层未收到预期的 bearer token。	验证 `OLLAMA_API_TOKEN`、Caddy 服务覆盖配置以及客户端的 `api_key`。
代理返回 502	Caddy 无法通过 loopback 连接到 Ollama，或者容器已停止。	运行主机本地 curl 检查，并查看 `docker logs ollama`。
流量高峰时出现 503	队列或内存压力。	降低并发数/上下文，设置队列策略，或增加容量/后备方案。
空闲后首次请求缓慢	模型已被卸载或需要预热。	评估较长的 `keep_alive` 预算是否值得占用保留的 VRAM。

如需了解更通用的自托管服务器模式，请参阅如何构建兼容 OpenAI 的推理服务器。该指南涵盖更广泛的边缘层、后备方案和验收测试问题；本文则专注于安全的远程 Ollama 工作流。

何时不应运行 Ollama 云 GPU 服务器

当基础设施本身是产品需求的一部分时，自托管很有价值。但如果目标只是针对不断变化的工作负载调用可用的最佳模型，其吸引力就较低。出现以下情况时，请考虑使用托管模型 API 或混合后备方案：

流量呈突发性，GPU 将长期闲置；
您需要多个模型系列或频繁更换模型；
您的团队无法维护驱动程序、模型卷、TLS、令牌轮换、可观测性和事件响应；或
一旦计入重试和运维人员时间，GPU 路径的已接受输出成本更高。

Flatkey 可以作为这种对比或后备路径：一个密钥和一个余额即可使用 300 多个官方模型及 1,000 多种按次付费工具。让客户端保持 OpenAI 兼容的形式，并使用相同的提示词、成功标准和超时策略，将自托管路径与托管替代方案进行衡量。

Ollama 云 GPU 生产清单

[ ] 可通过 nvidia-smi 和 Docker GPU 测试看到 GPU。
[ ] Ollama 的 Docker 端口仅映射到 127.0.0.1:11434。
[ ] 端口 11434 未在云防火墙或主机防火墙中公开。
[ ] 代理在真实主机名上提供 HTTPS，并拒绝没有令牌的请求。
[ ] bearer token 存储在代码库外，并且有文档化的轮换流程。
[ ] 使用令牌的远程 /api/chat 请求成功，而不使用令牌时失败。
[ ] 从您的应用实际使用的 SDK 发起远程 /v1/chat/completions 测试并成功。
[ ] 已记录精确的模型标签、量化方式、上下文窗口和并发目标。
[ ] ollama ps、GPU 遥测、代理日志和 5xx 比率已纳入运行手册。
[ ] 您已测试过过载、重启和令牌轮换场景。
[ ] 在模型灵活性或可用性很重要的情况下，您已将Ollama 云 GPU路径与托管 API 基线进行比较。

常见问题

Ollama 会自行对远程 API 进行身份验证吗？

不要依赖本地 API 进行远程身份验证。Ollama 的本地服务器示例省略了授权，或者使用了本地服务器会忽略的 API 密钥值。应保持服务私有，并在 TLS 代理、私有网络边界或身份感知网关处强制实施身份验证。

我可以将 OpenAI SDK 与 Ollama 云 GPU 一起使用吗？

可以，Ollama 提供了本地 OpenAI 兼容的 /v1 基础 URL 及常见客户端示例。将 SDK 指向您的 HTTPS 代理的 /v1/ 路径，并让该代理验证 bearer token。请测试您实际使用的确切端点，因为兼容性是一个子集，而非无条件保证。

2026 年最适合 Ollama 的低成本 GPU 云是什么？

2026 年最适合 Ollama 的低成本 GPU 云，是能够满足您实际模型、上下文和并发需求，同时不会产生隐藏闲置时间或 CPU 卸载的那个。请在几个候选方案上运行相同的短基准测试，并比较每个已接受输出的成本，而非供应商宣传的每小时价格。

为什么我的 Ollama 容器在 CPU 而不是 GPU 上运行？

首先使用 nvidia-smi 检查主机，然后在配置 NVIDIA Container Toolkit 后确认 Docker 能够看到 GPU。最后检查 ollama ps：当模型无法装入可用 GPU 内存时，它可能部分或完全运行在 CPU 上。

为了省去一次代理跳转，我应该直接暴露端口 11434 吗？

不应该。为 TLS、调用方身份验证、密钥轮换和明确的公共边界而增加的小型本地代理跳转是值得的。暴露裸露的本地模型服务器，会将基础设施捷径变成不必要的安全和滥用风险。

最终建议

可靠地运行 Ollama cloud GPU 服务器的方法很直接：验证 GPU 运行时，将 Ollama 绑定到回环地址，使用带有持有者令牌检查的 HTTPS 代理，并从您实际要发布的客户端测试原生 /api 和兼容 OpenAI 的 /v1 调用。

这样，您既能获得自托管模型的控制权，又不会将未经身份验证的本地端点变成公共 API。在扩展服务器之前，请衡量模型适配性、上下文、并发能力和已接受输出的成本；对于自行运营 GPU 所增加的复杂性超过其价值的工作负载，则保留托管 API 作为基准方案。

来源

成本、计费与运维

GPU 服务器：架构、性能与云部署指南

2026年10月23日Flatkey Team

成本、计费与运维

租用 GPU 服务器：架构、性能与云端部署指南

2026年10月28日Flatkey Team

成本、计费与运维

GPU 服务器机架：架构、性能与云部署指南

2026年10月27日Flatkey Editorial Team

返回博客

Ollama Cloud GPU：运行安全的远程 API 服务器