核查日期：2026-11-04。本指南覆盖语言、推理、代码、多模态理解、图像、视频、语音及检索服务。模型见语言与理解目录和媒体目录，收录与证据口径见知识库入口。
选择顺序是：任务与质量要求 → 具体权重 → 可用运行时与硬件 → 量化和并行布局 → 服务负载验证。框架名不是独立的性能结论；在远端速度与并发优先的场景中，应比较达到质量和延迟要求后的有效吞吐。
1. 按服务类型缩小范围
下表是进入评估的顺序，前提是具体检查点、硬件和任务已被对应实现支持。
| 任务 | 优先评估的路线 | 其他候选与条件 | 关键判断 |
|---|---|---|---|
| 文本、代码、推理与工具调用 | 该模型官方配方中的 vLLM / SGLang | 有匹配实现的 TensorRT-LLM、LMDeploy 或专用引擎 | 模板、工具协议、思考预算、长短请求混合 |
| 图片、视频、文档理解 | 支持该编码器及协议的 vLLM / SGLang / 原厂实现 | 具体后端已适配的 LMDeploy、专用 OCR 流水线 | 图片预处理、视频抽帧、视觉 token 与输出结构 |
| 图像、视频、联合音视频生成 | 对应模型的 SGLang Diffusion / vLLM-Omni 配方 | Diffusers / 原厂代码用于基线与定制，ComfyUI 用于创作工作流 | 任务能力、编解码开销、每小时合格产出 |
| ASR、TTS、实时语音 | 原厂运行时或已适配的专用服务 | SGLang-Omni / vLLM-Omni 已覆盖完整链路时；Whisper 可对比专用实现 | 首音频、质量、连续播放、实时性与会话数 |
| Embedding / Reranker | 支持具体结构的 TEI、vLLM pooling 或原厂库 | 有匹配导出路线的 ONNX Runtime / OpenVINO | 检索质量、长度分布、文档吞吐与输出语义 |
| 单机、工作站与容量受限推理 | llama.cpp / MLX-LM / 模型专用原生引擎 | KTransformers 等异构方案 | 质量、容量、交互延迟与总成本 |
| 多节点、多模型在线服务 | 先验证引擎，再评估 Dynamo / Ray Serve 等服务层 | 有路由、扩缩容或 prefill/decode 资源冲突证据时 | 调度收益与网络、KV 传输及运维成本 |
这是选择建议，不是逐模型支持表。交叉核对 vLLM 支持清单、SGLang 配方、vLLM-Omni 模型与任务及 TEI 支持表。
2. 技术栈分层：部署方案不等于框架
| 层次 | 职责 | 常见对象 |
|---|---|---|
| 模型与产物 | 网络、权重、tokenizer/processor、任务能力 | 原始模型、量化、蒸馏版、LoRA、视觉编码器 |
| 运行时与内核 | 张量、设备、算子、内存与执行 | PyTorch、CUDA/ROCm、ggml、MLX、优化 attention/MoE 内核 |
| 模型与流水线库 | 加载组件并组织生成、识别或编码 | Transformers、Diffusers、Sentence Transformers、原厂代码 |
| 推理引擎 | 执行模型、管理状态、批处理与多卡计算 | vLLM/SGLang 后端、TensorRT-LLM、llama.cpp、ds4 |
| 服务与调度 | 队列、准入、批处理、流式输出与接口 | vLLM/SGLang 服务、vLLM-Omni、TEI、模型 server |
| 工作流与平台 | 多步骤处理、素材、多个实例或模型的组合 | ComfyUI、Ray Serve、Dynamo、Triton Inference Server |
| 部署运维 | 环境固定、资源、存储、监控、升级与恢复 | 容器、脚本、必要时的 Kubernetes、网关和对象存储 |
一个项目可覆盖多层。vLLM 和 SGLang 可称为推理与服务框架；llama.cpp 和 ds4 也有 server；ComfyUI 除界面外还有执行引擎。完整部署方案还必须包含权重、版本、硬件、并行参数、接口、资源预算和验收恢复步骤。
Docker 承载运行环境，并不代替模型引擎。统一 API 入口可以连接不同后端，也不意味着后端具有相同能力或性能。
图示文字说明
- 业务调用方 → 请求入口与路由
- 请求入口与路由 → 文本与多模态理解服务
- 请求入口与路由 → 图像与视频任务服务
- 请求入口与路由 → 语音与实时会话服务
- 请求入口与路由 → 向量与重排服务
- 文本与多模态理解服务 → vLLM / SGLang / 对应引擎
- 图像与视频任务服务 → SGLang Diffusion / vLLM-Omni / 对应流水线
- 语音与实时会话服务 → 原厂语音运行时 / 适配后的多模态服务
- 向量与重排服务 → TEI / pooling / 对应编码器
- vLLM / SGLang / 对应引擎 → 各自分配的计算资源
- SGLang Diffusion / vLLM-Omni / 对应流水线 → 各自分配的计算资源
- 原厂语音运行时 / 适配后的多模态服务 → 各自分配的计算资源
- TEI / pooling / 对应编码器 → 各自分配的计算资源
这是逻辑职责图，不要求一开始部署四组独立平台。规模小时可减少组件，规模增加后按实际资源瓶颈拆分。
3. PyTorch 为什么用于推理？能否不用？
训练完成后仍要执行矩阵乘法、注意力等计算。PyTorch 同时提供训练和推理所需的张量、模型及设备运行机制；关闭梯度不会移除这些需要。
采用 PyTorch 的框架可以调用融合内核、CUDA Graph、专用注意力和量化算子。Python 通常组织执行，不表示每个标量都在 Python 中计算。现代 TensorRT-LLM 也采用 PyTorch 原生架构，因此“TensorRT-LLM 一定不需要 PyTorch”不是准确的通用描述。TensorRT-LLM 架构
| 说法 | 应如何理解 |
|---|---|
| 服务依赖 PyTorch | 所选实现需要它，模型在数学上并不限定运行时 |
| 官方容器包含依赖 | 通常无需在宿主 Python 再装一份；宿主仍须有匹配驱动和 GPU 容器支持 |
关闭 torch.compile | 关闭编译优化，不会关闭 PyTorch 或改成 CPU 推理 |
| 使用 Torch SDPA | 选择注意力执行接口与实现路径，不能由名字推断运行在 CPU |
| 使用 C/C++、ggml 或 MLX | 使用另一套模型与算子实现，不会自动获得全部模型支持 |
例如，SGLang Diffusion 的标准 NVIDIA 容器包含扩散依赖，H3 只是其中一个应用。安装说明 原生路线可参考 llama.cpp、MLX-LM及 ds4。应比较完整工作负载，减少 Python 依赖本身不是速度证明。
4. 框架与工具的适用范围
4.1 文本与多模态理解
| 项目 | 主要价值 | 应核查的边界 |
|---|---|---|
| vLLM | 调度、连续批处理、KV 管理、量化、多卡与 API | 架构支持不代表所有工具解析、模态、量化和并行组合都支持 |
| SGLang | 高吞吐服务、前缀缓存、分布式执行与专用优化 | 缓存收益依赖真实前缀和路由；文本与扩散的参数不同 |
| TensorRT-LLM | NVIDIA 平台的模型执行、内核和并行优化 | GPU、后端、版本与功能矩阵；旧式构建流程不适用全部新后端 |
| LMDeploy | 压缩、推理与服务，含 TurboMind/PyTorch 路线 | 两种后端的模型和量化覆盖不同，需要分开查 |
| Transformers | 定义、加载、生成、训练与调试生态 | 适合基线和定制；有 serving 入口不等于已满足目标负载 |
| TGI | 既有文本生成服务栈 | README 标为维护模式，仓库已于 2026-03-21 归档只读；新部署需评估后续维护来源 |
无需所有模型共用一个引擎。可以统一对外契约与观测方式，分别选择内部版本和调度。
4.2 图像、视频与全模态生成
| 项目 | 主要价值 | 需要避免的混淆 |
|---|---|---|
| SGLang Diffusion | 同一 SGLang 仓库和包中的扩散引擎 | sglang[diffusion] 是额外依赖；语言模型走另一执行路径 |
| vLLM-Omni | 多模态、非自回归和多阶段生成服务 | 普通 LLM 命令仅替换模型名，不能获得完整音视频服务 |
| SGLang-Omni | 基于 SGLang 的多阶段语音、Omni 与实时交互运行时 | 独立仓库与安装路径；具体模型的平台、流式和双工能力要按配方核对 |
| Diffusers | 组件化图像、视频和音频生成 | 需匹配 pipeline、权重布局、scheduler、编码器 |
| ComfyUI | 节点工作流、素材处理、创作和 API 执行 | 可以用于服务器；工作流跑通不证明多用户吞吐 |
| FastVideo等专用实现 | 特定模型、内核和加速产物 | Fast/Turbo/少步版可能改变模型、任务与采样条件 |
“理解视频并返回文本”和“生成视频”不同，“输入音频”也不等于“生成音频”。Omni 名称不能代替输入/输出模态、流式与双工能力的检查。
SGLang Diffusion 侧重扩散生成执行；SGLang-Omni 负责预处理、模型、talker/codec/vocoder 等多阶段服务与会话。两者属于同一项目生态，但不能互换安装项和启动命令。SGLang-Omni 架构与入口
4.3 原生、轻量与异构路线
| 项目 | 场景 | 选型依据 |
|---|---|---|
| llama.cpp | GGUF、多硬件、量化、CPU/GPU 混合 | 精确模型支持、质量、内存与实际负载 |
| Ollama | 简化模型获取、管理与调用 | 具体 tag、后端、是否本地执行及并发策略 |
| MLX-LM | Apple Silicon 语言模型推理与微调 | 结构、转换产物、统一内存与吞吐 |
| ds4 / DwarfStar | 特定大型模型及自有量化产物 | 专门适配范围、后端和该模型的 benchmark |
| KTransformers | CPU/GPU 异构执行与容量优化 | 内存带宽、NUMA、专家分配、负载下的延迟与成本 |
| ONNX Runtime / OpenVINO GenAI | 有匹配导出实现的 CPU、Intel 等平台 | 算子、导出精度、动态形状、硬件后端与服务组合 |
Redis 作者 antirez 的 ds4 现称 DwarfStar，有 CLI、server 和 agent，核心原生实现不依赖 PyTorch。项目刻意适配少数模型，并要求使用其支持的 GGUF 产物，不能作为任意 GGUF 加载器。项目说明
比较时要区分完整模型与 Flash/小型变体、整层多卡放置与 TP、聚合吞吐与每用户速度。某个 DeepSeek 的速度不能代替 GLM 或 Qwen 的结果；有 server 也不证明同负载下胜过其他框架。原生引擎应按目标模型的实测进入选择。
4.4 语音、检索与平台层
| 项目 | 职责 |
|---|---|
| faster-whisper、whisper.cpp | Whisper 的专用执行路线，不能泛化为全部 ASR/TTS 引擎 |
| 原厂语音服务 | 保留声学处理、分块、vocoder、说话人条件与时序契约，入口见媒体目录 |
| TEI | 向量等受支持任务的专用服务；需查具体结构和硬件 |
| vLLM pooling | 支持的向量、分类、打分与重排，输出语义不同于聊天 |
| NVIDIA Dynamo | 分布式服务与路由，协同实际推理后端 |
| Ray Serve | 组织推理引擎、应用服务、资源和扩缩容 |
| NVIDIA Triton Inference Server | 多后端服务与执行组织；模型能力取决于后端 |
NVIDIA Triton Inference Server 与 Triton GPU 编程语言/编译器是不同项目：前者用于服务，后者用于编写和编译算子。
5. 逐模型核对“支持”
可用配置应描述为：精确权重/revision × 任务与模态 × 框架版本 × GPU 与互联 × 精度和内核 × 模板/processor/parser × 并行和负载。
| 查到的信息 | 仍需核对 |
|---|---|
| 支持一个架构类 | 新型号是否更换 attention、MoE、记忆模块或视觉编码器？ |
| 支持 FP4 / FP8 / GGUF | 哪种格式、哪些组件、什么后端和 GPU？ |
| 模型卡列出框架 | 是否要指定 commit、nightly、额外内核或转换？ |
| OpenAI 兼容 API | 工具参数、reasoning、usage、流结束、取消和错误语义？ |
| 1M 上下文 | 原生、扩展或托管能力？目标并发下能否容纳？ |
| 多模态示例 | 理解还是生成？流式、首尾帧、参考素材或实时打断？ |
| 自动生成的安装代码 | 是否与真正 README 的支持限制相符？ |
优先读取发布者正文及对应配方，再核对具体版本。main 已有实现，不代表现有固定镜像已包含它。
6. 硬件选择：容量、架构和互联
MoE 只激活部分专家，但未激活专家仍需按部署策略存储或加载。**激活参数量用于理解计算成本，不能替代完整权重容量。**整套模型还可能包含视觉/音频编码器、VAE/vocoder、投影、记忆模块和草稿模型，不能只按主干名称估算。
| 内存部分 | 主要影响因素 |
|---|---|
| 权重与元数据 | 全部组件、精度、scale、分组和打包形式 |
| KV 或序列状态 | 上下文、并发、状态精度及架构 |
| 激活和工作区 | 输入长度、媒体规格、batch、算子、prefill 峰值 |
| 通信和图缓存 | TP/EP/序列并行、CUDA Graph 等执行方式 |
| 服务与编解码 | 预处理、视频帧、音频缓冲、队列和结果 |
可使用算力工具作容量初步估算。标准 GQA KV 公式不能直接套到所有 MLA、SSM/Mamba、滑窗、混合注意力和视频模型；多卡显存相加也不是可任意分配的一块显存。
| 平台 | 首先确认 |
|---|---|
| NVIDIA 数据中心 GPU | 完整容量、带宽、算力、NVLink/NVSwitch、精度内核与通信 |
| NVIDIA 工作站/消费卡 | 对应 SM 内核、PCIe/NUMA、单卡峰值与 P2P；不照搬数据中心配方 |
| AMD / ROCm | 具体模型、量化、attention/MoE 算子及框架版本 |
| Ascend 等 NPU | 插件/原生框架支持、CANN 等运行栈与集合通信 |
| Apple Silicon | 统一内存、带宽、转换产物与 MLX/Metal 实现 |
| CPU/GPU 混合 | CPU 内存带宽、NUMA、算子、搬运与并发退化 |
| 多节点 | 跨机带宽/延迟、RDMA、集合通信、KV/专家传输及故障处理 |
SGLang 硬件入口与 vLLM Ascend可用于发现平台路线；平台受支持不保证每个模型功能相同。量化约束另见 vLLM 量化支持。
远端硬件尚未选定时，先确定质量和请求分布，再比较整套配置成本。最大显存、最少卡数和最高标称算力分别只是一个条件。
7. 并行、缓存和生成优化
| 术语 | 含义 | 取舍 |
|---|---|---|
| Prefill / Decode | 多数自回归模型先处理输入，再生成 token | 两阶段瓶颈不同 |
| TP，张量并行 | 将层内计算和权重拆到多设备 | 容量/延迟收益与通信 |
| DP，多副本 | 多实例分担请求，每个实例也可由多卡组成 | 吞吐与复制权重的容量 |
| PP，流水线并行 | 按层将模型分成设备上的不同阶段 | 传输与流水线空闲；整层放置不自动带来流水线加速 |
| EP，专家并行 | 分布 MoE 专家 | 负载不均与 token 路由通信 |
| Ulysses/Ring 等序列并行 | 分担长序列相关计算 | 激活容量与互联成本 |
| Continuous batching | 执行中动态加入/移除请求 | 利用率改善随模型和规格变化 |
| 前缀缓存 | 复用匹配前缀的状态 | 真实可复用输入、容量和路由 |
| MTP 与推测解码 | MTP 可提出候选，再由目标路径验证 | 接受率、验证开销和负载；两者不是同义词 |
| 编译/图捕获 | 减少部分执行或调度开销 | warmup、内存、动态形状和兼容性 |
| 扩散缓存/近似注意力 | 减少或复用部分去噪计算 | 某些策略引入近似，需质量验证 |
并发数、batch 大小和到达率不同：接收很多请求却让大部分排队，不等于 GPU 在高效并发执行。固定 8 卡预算下，可研究一个 8 卡实例与两个 4 卡实例，但要先证实各实例完整流水线能放下。
单请求最快不一定意味着总产出最高。长视频去噪可能已占满计算资源，增大 batch 未必获得语言模型短 token 解码的收益。推测解码也要区分保持目标分布的算法与含近似采样的实现，不能只看名字就承诺质量不变。
8. 量化、蒸馏与高效型号
| 对象 | 需要记录 |
|---|---|
| 权重量化 | 哪些组件、位宽、分组、校准、量化工具与 revision |
| 激活精度 | 真正的低精度计算，还是低精度权重加载后转高精度执行 |
| KV/序列状态精度 | 与权重独立；长上下文和并发质量可能单独变化 |
| 文件格式 | safetensors、GGUF 等容器与量化算法是不同维度 |
| 实际内核 | 对应 GPU、结构、维度与精度是否有高效实现 |
| 质量证据 | 原始基线、业务样本、设置、差异与失败模式 |
FP4、INT4、NVFP4、MXFP4、AWQ/GPTQ、GGUF 的量化不能仅按“4 bit”互换。节省显存也可能增加反量化或通信瓶颈，应测试完整负载。量化与硬件支持
不同发布者的同名量化不共享质量结论。GLM-5.3 的不同 NVFP4 产物就是独立候选；gpt-oss 的原生 MXFP4 也不能任意替换成别的 FP4 文件。NVIDIA GLM 模型卡、gpt-oss 官方资料
Flash、Mini、Small、Nano、Turbo 可能代表架构、训练、尺寸或采样路线变化，不一定是原模型量化版。少步蒸馏还可能依赖专用 scheduler、attention 或 adapter。接受量化不等于已接受能力改变的蒸馏模型；FastH3、LTX 的不同产物等都应单独核对任务范围，详见媒体目录。
“经过验证”至少指来源可追溯、目标运行路径正确、业务质量对照通过、目标规格/并发稳定且有实际收益。公开评测帮助选择候选，目标质量与负载验证决定能否采用。
9. 不同任务怎样选模型？
| 任务 | 模型筛选重点 | 容易忽略的服务成本 |
|---|---|---|
| 问答、推理 | 正确率、语言、指令遵从、思考预算 | reasoning 长度、可见答案等待、前缀命中 |
| 代码、Agent | 代码运行结果、工具协议、多轮成功率 | 工具等待、上下文增长、累计失败与重试 |
| VLM、OCR、文档 | 页面、图表、细字、版面、坐标、结构化字段 | 预处理、多页切分、视觉 token 和编码 |
| Embedding / Reranker | Recall/nDCG、跨语言、长文、查询与文档语义 | 长度、候选数、索引构建、级联重排 |
| 图像生成/编辑 | 提示遵从、文字、人物/物体、编辑保留程度 | 文本编码、VAE、参考图片、分辨率 |
| 视频/音视频 | 时间一致性、运动、参考遵从、音画同步 | 序列长度、去噪、编解码、传输、排队 |
| ASR | WER/CER、语言/口音、噪声、时间戳、说话人 | 分块、VAD、长音频与实时流状态 |
| TTS/语音交互 | 自然度、发音、音色、轮流说话与打断 | 首音频、分块、vocoder、缓冲与并发 |
通用问答榜不能代替代码或 OCR 验收，视觉理解分数不能代替生成质量。语音交互可采用 ASR→LLM→TTS 或原生语音模型，二者的组件优化空间、韵律和时序契约不同。
大型旗舰可作质量上限对照，高效型号用于测试吞吐/成本，专项模型负责特定环节。只有任务可分流且测得收益时，才增加路由与级联复杂度。
10. 怎样进行有效对比？
10.1 固定身份与条件
记录权重仓库/revision、所有组件、量化、镜像 digest、框架 commit、GPU/拓扑、精度与内核、并行/实例数、请求集、长度预算和采样设置。
分别比较“同一硬件的软件方案”和“达到同一业务目标的整套成本”。不同卡数、租价、精度和质量不能用裸 token/s 混排。
10.2 指标口径
| 指标 | 正确的用法 |
|---|---|
| TTFT | 请求发起到首个生成 token；HTTP 首字节或空 SSE 不算 |
| 首个可见答案 | 思考型模型另计，区分 reasoning 与最终内容 |
| 每用户 token/s / token 间隔 | 观察有其他请求时的体验；一个流式块不一定是一个 token |
| 聚合输出 token/s | 固定统计窗口，明确是否包含 reasoning |
| 合格媒体产出 | 固定规格，包含失败和不合格率，必要时按合格时长归一化 |
| 首音频与 RTF | 记录启动等待、处理时间/音频时长，另测连续供给 |
| 向量/重排吞吐 | 固定长度、候选规模，注明文档/query-doc 对/token 口径 |
| P50/P95/P99 | 端到端与排队分开统计，样本量足以支持分位数 |
| 单位成本 | 同一计费窗口、资源、合格结果和有效利用率 |
跨模型 tokenizer 不同，token/s 可能不可直接比较；还应比较完成同一任务的时间、成功率和成本。不能用一种模型的 tokenizer 估算另一种模型而不注明。
有效吞吐指在预先确定的质量、延迟和错误率条件内，单位时间完成的合格工作量。同步报告总提交、成功、失败、截断与超时，避免只保留成功样本。
10.3 最小实验流程
- 固定业务样本、质量门槛、延迟与预算，选少量候选。
- 用有依据的原始/发布精度跑通，验收真实输出、流式与所需子功能。
- 比较业务质量，将不达标配置排除在最终性能排序之外。
- 分开记录冷启动、首次编译/warmup 和稳态。
- 逐步增加并发，例如 1、2、4、8，资源或服务目标不满足时结束该配置加压。
- 按真实到达率、突发和长短请求混合测试；仅完成一个再发一个的闭环负载可能掩盖排队问题。
- 分别比较缓存命中/未命中、多副本/多卡、原始/量化、MTP 等，一次改变可归因的因素。
- 观察稳态、取消/失败恢复和成本，保留原始证据后决策。
视频/语音应把预处理、编解码和输出可获取时间计入端到端体验。相同 seed、同名质量档或同样步数不保证跨框架同语义、同输出。
11. 面向远端速度与并发的推荐顺序
- 按任务选组合。 从两个模型目录中取质量候选和高效候选，必要时加专项模型。
- 优先匹配现成配方。 文本/VLM 首看该型号的 vLLM/SGLang；媒体首看对应扩散/多模态服务与原厂实现；语音和检索走专用路径。
- 硬件与精度一并选择。 完整驻留、每卡峰值、内核和互联优先于纸面总算力。
- 测目标负载后决定加速。 量化、MTP、batch、DP/TP/EP 的效果随模型和并发变化。
- 用有效吞吐取舍。 工具正确性、视频质量或尾延迟不达标，峰值吞吐再高也不能成为最终依据。
- 有规模证据再扩平台。 多实例、缓存路由或资源争用出现后，再评估分布式服务层。
不能预先认定某框架全球最快，也不能认定原生引擎只能个人使用。候选顺序用于降低验证成本，最终由精确组合的结果决定。
原讨论中的 H3 与 GLM-5.3 是两个例子：H3 可从 SGLang Diffusion 对比 vLLM-Omni；GLM 可用同一 FP8 比较 vLLM/SGLang，再评估具体 NVFP4。方法同样适用于 DeepSeek、Qwen、Kimi、Mistral、Gemma、Nemotron、FLUX、Wan、LTX 和语音模型，具体支持以各目录来源为准。
12. 知识、手册与运行证据的分工
本指南维护方法，两个模型目录维护能力与官方入口。具体服务器的版本、脚本与运行记录保存在各自部署项目中，实际状态以对应环境的验收证据为准。
| 实际采用候选时 | 记录内容 |
|---|---|
| 目标 | 任务、质量、长度/规格、请求率、延迟和预算 |
| 身份 | 全部组件、revision、量化、镜像与框架版本 |
| 环境 | GPU/显存/互联、CPU/RAM、存储、实例和并行 |
| 口径 | warmup、样本数、时间、缓存、token/媒体范围 |
| 结果 | 质量、错误率、尾延迟、有效吞吐、峰值显存、成本 |
| 证据 | 请求、原始响应/生成文件、日志、配置、复现入口 |
| 决策 | 采用/备选/排除，适用范围与复核条件 |
升级权重、硬件、内核或镜像后，旧结果只作历史参考。文中 main/latest 链接用于发现能力，真正部署必须固定具体版本。