万亿参数大模型本地部署教程与预算测算

1. 教程目标：完成一次可落地的本地部署评估

本教程的目标，是帮助读者围绕“本地部署万亿参数级稀疏大模型”这一任务，完成一套可执行的技术评估与部署流程。具体来说，读者最终应能够回答以下几个问题：

1. 该模型是否可以在本地或自有云环境中运行；
2. 至少需要多少 GPU 显存、多少张卡、什么级别的服务器；
3. 从“能启动”到“可稳定推理”之间，还需要哪些工程准备；
4. 单人使用、多人并发使用时，性能指标应如何验证；
5. 采购、租用、运维和长期使用的成本大致如何估算；
6. 遇到显存不足、吞吐不足、启动失败等问题时，应如何排查。

需要强调的是，万亿参数级稀疏大模型并不等同于普通小模型。稀疏结构会降低单次推理时的计算量，但并不会显著降低模型权重的存储和驻留成本。因此，部署这类模型时，显存容量是第一道门槛，其次才是算力、带宽、调度和工程优化。

---

2. 适用场景：哪些业务适合本地部署这类模型

本地部署万亿参数级模型通常不是普通开发环境的选择，而更适合以下场景：

2.1 数据敏感型业务

如果业务数据不能出内网、不能上传到外部推理接口，或者涉及内部文档、代码、财务、法务、医疗、政务等敏感内容，本地部署是更可控的方案。

2.2 内网隔离环境

部分企业、研究机构或实验室要求模型推理服务运行在独立网络内，无法依赖公网服务。此时需要在本地或私有云环境中完成模型部署。

2.3 长上下文与高价值推理任务

对于长文档分析、复杂代码理解、合同审阅、知识问答、研究报告生成等任务，用户可能希望模型能够稳定运行在本地，以便针对上下文长度、并发数和输出质量做更细的优化。

2.4 批量离线任务

如果业务不是实时在线服务，而是夜间批处理、离线摘要、批量翻译、批量标注等任务，本地部署可以通过更大批量提高吞吐，降低单次请求的响应要求。

需要注意的是，如果团队只是希望快速接入大模型能力，且对数据隐私没有硬性要求，使用托管推理服务通常更轻量。本地部署更适合对数据边界、服务可控性和长期成本有明确要求的团队。

---

3. 前置知识：部署前必须理解的几个核心概念

在开始部署之前，建议读者先理解以下概念。否则，在选型、配置和压测阶段容易误判。

3.1 总参数与激活参数的区别

大模型通常有两个容易混淆的指标：

• 总参数：模型包含的全部权重数量；
• 激活参数：每生成一个 token 时，实际参与计算的那部分参数数量。

对于稀疏模型来说，激活参数通常远低于总参数，这会降低单次推理的计算量。但问题是，模型推理时并不是只加载“当前激活的那部分参数”。为了能够在不同输入、不同专家路由条件下随时调用，全部权重通常仍需要驻留在显存或可被快速访问的存储中。

因此，判断能否跑起来，不能只看激活参数，而必须优先看总参数和权重体积。

3.2 权重量化不是“免费压缩”

很多模型支持低比特权重，例如 4bit、8bit 等。低比特可以显著减少显存占用，但也要注意：

• 如果是模型原生设计的低比特权重，通常更符合模型训练目标；
• 如果是推理时临时从高精度权重量化得到的低比特权重，可能会损失部分精度；
• 如果硬件或推理框架不原生支持某种低比特格式，还可能需要运行时反量化，从而增加显存、计算和延迟开销。

因此，在本地部署时，需要确认服务器、驱动、推理框架和模型权重格式之间是否匹配。

3.3 KV Cache 会随上下文和并发增长

除了模型权重，推理过程中还需要为每个请求维护上下文状态。对于 Transformer 类模型，这部分通常体现为 KV Cache 或类似状态缓存。

KV Cache 的大小通常受以下因素影响：

• 上下文长度；
• 并发请求数；
• 模型层数；
• 注意力头数量；
• 每个头的维度；
• 缓存精度；
• 推理框架的内存复用策略。

