E7 · 如何部署和运行开源模型？ - Model Deployment

所属知识库：Agent 全栈技术地图
所属领域：01 · AI
所属章节：03 · 如何使用和管理 AI 模型？ - Model Engineering
文档类型：技术原理与工程实践研究
版本：v2.0
更新日期：2026 年 10 月 27 日
核心问题：模型权重如何变成可访问的推理服务？如何选择模型、硬件、量化格式、推理框架和部署拓扑，并保障安全、性能与运维？

专题导读

当 AI 应用不再完全依赖第三方模型 API，而是希望在本地设备、私有服务器或云计算环境中自主运行模型时，如何将模型权重转化为稳定、可访问、可管理的推理服务，就成为模型工程的重要课题。

本篇围绕 Model Deployment（模型部署）展开研究，从模型文件、权重格式、Tokenizer 和推理运行时的基本组成出发，系统解释模型如何被加载到 CPU 或 GPU 中执行，以及模型参数、计算精度、KV Cache、上下文长度和并发请求如何共同决定计算资源需求。

在工程实践部分，比较 Transformers、llama.cpp 和 vLLM 等主要技术方案，研究模型选择、量化、硬件配置、服务部署、容器化和多 GPU 架构，并通过本地 GGUF 模型服务与 GPU 推理服务两个案例，展示从环境准备到 API 调用的部署过程。

最后进一步讨论模型服务的安全、监控、容量规划、成本与版本治理，说明自托管模型如何接入 Agent System，成为能够被统一调用、路由和管理的基础模型能力。

一、研究概述

E1 介绍托管模型 API，E6 讨论如何选择和路由不同模型。E7 研究另一条重要路径：在自己控制的计算环境中运行模型，并将其封装为服务。 这可能发生在个人电脑、工作站、单机 GPU 服务器、云 GPU 实例或 Kubernetes 集群。

需要首先区分“开源模型”和“开放权重模型”。很多可下载权重的模型并不采用传统开源软件许可证，可能存在用途限制、分发要求或商业许可条款。因此，模型可下载不等于可无限制使用。实际部署必须检查权重许可证、代码许可证、数据处理要求和适用地域法规。

1.1 学习目标

理解模型文件、Tokenizer、配置、权重与推理运行时。
估算参数显存、KV Cache、激活与运行时开销。
区分 CPU、GPU、量化、张量并行与流水线并行。
比较 Transformers、llama.cpp、vLLM 等典型部署路径。
设计单机、容器、集群和服务 API 架构。
掌握模型加载、健康检查、监控、版本、权限与回滚。
建立面向 Agent System 的自托管模型服务方案。

二、模型部署究竟包含什么？

部署不只是“下载一个模型文件”。完整服务通常包括：

text

模型来源 / Model Registry
          │
          ▼
权重 + 配置 + Tokenizer
          │
          ▼
推理运行时（Inference Runtime）
          │
          ▼
CPU / GPU / 内存 / 显存
          │
          ▼
API Server
          │
          ▼
认证 / 限流 / 日志 / 监控
          │
          ▼
Application / Agent System

其中，权重保存训练后的参数，Tokenizer 定义文本到 Token 的映射，模型配置描述结构参数，运行时负责加载、调度和推理，API Server 将能力暴露给客户端。多模态模型还可能依赖图像处理器、音频编码器和其他组件。

2.1 部署与训练的区别

训练通过反向传播更新参数；推理主要执行前向计算。模型部署通常不需要训练数据和优化器状态，但需要可运行的权重、计算资源与兼容的软件栈。若要进行 LoRA 微调或继续训练，则是另一个工程流程。

三、如何选择模型？

模型选择需要同时考虑任务质量、参数规模、许可证、语言能力、上下文长度、工具支持、结构化输出兼容性和硬件要求。

维度	需要回答的问题
任务适配	是否擅长中文、代码、分析或视觉？
模型形态	Dense 还是 MoE？文本还是多模态？
参数与内存	权重与 KV Cache 能否放入硬件？
上下文	实际可用窗口与长上下文表现如何？
许可证	是否允许当前用途、商业使用和再分发？
模型来源	权重是否来自可信发布者？
生态兼容	推理框架是否支持其架构与 Tokenizer？
质量评估	是否通过业务测试集？

