大模型部署方式与选型¶

面试中问“大模型有哪些部署方式”，不要只回答 Ollama、vLLM 或 Docker。这几个词不在同一个层级：云端 API / 私有化部署描述模型运行在哪里，单卡 / 多卡 / 多机描述算力怎样组织，Ollama / vLLM则是负责加载模型并提供推理能力的软件。

可以按下面四层回答：

应用：聊天、RAG、Agent、批量抽取
  ↓ 调用
服务：云端 API / 本地进程 / 私有 API / 集群服务
  ↓ 承载
推理引擎：Ollama / vLLM / llama.cpp / TensorRT-LLM 等
  ↓ 使用
算力：CPU / 单 GPU / 单机多 GPU / 多机多 GPU

一、按交付形态分类¶

部署方式	模型和数据在哪里	优点	局限	适合场景
云端模型 API	服务商平台	无需购买 GPU，上线快，模型能力更新快	数据需要出域；按量计费；受网络、限流和服务商约束	快速验证、调用量波动大、无严格私有化要求
本地桌面/边缘部署	PC、工作站或边缘设备	数据本地，离线可用，上手简单	模型规模、速度和并发受本机资源限制	个人助手、开发验证、现场离线使用
单机私有推理服务	一台 CPU/GPU 服务器	数据不出内网；部署与排障相对简单	单机容量和可用性有限；故障时服务中断	内部 RAG、部门级共享 API、中小并发
单机多 GPU	一台服务器内多张 GPU	能承载更大模型或更大并发；节点内通信相对快	受 PCIe/NVLink 拓扑影响；单机仍是故障域	单卡放不下的模型、较高吞吐推理
多机多 GPU	多个 GPU 节点	可以承载超大模型，突破单机显存上限	通信、网络、存储、调度和故障处理复杂	大模型集中式推理、超大模型或极高吞吐
Kubernetes 平台化部署	容器化推理服务运行在集群	便于副本、滚动升级、资源调度、监控和网关治理	K8s 不会自动解决模型并行和 GPU 性能问题；平台成本更高	多模型、多团队、需要弹性与标准化交付的平台

一句话理解区别¶

云端 API 解决“我不维护模型服务也能使用模型”。
本地或私有化解决“数据、模型和资源由自己控制”。
多 GPU / 多机解决“模型放不下或吞吐不够”。
Kubernetes 解决“如何标准化管理多个推理服务”，不是让模型本身变快。

二、离线推理和在线推理¶

部署载体也可以单独说明：直接在主机的 Python 环境启动进程，便于调试但需要管理依赖；Docker/Compose 固化引擎环境、模型挂载和启动参数，适合单机交付；Kubernetes 在容器之上增加集群调度和发布管理。这些方式都可以运行同一个 vLLM 服务，模型精度和并行策略仍由引擎配置决定。

模式	请求特点	核心目标	常见实现
离线批处理	已经积累的一批数据，不要求立即返回	总吞吐高、单位成本低、任务可恢复	Python 脚本、队列任务、vLLM Batch API
在线服务	用户或应用实时请求	首 token 快、输出稳定、并发可控	OpenAI 兼容 API、vLLM、Ollama、网关和负载均衡

同一个模型在离线和在线场景的调优方向不同。离线任务可以接受较大的批次和较长等待；在线聊天更关注首 token 延迟（TTFT）、token 间延迟（ITL）和 P95/P99。

三、单卡、多卡与多副本¶

单卡¶

模型权重、运行时内存和 KV Cache 都放在一张 GPU 上。结构最简单；只要显存和性能满足，就优先从单卡开始。

Tensor Parallel：把同一层拆到多张卡¶

Tensor Parallel（TP）把模型层内部的矩阵计算拆到多张 GPU。它主要解决单卡放不下模型，但每层都会发生跨卡通信，因此 GPU 互联越差，收益越容易被通信开销抵消。

Pipeline Parallel：把不同层放到不同卡或节点¶

Pipeline Parallel（PP）把模型的连续层切成多个阶段。它可以跨节点容纳更大模型，但请求需要依次经过各阶段，存在流水线等待和节点间通信。

多副本：每组 GPU 各加载一份完整模型¶

当一份模型已经能放入一张卡或一组卡，而需求是提高并发和可用性时，通常启动多个独立副本，再由负载均衡分发请求。代价是每个副本都要保存一份模型权重。

模型放不下       → 先考虑 TP，跨节点时再组合 PP
模型放得下但并发高 → 多副本 + 负载均衡
离线任务量大       → 批处理，提高 GPU 吞吐

四、Ollama、vLLM 应该怎样选¶

维度	Ollama	vLLM
定位	简化本地模型下载、管理和运行	面向在线服务的高吞吐推理引擎
典型用户	个人、开发验证、小型内部工具	运维平台、RAG 服务、共享模型 API
优势	安装和模型管理简单，适合快速试用	连续批处理、KV Cache 管理、并行与服务参数更完整
调优重点	模型是否进入 GPU、上下文、并发、常驻时间	显存预算、KV Cache、批处理、上下文、并行、量化
不适合硬套的场景	大规模并发和精细性能治理	只想在笔记本快速试一个模型

二者不是模型，也不是训练框架。它们都位于“推理服务”这一层：加载已经训练好的模型，根据请求执行推理，并向应用提供接口。

五、选型流程¶

1. 明确任务和数据边界
   ↓
2. 用评测集选择模型，而不是先选引擎
   ↓
3. 计算权重、KV Cache、并发所需显存
   ↓
4. 决定单卡、并行还是多副本
   ↓
5. 选择推理引擎与部署平台
   ↓
6. 压测质量、TTFT、ITL、吞吐、P95 和成本

需要同时确认：模型许可证、GPU 类型与显存、上下文长度、并发、是否多模态、是否支持工具调用，以及数据能否离开内网。

面试回答模板¶

大模型部署可以先分为云端 API、本地/边缘部署和私有化服务；私有化再按单卡、单机多卡、多机多卡以及 Kubernetes 平台化部署区分。单卡最简单，模型放不下时用 Tensor Parallel 或 Pipeline Parallel，模型放得下但并发不足时更适合做多副本。Ollama 和 vLLM 是推理引擎，不是部署位置：Ollama偏本地和快速验证，vLLM 偏生产在线服务，通过连续批处理和更高效的 KV Cache 管理提高吞吐。最后还要根据数据安全、模型规模、显存、并发、延迟和成本做选择。

继续阅读：vLLM 部署与优化、Ollama 本地部署与管理。

官方参考：vLLM 并行与扩展、vLLM OpenAI 兼容服务。