所以，即使模型权重本身刚好能放进显存，也不代表可以无限增加上下文或并发。长上下文和多人并发会进一步吃掉显存。

3.4 多卡部署的关键不只是“卡够”

万亿参数模型通常无法用单张 GPU 完成加载，需要多卡并行。常见并行方式包括：

• 张量并行：把单个计算层拆分到多张卡上；
• 专家并行：针对稀疏模型中的专家模块进行拆分；
• 流水并行：把模型不同层分配到不同设备上；
• 数据并行：主要用于多请求或多副本场景。

对于本地部署来说，单机多卡通常比多机部署更简单，因为卡间通信延迟更低。如果必须跨机器部署，则需要高速网络互联，否则推理延迟和吞吐都可能受到明显影响。

---

4. 硬件容量测算：为什么“能跑”就已经是服务器级门槛

4.1 基础权重体积估算

以总参数约 2.8 万亿、每参数使用 4bit 存储为例，可以进行如下估算：

权重体积 = 总参数量 × 每参数比特数 ÷ 8
权重体积 = 2.8万亿 × 4bit ÷ 8
权重体积 ≈ 1.4TB

也就是说，仅模型权重本身，就已经接近 1.4TB 级别。

4.2 运行时还需要额外显存

除了权重，推理过程还需要额外显存用于：

• 请求上下文缓存；
• 中间激活值；
• 临时计算缓冲区；
• 通信缓冲区；
• 框架运行时开销；
• 并发调度队列；
• 可能的量化/反量化临时空间。

因此，不能只按权重体积规划显存。更稳妥的估算方式是：

单用户最小可用显存 ≈ 权重体积 + 运行时开销 + 上下文缓存 + 安全余量

对于该类模型，如果仅按单用户、较短上下文、低并发运行，通常至少应按约 1.5TB GPU 显存来规划。

4.3 理论卡数估算

如果只从显存容量角度估算，不考虑性能、通信和调度效率，可以这样算：

• 若单卡显存为 80GB：

1.5TB ÷ 80GB ≈ 19张

• 若单卡显存为 141GB：

1.5TB ÷ 141GB ≈ 11张

这说明，即使不考虑推理速度，仅仅是为了把模型装进显存，也需要接近十几张高端数据中心级 GPU。

4.4 为什么“装进去”不等于“跑得好”

容量够只是第一步。真正影响体验的还包括：

• GPU 是否支持原生低比特权重；
• 卡间互联带宽是否足够；
• 推理框架是否支持该模型的并行策略；
• 内存带宽是否足以维持生成速度；
• 上下文长度和并发数是否导致缓存膨胀；
• 是否存在频繁权重换入换出。

因此，最低容量配置可以作为“能否启动”的参考，但不能作为“能否稳定提供可用服务”的依据。

---

5. 三档部署目标：从能跑到多人并发

根据使用目标不同，本地部署这类模型可以分为三档。不同档位的重点不同，不能简单用“显存够”或“卡多”概括。

---

5.1 第一档：只要能跑，不关心速度

目标

这一档的核心目标是：让模型完成加载，并能对简单请求产生输出。用户可能只是做技术验证、内部演示或离线实验。

硬件判断

从容量角度看，理论最低配置可能是：

• 约 19 张 80GB 级别 GPU；
• 或约 11 张 141GB 级别 GPU。

但这只是容量层面的估算。若硬件不支持模型原生低比特权重，可能还需要运行时反量化，这会带来额外开销，甚至导致速度不可接受。

更现实的起点

更现实的“能跑”方案，通常是 8 卡级别的新一代高显存、高带宽推理服务器。原因在于：

1. 单卡显存越大，越容易在较少卡数内完成权重加载；
2. 单机 8 卡部署比多机部署更容易管理；
3. 新一代推理硬件通常对低比特权重有更好支持；
4. 主流推理方案的公开部署建议，也倾向于采用 8 卡级并行。