3.1 参数量不是唯一指标

两个相同参数规模的模型可能在训练数据、架构、量化和对齐上差异很大。MoE 模型的总参数量也不等于每 Token 激活的参数量；显存与计算需求需要按具体实现估算。

3.2 下载来源与供应链

优先使用模型发布方的官方仓库或可信镜像，检查版本、哈希、许可证与模型卡。某些模型仓库包含需要执行的自定义代码，使用 trust_remote_code 等选项时必须评估代码执行风险；不要对未知来源无条件开启。

四、模型权重与文件格式

4.0 从文件到一次推理：加载链路

一个可复现的部署不仅要固定权重，还应固定配置、Tokenizer、Chat Template、模型代码依赖和推理引擎版本。加载链路可以拆为：解析模型清单与许可证 → 读取配置 → 构造网络结构 → 载入或映射权重 → 初始化设备与计算精度 → 加载 Tokenizer/模板 → 分配运行时缓存 → 预热 → 提供服务。任何环节版本不匹配，都可能出现加载失败或“能够运行但回答异常”的情况。

尤其要警惕 Tokenizer 与权重不配套：即使权重张量形状正确，特殊 Token、角色边界、工具调用模板也可能变化。模型生成行为依赖训练时采用的对话格式；把不同模型的模板混用可能破坏指令遵循和工具调用。应在模型卡与运行时文档中核实所需模板，并通过已知提示词做冒烟测试。

可复现清单：模型仓库及精确 revision/commit、权重文件校验和、许可证、Tokenizer 版本、Chat Template、框架版本、容器镜像摘要、GPU 型号与驱动、推理参数。单独保存 model_id 不足以复现部署。

4.1 权重（Weights）

模型权重是训练得到的参数集合。它们可能保存为单个文件，也可能分片存储。权重格式与推理框架必须兼容。

4.2 Safetensors

Safetensors 是一种用于安全存储张量数据的格式，设计目标之一是避免传统任意对象反序列化的代码执行风险。它不意味着模型仓库中的所有其他文件都是安全的。

4.3 GGUF

GGUF 是 llama.cpp 生态常用的模型文件格式，常用于本地推理与量化权重分发。并非所有模型都存在可用的 GGUF 转换版本。

4.4 Tokenizer 与 Chat Template

同一段文字经不同 Tokenizer 可能产生不同 Token 序列。对聊天模型，还需要使用匹配训练格式的 Chat Template；错误的角色标记或特殊 Token 可能显著影响输出。

五、如何估算显存与内存？

5.0 资源预算的组成

显存预算可写为近似关系：

M_{t o t a l} \approx M_{w e i g h t s} + M_{K V} + M_{a c t i v a t i o n s} + M_{w o r k s p a c e} + M_{r u n t i m e} + M_{f r a g m e n t a t i o n}

其中权重通常决定静态基线，KV Cache 随序列长度、并发及模型结构增长，临时激活与工作区受实现、批量和算子影响。这个式子用于容量规划，不应被误当成框架无关的精确显存计算器。不同量化方法还会引入 scale、zero-point 等元数据与非量化层。

5.1 权重内存的粗略估算

若模型包含 $N$ 个参数，权重平均每参数占用 $b$ 字节，则：

M_{w e i g h t s} \approx N \times b

例如，一个 7B 参数的 Dense 模型在理想情况下：

权重精度	每参数字节数（近似）	权重占用（十进制）
FP32	4	28 GB
FP16 / BF16	2	14 GB
INT8	1	7 GB
4-bit	0.5	3.5 GB

这些仅是权重理论下限附近的估算，不是整机显存需求。量化通常还需要 scale、zero-point、分组元数据等额外空间；模型运行还需要 KV Cache、激活、工作区和框架开销。实际模型也可能有不同精度的层。

5.2 KV Cache

