开源大模型能力越来越强之后，越来越多企业开始认真考虑：与其把敏感数据发给云端 API，不如把模型自己托管起来。像 GLM 5.2 这类采用 MoE（混合专家）架构的开源模型，正是这波私有化部署的主角。但"把模型下下来跑起来"和"稳定支撑线上业务"之间，隔着硬件选型、推理框架、性能调优和成本核算四道坎。这篇文章梳理自托管的决策要点，帮你判断这条路是否适合自己、以及怎么走更稳。
先算清楚：自托管到底适合谁
自托管的核心价值有四个，但每一个都对应特定的适用前提，不是所有团队都划算：
- 数据不出域：所有业务文本、代码、文档都留在自有服务器，满足金融、政务、医疗等对数据合规有硬性要求的场景。如果你的业务本身没有这类监管约束，这条价值会打折。
- 可深度定制：能基于私有知识库对模型做微调，适配行业术语和业务流程，这是通用云端模型难以做到的。
- 长期成本可控：在高频、大用量场景下，硬件摊销加电费的总成本可能低于按量计费的云端 API；但用量不大时，结论往往相反。
- 性能自主：可以按并发情况自行调整显卡和批处理参数，不受云端高峰限流影响。
一句话判断：强合规需求 + 稳定的高 Token 用量，自托管才真正划算；否则云端 API 或订阅方案通常更经济。
硬件选型：MoE 的显存账不能算错
MoE 架构最容易被误解的一点，是它的显存需求。MoE 每次推理只激活一部分专家，这降低的是每个 token 的计算量，从而提升吞吐；但显存必须容纳全部参数，因为所有专家权重都要常驻 GPU 内存。换句话说，别拿"激活参数量"去估显存，要按"总参数量"算。
显存的基础算法很直接——参数量乘以每参数字节数：
- BF16/FP16：每参数 2 字节；
- FP8/INT8：每参数 1 字节；
- INT4（AWQ/GPTQ）：每参数约 0.5 字节。
对一个总参数达数百 B 到上千 B 的前沿 MoE 模型来说，即便按 FP8 计算，权重本身也要数百 GB 到上千 GB 显存，属于典型的多卡、甚至多节点部署。落到量化档位的选择上，有一条被反复验证的经验：
- FP8：在 Hopper/Blackwell 这类新架构 GPU 上近乎无损，是高吞吐生产部署的事实标准，绝大多数线上业务优先选它；
- INT8：在不支持 FP8 的 Ampere 老卡上是替代选择，精度损失通常只有百分之几；
- INT4（W4A16）：显存约为 FP16 的四分之一、FP16 的一半左右（4-bit GGUF 实际略高于理论值），精度大约有 3%~5% 的下降，适合延迟敏感、低批量、预算有限的场景。
还有两个常被漏算的点：一是权重不是显存的全部，KV 缓存会随上下文长度和并发线性增长，长上下文场景下它甚至可能超过权重本身，选型时要预留至少两成余量；二是多卡通信，大模型跨卡推理时，NVLink/NVSwitch 这类高速互联能显著降低通信瓶颈，缺了它多卡延迟容易飙升。
选型的实际操作是：先试能装下的最高精度，装不下再逐档降。FP16 装不下就退 FP8，FP8 还紧张就上 INT4 量化。
推理框架：vLLM 与 SGLang 怎么选
vLLM 和 SGLang 是当前适配开源大模型最主流的两套推理框架，底层的缓存和批处理逻辑不同，适配的业务场景也不一样。
vLLM 的核心是 PagedAttention，把 KV 缓存当作虚拟内存分页管理，显存利用率高，通用问答和批量文本任务的兼容性强。它的 PagedAttention 用 C++/CUDA 实现，在高并发下能更好地利用多核、规避 Python GIL 争用，所以当并发压力很大、需要靠并行度把 GPU 喂满时，vLLM 往往更稳。
SGLang 的核心是 RadixAttention，在分页缓存基础上加了前缀缓存——用基数树按 token 前缀组织缓存块，多个请求共享同一段前缀（比如相同的系统提示、RAG 文档、多轮历史）时可以直接复用。它的优势场景很明确：
- 对前缀重叠多的工作负载（共享系统提示、RAG、多轮 Agent），首 token 延迟（TTFT）可显著降低；
- 多轮对话和智能体循环任务中，缓存复用让批量更大、跳过重复预填充，吞吐相对 vLLM 有明显优势；
- 原生支持结构化 JSON、SQL 输出，更贴合 Agent 自动化场景。
需要提醒的是：对没有前缀重叠的独立请求，RadixAttention 的优势基本消失，性能与 vLLM 相当；而在极高并发下，SGLang 基于 Python 的路由可能受 GIL 制约。
选型结论因此很清晰：通用问答、高并发在线服务偏向 vLLM；多轮对话、RAG、Agent 编排这类前缀复用密集的场景偏向 SGLang。两者可以用同一份模型权重，切换成本不高，值得按实际流量特征做一次压测再定。
通用的性能优化手段则跨框架适用：开高显存利用率参数、非核心业务切低量化档、长对话启用上下文/前缀缓存减少重复 token、合理设置批处理上限、长文本开启分段预填充。
成本核算：找到自托管的盈亏平衡点
自托管的成本主要由三块构成：GPU 硬件按几年折旧的月度摊销、满载运行的电费、以及服务器托管加运维人力。这三项相加，就是每月的固定支出。云端 API 则按输入/输出 token 单价计费，是纯变动成本。
两者的关系决定了决策：
- 当月度云端 API 费用 ≈ 自托管固定支出时，对应一个 token 用量的临界点；
- 用量长期稳定高于这个临界点，自托管更省；低于或波动大，云端订阅/按量更划算。
具体数字会随硬件价格、电价、模型单价大幅波动，不必套用别人的账本，而应用自己的真实月度 token 用量代入测算。几条通用的降本策略值得参考：非工作时段关闭推理服务、非核心业务切低量化档缩减硬件规模、多个模型共用一套 GPU 集群提升利用率。
更务实的落地形态：混合架构
对多数企业来说，纯自托管或纯云端都不是最优解，"核心敏感业务本地自托管 + 弹性/轻量需求走云端"的混合架构往往更平衡。核心业务、合规数据在本地私有化运行；对外营销、临时测试、突发流量则用云端 API 或订阅方案弹性补充，既避免本地集群闲置浪费，也不用为峰值长期备着冗余算力。
按场景给几条选型建议：
- 强合规 + 大用量：FP8 量化多卡自托管，承载核心业务；
- 中小团队日常办公/编码、预算有限：INT4 量化少卡本地部署，够用且省；
- 短期项目、临时测试、用量极低：直接用云端 API 或订阅，不必自建 GPU 集群；
- 只需消息机器人、简单提醒：轻量服务器跑个智能体框架、对接云端模型即可。
自托管开源大模型不是一道"要不要跟风"的选择题，而是一道结合数据合规要求、月度用量和业务复杂度的成本-收益计算题。把显存账算准、按流量特征选对推理框架、用真实用量测出盈亏平衡点，再决定本地、云端还是混合，才是稳妥的落地路径。