注意事项

即使只是“能跑”，也已经不是普通工作站项目。通常需要：

• 数据中心级 GPU；
• 多卡互联；
• 大容量系统内存；
• 高速本地存储；
• 稳定供电与散热；
• 服务器级运维能力。

---

5.2 第二档：单人使用，目标约 25 Token/s

目标

这一档不只是能启动，而是希望单个用户能够获得相对可接受的生成速度，例如约 25 Token/s。

硬件判断

硬件起点仍然建议从 8 卡级高显存推理服务器考虑。原因不是算力不够，而是模型权重必须先完整放入显存。用户数量少，并不能降低权重驻留要求。

也就是说，不能因为“只有一个人用”，就把服务器缩到两三张卡。显存容量是硬约束。

能否稳定达到 25 Token/s

是否能在单人场景稳定达到 25 Token/s，取决于多种因素：

• 上下文长度；
• 输入和输出长度；
• 是否开启流式输出；
• 是否使用批处理；
• 张量并行或专家并行配置；
• 卡间通信效率；
• 推理框架调度策略；
• 模型权重格式是否原生支持。

因此，不能仅凭硬件配置直接保证速度。上线前必须按实际业务上下文长度进行压测。

合理预期

单路大模型推理通常处于“每秒数十 Token”的量级。对于本地部署的超大模型，25 Token/s 是一个相对合理但需要验证的目标。若上下文很长，或输出并发更高，实际速度可能下降。

---

5.3 第三档：10 并发，每人约 25 Token/s

目标

这一档要求系统在 10 个并发请求下，仍能维持较好的单请求体验。如果每个用户都要求约 25 Token/s，则聚合输出能力至少需要达到：

10 × 25 Token/s = 250 Token/s

显存是否要翻倍

不一定。显存配置未必需要比第二档显著增加。原因是：

• 模型权重是共享的，不会因为并发增加 10 倍就重复加载 10 份；
• 只要权重已经驻留显存，多请求可以共享同一份模型；
• 主要变化是每个请求的上下文缓存和调度开销会增加。

在一些部署方案下，一台 8 卡级节点可以处理数十个并发请求。如果上下文不是百万级，理论可驻留请求数还会更多。

真正的瓶颈

10 并发的关键问题不是“能不能装下请求”，而是：

1. 多路请求同时生成时，能否保持调度公平；
2. 每一路请求是否能维持 25 Token/s；
3. 长上下文请求是否会挤占其他请求的缓存；
4. 队列是否积压；
5. 首 Token 延迟是否可接受；
6. GPU 利用率是否长期饱和。

因此，10 并发场景必须做真实压测，不能只根据显存容量推算。

---

6. 部署前准备：硬件、软件、模型和网络

6.1 硬件准备

建议至少准备以下硬件能力：

组件	建议关注点
GPU	数据中心级、高显存、高带宽、支持多卡并行
显存总量	至少覆盖 1.4TB 权重，并预留 1.5TB 左右运行空间
卡间互联	支持高速卡间通信，降低并行推理延迟
系统内存	足够大，便于权重加载、页缓存和临时缓冲
存储	高吞吐本地存储，避免模型加载过慢
网络	若多机部署，需要高速网络互联
电源与散热	满足长时间满载推理需求
监控	可观察 GPU 显存、利用率、温度、功耗和错误日志

如果是云平台部署，需要在云服务控制台确认实例规格、GPU 数量、显存容量、网络带宽、存储性能和可预留周期。

6.2 软件准备

通常需要准备：

• 主流服务器操作系统；
• GPU 驱动与设备管理组件；
• 容器运行时或进程管理工具；
• 推理服务框架；
• 模型加载与并行推理支持组件；
• 日志与监控组件；
• 模型文件校验工具；
• 必要的安全访问控制组件。

不同推理框架对模型格式、并行策略和量化支持不同，部署前需要确认兼容关系。

6.3 模型准备

模型文件通常包括：