自回归模型在解码时通常缓存历史 Token 的 Key/Value 表示，减少重复计算。粗略估算（忽略特殊压缩和架构差异）：

M_{K V} \approx 2 \times L \times H_{k v} \times D_{h e a d} \times S \times B \times b_{k v}

其中 $L$ 是层数， $H_{k v}$ 是 KV 头数， $D_{h e a d}$ 是头维度， $S$ 是缓存序列长度， $B$ 是并发序列数， $b_{k v}$ 是每元素字节数。GQA/MQA 会改变 KV 头数，因此不能只用总注意力头数估算。

5.3 显存预算

M_{t o t a l} \approx M_{w e i g h t s} + M_{K V} + M_{a c t i v a t i o n s} + M_{r u n t i m e} + M_{m a r g i n}

必须保留安全余量，尤其在长上下文和高并发场景下。一个模型“刚好能加载”不代表能够稳定处理生产请求。

六、CPU、GPU 与计算资源

CPU 适合轻量模型、低并发或本地实验，但大模型的矩阵运算通常更适合 GPU 等加速器。GPU 部署需要考虑显存、带宽、算力、驱动、CUDA/ROCm 版本及框架兼容性。

6.1 算力与带宽

Prefill 阶段通常对大量输入 Token 并行计算，可能更受计算能力影响；Decode 阶段逐步生成 Token，在一些负载下更受内存带宽和 KV Cache 访问影响。实际瓶颈随模型大小、Batch Size、硬件和框架而变化。

6.2 多 GPU

Tensor Parallelism 将同一层的计算分布到多个设备，涉及跨设备通信；Pipeline Parallelism 将不同层分布到不同设备，可能产生流水线气泡；Data Parallelism / Replica 则使用多个副本提高服务吞吐。部署方式应由模型规模、单卡显存和并发需求决定。

七、量化（Quantization）是什么？

量化将权重或激活从较高精度表示转换为较低位宽表示，以减少内存与带宽需求，有时也能提升吞吐。

7.1 常见方式

FP16/BF16：常见半精度推理格式。
INT8：8 位量化。
4-bit：更激进的低比特量化。
FP8：部分硬件和推理框架支持的低精度浮点格式。

量化并不保证所有硬件上都更快；性能取决于量化内核、数据转换和设备支持。

7.2 量化与质量

低比特量化可能导致输出质量下降，尤其对数值、代码、长上下文或特殊任务。应对业务测试集评估，而不是只根据文件大小判断是否可用。

7.3 量化的两类路线

Post-training Quantization（PTQ）在训练完成后量化；Quantization-aware Training（QAT）在训练中考虑量化误差。部署场景通常优先评估现成的 PTQ 模型，但具体选择取决于模型与质量要求。

八、主要推理框架如何选择？

8.0 先选运行约束，再选框架

框架选型应从 目标模型支持情况、设备、服务负载、输出能力、可维护性 出发，而不是仅比较一次基准的 tokens/s。开发调试和模型实验常需要灵活访问内部张量；个人设备常需要 CPU/混合卸载与 GGUF；面向多用户的 GPU 服务则更关注请求调度、KV Cache 管理、并发和 OpenAI 兼容接口。若需要多模态、结构化输出、工具调用或 LoRA 热切换，必须针对具体模型与框架版本逐项核对，不能把“接口兼容”推断成“语义能力完全兼容”。

8.1 Hugging Face Transformers

适合研究、模型加载、原型和多模型生态。优势是模型覆盖广、可定制；但直接使用 generate() 不等于已经具备生产级调度、限流和服务能力。

8.2 llama.cpp

面向本地和资源受限环境的高效推理生态，支持多种 CPU/GPU 后端与 GGUF。适合个人电脑、本地实验、轻量服务；模型架构和量化格式的支持需要核实。

8.3 vLLM

面向高吞吐推理服务，支持连续批处理、PagedAttention 等技术，并提供兼容部分 OpenAI API 风格的服务接口。兼容接口不意味着全部参数、工具与结构化输出能力完全等同于托管服务。

8.4 其他路线

