ai-engineering-from-scratch 自建推理如何按硬件、规模与负载选择 llama.cpp、Ollama、vLLM 与 SGLang 引擎【免费下载链接】ai-engineering-from-scratchLearn it. Build it. Ship it for others.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-from-scratch团队启动一个新的自托管 LLM 项目时经常出现这种情况一个工程师说用 Ollama另一个说 vLLM还有人问TGI 不是开箱即用吗。ai-engineering-from-scratch 的 Phase 17 · 28 课Self-Hosted Serving Selection给出的答案是这四者各有适用场景没有通吃的选项。本文沿该课的决策树说明如何按硬件第一、规模第二、负载第三的顺序在 llama.cpp、Ollama、vLLM、SGLang以及 TGI、TRT-LLM 的边界位置中做出可复核的选择。该课的前提是你已经决定自建推理自托管 vs 托管是另一个独立决策分别见 Phase 17 · 01 与 Phase 17 · 02。课列出的前置知识是 Phase 17 中涉及引擎的 04、06、07、09、18 课。准备条件先确认你的三项约束决策树只吃三个输入对照文档定义确认自己属于哪一档维度文档中的取值硬件CPU / Apple SiliconM 系列/ AMD GPU / NVIDIA HopperH100、H200/ NVIDIA BlackwellB200、GB200规模单用户single_user/ 小团队small_team/ 生产production/ 企业enterprise负载通用聊天问答 / agentic 多轮工具、规划、记忆/ 前缀复用重的 RAG / 代码生成 / 128K 长上下文课中同时给出五个引擎的定位作为后文决策的参照引擎适用场景备注文档原述llama.cppCPU / 边缘 / 最小依赖 / 模型支持最广CPU 上最快完全可控Ollama开发笔记本、单用户、一条命令安装比 llama.cpp 慢 15–30%生产类负载下有 3 倍吞吐差距TGIHF 生态、受监管行业2025 年 12 月 11 日进入维护模式vLLM通用生产、100 用户2026 年广泛的生产默认项v0.15.1 发布于 2026 年 2 月SGLangagentic 多轮、前缀复用重的负载生产环境 400,000 GPUxAI、LinkedIn、Cursor、Oracle、GCP、Azure、AWS决策第一层硬件决定下限硬件是最硬的约束文档给出的分支如下CPU 优先→ llama.cpp。Ollama 也能跑但更慢其他引擎在 CPU 上没有竞争力。AMD GPU→ vLLM 是支持最强的路径ROCmSGLang 也可用。TRT-LLM 锁定 NVIDIA直接排除。NVIDIA HopperH100 / H200→ vLLM、SGLM、TRT-LLM 三个都是一线选择。NVIDIA BlackwellB200 / GB200→ TRT-LLM 是吞吐领先者见 Phase 17 · 07vLLM 与 SGLang 紧随其后。Apple SiliconM 系列→ llama.cppMetalOllama 只是对它的封装。文档把其中两条列为硬约束CPU-only → llama.cppAMD → 不能用 TRT-LLM。outputs/skill-engine-picker.md 中的 skill 也把它们写成了硬性拒绝规则并且规定混合硬件部分 AMD、部分 NVIDIA时必须按集群分别做引擎决策不能强行统一成一个引擎。决策第二层规模决定形态硬件定了候选范围后按用户规模进一步收敛1 用户 / 本地开发→ Ollama。一条命令首 token 秒级返回。10–100 用户 / 小团队→ vLLM 单卡。100–10k 用户 / 生产→ vLLM production-stackPhase 17 · 18或 SGLang。10k 用户 / 企业→ vLLM production-stack 解耦式 prefill/decodePhase 17 · 17 LMCachePhase 17 · 18。决策第三层负载决定 vLLM 还是 SGLang在 GPU 生产环境里 vLLM 和 SGLang 同时可行时按负载形态二选一通用聊天 / 问答→ vLLM广泛默认项胜出。agentic 多轮工具、规划、记忆→ SGLang 的 RadixAttention 占优见 Phase 17 · 06。前缀复用重的 RAG→ SGLang。代码生成→ vLLM 可用缓存维度上 SGLang 略好。长上下文128K→ vLLM chunked prefillSGLang tiered KV。2026 年的两个时间点TGI 维护模式与 vLLM v0.15.1文档要求记住的四个数字TGI 维护模式2025 年 12 月 11 日——此后只有 bug 修复。TGI 历史上有顶级可观测性和最好的 HF 生态集成但裸吞吐略低于 vLLM。对新项目默认避开TGI存量 TGI 部署可以继续跑但应规划迁移skill 文档给出的时间线是不紧急但应在 6 个月内启动。vLLM v0.15.12026 年 2 月——支持 PyTorch 2.10、RTX Blackwell SM120、H200 优化。SGLang 生产规模400,000 GPU。Ollama 相对 llama.cpp 的吞吐差距慢 15–30%生产类负载下 3 倍差距。Ollama 的生产边界也值得明确Go HTTP 序列化带来额外开销并发管理弱于 vLLMOpenTelemetry 支持滞后。文档的结论是——Ollama 用在一个用户、一条命令的场景共享生产切到 vLLMskill 文档把它写成硬性拒绝项并发用户数大于 1 的共享生产环境不用 Ollama。dev → staging → prod 的管线模式与权重格式转换文档给出的 2026 年管线模式是dev Ollamastaging llama.cppprod vLLM 或 SGLang。各阶段的分工工程师在笔记本上用 Ollama 快速迭代staging 用 llama.cpp 镜像生产环境的量化prod 才是真正的 serving 目标。需要注意的是各引擎吃不同的权重格式——llama.cpp 系用GGUFGPU 引擎用HF safetensors——所以阶段之间可能夹一次格式转换跨引擎迁移前要先确认权重格式。用决策树脚本验证你的选择该课附带一个纯 stdlib 的 Python 决策树脚本 code/main.py输入硬件 规模 负载输出引擎选择和理由。在仓库根目录运行python3 phases/17-infrastructure-and-production/28-self-hosted-serving-selection/code/main.py脚本内置 7 个场景代码中的SCENARIOS列表逐一走完决策树按main.py的选择逻辑各场景的判定结果如下这是源码逻辑推导供你与终端实际输出对照而非固定日志硬件规模负载脚本判定引擎CPUsingle_userchatOllama (llama.cpp under the hood)Apple Siliconsingle_usercoding assistantOllamaNVIDIA Hopperproductiongeneral chatvLLMNVIDIA Hopperproductionagentic multi-turnSGLangNVIDIA BlackwellenterpriseMoE frontier servingTRT-LLMAMDproductionRAG with heavy prefix reuseSGLangNVIDIA Hoppersmall_teamlong-context 128KvLLM核对方式跑一遍命令确认 7 个场景的输出引擎与上表一致并且每条reasons都指向硬件/规模/负载中的具体一层。课的第一道练习就是这个动作换成你自己的硬件、规模、负载组合跑pick_engine看输出是否符合直觉。产出一页推荐结论engine-picker该课的 Ship It 产物是 outputs/skill-engine-picker.md给定约束产出一页包含引擎选择、排除理由、管线、生产叠加和 TGI 迁移立场的推荐。它的输出结构可以作为你内部评审的模板Engine——点名具体引擎引用硬件/规模/负载三层依据Why not the alternatives——每个被排除的引擎写明排除原因TGI 维护模式、AMD 排除 TRT-LLM、Ollama 仅限开发Pipeline——生产场景写清 dev Ollama → staging llama.cpp → prod vLLM/SGLang并确认权重格式GGUF 或 HF如何流转Production stacking——生产规模时指向 Phase 17 · 18production-stack、· 17disaggregated、· 11cache-aware router做组合TGI migration——存量是 TGI 时给出迁移计划和 6 个月时间线Hardware gotcha——重申 CPU-only 与 AMD 两条硬约束。另有两条兜底规则生产规模下负载为 unknown/general 时默认 vLLM 并计划在 3 个月流量数据后重新评估以及每季度的固定动作——负载形态发生实质变化时重新评估引擎选择。限制与不适用情况本课只做引擎选型不覆盖自托管 vs 托管平台本身的取舍Phase 17 · 01/02和 K8s 部署细节Phase 17 · 18。混合 AMD NVIDIA 集群不存在单一引擎答案必须分集群决策。Ollama 不适用于并发用户数大于 1 的共享生产环境TGI 不适用于 2026 年新项目的默认项TRT-LLM 不适用于非 NVIDIA 硬件。跨 dev/staging/prod 阶段换引擎时GGUF 与 safetensors 的格式转换是文档明确提示的额外工作项选型时应计入迁移成本。下一步选型确定后按所选引擎进入对应深潜课vLLM 内部机制见 Phase 17 · 04SGLang 与 RadixAttention 见 Phase 17 · 06TRT-LLM 与 Blackwell 见 Phase 17 · 07生产量化见 Phase 17 · 09vLLM 生产栈与 LMCache 见 Phase 17 · 18。【免费下载链接】ai-engineering-from-scratchLearn it. Build it. Ship it for others.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-from-scratch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ai-engineering-from-scratch 自建推理如何按硬件、规模与负载选择 llama.cpp、Ollama、vLLM 与 SGLang 引擎？
ai-engineering-from-scratch 自建推理如何按硬件、规模与负载选择 llama.cpp、Ollama、vLLM 与 SGLang 引擎【免费下载链接】ai-engineering-from-scratchLearn it. Build it. Ship it for others.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-from-scratch团队启动一个新的自托管 LLM 项目时经常出现这种情况一个工程师说用 Ollama另一个说 vLLM还有人问TGI 不是开箱即用吗。ai-engineering-from-scratch 的 Phase 17 · 28 课Self-Hosted Serving Selection给出的答案是这四者各有适用场景没有通吃的选项。本文沿该课的决策树说明如何按硬件第一、规模第二、负载第三的顺序在 llama.cpp、Ollama、vLLM、SGLang以及 TGI、TRT-LLM 的边界位置中做出可复核的选择。该课的前提是你已经决定自建推理自托管 vs 托管是另一个独立决策分别见 Phase 17 · 01 与 Phase 17 · 02。课列出的前置知识是 Phase 17 中涉及引擎的 04、06、07、09、18 课。准备条件先确认你的三项约束决策树只吃三个输入对照文档定义确认自己属于哪一档维度文档中的取值硬件CPU / Apple SiliconM 系列/ AMD GPU / NVIDIA HopperH100、H200/ NVIDIA BlackwellB200、GB200规模单用户single_user/ 小团队small_team/ 生产production/ 企业enterprise负载通用聊天问答 / agentic 多轮工具、规划、记忆/ 前缀复用重的 RAG / 代码生成 / 128K 长上下文课中同时给出五个引擎的定位作为后文决策的参照引擎适用场景备注文档原述llama.cppCPU / 边缘 / 最小依赖 / 模型支持最广CPU 上最快完全可控Ollama开发笔记本、单用户、一条命令安装比 llama.cpp 慢 15–30%生产类负载下有 3 倍吞吐差距TGIHF 生态、受监管行业2025 年 12 月 11 日进入维护模式vLLM通用生产、100 用户2026 年广泛的生产默认项v0.15.1 发布于 2026 年 2 月SGLangagentic 多轮、前缀复用重的负载生产环境 400,000 GPUxAI、LinkedIn、Cursor、Oracle、GCP、Azure、AWS决策第一层硬件决定下限硬件是最硬的约束文档给出的分支如下CPU 优先→ llama.cpp。Ollama 也能跑但更慢其他引擎在 CPU 上没有竞争力。AMD GPU→ vLLM 是支持最强的路径ROCmSGLang 也可用。TRT-LLM 锁定 NVIDIA直接排除。NVIDIA HopperH100 / H200→ vLLM、SGLM、TRT-LLM 三个都是一线选择。NVIDIA BlackwellB200 / GB200→ TRT-LLM 是吞吐领先者见 Phase 17 · 07vLLM 与 SGLang 紧随其后。Apple SiliconM 系列→ llama.cppMetalOllama 只是对它的封装。文档把其中两条列为硬约束CPU-only → llama.cppAMD → 不能用 TRT-LLM。outputs/skill-engine-picker.md 中的 skill 也把它们写成了硬性拒绝规则并且规定混合硬件部分 AMD、部分 NVIDIA时必须按集群分别做引擎决策不能强行统一成一个引擎。决策第二层规模决定形态硬件定了候选范围后按用户规模进一步收敛1 用户 / 本地开发→ Ollama。一条命令首 token 秒级返回。10–100 用户 / 小团队→ vLLM 单卡。100–10k 用户 / 生产→ vLLM production-stackPhase 17 · 18或 SGLang。10k 用户 / 企业→ vLLM production-stack 解耦式 prefill/decodePhase 17 · 17 LMCachePhase 17 · 18。决策第三层负载决定 vLLM 还是 SGLang在 GPU 生产环境里 vLLM 和 SGLang 同时可行时按负载形态二选一通用聊天 / 问答→ vLLM广泛默认项胜出。agentic 多轮工具、规划、记忆→ SGLang 的 RadixAttention 占优见 Phase 17 · 06。前缀复用重的 RAG→ SGLang。代码生成→ vLLM 可用缓存维度上 SGLang 略好。长上下文128K→ vLLM chunked prefillSGLang tiered KV。2026 年的两个时间点TGI 维护模式与 vLLM v0.15.1文档要求记住的四个数字TGI 维护模式2025 年 12 月 11 日——此后只有 bug 修复。TGI 历史上有顶级可观测性和最好的 HF 生态集成但裸吞吐略低于 vLLM。对新项目默认避开TGI存量 TGI 部署可以继续跑但应规划迁移skill 文档给出的时间线是不紧急但应在 6 个月内启动。vLLM v0.15.12026 年 2 月——支持 PyTorch 2.10、RTX Blackwell SM120、H200 优化。SGLang 生产规模400,000 GPU。Ollama 相对 llama.cpp 的吞吐差距慢 15–30%生产类负载下 3 倍差距。Ollama 的生产边界也值得明确Go HTTP 序列化带来额外开销并发管理弱于 vLLMOpenTelemetry 支持滞后。文档的结论是——Ollama 用在一个用户、一条命令的场景共享生产切到 vLLMskill 文档把它写成硬性拒绝项并发用户数大于 1 的共享生产环境不用 Ollama。dev → staging → prod 的管线模式与权重格式转换文档给出的 2026 年管线模式是dev Ollamastaging llama.cppprod vLLM 或 SGLang。各阶段的分工工程师在笔记本上用 Ollama 快速迭代staging 用 llama.cpp 镜像生产环境的量化prod 才是真正的 serving 目标。需要注意的是各引擎吃不同的权重格式——llama.cpp 系用GGUFGPU 引擎用HF safetensors——所以阶段之间可能夹一次格式转换跨引擎迁移前要先确认权重格式。用决策树脚本验证你的选择该课附带一个纯 stdlib 的 Python 决策树脚本 code/main.py输入硬件 规模 负载输出引擎选择和理由。在仓库根目录运行python3 phases/17-infrastructure-and-production/28-self-hosted-serving-selection/code/main.py脚本内置 7 个场景代码中的SCENARIOS列表逐一走完决策树按main.py的选择逻辑各场景的判定结果如下这是源码逻辑推导供你与终端实际输出对照而非固定日志硬件规模负载脚本判定引擎CPUsingle_userchatOllama (llama.cpp under the hood)Apple Siliconsingle_usercoding assistantOllamaNVIDIA Hopperproductiongeneral chatvLLMNVIDIA Hopperproductionagentic multi-turnSGLangNVIDIA BlackwellenterpriseMoE frontier servingTRT-LLMAMDproductionRAG with heavy prefix reuseSGLangNVIDIA Hoppersmall_teamlong-context 128KvLLM核对方式跑一遍命令确认 7 个场景的输出引擎与上表一致并且每条reasons都指向硬件/规模/负载中的具体一层。课的第一道练习就是这个动作换成你自己的硬件、规模、负载组合跑pick_engine看输出是否符合直觉。产出一页推荐结论engine-picker该课的 Ship It 产物是 outputs/skill-engine-picker.md给定约束产出一页包含引擎选择、排除理由、管线、生产叠加和 TGI 迁移立场的推荐。它的输出结构可以作为你内部评审的模板Engine——点名具体引擎引用硬件/规模/负载三层依据Why not the alternatives——每个被排除的引擎写明排除原因TGI 维护模式、AMD 排除 TRT-LLM、Ollama 仅限开发Pipeline——生产场景写清 dev Ollama → staging llama.cpp → prod vLLM/SGLang并确认权重格式GGUF 或 HF如何流转Production stacking——生产规模时指向 Phase 17 · 18production-stack、· 17disaggregated、· 11cache-aware router做组合TGI migration——存量是 TGI 时给出迁移计划和 6 个月时间线Hardware gotcha——重申 CPU-only 与 AMD 两条硬约束。另有两条兜底规则生产规模下负载为 unknown/general 时默认 vLLM 并计划在 3 个月流量数据后重新评估以及每季度的固定动作——负载形态发生实质变化时重新评估引擎选择。限制与不适用情况本课只做引擎选型不覆盖自托管 vs 托管平台本身的取舍Phase 17 · 01/02和 K8s 部署细节Phase 17 · 18。混合 AMD NVIDIA 集群不存在单一引擎答案必须分集群决策。Ollama 不适用于并发用户数大于 1 的共享生产环境TGI 不适用于 2026 年新项目的默认项TRT-LLM 不适用于非 NVIDIA 硬件。跨 dev/staging/prod 阶段换引擎时GGUF 与 safetensors 的格式转换是文档明确提示的额外工作项选型时应计入迁移成本。下一步选型确定后按所选引擎进入对应深潜课vLLM 内部机制见 Phase 17 · 04SGLang 与 RadixAttention 见 Phase 17 · 06TRT-LLM 与 Blackwell 见 Phase 17 · 07生产量化见 Phase 17 · 09vLLM 生产栈与 LMCache 见 Phase 17 · 18。【免费下载链接】ai-engineering-from-scratchLearn it. Build it. Ship it for others.项目地址: https://gitcode.com/GitHub_Trending/ai/ai-engineering-from-scratch创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考