LLM 推理工程快速参考指南
8/29/2026, 11:41:30 AM
This article hasn't been translated to English yet — showing the Chinese original.
本文系统梳理了 LLM 推理工程的分层架构与核心概念，从用户端到模型端层层拆解 Runtime、推理引擎及服务器组件，并深入讲解 KV Cache、Quantization、Prefill/Decode 等关键优化技术与性能指标体系。
LLM 推理工程快速参考指南
核心原则：Claude Code 是前端消费者；Ollama、oMLX、llama.cpp、vLLM 等属于后端推理基础设施；Inference Engineering（推理工程）则是把这些组件组合、优化和运营起来的整个工程体系。
1. 一张图理解整个体系
用户
↓
Claude Code
↓
API
↓
推理服务器
↓
推理引擎
↓
推理运行时
↓
计算后端
↓
硬件
↓
模型
对应关系：
Claude Code
│
▼
API / 协议
│
▼
oMLX / Ollama / llama-server / vLLM
│
▼
推理引擎 / Serving
│
▼
MLX-LM / llama.cpp / 其他 Runtime
│
▼
MLX / CUDA / Metal
│
▼
Apple Silicon / NVIDIA GPU
│
▼
Qwen / Llama / DeepSeek
2. 用户看到什么，系统后台做什么？
这是理解 Claude Code + 本地 LLM 最重要的一张表。
层级
用户可见性
主要组件
主要工作
用户
可见
用户
输入任务
Claude Code
可见
Claude Code
Agent、工具调用、文件操作
API
部分可见
API
传递请求和响应
推理服务器
不可见
oMLX、Ollama、vLLM
接收请求、提供模型服务
推理引擎
不可见
oMLX、vLLM、llama-server
调度、批处理、缓存
Runtime
不可见
MLX-LM、llama.cpp
执行模型推理
计算后端
不可见
MLX、CUDA、Metal
执行底层计算
硬件
不可见
Apple GPU、NVIDIA GPU
实际计算
模型
部分可见
Qwen、Llama
生成结果
简单记忆
Claude Code 看到的是：
任务
↓
工具
↓
结果
↓
最终答案
Inference Engineer 看到的是：
请求
↓
Context
↓
Cache
↓
Scheduling
↓
Batching
↓
Inference
↓
GPU
↓
Token
↓
Performance
3. Runtime、Inference Engine、Server 到底有什么区别？
这是最容易混淆的三个术语。
Runtime：负责“把模型跑起来”
核心问题：
模型如何执行？
例如：
-
llama.cpp
-
MLX-LM
-
ONNX Runtime
主要负责：
模型
↓
加载
↓
计算
↓
生成 Token
Inference Engine：负责“高效地跑”
核心问题：
如何让推理更快、更高效、更适合并发？
典型功能：
-
KV Cache
-
Prefix Cache
-
Batching
-
Continuous Batching
-
Scheduling
-
Memory Management
-
Streaming
例如：
-
vLLM
-
SGLang
-
oMLX
-
TensorRT-LLM
Inference Server：负责“让应用访问模型”
核心问题：
Claude Code 或其他应用如何调用模型？
例如：
Claude Code
↓
HTTP API
↓
Inference Server
↓
Model
常见接口：
-
OpenAI API
-
Anthropic API
-
自定义 HTTP API
4. 为什么有些工具同时属于多个类别？
因为实际软件并不会严格按照教科书分层。
例如：
工具
Runtime
Engine
Server
Model Manager
Ollama
是
部分
是
是
oMLX
基于 MLX-LM
是
是
部分
llama.cpp
是
是
是
否
MLX-LM
是
部分
基础
否
vLLM
部分
是
是
否
所以不要纠结：
“llama.cpp 到底是 Runtime 还是 Engine？”
正确理解是：
它从 Runtime 一直覆盖到了 Server。
同理：
oMLX 已经不是单纯 Runtime，而是更完整的 Apple Silicon 推理服务体系。
5. 主要工具的正确定位
Ollama
Ollama
├── 模型管理
├── Runtime
└── API Server
核心特点：
简单、易用、本地模型管理方便。
适合：
-
快速运行模型
-
本地聊天
-
开发测试
-
简单 API
MLX
MLX
└── Apple Silicon 计算框架
核心特点：
Apple Silicon 的底层机器学习计算框架。
它不是 Ollama 的直接替代品。
MLX-LM
MLX
↓
MLX-LM
↓
LLM 推理
核心特点：
在 MLX 上执行 LLM 推理。
更偏向：
-
模型研究
-
推理实验
-
Apple Silicon 优化
-
底层控制
oMLX
MLX
↓
MLX-LM
↓
oMLX
├── API
├── KV Cache
├── Prefix Cache
├── Batching
├── Scheduling
├── 模型服务
└── Agent 支持
核心特点：
针对 Apple Silicon 的 LLM 推理服务器和推理系统。
对于：
Mac Studio
+
Qwen
+
Claude Code
+
Agentic Coding
尤其值得测试。
llama.cpp
llama.cpp
├── Runtime
├── 推理执行
├── KV Cache
├── Quantization
└── Server
核心特点：
高效、跨平台、本地 LLM 推理。
特别适合：
-
GGUF
-
本地电脑
-
Apple Silicon
-
CPU
-
GPU
-
边缘设备
vLLM
vLLM
├── Inference Engine
├── Scheduler
├── Continuous Batching
├── KV Cache
└── Server
核心特点：
高吞吐、高并发、生产级 LLM Serving。
更偏向：
-
NVIDIA GPU
-
数据中心
-
多用户
-
高并发
6. 一个更清晰的技术地图
模型
│
┌──────────┼──────────┐
▼ ▼ ▼
Qwen Llama DeepSeek
│
▼
计算框架
│
┌──────────┴──────────┐
▼ ▼
MLX CUDA
│ │
▼ ▼
MLX-LM CUDA Runtime
│
▼
推理 Runtime / Engine
│
┌─────┼─────┐
▼ ▼ ▼
oMLX llama vLLM
cpp
│ │ │
└─────┼─────┘
▼
推理 Server
│
▼
Claude Code
注意：
实际架构不是严格的单向树。
这是一个逻辑分层图，用于理解术语。
7. Claude Code 实际发生了什么？
假设你输入：
修复我的 Next.js 登录问题。
Claude Code 可能执行：
用户请求
↓
Claude Code
↓
读取文件
↓
分析代码
↓
修改文件
↓
运行测试
↓
读取错误
↓
再次修改
↓
再次测试
↓
完成
用户看到的是：
读取文件
修改文件
运行测试
修复错误
完成
但后台实际上可能是：
Claude Code
↓
API Request
↓
Context Assembly
↓
Prefix Cache
↓
Prefill
↓
KV Cache
↓
Scheduler
↓
Inference Engine
↓
Runtime
↓
GPU
↓
Token Generation
↓
API Response
↓
Claude Code
然后 Agent 又发起下一次请求。
所以：
一次 Claude Code 任务，可能对应几十甚至上百次模型推理。
8. Claude Code 用户看到的世界
┌──────────────────────────────┐
│ Claude Code │
├──────────────────────────────┤
│ │
│ 用户输入 │
│ │
│ Agent │
│ │
│ 工具调用 │
│ │
│ 文件修改 │
│ │
│ Terminal │
│ │
│ 测试结果 │
│ │
│ 最终答案 │
│ │
└──────────────────────────────┘
9. Inference Engineer 看到的世界
┌──────────────────────────────┐
│ Inference System │
├──────────────────────────────┤
│ API Request │
│ Context Length │
│ Prefix Cache │
│ KV Cache │
│ Prefill │
│ Decode │
│ Scheduling │
│ Batching │
│ Quantization │
│ MTP │
│ Speculative Decoding │
│ Memory Usage │
│ GPU Usage │
│ TTFT │
│ Token/s │
│ Throughput │
│ Error Rate │
│ Crash Rate │
│ Uptime │
└──────────────────────────────┘
10. 最关键的两个阶段：Prefill 和 Decode
输入 Context
│
▼
PREFILL
│
▼
KV Cache
│
▼
DECODE
│
├── Token 1
├── Token 2
├── Token 3
├── Token 4
└── ...
Prefill
处理：
模型需要阅读多少内容？
主要影响：
TTFT
Decode
处理：
模型生成 Token 的速度。
主要关注：
Token/s
11. KV Cache 是什么？
简单理解：
把模型已经计算过的上下文中间结果保存下来，避免重复计算。
第一次请求
Context
↓
计算
↓
KV Cache
第二次：
相同 Context
↓
读取 KV Cache
↓
只计算新增内容
对于 Claude Code：
System Prompt
+
Tools
+
Project Context
+
Conversation
大量内容可能重复。
所以 KV Cache 非常重要。
12. Prefix Cache 是什么？
Prefix Cache 更强调：
重复的 Prompt 前缀可以直接复用。
例如：
第一次：
System
+
Tools
+
Project
+
Task A
↓
Cache
第二次：
System
+
Tools
+
Project
+
Task B
↓
复用前面的 Cache
对于 Agentic Coding：
Prefix Cache 往往非常重要。
13. Speculative Decoding
核心思想：
大模型
▲
│ 验证
│
小模型
│
▼
猜测多个 Token
小模型先猜：
A B C D E
大模型验证。
猜得越准：
大模型生成速度越快。
14. MTP
MTP：
Multi-Token Prediction
简单理解：
模型尝试一次预测多个未来 Token。
它和 Speculative Decoding 都属于：
推理加速技术
15. Quantization
量化：
FP16
↓
INT8
↓
INT4
目的：
-
减少内存
-
提高运行效率
-
让更大的模型进入本地内存
-
降低部署成本
但要平衡：
模型质量
↕
模型大小
↕
推理速度
↕
内存占用
16. Claude Code 中最重要的隐藏链路
Claude Code
↓
API
↓
Context
↓
Prefix Cache
↓
Prefill
↓
KV Cache
↓
Scheduler
↓
Batching
↓
Inference Engine
↓
Runtime
↓
MLX / llama.cpp / CUDA
↓
GPU
↓
Qwen
↓
Token
↓
API
↓
Claude Code
这条链路基本就是：
Inference Pipeline（推理流水线）
17. 从用户角度看，什么是“快”？
用户只知道：
“Claude Code 很快。”
但是工程师需要拆成：
快
│
├── TTFT 快
│
├── Prefill 快
│
├── Decode 快
│
├── KV Cache 命中率高
│
├── Prefix Cache 命中率高
│
├── Scheduling 好
│
├── Memory 没有压力
│
└── API 没有重试
所以：
“快”不是一个指标。
18. Inference Engineering 最重要的指标
指标
中文
说明
TTFT
首 Token 延迟
从请求到第一个 Token
Prefill TPS
预填充速度
处理输入的速度
Decode TPS
解码速度
生成 Token 的速度
Token/s
Token 每秒
常用速度指标
TPOT
每 Token 时间
Token 间平均时间
Throughput
吞吐
系统整体处理能力
Context
上下文长度
当前请求包含多少信息
KV Cache
KV 缓存
Attention 中间结果
Cache Hit
缓存命中
成功复用缓存
Memory
内存
模型和 Cache 占用
Concurrency
并发
同时处理多少请求
Error Rate
错误率
API/推理错误
Crash Rate
崩溃率
Server/Runtime 崩溃
Uptime
在线时间
长时间运行稳定性
19. 用户看到的症状 vs 后台可能的问题
用户看到
后台可能的问题
API failed
Server、API、Runtime
Claude Code 卡住
Context、KV Cache、Memory
越用越慢
Context 增长、Cache、Memory
模型突然退出
Runtime、Memory
API timeout
Server、Scheduler、Inference
Token 很慢
Runtime、Quantization、Hardware
长时间后崩溃
Memory、Cache、Runtime
Tool calling 失败
API 协议、模型、Server
Streaming 失败
API、Server、Runtime
新模型不能运行
Runtime/模型兼容性
模型能跑但 Agent 不稳定
Server/API/Tool/Context
20. 你的 Ollama + MLX 问题应该怎么定位？
你现在遇到：
API Calls Failed
Crash
运行不稳定
不要直接判断：
“MLX 不行。”
应该逐层排查：
Claude Code
↓
API
↓
Server
↓
Inference Engine
↓
Runtime
↓
MLX
↓
Memory
↓
Apple Silicon
然后逐层测试。
21. 最推荐的四套实验环境
你的情况可以建立四条独立测试路线。
A：Ollama
Claude Code
↓
Ollama
↓
Qwen
↓
Apple Silicon
B：oMLX
Claude Code
↓
oMLX API
↓
oMLX
↓
MLX-LM
↓
MLX
↓
Apple Silicon
C：llama.cpp
Claude Code
↓
llama-server
↓
llama.cpp
↓
Qwen
↓
Apple Silicon
D：MLX-LM
测试程序
↓
MLX-LM
↓
MLX
↓
Apple Silicon
D 更适合：
底层性能研究
而不是直接作为 Claude Code 的完整生产服务层。
22. 最重要的 Benchmark 思路
不要只比较：
Qwen 27B
vs
Qwen 35B
应该比较：
同一个模型
│
├── Ollama
│
├── oMLX
│
├── llama.cpp
│
└── MLX-LM
然后保持：
-
相同模型
-
相同量化
-
相同 Context
-
相同 Prompt
-
相同 Agent
-
相同硬件
-
相同测试时间
最后比较：
TTFT
Prefill
Decode
Token/s
Memory
KV Cache
Cache Hit
API Stability
Agent Stability
24h Stability
72h Stability
23. Inference Engineering 的完整流程
这是建议你长期保存的 Process Map。
① 定义 Workload
↓
② 选择 Model
↓
③ 选择 Runtime
↓
④ 选择 Inference Engine
↓
⑤ 建立 API Server
↓
⑥ 接入 Claude Code / Agent
↓
⑦ 建立 Baseline
↓
⑧ 测量性能
↓
⑨ 优化 Cache / Context / Decode
↓
⑩ 优化 Memory / Scheduling
↓
⑪ Benchmark
↓
⑫ Stress Test
↓
⑬ 24/72 小时稳定性测试
↓
⑭ Production
24. 出问题时的标准流程
发现问题
↓
确认 API
↓
确认 Server
↓
确认 Engine
↓
确认 Runtime
↓
确认 Model
↓
检查 Context
↓
检查 KV Cache
↓
检查 Memory
↓
检查 GPU
↓
重新 Benchmark
不要直接换模型。
先确定：
到底是哪一层出了问题。
25. 最终“工具定位”速查表
工具
最准确的理解
重点
Qwen
模型
AI 能力
MLX
计算框架
Apple Silicon
MLX-LM
LLM 推理层
MLX 上运行 LLM
llama.cpp
Runtime + Engine + Server
高效本地推理
Ollama
Runtime + Server + 模型管理
简单易用
oMLX
Apple Silicon Inference Server/Engine
Mac 高性能推理
vLLM
Inference Engine + Server
高吞吐服务器
SGLang
Inference Engine + Server
高性能/Agent
CUDA
GPU 计算平台
NVIDIA
Metal
GPU 计算 API
Apple
KV Cache
推理优化
减少重复计算
Prefix Cache
推理优化
复用 Prompt
Quantization
推理优化
降低内存
MTP
推理加速
多 Token
Speculative Decoding
推理加速
小模型辅助大模型
Batching
Serving 优化
多请求一起处理
Scheduling
Serving 优化
请求调度
Model Routing
系统设计
决定使用哪个模型
Benchmark
工程测试
测性能
Stress Test
工程测试
测稳定性
Inference Engineering
完整工程体系
全部组合起来
26. 最终记忆公式
以后看到任何新工具，先问：
它是什么？
↓
模型？
↓
计算框架？
↓
Runtime？
↓
Inference Engine？
↓
Server？
↓
Optimization？
↓
Orchestration？
然后再问：
它解决什么问题？
↓
速度？
内存？
Context？
Cache？
并发？
API？
稳定性？
最后问：
它对我的 workload 有什么价值？
↓
Claude Code
↓
Agentic Coding
↓
Qwen
↓
Apple Silicon
↓
长 Context
↓
长时间运行
27. 一张最终速查图
用户
│
▼
Claude Code
│
▼
API
│
▼
┌────────────────────┐
│ Inference Server │
│ │
│ oMLX │
│ Ollama │
│ llama-server │
│ vLLM │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Inference Engine │
│ │
│ Scheduling │
│ Batching │
│ KV Cache │
│ Prefix Cache │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Inference Runtime │
│ │
│ MLX-LM │
│ llama.cpp │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Compute Backend │
│ │
│ MLX / Metal │
│ CUDA │
└─────────┬──────────┘
│
▼
硬件
│
▼
模型
│
▼
Token 输出
│
▼
Claude Code
最终记忆：
用户看到：
Claude Code → Agent → Tool → Result
应用开发者看到：
Claude Code → API → Server → Model
Inference Engineer 看到：
API
↓
Context
↓
Cache
↓
Scheduling
↓
Batching
↓
Engine
↓
Runtime
↓
Backend
↓
Hardware
↓
Model
而：
Inference Engineering（推理工程）就是对这整条链路进行设计、测量、优化、故障排查和长期运行管理。
对于你的 Mac Studio + Qwen + Claude Code + Agentic Coding 场景，真正值得研究的不是单独的 Ollama、MLX 或 oMLX，而是：
Model
+
Runtime
+
Inference Engine
+
Server
+
Context
+
KV Cache
+
Prefix Cache
+
Scheduling
+
Decoding
+
Memory
+
Hardware
+
Agent
+
Benchmark
+
Reliability
↓
Inference Engineering
这套结构以后基本可以作为你阅读任何 LLM 推理、oMLX、MLX、llama.cpp、vLLM、Qwen、Agentic Coding 文章时的“坐标系”。
Learning map
LLM 推理工程学习路线图
第一阶段：建立分层认知框架（1-2 周）
目标： 理解整条推理链路中每一层组件的角色与职责
- 区分用户可见层与应用层（Claude Code → API）
- 理解 Inference Server 的作用与常见实现（Ollama、llama-server、vLLM）
- 认识 Runtime 与推理引擎的区别（llama.cpp/MLX-LM vs vLLM/SGLang）
- 了解底层计算框架（MLX、CUDA、Metal）与硬件的关系
第二阶段：核心概念突破（2-3 周）
目标： 掌握推理过程中最关键的技术概念
- KV Cache 原理——缓存已计算的上下文避免重复
- Prefix Cache 作用——复用相同 Prompt 前缀加速推理
- Prefill & Decode 两阶段执行模型
- Quantization（量化）机制与质量/速度的权衡
- Speculative Decoding 和 MTP 等加速技术
第三阶段：性能指标与实践掌握（2-3 周）
目标： 能用正确指标评估和优化推理系统
- TTFT（首 Token 延迟）、Token/s、Throughput 的含义与测量方法
- Context 长度、Memory 占用对性能的影响分析
- Concurrency 和 Scheduling 优化策略
- 搭建完整的 Benchmark 测试：统一模型/量化/Prompt/硬件进行横向对比
- 24h/72h 压测方法评估系统稳定性
第四阶段：实战与排错（持续）
目标： 实际部署推理服务并排查问题
- 搭建多环境测试路线（Ollama / oMLX / llama.cpp / MLX-LM）
- 逐层问题定位方法：API → Server → Engine → Runtime → Model
- 常见用户症状与后台问题的对应关系分析
- 标准排查流程实践并积累排错经验
Get hands-on — step by step
LLM 推理工程实操指南
步骤 1：理解你的推理栈层级
打开任意一家主流推理框架的文档（如 Ollama 或 vLLM），对照文章中的层级图逐层查看各组件在代码层面的对应关系。确认你的硬件支持——Apple Silicon 看 MLX/Metal，NVIDIA GPU 看 CUDA/CUDA Runtime。
步骤 2：选择一个基础推理框架并部署
从 Ollama 或 llama.cpp 开始，拉取一个开源模型（如 Qwen 或 Llama），用最小配置运行起来。验证你能正常发起 API 请求并得到 Token 输出。这是理解整个链路最直接的起点。
步骤 3：测量核心性能指标
对已部署的推理服务进行基准测试，记录以下关键指标：
- TTFT（首 Token 延迟）：发送请求到收到第一个 Token 的时间
- Decode Speed（Token/s）：生成 Token 的平均速率
- Memory Usage：模型和 KV Cache 占用的内存量
- Context Length：当前请求处理的上下文长度
步骤 4：探索 KV Cache 优化效果
通过向推理服务器连续发送相同或相似的前缀（System Prompt + Tools），观察并记录 Prefix Cache 命中率和提升效果。这能直观理解缓存机制对性能的影响。
步骤 5：对比不同量化等级
下载同一模型的不同量化版本（如 GGUF 格式的 INT4、INT8、FP16），在相同硬件和相同 Prompt 下分别测试 TTFT、Token/s 和 Memory 占用。记录质量与速度/内存之间的权衡关系。
步骤 6：搭建多框架横向对比环境
按照文章推荐的四套实验路线建立独立测试环境：
- A：Ollama + Model + Apple Silicon
- B：oMLX（如可用）或 vLLM 作为推理引擎
- C：llama.cpp/llama-server + llama.cpp Runtime
- D：MLX-LM 用于底层性能研究 保持相同模型、相同量化、相同 Prompt 做公平对比。
步骤 7：模拟真实场景并排查问题
class="code"
模拟一个实际场景（如连续发起多个文件修改请求），观察用户侧的症状（Token 慢、API Timeout、Crash），然后用文章给出的逐层排查法从 API → Server → Engine → Runtime → Model 逐层定位。这是建立排错直觉的关键步骤。
步骤 8：设计并执行 24h 稳定性测试
在你的测试环境中，持续运行推理服务至少 24 小时或 72 小时，监控 Memory 增长趋势、Crash Rate、Error Rate 和 Cache Hit 率的变化。观察上下文增长过程中缓存命中的衰减曲线，记录影响稳定性的关键因素。
Top 3 sources
- 1Ollama Official Documentation
Ollama 官方模型库与文档，提供从安装、模型拉到 API 调用的完整入门指南，适合理解推理服务器的基础用法。
https://ollama.com/library
- 2vLLM Documentation
vLLM 官方文档涵盖 PagedAttention、Continuous Batching、KV Cache 等核心技术原理，是高吞吐推理引擎的最佳入门资源。
https://docs.vllm.ai
- 3HuggingFace AI Acceleration Guide
Transformers 高性能推理指南，介绍 Quantization、CUDA Graphs、模型并行等优化技术，覆盖从理论到实践的完整链路。
https://huggingface.co/docs/transformers/perf_infer_gpu_one
Links are AI-suggested — worth a quick sanity check before diving in.