• 权重分片；
• 模型配置；
• 分词器或输入输出处理配置；
• 并行配置；
• 量化配置；
• 可能的路由配置或专家配置。

下载后需要检查：

1. 文件数量是否完整；
2. 文件大小是否与预期一致；
3. 校验值是否匹配；
4. 权重格式是否与推理环境兼容；
5. 是否支持原生低比特加载；
6. 是否需要额外模板或配置文件。

6.4 网络与安全准备

如果服务会被多人访问，还需要准备：

• 内网域名或服务地址；
• 访问鉴权机制；
• 日志记录；
• 请求限流；
• 超时控制；
• 健康检查接口；
• 监控告警；
• 备份与恢复机制。

---

7. 实施步骤：从环境准备到服务启动

下面给出一套通用的部署步骤。不同推理框架的具体命令可能不同，但整体流程相近。

---

步骤一：明确部署目标

先确定属于哪一档：

• 只做技术验证；
• 单人日常使用；
• 多人并发使用；
• 离线批量任务；
• 长上下文推理任务。

不同目标会影响：

• 卡数选择；
• 上下文长度设置；
• 并发上限；
• 批大小；
• 是否需要多副本；
• 是否需要监控告警。

建议先以最小目标启动，例如“单用户可生成输出”，再逐步压测并发和速度。

---

步骤二：准备 8 卡级推理服务器

如果目标是可稳定推理，建议优先选择单机 8 卡级服务器。

原因如下：

1. 单机部署减少跨机通信复杂度；
2. 卡间互联更容易优化；
3. 运维成本低于多机集群；
4. 推理框架通常更容易支持单机多卡并行；
5. 对中小团队更友好。

如果单机无法满足显存或吞吐要求，再考虑多节点部署。多节点部署需要重点关注：

• 节点间网络带宽；
• 网络延迟；
• 并行通信效率；
• 分布式存储性能；
• 故障恢复能力。

---

步骤三：安装基础环境

在服务器上安装并确认以下组件：

1. 操作系统；
2. GPU 驱动；
3. 容器运行时或进程管理环境；
4. 推理框架；
5. 必要依赖库；
6. 监控组件。

安装完成后，应确认：

• 所有 GPU 能被系统识别；
• 每张 GPU 的显存容量正确；
• GPU 之间通信正常；
• 用户权限足够；
• 容器或进程可以访问 GPU 设备；
• 日志输出正常。

---

步骤四：部署模型文件

将模型文件放到高速存储中，例如本地 NVMe 盘或高吞吐云盘。建议目录结构如下：

/data/models/large-sparse-model/
├── model_config
├── tokenizer
├── weights/
│   ├── shard-00001
│   ├── shard-00002
│   └── ...
└── deploy/
    └── service_config.yaml

注意：

• 不要从低吞吐网络盘直接加载超大权重，否则启动时间会很长；
• 权重目录权限应正确；
• 配置文件应版本化管理；
• 模型文件应记录版本号和校验值。

---

步骤五：编写推理服务配置

不同推理框架的字段名可能不同，但通常都需要配置：

• 模型路径；
• 权重格式；
• 并行度；
• 上下文长度；
• 最大并发序列数；
• 最大批 token 数；
• 显存利用率；
• 日志级别；
• 服务监听地址和端口。

下面是一个示意性配置，仅用于说明结构，不代表某一具体工具的固定语法：

model:
  path: "/data/models/large-sparse-model"
  weight_format: "native-4bit"
parallel:
  tensor_parallel_size: 8
  expert_parallel_size: 1
context:
  max_model_len: 32768
scheduler:
  max_num_seqs: 16
  max_batch_tokens: 65536
memory:
  gpu_memory_utilization: 0.90
logging:
  level: "info"
server:
  host: "0.0.0.0"
  port: 8080

---

步骤六：启动服务

使用推理服务提供的启动方式加载配置。伪代码形式如下：

start_inference_server --config /data/models/large-sparse-model/deploy/service_config.yaml

启动后应观察：