还可以根据硬件与工作负载评估 TensorRT-LLM、Text Generation Inference、Ollama 等。选择框架时应比较模型兼容性、量化支持、GPU 类型、并发、运维复杂度和 API 能力。

8.5 简要比较

框架	主要定位	典型优势	需要注意
Transformers	研究与灵活推理	模型生态广	生产服务需补充工程层
llama.cpp	本地与轻量部署	低资源、GGUF 生态	支持矩阵随模型而变
vLLM	高吞吐推理服务	调度、缓存管理、服务接口	资源与部署复杂度
Ollama	本地模型管理体验	易于启动与使用	生产需求需单独评估

九、最小可运行部署示例

9.0 案例验收规则

以下示例按两条路径组织：A. 本地低门槛推理，用于验证模型文件与运行时是否匹配；B. GPU API 服务，用于验证模型能否通过标准 HTTP 接口被应用访问。所有示例均属于部署模板，未在本次会话中进行真实模型下载、GPU 加载或服务实测。读者执行前应锁定模型 revision、运行时版本与驱动兼容矩阵。

9.A 本地路径：llama.cpp / GGUF

准备经过许可核验、适配当前架构的 GGUF 模型文件；下载后记录 SHA-256，并确认 llama.cpp 的当前构建方式。示例假设已存在 llama-server 可执行文件及 model.gguf：

bash

# 概念可执行模板：路径、二进制和选项需依安装版本调整
sha256sum ./model.gguf
./llama-server -m ./model.gguf --host 127.0.0.1 --port 8080 -c 4096

另开终端进行接口冒烟测试。端点形态可能随版本变化；以下为常见 OpenAI 兼容路径，执行前核对当前 server 文档：

bash

curl -sS http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"local","messages":[{"role":"user","content":"请用一句话解释什么是推理服务。"}],"max_tokens":96}'

检查 HTTP 状态、模型是否确实完成加载、输出语言和内容、首 Token 时间、显存/内存峰值；若失败，优先核对 GGUF 格式、模型架构支持、模板、上下文长度与设备卸载设置。不能只凭服务进程启动判断部署成功。

9.B GPU 路径：vLLM 的 API 服务

部署前检查 GPU 驱动、CUDA/PyTorch 兼容关系、模型架构支持与显存预算。安装步骤随操作系统、CUDA 和 vLLM 版本变化，务必采用官方版本对应的安装说明。以下仅展示启动形态：

bash

MODEL_ID='your-org/your-supported-model'
vllm serve "$MODEL_ID" --host 127.0.0.1 --port 8000

客户端请求示意：

python

# 概念示意：需安装兼容 SDK、确认服务端的模型名与端点
from openai import OpenAI
client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="local-only")
result = client.chat.completions.create(
    model="your-org/your-supported-model",
    messages=[{"role": "user", "content": "简述模型部署与模型训练的区别"}],
    max_tokens=128,
)
print(result.choices[0].message.content)

api_key="local-only" 只是本地兼容客户端的占位值，不代表服务端已启用鉴权。对外服务必须由经过配置的网关、服务端认证机制或网络策略实际验证身份。建议固定请求 ID，检查超时、取消、错误码、排队延迟与并发下的显存峰值。

9.1 使用 Transformers 进行本地推理

python

from transformers import pipeline

# 替换为已经核实许可证、下载权限与硬件要求的模型。
model_id = "YOUR_COMPATIBLE_MODEL_ID"

pipe = pipeline("text-generation", model=model_id)
result = pipe("请用一句话解释什么是 Agent。", max_new_tokens=80)
print(result[0]["generated_text"])

该示例展示基本调用形式。具体模型可能需要 Chat Template、特定设备、精度、登录权限或额外依赖；不能直接把任意模型 ID 替换后就假设能够运行。

9.2 使用 vLLM 启动服务

下面展示命令形态，具体参数需按安装版本与模型核对：

bash

vllm serve YOUR_COMPATIBLE_MODEL_ID --host 127.0.0.1 --port 8000

