2026年 AI VPS 完全指南:在自有服务器上运行大语言模型与 AI 工作负载
对比 GPU 和 CPU VPS 方案,详解在自有服务器上自建 AI 推理服务的硬件要求、真实价格和部署步骤。
为什么要在自己的 VPS 上跑 AI?
但大多数教程不会告诉你的是:适合跑 AI 的 VPS 取决于你到底要跑什么。一个量化 7B 聊天模型和一个 70B 推理模型、或者一个 Stable Diffusion 管线的硬件需求完全不同。这篇文章拆解实际需求,对比我们在 VPSDex 上覆盖的各家服务商真实价格,并告诉你如何从零开始搭建一个能用的自托管 AI 技术栈。
现在买家问的问题已经不是"你支持 AI 工作负载吗",而是"我能多快部署好?"。无摩擦部署成了新的竞争点。
AI 工作负载分类
在比较服务器之前,你需要知道自己的工作负载属于哪一类。硬件需求完全不同。
CPU 推理(量化模型)
这是 2025-2026 年爆发的类别。得益于 llama.cpp 的 GGUF 格式和 Ollama 的打包,Llama 3.1 8B、Mistral 7B、Phi-3 等模型可以在纯 CPU 的 VPS 上运行。速度不如 GPU,但成本差距巨大。
- 7B 模型(Q4 量化):需要约 5-6 GB 内存,4 核 8GB 的 VPS 即可
- 13B 模型(Q4):需要约 9-10 GB 内存,建议 8 核 16GB 的 VPS
- 33B-34B 模型(Q4):需要约 20-24 GB 内存,需要高内存实例
- 70B 模型(Q4):需要约 40 GB 内存,CPU 上一般不实用
7B 模型在不错的 CPU VPS 上大约能生成每秒 8-20 token。聊天够用,批处理可以接受,多用户实时场景会吃力。
GPU 推理
如果你需要速度、吞吐量,或者想交互式运行更大的模型,GPU 是必经之路。2026 年中的格局是这样的:
- NVIDIA RTX 4000 Ada(20 GB):入门级 GPU,适合 7B-13B 模型 FP16 运行
- NVIDIA L40S(48 GB):能跑 Q4 量化的 70B 模型,生产推理可靠
- NVIDIA H100(80 GB):标杆。FP16 跑 70B,支持多模型并发
- NVIDIA H200(141 GB):当前代,针对大上下文窗口优化
- NVIDIA B300(288 GB):Blackwell 架构,DigitalOcean 2026 年已上线
- AMD MI300X(192 GB)/ MI350X(288 GB):AMD 的竞争方案,软件生态持续完善
微调和训练
这一层成本会暴涨。用 LoRA 微调 7B 模型至少需要 24 GB 显存。13B 以上的全量微调实际上需要多 GPU 集群或云 GPU 集群。如果你到了这个阶段,大概率已经知道自己需要什么了,这篇指南对你来说太基础。但其他人的话,继续往下看。
CPU VPS 价格与套餐核验
CPU 套餐是否适合,取决于已实测的模型文件、上下文窗口、并发量和操作系统开销。价格和含流量会变化,因此本文不把旧套餐名或促销价当作现价。截至 2026-09-14,Hetzner 官方页面区分共享 CPX 与独享 CCX 资源;Contabo 官方页面公布套餐条款,并对出站“无限流量”附有公平使用条件。购买前必须在结账页核对准确套餐、区域、税费、付款周期、端口/流量额度、取消和续费总价。
- 官方套餐页:Hetzner https://www.hetzner.com/cloud;Contabo https://contabo.com/en/vps/。
- 配置方法:为系统、运行时和 KV cache 预留内存,再在月付或按小时实例上跑目标模型与负载测试。
- 促销规则:有日期的优惠码或年付价,只有在服务商实时结账页仍可用于同一套餐时才可视为当前有效;否则是历史信息,必须标注日期并复核总价。
GPU 价格与套餐核验
GPU 库存、小时费率、附带 CPU/内存/存储和计费规则都可能因区域变化。不要采用博客价格表,应以服务商当前产品页和结账/API 报价为准。截至 2026-09-14,DigitalOcean 文档列出 GPU Droplet 费率,并明确计费在销毁 Droplet 时结束,而非仅关机;Vultr 也将 GPU 与计算实例定价分开公布。开机前确认配额、区域库存、出站流量、持久盘费用和销毁/终止规则。
- DigitalOcean:https://docs.digitalocean.com/products/droplets/details/pricing/
- Vultr:https://www.vultr.com/pricing/
搭建你的 AI 技术栈:工具和框架
有了 VPS 之后,安装什么软件是个问题。生态已经围绕几个可靠工具收敛了。
Ollama(最简单的路径)
Ollama 是从"刚开的 VPS"到"能用的 API"最快的路径。一条命令安装,拉一个模型,你就有一个 REST API 在返回响应了。它自动处理量化,并根据你的硬件选择最佳后端。
- 安装:curl -fsSL https://ollama.com/install.sh | sh
- 拉模型:ollama pull llama3.1:8b
- 服务:ollama serve(在 11434 端口暴露 API)
Ollama 在 CPU 和 GPU 上都能跑。在 8 GB 或以上内存的纯 CPU VPS 上,7B-8B 量化模型跑起来没问题。吞吐量取决于 CPU,但交互式聊天速度是可用的。
vLLM(高吞吐量)
如果你需要生产级推理,支持批处理、流式生成和 OpenAI 兼容 API,vLLM 是标准选择。它需要 GPU 和一些 Python 知识来配置,但相比朴素推理,吞吐量的提升很显著,尤其是在并发负载下。
llama.cpp(极致控制)
大多数 CPU 推理工具的底层基础。如果你想从特定 VPS 上挤出每一分性能,llama.cpp 配合手动 GGUF 量化和线程调优给你最大的控制权。不适合新手,但在优化方面无可匹敌。
应用层
在推理引擎之上,几个开源项目给你可用的界面:
- LibreChat:类似 ChatGPT 的 Web UI,连接你本地的 Ollama 或 vLLM 端点
- AnythingLLM:文档感知聊天,连接 Ollama 做本地 RAG 管线
- Flowise:可视化工作流构建器,用于 LLM 链和 Agent
- Open WebUI:另一个精致的前端,和 Ollama 开箱即用配合很好
如果选择 Open WebUI 作为 Ollama 的聊天前端,下一步可参考 AIX Cove 的Open WebUI 与 Ollama 配置教程,检查 Docker 到模型服务的连接、聊天数据持久化和账户模式。教程中的单用户免登录选项不适合公网 VPS;对外提供访问前,应保留认证并限制端口暴露。
内存需求:真正的瓶颈
这是大多数人低估的实际问题。CPU 推理时,内存是硬约束。不是 CPU 速度,不是存储,不是带宽。模型放不进内存就跑不了。勉强放进去,系统就会 swap,性能直接崩溃。
Q4_K_M 量化(质量和大小最常见的平衡点)的大致规则:
- 3.8B 模型:模型文件约 2.5 GB,总共需要 4 GB 内存
- 7B-8B 模型:模型文件约 4.5-5 GB,总共需要 8 GB 内存
- 13B-14B 模型:模型文件约 8-9 GB,总共需要 16 GB 内存
- 33B 模型:模型文件约 20 GB,总共需要 32 GB 内存
- 70B 模型:模型文件约 40 GB,总共需要 64 GB 内存
操作系统、推理引擎和前端应用还需要额外的 1-2 GB。永远向上取整。16 GB 的 VPS 是跑单个 13B 模型加 Web UI 的甜点。低于 8 GB 就只能跑 7B 及更小的模型了。
如果预算迫使你在更多内存和更多 CPU 之间选择,选内存。慢 CPU 上推理可以忍受。不停 swap 的推理是坏的。
决策框架:哪家服务商,哪个套餐?
应根据目标模型、量化方式、上下文长度和并发请求的实测结果选择,而不是根据 CPU GHz 或宣传月价。对比结账页总价,并记录计费单位(按小时或按月)、区域、含流量、存储、IP、备份和税费。条件允许时先短期使用;取消、退款和续费以服务商当前结账页和法律页面为准。
- 个人或原型:按实测内存加余量选型,用短期实例验证延迟与吞吐。
- 团队推理:测试并发、上下文/KV cache 增长、持久化、认证和备份。
- 生产 API:除计算资源外,还要预算冗余、监控、出站流量、限流和事故恢复。
- 促销/历史价格:必须标出日期,且在依赖前用实时结账页复核。
网络和地理位置
AI 推理 API 和其他网络服务一样受延迟影响。如果你的用户在亚洲,VPS 在德国,光网络往返延迟就可能 250-300ms,模型还没开始生成 token。
各服务商 AI 工作负载的区域覆盖:
- 欧洲:Hetzner(德国、芬兰),Contabo(德国),DigitalOcean(阿姆斯特丹、法兰克福、伦敦)
- 北美:Vultr(美国多个城市),DigitalOcean(纽约、旧金山、多伦多),Hetzner(美国)
- 亚太:Vultr(东京、新加坡、悉尼),Contabo(新加坡),DigitalOcean(新加坡、班加罗尔)
- 中国大陆优化路由:搬瓦工(CN2 GIA),DMIT(CN2 GIA、CMIN2),V.PS(多个亚洲节点)
如果你专门服务中国大陆用户,搬瓦工和 DMIT 这类 CN2 优质路由的服务商延迟会明显好于普通国际线路。代价是每 GB 带宽成本更高。
安全:别把你的 AI 端点暴露出去
自托管 AI 的一个常见错误是把推理 API 暴露在公网。Ollama 默认 API 没有认证。开放的 11434 端口意味着任何找到你 IP 的人都能用你的算力,如果你的模型有工具或文件访问权限,后果可能更严重。
- 绑定 localhost:设置 OLLAMA_HOST=127.0.0.1:11434,用反向代理做外部访问
- 加认证:在前面放 nginx 或 Caddy,加 basic auth 或 API key
- 用 SSH 隧道:个人使用的话,通过 SSH 隧道转发端口。简单且安全。
- 防火墙:在操作系统防火墙层面封锁 11434。只允许通过你的代理访问。
LibreChat、Open WebUI 等前端也一样。它们通常默认开放访问。在暴露到公网之前一定要配置认证。
成本问题:自建 vs. API
应比较实测的总成本,而不是只看 VPS 标价:服务器在线时间、存储、出站流量、备份、监控、工程维护时间,以及模型/API token 组合都要计入。OpenAI 的当前 API 价目表在 https://developers.openai.com/api/docs/pricing;费率与模型可用性会变化,决策时应读取实时表。自托管可能因隐私、控制或长期稳定利用率而合适,但在低用量或波动用量下不必然更便宜。
接下来会怎样
VPS 行业的趋势指向 AI 工作负载正在成为标准类别而非特殊领域。我们看到主机商开始构建 Ollama、vLLM 和常见 AI 技术栈的一键部署模板。LowEndBox 社区在 2026 年中注意到,客户咨询已经从"你支持 AI 吗"转向"我能多快部署 AI 环境?"。这是一个实质性的变化。
硬件同时在两个方向上发展。GPU 服务商在添加下一代显卡(Blackwell B300、AMD MI350X),显存池越来越大。CPU 服务商则受益于更好的量化技术,能在更少内存中塞进更大的模型。两条路径都在降低自托管 AI 的门槛。
对于 2026 年考虑这件事的人来说,实用建议很直接。从中档 CPU VPS 开始,装 Ollama,跑 7B 模型。如果质量满足你的需求,完成了。如果不满足,你会确切知道差在哪,然后决定 GPU 升级是否值得。入门门槛从未这么低过。