自托管服务选型

自托管服务选型

本节摘要:引擎选型是硬件、规模、生态的函数——不是排行榜朗读。2026 自托管推理由四个引擎主导:llama.cpp、Ollama、vLLM、SGLang,TGI 处于维护模式殿后。llama.cpp 在 CPU 上最快——模型支持最广,对量化与线程有完全控制。Ollama 是开发本机的一键安装,比 llama.cpp 慢 15~30%(Go + CGo + HTTP 序列化),类生产负载下吞吐差 3 倍。TGI 在 2025 年 12 月 11 日进入维护模式——只修 bug,原始吞吐比 vLLM 慢约 10%,但历史上有顶级可观测性与 HF 生态集成。这个维护状态让它成为长期下注的风险——新项目用 SGLang 或 vLLM 更安全。vLLM 是通用生产默认——v0.15.1(2026 年 2 月)加了 PyTorch 2.10、RTX Blackwell SM120、H200 优化。SGLang 是智能体多轮/前缀密集专长——生产中 40 万+ GPU(xAI、LinkedIn、Cursor、Oracle、GCP、Azure、AWS)。硬件约束:CPU 优先→llama.cpp;AMD/非 NVIDIA→vLLM 是支持最强的路径(TRT-LLM 锁 NVIDIA)。2026 流水线模式:开发=Ollama,staging=llama.cpp,生产=vLLM 或 SGLang。各引擎权重格式不同——llama.cpp 家族用 GGUF,GPU 引擎用 HF safetensors——所以阶段间可能夹一次格式转换。

对应原课程:Phase 17 · Lesson 28 · 28-self-hosted-serving-selection(原英文 phases/17-infrastructure-and-production/28-self-hosted-serving-selection/docs/en.md)。本节同时作为第 18 章「基础设施与生产化」的收尾。

学习目标

阅读完本节,你应当能够:

1. 给定硬件(CPU / AMD / NVIDIA Hopper / Blackwell)、规模(1 用户 / 100 / 1 万)、工作负载(通用聊天 / 智能体 / 长上下文),选出引擎。
2. 说出 2026 年 TGI 维护模式状态(2025 年 12 月 11 日),以及它为何把新项目推向 vLLM 或 SGLang。
3. 描述开发/staging/生产流水线,包括 GGUF 转 safetensors 的格式转换在阶段间位于何处。
4. 解释为何「CPU 优先」指向 llama.cpp,「AMD」排除 TRT-LLM。

一、问题与直觉

你的团队启动一个新的自托管 LLM 项目。一个工程师说 Ollama,另一个说 vLLM,第三个说「TGI 开箱即用不行吗?」三人各自在不同语境下都对,没有一个人在所有语境下对。

2026 年选择树很要紧:硬件第一,规模第二,工作负载第三。还有一个 2025 年的具体事件——TGI 在 12 月 11 日进入维护模式——改变了新项目的默认。

二、核心概念

五个引擎

硬件优先决策

CPU 优先 → llama.cpp。Ollama 也可但更慢。其他引擎在 CPU 上无竞争力。

AMD GPU → vLLM 是支持最强的路径(AMD ROCm)。SGLang 也可。TRT-LLM 锁 NVIDIA,排除。

NVIDIA Hopper(H100/H200) → vLLM 或 SGLang 或 TRT-LLM。三者顶级。

NVIDIA Blackwell(B200/GB200) → TRT-LLM 是吞吐领导者(第 07 节)。vLLM 与 SGLang 紧随。

Apple Silicon(M 系列) → llama.cpp(Metal)。Ollama 包装它。

规模其次决策

1 用户 / 本地开发 → Ollama。一条命令,首 token 秒级。

10~100 用户 / 小团队 → vLLM 单 GPU。

100~1 万用户 / 生产 → vLLM production-stack(第 18 节)或 SGLang。

1 万+ 用户 / 企业 → vLLM production-stack + 分离式预填充解码(第 17 节)+ LMCache(第 18 节)。

工作负载第三决策

通用聊天 / 问答 → vLLM 在广义默认上胜出。

智能体多轮(工具、规划、记忆) → SGLang 的 RadixAttention(第 06 节)统治。

带重度前缀复用的 RAG → SGLang。

代码生成 → vLLM 够用;SGLang 在缓存上略优。