1. 模型是否完成加载；
2. 是否所有 GPU 都参与服务；
3. 显存占用是否稳定；
4. 是否出现驱动或设备错误；
5. 是否出现权重格式不兼容；
6. 是否出现通信超时；
7. 日志中是否有异常退出。

首次启动可能需要较长时间，尤其是权重分片较多或存储带宽不足时。

---

步骤七：单机功能验证

先不要直接压测，应进行基础功能验证：

1. 发送一个短提示词；
2. 确认服务能返回文本；
3. 确认返回内容不是空；
4. 确认流式输出是否正常；
5. 确认显存占用是否稳定；
6. 确认没有频繁报错；
7. 确认服务接口可以正常关闭和重启。

示例请求伪代码：

{
  "prompt": "请用三句话解释什么是模型量化。",
  "max_tokens": 128,
  "stream": true
}

如果基础请求都无法完成，不要进入并发压测阶段。

---

步骤八：性能压测

性能压测应分梯度进行，例如：

压测阶段	并发数	观察目标
基线测试	1	单请求延迟和生成速度
轻并发	2	是否存在队列延迟
中并发	5	显存和吞吐是否稳定
目标并发	10	是否能维持目标速度
极限测试	大于目标并发	系统是否会拒绝服务或崩溃

压测指标建议包括：

• 首 Token 延迟；
• 每秒输出 Token 数；
• 单请求平均耗时；
• P50、P95、P99 延迟；
• 聚合吞吐；
• GPU 显存占用；
• GPU 利用率；
• 显存缓存增长；
• 队列长度；
• 错误率；
• 服务是否重启。

---

8. 配置说明：关键参数如何理解

8.1 模型路径

用于指定权重和配置文件所在目录。路径应位于高速存储上，避免网络盘拖慢加载速度。

8.2 权重格式

用于说明模型权重是原生低比特格式，还是需要反量化或重新转换。

风险点：

• 格式不匹配可能导致启动失败；
• 强制转换可能增加延迟；
• 非原生量化可能影响输出稳定性。

8.3 并行度

常见配置包括张量并行、专家并行等。

建议：

• 优先使用推理框架推荐的默认并行策略；
• 不建议随意修改并行度；
• 并行度过高可能增加通信开销；
• 并行度过低可能导致显存不足。

8.4 最大上下文长度

该参数决定单请求最多可处理多少 token。上下文越长，KV Cache 越大，显存占用越高。

建议：

• 初期可设置较短上下文进行验证；
• 根据业务需求逐步增加；
• 长上下文场景需要单独压测；
• 不要只按模型理论支持的最大上下文直接上线。

8.5 最大并发序列数

该参数决定同时驻留多少请求。

风险：

• 设置过高可能导致显存不足；
• 设置过低可能降低吞吐；
• 长上下文请求会显著增加缓存压力。

8.6 最大批 token 数

用于控制一次调度中处理的 token 总量。

风险：

• 过大可能导致单批延迟升高；
• 过小可能导致 GPU 利用率不足；
• 需要根据上下文长度和并发数调整。

8.7 显存利用率

用于控制推理框架可使用显存的比例。

建议：

• 不建议直接设置过高；
• 需要为临时缓存和通信缓冲保留余量；
• 多并发场景下可适当降低该值，避免 OOM。

---

9. 成本测算：本地部署到底要花多少钱

成本不只是 GPU 费用，还包括服务器、存储、网络、电力、运维和人力成本。

9.1 租用成本示例

如果通过云平台租用数据中心级 GPU 实例，价格通常以“每 GPU 每小时”或“整机每小时”计算。

以某类云平台 12 个月预留价格为例，假设某型数据中心 GPU 的价格约为：

4.76 美元 / GPU / 小时

如果采用 8 卡节点，则每小时成本为：

4.76 × 8 = 38.08 美元 / 小时

按月计算，若每月按 730 小时估算：

38.08 × 730 ≈ 27798.4 美元 / 月

按年计算，若每年按 8760 小时估算：

38.08 × 8760 ≈ 333580.8 美元 / 年