启动后可使用其支持的 API 端点访问。首次部署应仅绑定本机或受保护网络，避免未经认证的推理服务直接暴露到公网。

9.3 为什么不建议直接开放公网？

推理接口可能消耗昂贵计算资源，且可能暴露输入内容或允许滥用。生产环境应增加认证、TLS、速率限制、请求大小限制、审计、网络隔离与预算控制。

十、部署拓扑如何选择？

10.0 资源扩展与并行方式的差异

副本/数据并行：多个独立模型实例分担请求，增加总吞吐和可用性；每个副本仍需能够放下完整模型（或其自身并行分片）。
张量并行：将同一层的张量计算分散到多个 GPU，可处理超出单卡容量的模型，但每层往往产生跨卡通信，对 GPU 互联敏感。
流水线并行：将不同层分配给不同设备，减轻单卡权重负担；微批调度和流水线气泡影响利用率与延迟。
专家并行：对 MoE 模型的专家进行设备分布，需要结合路由负载、通信和热点专家分析。

决定多卡方案前应先尝试选择更合适的模型、量化、缩短上下文或降低并发。增加 GPU 不保证线性加速，网络带宽、通信、KV Cache 分布和调度策略都可能成为瓶颈。

10.1 本地单机

text

Desktop / Workstation
    ├── Model Files
    ├── Inference Runtime
    └── Local API

适合实验、离线任务和隐私敏感的个人工作流。局限是并发和资源受单机约束。

10.2 单 GPU 服务器

text

Application ──► API Gateway ──► GPU Inference Server

适合小规模生产与内部服务。需要监控显存、并发、队列和失败恢复。

10.3 多实例服务

text

Load Balancer
    │
    ├── Model Replica A
    ├── Model Replica B
    └── Model Replica C

可通过多个副本提高吞吐与可用性，但成本也随之增长。需要考虑请求路由、缓存局部性、冷启动和实例扩缩容。

10.4 Kubernetes 与集群

适合需要统一调度、自动扩缩容、滚动发布和服务治理的环境，但复杂度更高。对于单人原型，通常没有必要一开始就建设完整集群。

十一、模型服务 API 与兼容性

自托管推理服务可以暴露 HTTP API。常见实践是提供与某类通用模型 API 相似的请求形式，以便现有客户端接入。但必须核实：消息格式、流式事件、工具调用、JSON Schema、Token 统计、最大输出、模型别名、错误码和认证。

text

Agent Runtime
      │
      ▼
Unified Model Client
      │
      ▼
Self-hosted API Adapter
      │
      ▼
Inference Server
      │
      ▼
Model Runtime

兼容性测试应包含真实任务，而不只是一个“Hello World”文本请求。

十二、生产环境需要哪些运维能力？

12.0 将模型服务视为有状态的资源密集型服务

推理服务通常不持久保存业务会话，但会持有昂贵的 GPU 资源、权重驻留状态、请求队列和 KV Cache，因此不能直接套用无状态 HTTP 服务的全部假设。启动时权重加载和预热可能持续较久；健康检查应区分进程存活、模型就绪和实际推理成功。过早将流量导入仅“进程存活”的实例，可能导致大量超时。

12.A 一条请求的生产路径

text

Client / Agent
    ↓ TLS + 身份认证
API Gateway（配额、速率限制、请求大小）
    ↓
Model Router（模型版本、容量、故障切换）
    ↓
Inference Service（排队 → Prefill → Decode）
    ↓
Response Validator（输出协议、错误映射、审计字段）
    ↓
Client / Agent

日志应记录请求 ID、模型与版本、Token 数、耗时、错误类别、资源指标；默认避免存储敏感原始提示词和输出。对需要审计的场景，采用脱敏、访问控制和保留期限。多租户部署应将认证、限流、数据隔离和资源配额视为独立的系统职责，而非模型 Prompt 约束。

12.B 版本发布与回滚

采用不可变模型 revision + 镜像摘要 + 配置版本组合形成发布单元。灰度期间同时检查任务质量与性能指标，尤其是工具调用格式、结构化输出、拒绝行为和长上下文表现。回滚不只是恢复镜像：如果 Tokenizer、Chat Template 或客户端数据契约改变，还需恢复配套配置并验证兼容性。