长上下文(128K+) → vLLM + 分块预填充;SGLang + 分层 KV。

TGI 维护陷阱

Hugging Face TGI 在 2025 年 12 月 11 日进入维护模式——往后只修 bug。历史:顶级可观测性、最好的 HF 生态集成(模型卡、安全工具)、原始吞吐略逊 vLLM。

2026 新项目:默认避开 TGI。现有 TGI 部署可继续但应最终迁移。SGLang 与 vLLM 是更安全的默认。

流水线模式

开发(Ollama)→ staging(llama.cpp)→ 生产(vLLM)。各引擎权重格式不同——llama.cpp 家族用 GGUF,GPU 引擎用 HF safetensors——所以阶段间可能夹一次格式转换。工程师在本机快速迭代;staging 镜像生产量化;生产是服务目标。

Ollama 的告诫

Ollama 适合开发。它不适合共享生产:Go HTTP 序列化加开销,并发管理比 vLLM 简单,OpenTelemetry 支持滞后。在它擅长处用它——单用户、一条命令——共享场景切到 vLLM。

自托管 vs 托管是另一个决策

第 01 节(托管超大规模)、第 02 节(推理平台)覆盖托管。本节假设你已决定自托管。自托管的理由:数据驻留、定制微调、规模下的总拥有成本、托管上没有的领域模型。

你该记住的数字

• TGI 维护模式:2025 年 12 月 11 日。
• vLLM v0.15.1:2026 年 2 月;PyTorch 2.10;Blackwell SM120 支持。
• SGLang 生产足迹:40 万+ GPU。
• Ollama 相对 llama.cpp 的吞吐差:慢 15~30%;生产负载下 3 倍。

三、从零实现:决策树遍历器

原课程 code/main.py 是一个决策树遍历器:给定硬件 + 规模 + 工作负载,选引擎并解释。下面给最小可读的遍历骨架。

def pick_engine(hardware, scale, workload):
    """依硬件→规模→工作负载选自托管引擎。

    hardware: 'cpu' | 'amd' | 'hopper' | 'blackwell' | 'apple'
    scale:    'dev' | 'small' | 'prod' | 'enterprise'
    workload: 'chat' | 'agent' | 'rag' | 'code' | 'longctx'
    返回: (引擎, 理由)
    """
    # 硬件优先
    if hardware == "cpu" or hardware == "apple":
        return "llama.cpp", f"{hardware} 上 CPU 最快,模型支持最广(Ollama 也可但慢 15~30%)"
    if hardware == "amd":
        return "vLLM", "AMD ROCm 支持最强;TRT-LLM 锁 NVIDIA 已排除"
    if hardware == "blackwell":
        return "TRT-LLM", "Blackwell 吞吐领导者(第07节);vLLM/SGLang 紧随"
    # Hopper:看工作负载
    if workload in ("agent", "rag"):
        return "SGLang", "RadixAttention 在多轮/前缀密集上统治(第06节)"
    if scale == "enterprise":
        return "vLLM production-stack + 分离式 + LMCache", "企业级叠加(第17、18节)"
    return "vLLM", "通用生产默认(v0.15.1, 2026-02)"


# 案例:12 块 H100 + 智能体多轮工作负载
print(pick_engine("hopper", "prod", "agent"))   # SGLang
print(pick_engine("amd",   "prod", "chat"))     # vLLM
print(pick_engine("cpu",   "dev", "chat"))      # llama.cpp
​

💡 决策顺序很重要:先硬件(它排除最多选项——CPU 排除所有 GPU 引擎,AMD 排除 TRT-LLM),再规模(决定单卡还是生产栈),最后工作负载(在剩下的引擎里按专长挑)。反过来问会陷入「我喜欢 X 引擎」的偏见。

四、框架对比:五大引擎横向对照

心法:CPU 选 llama.cpp;AMD 选 vLLM;Hopper 通用选 vLLM、智能体选 SGLang;Blackwell 选 TRT-LLM。TGI 因维护模式不推荐新项目。Ollama 只在开发用。

五、可复用产物

本节产出 outputs/skill-engine-picker.md(原课程目录)。给定约束,它选引擎并写迁移计划:

1. 决策树遍历:硬件 → 规模 → 工作负载,输出引擎与理由。
2. 权重格式转换:GGUF(llama.cpp 家族)↔ safetensors(GPU 引擎)的转换步骤,定位流水线阶段。
3. 迁移计划:TGI → vLLM/SGLang,或 Ollama 开发 → vLLM 生产,的量化、配置、可观测性差异。
4. 堆叠建议:与第 11 节(多区域 KV 局部性)、第 18 节(LMCache)、第 17 节(分离式预填充解码)的叠加方式。

六、练习

1. 跑通遍历器:用你的硬件/规模/工作负载跑 code/main.py。输出是否符合直觉?

2. 混合硬件:你的基础设施是 12 块 H100 + 8 块 MI300X AMD。选什么引擎?为何 TRT-LLM 出局?

3. 迁移论证:一个团队 2026 年想用 TGI 因为「我们熟」。论证迁移案例。

4. Ollama → vLLM:Ollama 开发到 vLLM 生产:量化、配置、可观测性各变什么?

5. RAG 选型:一个 RAG 产品,P99 前缀长度 8K、跨租户高复用。选引擎并用第 11、18 节叠加。

本节要点回顾

1. 选型是硬件×规模×生态函数:不是排行榜朗读,要先问硬件。
2. 五个引擎:llama.cpp(CPU 最快)、Ollama(开发本机)、TGI(维护模式)、vLLM(生产默认)、SGLang(智能体/前缀)。
3. 硬件优先:CPU→llama.cpp;AMD→vLLM(ROCm);Hopper→三选一;Blackwell→TRT-LLM 领先。
4. 规模其次:dev→Ollama;小团队→vLLM 单卡;生产→vLLM production-stack 或 SGLang;企业→叠加分离式 + LMCache。
5. 工作负载第三:通用聊天→vLLM;智能体多轮/RAG→SGLang RadixAttention;长上下文→vLLM 分块预填充。
6. TGI 维护陷阱:2025 年 12 月 11 日进入维护模式,新项目避开,现有部署应最终迁移。
7. vLLM v0.15.1(2026-02):PyTorch 2.10、Blackwell SM120、H200 优化。
8. SGLang 生产足迹:40 万+ GPU(xAI、LinkedIn、Cursor 等)。
9. Ollama 告诫:慢 15~30%、生产吞吐差 3 倍,只在开发用,共享场景切 vLLM。
10. 流水线模式:开发(Ollama)→ staging(llama.cpp)→ 生产(vLLM/SGLang),阶段间夹 GGUF↔safetensors 格式转换。

本章回顾:基础设施与生产化

至此,第 18 章「基础设施与生产化」28 节全部完成。整章可以压缩成一句话:训出一个模型只完成 10%,剩下 90% 是让它又快又稳又便宜地跑起来。28 节按四个递进层次展开:

1. 平台与经济(01~02):托管 LLM 平台的选型与推理平台经济学——先决定自托管还是托管。
2. 服务内核与加速(03~09):GPU 自动伸缩、PagedAttention/连续批处理、投机解码、RadixAttention、FP8/NVFP4 编译、goodput 指标、生产量化——把单机推理压到极限。
3. 规模化与可观测(10~20):冷启动缓解、多区域 KV 局部性、边缘推理、可观测性、语义缓存、批处理 API、模型路由、分离式预填充解码、vLLM 生产栈 + LMCache、AI 网关、影子/金丝雀渐进部署——把单机拼成可靠的生产系统。
4. 运营化(21~28):A/B 测试、负载测试、AI SRE、混沌工程、安全、合规、FinOps、引擎选型——让系统在真实用户、真实预算、真实法规下长期运行。

贯穿全章的三条主线:

• 测量先于优化:goodput(08)、负载测试(22)、可观测性(13)、FinOps 归因(27)——没有指标就没有决策。
• 渐进与回滚:影子/金丝雀(20)、A/B(21)、混沌工程(24)——任何改动都假设会失败,并预先备好秒级回滚。
• 工程决策=财务+合规决策:FinOps(27)、合规(26)、安全(25)——提示长度、模型选型、出口策略同时是成本、合规、安全杠杆。

下一章(第 19 章「伦理、安全与对齐」)将从「如何把模型上线」转向「上线后如何确保它行为正当」——对齐、红队、价值观、长效监督,与本章的安全/合规/护栏形成自然衔接。