如何在私有 GPU 服务器上自托管 LLM

在你租来的硬件上运行语言模型，是唯一能确保你的提示词不会被记录、保留，也不会被除你以外的任何人读取的方式。无论隐私政策写得多好，任何托管 API 都会接收你发送的每一个 token，而这份政策可能在你毫不知情的情况下发生变化。自托管挪动了这条边界：权重存放在你自己掌控的磁盘上，推理发生在你按小时租来的显存里，除非你主动把数据发送出去，否则不会有任何东西离开这台机器。软件层面已经变得相当简单。真正容易让人在此栽跟头的，是下单前把显卡型号算对，以及记住这一点——一个开放的推理端口，就是一个开放的推理端口。

自托管究竟能带来什么——又不能带来什么

把这个好处说清楚，因为"私密 AI"这个说法常常被泛泛而谈。跑在你自己 GPU 上的模型，会彻底改变一些事情，也有一些事情完全不会改变。

• 你的提示词和输出都留在这台机器上——没有服务商侧的日志记录，没有留存期限，也不会有人拿你问过的内容去构建数据集。
• 不需要账号，没有按密钥计算的速率限制，你和权重之间也没有任何策略层。你部署的是什么模型，得到的就是什么模型。
• 用量越大，成本越可预测。一旦每天的用量超过几百万 token，租一块显卡就会比按 token 计费更便宜，而且价格不会因为某个服务商调整报价表而跟着变动。
• 它不会把一个能力弱的模型变强。一个开放权重的模型放到你自己的硬件上，依然是那个模型——自托管买到的是掌控权，而不是前沿能力。
• 它也不会对主机商隐藏任何东西。任何能物理接触到一台正在运行的机器的人，原则上都能读取它的内存——这是关于主机商的问题，与模型本身无关。

显存才是关键：把模型和显卡匹配好

几乎每一次失败的初次尝试，都是显存算错了。权重、KV 缓存和运行余量必须同时塞进这块显卡里，而且没有什么优雅降级可言——加载到几秒钟就会直接报显存不足的错误。有一个可用的经验法则：16-bit 精度下，模型大约每十亿参数需要 2 GB 显存，8-bit 下大约是 1 GB，4-bit 下大约是 0.6 GB。然后再加上 KV 缓存——它会随上下文长度和并发请求数增长，而真正在生产环境里咬你一口的，往往正是它，而不是测试阶段。

• 7B 到 8B 的模型：FP16 下大约需要 16 GB，4-bit 下轻松控制在 8 GB 以内。这个级别用 RTX A4000 16 GB 绰绰有余。
• 13B 到 14B 的模型：FP16 下大约 28 GB，4-bit 下大约 9 GB。用 RTX 4090 24 GB 跑量化版本，还能留出充裕的上下文空间。
• 30B 到 34B 的模型：FP16 下大约 68 GB，4-bit 下接近 20 GB——这正是 RTX 5090 32 GB 的用武之地。
• 70B 的模型：FP16 下大约 140 GB，4-bit 下大约 40 GB。这意味着需要一块 A100 或 H100 80 GB，如果要用全精度，就得不止一块显卡。
• 长上下文放大的是 KV 缓存，而不是权重。一个大模型开到 128k token 的上下文窗口，光是 KV 缓存就可能需要几十 GB——这笔账要在下单前算清楚，而不是下单之后。

选择 GPU：从 A4000 到 H100，以及什么时候按小时计费比按月更划算

GPU 服务器系列的每个套餐，给到的都是一整块物理显卡及其全部显存——没有 MIG 分区，也不分时共享——所以规格表上写的数字，就是你能实打实用满的数字。挑显卡时要匹配你打算实际部署的模型，而不是你哪天可能想试试的模型。