12.1 健康检查

区分进程存活（Liveness）、服务就绪（Readiness）和模型是否完成加载。GPU 显存耗尽或权重加载失败时，进程可能仍在运行，但服务不可用。

12.2 可观测性

建议监控：请求量、错误率、排队时间、TTFT、完整延迟、输出 Token/s、GPU 利用率、显存、KV Cache 占用、模型加载时间和请求成本。

12.3 容量规划

容量不能只看“单请求每秒多少 Token”。需要结合输入长度分布、输出长度分布、并发峰值、P95 延迟和模型缓存行为进行压测。

12.4 模型版本与回滚

权重、Tokenizer、推理框架、量化文件和 Chat Template 都应记录版本。更新任何一项，都可能影响输出。建议通过固定测试集与灰度部署进行验证。

12.5 安全与隔离

对外 API 应实施认证、授权、TLS、速率限制和审计；模型文件和容器镜像应来自可信来源；代码执行工具应与模型服务隔离；日志应保护用户输入与输出中的敏感数据。

十三、部署成本如何计算？

13.0 一个可复核的成本模型

自托管单位成本不等于 GPU 实例价格除以理论峰值吞吐。一个简化的每百万输出 Token 成本为：

C_{1 M} = \frac{C_{g p u / h o u r} + C_{c p u, s t o r a g e, n e t w o r k / h o u r} + C_{o p s / h o u r}}{T_{o u t p u t / h o u r}} \times 10^{6}

其中分母应使用目标请求分布和目标 SLO 下的有效输出吞吐，而非压测时不受约束的最大吞吐。还需考虑空闲时段、扩缩容、冷启动、模型更新、故障冗余、流量突发、提示词输入 Token 成本和组织维护投入。对于 Agent 多轮调用，额外上下文与工具结果会改变 Prefill 负载；仅按输出 Token 比较可能得出错误结论。

自托管成本包括：GPU/CPU 租用或购置、内存、存储、网络、运维、人力、空闲容量和故障处理。粗略单位成本可以表示为：

C_{p e r r e q u e s t} = \frac{C_{i n f r a} + C_{o p s} + C_{s t o r a g e} + C_{n e t w o r k}}{N_{s u c c e s s f u l r e q u e s t s}}

但请求长度差异很大，更有意义的比较可能是每百万有效输出 Token 成本或每个成功任务的总成本。需要将失败、重试和人工处理计算进去。

13.1 托管与自托管对比

维度	托管 API	自托管
初始开发	通常较快	需要搭建运行环境
模型更新	服务商管理	自行管理
GPU 运维	服务商承担	自行承担
数据控制	依赖合同与服务设置	可获得更强环境控制，但需自建安全
低负载成本	常按量付费	可能存在空闲资源成本
高稳定负载	需测算	可能有成本优势，但不保证
自定义	受接口限制	通常更灵活

十四、Agent System 中的自托管模型架构

14.0 模型服务的统一契约

Agent System 不应依赖某个部署引擎的私有响应字段。建议在 Model Gateway 中统一：模型能力描述、消息与工具调用格式、结构化输出能力、超时与重试、流式事件、Token 统计、请求追踪、预算与权限。OpenAI-compatible 主要表示部分接口形态兼容，不保证模型具备相同的 tool calling、JSON Schema 约束、推理参数或流式事件语义；上线前应逐能力测试。

可以建立能力矩阵：

能力	验收问题	失败时策略
中文任务	关键任务集的正确率是否达标？	切换更合适模型
长上下文	目标长度是否可稳定处理？	缩短/分块/检索
工具调用	是否生成正确调用结构？	Runtime 校验或回退
结构化输出	是否符合目标 Schema？	校验、修复或路由
流式输出	事件边界与取消是否正确？	关闭流式或适配
并发	p95、错误率和 OOM 是否可接受？	限流、扩容、降级

