自托管模型

自托管（self-hosting）把按 token 计费的成本变成一笔固定的基础设施开销，同时把和厂商的关系变成一个运维问题。

这两半都重要。做决定时通常只看到前半段，后悔则是因为后半段。

三个站得住的理由

**数据不能出去。**监管、合同或数据驻留要求，任何厂商条款都满足不了。这是最硬的理由，也是成本在此完全不是重点的那一个。

**规模经济。**在持续高吞吐量下，固定硬件比按 token 计价更划算。这个临界点其实相当高——在假定自己已经越过它之前，先把下面那笔账算一遍。

**控制权。**权重固定，不会在你脚下被换掉；没有静默的模型更新；没有速率限制；可以随意微调。

站不住的理由：感觉更便宜（低用量时通常并不便宜）、模型是免费的（GPU 不是）、以及看起来更专业。

显存这笔账

先算这个，别的都往后放。三块：

**权重。**参数个数乘以每个参数的字节数。16 比特下，一个 70B 模型约 140 GB；量化到 4 比特后大约 35 GB。

**KV cache。**随序列长度 × 层数 × 头数 × 并发请求数增长。在长上下文加真实并发的情况下，它经常超过权重本身，而这一块恰恰是大家最容易忘的。

**额外开销。**激活值、框架本身、显存碎片。要留出余量。

实际后果是：一个装得下的模型，可能只撑得住少量并发的长上下文请求。决定容量的是 cache，不是权重能不能加载进来。

在显存相同的前提下，更大的量化模型通常胜过更小的全精度模型——4 比特的 70B 一般强过 16 比特的 13B。这是量化带来的最主要的决策空间。

老实算成本

要拿总持有成本去和按 token 计价比，而不是拿 GPU 租金去和按 token 计价比。

硬件或实例成本，不管你那边有没有流量进来，这笔钱都要付。这就是关键：托管 API 空闲时不花钱，自托管凌晨三点也照付全价。

**利用率。**平均利用率只有 10% 的 GPU，其单位 token 成本比它标称的费率贵 10 倍。突发型流量正是自托管的经济账崩掉的地方。

**工程时间。**搭建、调优、监控、升级、故障响应。这一项成本被系统性低估，而且上线之后也不会结束。

**冗余。**一台机器就是一个单点故障。要真正可用至少得两台，硬件成本翻倍。

大致结论：自托管在稳定高流量下划算，在突发或低流量下不划算。如果你的流量有昼夜周期、峰谷比 10 倍，你就得按峰值来配置，然后在谷底时白付这笔钱。

你得运维哪些东西

一个服务化框架，不是一份训练脚本。生产环境的推理需要连续批处理、分页注意力、前缀缓存——正是这些特性把一套服务系统和「循环里调 generate()」区分开来。别自己写。

**负载管理。**排队、准入控制和背压。没有这些，一次流量尖峰会让每一个请求都变慢，而不是丢掉一部分请求。

**监控。**GPU 利用率和显存、队列深度、首 token 延迟和每秒 token 数（要分开看），以及缓存命中率。见 LLM 系统的可观测性。

**升级。**新的模型版本意味着重新测 prompt、重跑评测。自托管并没有消除迁移工作，它只是让你自己挑什么时候做。

**权重来源。**你加载的是文件——见模型供应链风险。

中间选项

这不是个二选一的问题，而大多数项目应该落在中间。

**托管的开放权重端点。**厂商在自己的基础设施上提供开放模型。你可以选模型、可以钉版本，却不用自己运维 GPU，按 token 计费。这经常就是正确答案，也是最常被忽略的选项。

**向托管厂商购买独占容量。**预留吞吐量，有时还能拿到更严格的数据条款。

**混合路由。**敏感流量走自托管模型，其余走托管 API。既解决了数据驻留的诉求，又不用扛下全部流量。

**小模型本地跑，大模型托管。**分类和抽取放在普通的本地硬件上，难的推理送出去。这往往就是能拿到的最优成本结构。

要点回顾

• 三个成立的理由：数据驻留、持续的规模经济，以及对版本的控制权。
• 先算显存：权重加 KV cache 加额外开销——决定并发数的一般是 cache，不是权重。
• 显存相同时，更大的量化模型通常胜过更小的全精度模型。
• 要按你自己真实的利用率去比总持有成本；空闲的 GPU 照收全价，突发流量会让这本账彻底不成立。
• 你必须运维一套真正的服务化框架、负载管理、监控和升级——工程时间是最被低估的那项成本。
• 托管的开放权重端点和混合路由，能拿到大部分好处，却不用背运维。

你已经走到这条路径的尽头。路线图里有完整的地图，想回看某一层随时可以翻。