• RTX A4000 16 GB，$89/mo——8 vCPU 和 64 GB 内存。足以支撑一个量化后的 7B 到 13B 助手、一个 embedding 服务，或一条整天运行的分类流水线。
• RTX 4090 24 GB，$189/mo——16 vCPU、128 GB 和 2 TB NVMe。对于 4-bit 的 13B 到 34B 模型来说，这是每 token 性价比最高的选择，也是小型生产端点的常见之选。
• RTX 5090 32 GB，$279/mo——24 vCPU 和 192 GB。多出来的这 8 GB，往往就是一个 34B 模型能不能装下真实上下文的分水岭。
• A100 80 GB，$690/mo——32 vCPU、256 GB 和 4 TB NVMe。HBM2e 带宽，加上足够的显存，可以在 4-bit 下为 70B 模型提供较长的上下文窗口，也能支撑高强度的批量推理服务。
• H100 80 GB，$1190/mo——48 vCPU、384 GB、8 TB NVMe，以及一个 10 Gbps 端口。FP8 支持加上 HBM3 带宽，让它成为追求高吞吐量或做训练时唯一说得通的选择。

计费方式是按小时或按月从同一笔预付余额中扣除，这一点对成本核算的影响，比大多数人以为的要大得多。一次只需要两个下午的评估任务，用 H100 跑的话，付的是运行的那几个小时，而不是一整个月。而一个凌晨三点也得随时应答的聊天端点，需要的是按月的主机。如果你需要在一台机器里塞下好几块显卡，或者需要一块 GPU 搭配大量本地存储，独立服务器是更合适的形态——用加密货币付款的通用做法，参见用加密货币租用 GPU 服务器。

分步指南：从加密货币充值到端点上线运行

1. 01用一次性邮箱注册账户只需邮箱和密码。不需要姓名、电话或证件，我们这边也就没有任何东西能把你运行的模型和你本人关联起来。
2. 02用加密货币为余额充值用比特币、门罗币或另外 8 种币种为预付余额充值。余额永不过期，也不会被冻结。
3. 03在 CUDA 镜像上部署 GPU 实例选择显卡型号、地区，以及预装最新驱动和 PyTorch 的 CUDA 就绪镜像。主机几分钟内即可就绪。
4. 04在拉取任何内容之前，先确认显卡可见一条 nvidia-smi 命令，就能报告 GPU 型号、驱动版本和空闲显存。这个十秒钟的检查，能省下一个小时的排查功夫。
5. 05把权重拉取到本地 NVMe 上把模型下载到实例自己的磁盘上，而不是网络挂载盘。权重文件动辄几十 GB，你也会不止一次加载它。
6. 06启动服务并绑定到 localhost在 127.0.0.1 上启动 vLLM 或 Ollama，先在本地确认能正常完成一次推理，再决定如何从外部访问它。

vLLM、Ollama 还是 llama.cpp：如何选择推理服务栈

三套技术栈几乎覆盖了所有场景，该选哪一个，取决于这个端点将会承受多大的请求量，而不是哪个技术上看起来最亮眼。

• Ollama——从零到可用端点最短的路径。一条命令就能拉取一个量化模型，并通过兼容 OpenAI 的 API 把它服务起来。适合单人使用、原型验证，或是私人助手。
• vLLM——面向生产环境的答案。连续批处理（continuous batching）和分页注意力（paged attention）让单块显卡就能同时服务大量并发请求，吞吐量是朴素循环实现的好几倍。这就是"只给自己用的端点"和"给应用程序用的端点"之间的差别。
• llama.cpp——实用主义的选择。支持低至 4-bit 甚至更低的 GGUF 量化，能把装不下的层卸载到 CPU，三者之中显存门槛最低。它能让一个明显偏大的模型，在一块明显偏小的显卡上也能跑起来。
• TGI、SGLang 和 TensorRT-LLM 在特定场景下还能更快。等你实际测出瓶颈之后再考虑它们，而不是提前上手。

这三者都提供兼容 OpenAI 的 chat-completions 接口，所以原本针对某个商业 API 编写的应用代码，通常只需要改一下 base URL，其他什么都不用动。正是这种兼容性，让自托管从一个"项目"变成了一个"配置选项"。