对于研究 Studio，可以把自托管模型作为 Model Router 的一个候选，而不是强制所有 Agent 使用同一模型：

text

Research Studio
      │
      ▼
Agent Runtime
      │
      ▼
Model Router
      │
      ├── Hosted Reasoning Model
      ├── Hosted Multimodal Model
      └── Private Inference Service
                  │
                  ▼
              GPU Server

例如，内部敏感资料提取可路由到符合治理要求的私有模型；复杂综合分析则根据数据策略和能力评估决定是否使用托管模型。敏感数据能否发送外部服务必须由策略控制，而不是仅由 Agent 自行决定。

14.1 上线验收

[ ] 模型许可证与用途经过核对。
[ ] 权重、Tokenizer、模板和运行时版本固定。
[ ] 真实输入长度与并发场景通过显存压测。
[ ] API 有认证、限流、TLS 与访问日志。
[ ] 健康检查能识别模型未就绪。
[ ] 有错误率、TTFT、Token/s 和显存监控。
[ ] 模型变更经过任务回归测试。
[ ] 具备回滚与故障恢复方案。
[ ] 数据处理符合实际安全与合规要求。

十五、常见误区

误区一：模型权重能下载就是完全开源。 许可证可能有额外限制。误区二：显存只需要容纳权重。 KV Cache 与运行时开销可能很大。误区三：量化越低越快。 取决于硬件、内核与质量损失。误区四：模型能加载就能稳定服务。 并发与长上下文可能导致 OOM。误区五：自托管一定便宜。 需要考虑利用率和运维成本。误区六：本地部署天然安全。 未授权 API、恶意模型代码和不当日志仍可能泄漏数据。误区七：兼容 OpenAI 风格接口就等于全部能力兼容。 必须逐项验证。

十六、核心结论

Model Deployment 的核心是将模型文件、推理运行时、计算资源和服务治理组合成可稳定访问的模型服务。选型应同时评估模型质量、许可证、硬件容量和框架兼容性；显存估算必须包括权重与 KV Cache；生产环境必须补充认证、监控、容量规划和版本治理。对于 Agent System，自托管模型最好作为统一模型服务层的可选资源，由路由器依据能力、成本和数据治理要求决定是否使用。

十七、参考资料与延伸阅读

Hugging Face. Transformers Documentation. 官方文档
Hugging Face. Safetensors. 官方文档
llama.cpp. GitHub Repository. 官方仓库
vLLM. Documentation. 官方文档
Kwon et al. (2023). Efficient Memory Management for Large Language Model Serving with PagedAttention. 论文
Dettmers et al. (2022). LLM.int8(): 8-bit Matrix Multiplication for Transformers at Scale. 论文
Hugging Face. Model Cards. 官方文档

十八、关联研究

文档	关联重点
M1 · Model Fundamentals	权重、参数与模型构成
M3 · Transformer Architecture	模型结构与注意力
M7 · Inference & Decoding	Prefill、Decode 与 KV Cache
E1 · Model API	自托管服务接口
E3 · Context Window	长上下文容量
E6 · Model Routing	托管与自托管模型选择
E8 · Inference Optimization	量化、批处理与吞吐
L1 · Infrastructure	GPU 与计算资源
L3 · Model Services	模型服务治理

E7 · 如何部署和运行开源模型？ - Model Deployment ​

专题导读 ​

一、研究概述 ​

1.1 学习目标 ​

二、模型部署究竟包含什么？ ​

2.1 部署与训练的区别 ​

三、如何选择模型？ ​

3.1 参数量不是唯一指标 ​

3.2 下载来源与供应链 ​

四、模型权重与文件格式 ​

4.0 从文件到一次推理：加载链路 ​

4.1 权重（Weights） ​

4.2 Safetensors ​

4.3 GGUF ​

4.4 Tokenizer 与 Chat Template ​

五、如何估算显存与内存？ ​

5.0 资源预算的组成 ​

5.1 权重内存的粗略估算 ​

5.2 KV Cache ​

5.3 显存预算 ​

六、CPU、GPU 与计算资源 ​