这只是 GPU 计算实例的基础成本，不包括：

• 高性能云盘费用；
• 对象存储费用；
• 网络流量费用；
• 负载均衡费用；
• 监控日志费用；
• 备份费用；
• 运维人力成本；
• 安全与合规成本。

9.2 采购成本

如果选择自建服务器，成本包括：

1. GPU 采购费用；
2. 服务器整机费用；
3. 高速网络费用；
4. 存储设备费用；
5. 机房空间；
6. 电力成本；
7. 散热成本；
8. 硬件维保；
9. 备件库存；
10. 运维团队成本。

自建方案在长期使用、数据完全本地化方面更有优势，但初始投入高，部署周期也更长。

9.3 成本优化建议

可以从以下方面降低成本：

• 使用预留实例而不是长期按量付费；
• 非高峰时段释放资源；
• 将离线任务集中在夜间批处理；
• 降低上下文长度，减少缓存开销；
• 合理设置并发上限，避免过度预留；
• 将模型加载与推理服务分离；
• 使用高吞吐存储减少启动等待；
• 对日志和监控进行冷热分层；
• 定期压测，避免资源长期空置；
• 根据业务优先级设置队列和限流。

---

10. 结果验证：如何判断部署是否成功

部署成功后，应通过多个维度验证，而不是只看“能返回文本”。

10.1 功能验证

检查项：

• 模型能正常加载；
• 服务端口可访问；
• 简单提示词能返回结果；
• 长文本输入不立即报错；
• 流式输出正常；
• 错误请求有明确提示；
• 服务重启后仍可正常启动。

10.2 显存验证

检查项：

• 权重加载后显存是否稳定；
• 单请求是否导致显存异常增长；
• 多请求是否出现 OOM；
• 长上下文是否导致缓存爆炸；
• 显存利用率是否过高；
• 是否存在频繁回收和重新分配。

10.3 性能验证

检查项：

• 单请求生成速度；
• 首 Token 延迟；
• 多并发下是否仍能维持目标速度；
• 聚合吞吐是否达到预期；
• 队列是否积压；
• P95 延迟是否可接受。

10.4 稳定性验证

检查项：

• 连续运行数小时是否稳定；
• 是否出现进程崩溃；
• 是否出现 GPU 掉卡；
• 是否出现通信超时；
• 是否出现日志异常；
• 是否能自动恢复。

---

11. 常见问题与排查思路

11.1 模型无法加载

可能原因：

1. 显存不足；
2. 权重文件损坏；
3. 模型配置不匹配；
4. 权重格式不被支持；
5. 驱动或推理框架版本不兼容；
6. 存储路径权限错误。

排查思路：

• 检查权重文件数量和校验值；
• 检查配置文件和权重目录是否匹配；
• 降低并行度或上下文长度再测试；
• 查看启动日志中的第一个错误；
• 确认推理框架是否支持该模型格式；
• 确认 GPU 设备是否全部被识别。

11.2 启动速度很慢

可能原因：

1. 权重分片过多；
2. 存储吞吐不足；
3. 从网络盘加载模型；
4. 模型文件未做本地缓存；
5. 并行初始化耗时过长。

优化思路：

• 将模型放到本地高速存储；
• 减少不必要的模型转换；
• 使用更快的云盘或本地 NVMe；
• 对权重目录进行预热；
• 避免多实例同时加载同一份模型。

11.3 单请求生成速度慢

可能原因：

1. 上下文过长；
2. 输入输出 token 过多；
3. 批调度未优化；
4. 并行通信瓶颈；
5. GPU 显存带宽不足；
6. 推理框架未充分并行；
7. 低比特权重需要反量化。

排查思路：

• 缩短上下文长度测试；
• 关闭不必要的流式输出再对比；
• 查看 GPU 利用率是否饱和；
• 检查是否频繁等待通信；
• 对比不同并行配置下的速度；
• 确认是否原生支持当前权重格式。

11.4 并发升高后速度明显下降

可能原因：

