部署相关的知识点
重点 CPU VS GPU
架构的差异
- CPU：设计初衷是处理顺序指令，擅长复杂逻辑控制和串行计算，核心数较少（数十核），但单核能力强
- GPU：由数千个小而高效的核心组成 => 适合处理LLM的并行矩阵运算。
核心 GPU 型号
硬件型号和云端可用性变化很快，应用工程师不应背“某型号必然适合某模型”的结论。选型要先用实际模型、量化方式、上下文、并发和 SLA 计算，再查当期硬件规格与报价。
| 维度 | 要问的问题 |
|---|---|
| 显存容量 | 权重、KV Cache、并发和预留空间能否同时放下？ |
| 带宽与算力 | 工作负载更受 Prefill、Decode 还是数据传输限制？ |
| 互联 | 多卡需要的张量/流水线并行是否受 PCIe、NVLink 或网络限制？ |
| 可靠性与运维 | 云上供给、驱动、监控、故障替换和预算是否满足要求？ |
| 方案替代 | 能否量化、缩短上下文、降低并发、走托管模型或做缓存？ |
本地消费级显卡适合开发验证；生产与训练资源由压测、成本和可用性共同决定。具体型号、显存规格和价格应链接到厂商或云服务商的当期文档，而不是写死在通用笔记里。
CPU 与内存的隐形瓶颈
推理不只是 GPU 的事。CPU 负责：并发请求调度、Tokenization（文本 ↔ Token）、前后处理（JSON、正则过滤）。
CPU 和 GPU 要配比。并发大时，CPU 过载或系统内存（DRAM）不够，GPU 会陷入饥饿等待：卡闲着等 CPU 喂数。
CPU 与 DRAM 没有可脱离负载背诵的固定配比。按 tokenizer、并发、上下文、KV 卸载、网络与数据预处理压测 CPU 利用率、内存余量和队列等待；文档中的硬件量级只能作为演练起点，不能当作配置结论。
和「内存墙」不是一回事：内存墙是 GPU 片内等 HBM；这里是整机 CPU / DRAM 跟不上，把 GPU 饿死。
重点 四大主流框架
| 框架 | 重点能力 | 常见评估场景 |
|---|---|---|
| vLLM | PagedAttention、批处理调度、OpenAI 兼容服务 | 通用 GPU 推理服务与高吞吐 API |
| SGLang | 前缀复用、约束生成与 LLM 程序运行时 | 共享前缀、结构化输出或复杂编排负载 |
| TensorRT-LLM | NVIDIA 平台上的深度编译与运行时优化 | 硬件固定且需要深度性能优化的服务 |
| Ollama | 本地模型管理与简化 API | 本地开发、原型、边缘或小规模部署 |
先跑通用生产选 vLLM；对话 / Agent 前缀长选 SGLang；本机 demo 选 Ollama；锁死英伟达、要极致性能再上 TRT-LLM。
重点 如何进行框架选型？
- 新手/快速验证 → Ollama（2分钟跑起来）
- 生产环境通用场景 → vLLM（生态最全，文档最丰富）
- 长上下文/Agent/多轮对话 → 评估 SGLang 的前缀缓存与结构化生成能力；收益取决于共享前缀比例和实际负载。
- 极致性能 / NVIDIA 平台深度优化 → 评估 TensorRT-LLM；量化格式与硬件支持以当前版本的官方兼容矩阵为准。
Ollama 的架构
两层分工：Go 对外提供服务，C++ 负责算，中间用 CGO 粘住。
- Go — HTTP API、拉模型、命令行。语言本身适合高并发（goroutine）、带 GC，适合写网关。
- llama.cpp（C++） — 矩阵乘和 token 生成。CGO 把它暴露成 Go 能调用的函数。
说「基于 llama.cpp」指的是推理内核，进程外壳是 Go。
Ollama 的定位与并发
Ollama 适合本地开发、原型和边缘环境，但不能简单说成“不支持并发”。官方 FAQ 提供了 OLLAMA_NUM_PARALLEL 控制每个模型可并行处理的请求数，默认值为 1；OLLAMA_MAX_QUEUE 控制忙碌时可排队的请求数。并行数提高会按上下文长度增加内存需求。
对线上服务的正确说法是：先按真实模型、上下文、并发和 P95 延迟压测。若目标是高吞吐、多请求动态调度或大规模 GPU 服务，再评估 vLLM、SGLang 或 TensorRT-LLM；它们不是“唯一能并发”的替代品，而是不同的服务与性能取舍。
参考：https://docs.ollama.com/faq（核验于 2026-09-12）。
重点 vLLM 的架构
是由伯克利大学 LMSYS 组织开源的LLM高速推理框架，用于提升LLM的吞吐量与内存使用效率。它 通过 PagedAttention 技术高效管理注意力键和值的内存，并结合连续批处理技术优化推理性能。vLLM 支持量化 技术、分布式推理、与 Hugging Face 模型无缝集成等功能
vLLM 的调度和 KV 管理位于推理路径，适合需要高吞吐调度与 KV Cache 管理的服务场景。
- API 层 — OpenAI 兼容 HTTP，收请求、流式回 token。Tokenizer 多在 CPU。
- 调度器 — Continuous Batching：按 token 插队，谁结束谁让位，多条请求挤在同一次 forward。
- KV 管理（PagedAttention） — 把 KV Cache 切成固定大小的页，像操作系统的虚拟内存。序列长短不一也能拼在一起，显存不按「最长那条 × 最大 batch」预留，碎片少。
- 执行层 — Worker 在 GPU 上跑模型计算；多卡时再加并行（张量并行等）。
门口收请求 → 调度拼 batch → 页式 KV → GPU 算一步。生产高吞吐靠的是 2 + 3，不是换一个更快的 HTTP 框架。
vLLM 部署流程
环境 → 锁依赖 → 下权重 → 起 API → 打通接口。Node 只当客户端，推理进程是 Python。
- 机器 — NVIDIA 驱动和 CUDA 对齐，
nvidia-smi能看到卡。CPU / DRAM 按前面「隐形瓶颈」配，否则卡会饿。 - Python 环境 — 独立 venv / conda，按下面工具箱装，版本不要随便升。
- 权重 — 从 Hugging Face 或镜像拉模型目录；Tokenizer 必须和权重同一套。
- 启动 —
vllm serve <模型路径>（或等价 API 入口），默认 OpenAI 兼容/v1。显存不够再开量化、缩max-model-len、多卡并行。 - 验收 —
curl打/v1/chat/completions能出字；再看吞吐和 P99，不是只看进程还在。 - 业务接入 — 应用（Node / Python）把
baseURL指到这台服务。
SGLang 框架
SGLang 是面向 LLM 程序与推理服务的开源运行时。它的 RadixAttention 适合共享前缀明显的请求，是否优于其他引擎必须以目标模型、版本和负载压测决定。
- RadixAttention — 用前缀树复用 KV。多轮对话、Agent、RAG 的系统提示重复时，可能减少重复 prefill。
- 结构化输出 — 支持约束解码等能力；应以格式正确率、兼容性和实际延迟比较，而不是承诺固定倍数。
- Runtime — 原生多模态（图 / 视频）；DeepSeek R1 一类推理模型开箱能跑。
- DSL — 用很像普通 Python 的方式写 LLM 程序，支持条件、循环、并行调用。
和 vLLM 怎么选：短请求、通用高吞吐先 vLLM；多轮 / Agent / 超长共享前缀再上 SGLang。
适合场景
- 聊天 / 客服 — 多轮和系统提示相似时，前缀缓存更可能带来收益。
- Agent / Function Calling — 要频繁吐结构化 JSON。
- 长文档 — 论文总结、代码审查等长上下文。
- 多模态 API — 同时处理图文、视频。
和 vLLM 的对比方法
用相同模型、版本、硬件、输入输出长度和并发压测 TTFT、TPOT、吞吐、显存、错误率和成本。短、分散、没有共享前缀的请求，前缀缓存收益通常较小；具体数字不应脱离实验条件引用。