6.1 算力与带宽 ​

6.2 多 GPU ​

七、量化（Quantization）是什么？ ​

7.1 常见方式 ​

7.2 量化与质量 ​

7.3 量化的两类路线 ​

八、主要推理框架如何选择？ ​

8.0 先选运行约束，再选框架 ​

8.1 Hugging Face Transformers ​

8.2 llama.cpp ​

8.3 vLLM ​

8.4 其他路线 ​

8.5 简要比较 ​

九、最小可运行部署示例 ​

9.0 案例验收规则 ​

9.A 本地路径：llama.cpp / GGUF ​

9.B GPU 路径：vLLM 的 API 服务 ​

9.1 使用 Transformers 进行本地推理 ​

9.2 使用 vLLM 启动服务 ​

9.3 为什么不建议直接开放公网？ ​

十、部署拓扑如何选择？ ​

10.0 资源扩展与并行方式的差异 ​

10.1 本地单机 ​

10.2 单 GPU 服务器 ​

10.3 多实例服务 ​

10.4 Kubernetes 与集群 ​

十一、模型服务 API 与兼容性 ​

十二、生产环境需要哪些运维能力？ ​

12.0 将模型服务视为有状态的资源密集型服务 ​

12.A 一条请求的生产路径 ​

12.B 版本发布与回滚 ​

12.1 健康检查 ​

12.2 可观测性 ​

12.3 容量规划 ​

12.4 模型版本与回滚 ​

12.5 安全与隔离 ​

十三、部署成本如何计算？ ​

13.0 一个可复核的成本模型 ​

13.1 托管与自托管对比 ​

十四、Agent System 中的自托管模型架构 ​

14.0 模型服务的统一契约 ​

14.1 上线验收 ​

十五、常见误区 ​

十六、核心结论 ​

十七、参考资料与延伸阅读 ​

十八、关联研究 ​

E7 · 如何部署和运行开源模型？ - Model Deployment

专题导读

一、研究概述

1.1 学习目标

二、模型部署究竟包含什么？

2.1 部署与训练的区别

三、如何选择模型？

3.1 参数量不是唯一指标

3.2 下载来源与供应链

四、模型权重与文件格式

4.0 从文件到一次推理：加载链路

4.1 权重（Weights）

4.2 Safetensors

4.3 GGUF

4.4 Tokenizer 与 Chat Template

五、如何估算显存与内存？

5.0 资源预算的组成

5.1 权重内存的粗略估算

5.2 KV Cache

5.3 显存预算

六、CPU、GPU 与计算资源

6.1 算力与带宽

6.2 多 GPU

七、量化（Quantization）是什么？

7.1 常见方式

7.2 量化与质量

7.3 量化的两类路线

八、主要推理框架如何选择？

8.0 先选运行约束，再选框架

8.1 Hugging Face Transformers

8.2 llama.cpp

8.3 vLLM

8.4 其他路线

8.5 简要比较

九、最小可运行部署示例

9.0 案例验收规则

9.A 本地路径：llama.cpp / GGUF

9.B GPU 路径：vLLM 的 API 服务

9.1 使用 Transformers 进行本地推理

9.2 使用 vLLM 启动服务

9.3 为什么不建议直接开放公网？

十、部署拓扑如何选择？

10.0 资源扩展与并行方式的差异

10.1 本地单机

10.2 单 GPU 服务器

10.3 多实例服务

10.4 Kubernetes 与集群

十一、模型服务 API 与兼容性

十二、生产环境需要哪些运维能力？

12.0 将模型服务视为有状态的资源密集型服务

12.A 一条请求的生产路径

12.B 版本发布与回滚

12.1 健康检查

12.2 可观测性

12.3 容量规划

12.4 模型版本与回滚

12.5 安全与隔离

十三、部署成本如何计算？

13.0 一个可复核的成本模型

13.1 托管与自托管对比

十四、Agent System 中的自托管模型架构

14.0 模型服务的统一契约

14.1 上线验收

十五、常见误区

十六、核心结论

十七、参考资料与延伸阅读

十八、关联研究