保持端点私密：绝不暴露推理端口

一台没有身份验证的推理服务器，就是当代版的"不设密码的公开数据库"。扫描器几个小时内就能找上新出现的 IP，一个暴露在外的端点，意味着别人在替你消耗 GPU 时长——或者在读取你的应用程序通过它发送的一切内容。

如果这个端点确实必须公开——它是一个产品，而不是私人助手——那就在反向代理这一层终止 TLS，要求使用会定期轮换的 bearer token，并按密钥做速率限制。把这个代理放在一台单独的小型 VPS 上，让 GPU 主机只能通过隧道访问，是更干净的架构。这和无需 KYC 托管的网站是同一个道理：直接面向公网的那台机器，应该尽可能少存放东西。

微调：什么时候一个下午的租用显卡比包月账单更划算

微调是"租用"优于"订阅"的最有力论据。对一个 7B 到 13B 的模型做 LoRA 或 QLoRA——几千条样本、寥寥几个 epoch——在一块 4090 上几个小时就能跑完，花的钱正好是运行的那几个小时。跑出来的适配器（adapter）只有几百 MB，你可以把这个检查点保存下来，销毁实例，之后再把这个适配器加载到一块更小的显卡上做推理服务。对 70B 模型做全参数微调是另一个量级的预算，需要一块留有优化器状态空间的 A100 或 H100，但即便如此，也是以天为单位来衡量的，而不是靠一份合同。

按小时计费所支持的工作流程很简单：部署、训练、把适配器复制出主机，然后销毁它。你只需为用到的算力付费，中间不会有一块闲置的显卡在空耗成本。工作期间把数据集放在实例的 NVMe 上，完成后再取回本地——留在租用机器上的东西，永远不应该是唯一的副本。

诚实地说：不属于你自己的 GPU，隐私上要付出什么代价

自托管去掉了那个最大、也最实际的泄露源：一个会接收你每一条提示词、按某个留存期限保存它、并自行决定拿它做什么的第三方。在一块租来的显卡上，模型和你的数据都待在一台只听命于你的密钥的机器里。租用去不掉的，是主机商本身。任何能物理接触到一台正在运行的服务器的人，原则上都能读取它的内存；远程机器上的全盘加密，防得住的是被偷走的硬盘，防不住正在运行中的那一台。

所以真正有意义的问题不是"主机商能不能看到"，而是"主机商知不知道我是谁"。无 KYC 主机能彻底解决这一点：一个邮箱、一个密码，无需验证，也没有任何资料可供索取或泄露。用加密货币余额付款，则去掉了银行这一环。支付这一侧要做到什么程度，取决于你的威胁模型——比特币是化名制，不是匿名的，追溯到已实名验证的交易所的币，最终还是能牵出线索，而用门罗币充值能在协议层面补上这个漏洞。

那些悄悄浪费 GPU 时长的错误

• 只按权重大小估算，忘了 KV 缓存，结果模型顺利加载，却在第一个长请求上直接崩溃。
• 出于一种没人真正实测过的质量担忧，用 FP16 去跑一个本可以用 4-bit、以三倍上下文运行同一模型的显卡。
• 把四十 GB 的权重下载到网络挂载盘上，然后纳闷为什么每次重启都要花二十分钟。
• 以"只是想从自己笔记本电脑测试一下"为由，把服务绑定在 0.0.0.0 上，结果在公网 IP 上当天就被扫到。
• 为一块每天有二十个小时都在闲置的显卡按月付费，而这个工作负载其实从头到尾都只是个批处理任务。
• 用一次只发一个请求的方式做基准测试，得出"vLLM 不值得折腾"的结论，却没意识到它的全部优势都体现在并发场景下。

这些都不是什么稀奇古怪的故障，而是在模型选定之前就先选好了显卡时，自然会发生的事情。先定好模型和量化方案，老老实实把显存账算清楚，把端口关好，自托管的 LLM 就会是少数几件你可以放心一直运行、几乎不用操心的事情之一。