1. 并发超过调度能力；
2. KV Cache 占用过高；
3. 队列积压；
4. 单请求 token 数差异过大；
5. 长上下文请求挤占资源；
6. 网络或前端代理成为瓶颈。

优化思路：

• 设置最大并发上限；
• 对请求进行分级；
• 限制单请求最大上下文；
• 增加批调度优化；
• 使用队列和超时控制；
• 将长任务和短任务分流。

11.5 偶发 OOM

可能原因：

1. 显存利用率设置过高；
2. 并发突增；
3. 长上下文请求叠加；
4. 缓存未及时释放；
5. 监控未覆盖显存峰值。

排查思路：

• 降低显存利用率；
• 降低最大并发；
• 降低最大上下文；
• 设置请求限流；
• 观察 OOM 发生前的请求模式；
• 增加监控告警。

11.6 输出质量不稳定

可能原因：

1. 权重文件不完整；
2. 量化格式不匹配；
3. 推理参数异常；
4. 上下文截断；
5. 模板或提示词配置错误；
6. 并行策略导致结果异常。

排查思路：

• 校验权重文件；
• 使用标准配置重新加载；
• 缩短输入验证；
• 对比不同上下文长度；
• 检查是否错误截断；
• 确认分词器和模板配置正确。

---

12. 优化建议：从能跑到稳定生产

12.1 性能优化

• 优先选择原生支持的低比特权重；
• 保持合理的并行度；
• 避免过度追求最大上下文；
• 对短请求和长请求分流；
• 使用批量推理提高离线吞吐；
• 监控 P95 延迟，而不是只看平均值；
• 对热点提示词进行缓存或复用。

12.2 稳定性优化

• 增加健康检查；
• 设置请求超时；
• 增加队列长度限制；
• 对异常请求快速失败；
• 对服务进程增加自动重启；
• 对 GPU 温度和功耗做监控；
• 对显存和队列水位设置告警。

12.3 安全优化

• 服务不要直接暴露公网；
• 使用内网访问或反向代理；
• 增加身份认证；
• 设置访问白名单；
• 记录请求日志和审计日志；
• 对敏感输入进行脱敏；
• 对模型文件做完整性校验；
• 对管理接口设置强权限。

12.4 可维护性优化

• 配置文件纳入版本管理；
• 模型版本与配置版本绑定；
• 保存每次部署的硬件参数；
• 记录压测结果；
• 建立故障排查手册；
• 将模型加载、推理服务、监控告警拆分为独立模块；
• 定期回归测试。

12.5 成本控制优化

• 非必要时不长期持有闲置 GPU；
• 将可预测任务放到预留实例；
• 将突发任务放到按量资源；
• 对低优先级任务设置队列延迟；
• 根据业务峰值决定副本数量；
• 避免为了“少量高峰”长期预留大量资源；
• 定期审查账单和资源使用率。

---

13. 总结：本地部署的关键判断标准

本地部署万亿参数级稀疏大模型，核心不是“能不能找到几张卡”，而是要先回答以下几个问题：

1. 权重是否能装下：总参数约 2.8 万亿、4bit 权重约 1.4TB，实际部署建议按 1.5TB 显存起步；
2. 硬件是否支持原生低比特推理：否则可能需要反量化，性能和稳定性都会受影响；
3. 单机 8 卡还是多机部署：单机 8 卡级方案通常更容易落地，多机部署需要高速网络；
4. 目标性能必须实测：单人 25 Token/s、10 并发每人 25 Token/s，都不能只靠显存容量推断；
5. 成本不只是 GPU 小时费：还包括存储、网络、运维、电力、机房和安全成本；
6. 部署完成后要持续验证：功能、显存、延迟、吞吐、稳定性和错误率缺一不可。

对于技术团队来说，建议按照“容量测算 → 环境准备 → 单机启动 → 功能验证 → 梯度压测 → 成本评估 → 优化上线”的顺序推进。这样可以避免一开始就陷入过度采购或错误选型，也能在真实业务压力下判断方案是否可持续。