LLM Inference Engineering 快速参考指南
2026/8/29 11:24:10 · 更新于 2026/8/29 11:36:36
本文系统性地梳理了 LLM 推理工程的核心概念体系，帮助读者快速识别模型、运行时、推理引擎和服务器各层次的术语，并掌握 KV Cache、推测解码、量化等优化技术的原理与实战应用。
它的目标不是教你某一个软件，而是当你以后看到 Ollama、oMLX、MLX、MLX-LM、llama.cpp、vLLM、KV Cache、Prefix Cache、MTP、Speculative Decoding、Serving、Runtime、Engine 等术语时，可以快速判断：
“它是什么？属于哪一层？我现在到底在做什么？下一步应该做什么？”
LLM Inference Engineering
推理工程长期参考指南
适用场景：Apple Silicon / Mac Studio / Qwen / Agentic Coding / Claude Code / Local AI
1. 一分钟版本：先记住这张图
AI 应用
│
▼
Agent / Claude Code
│
▼
API / Model Router
│
▼
┌─────────────────────────┐
│ INFERENCE ENGINEERING │
│ 推理工程 │
└────────────┬────────────┘
│
┌─────────────┼─────────────┐
▼ ▼ ▼
Serving Optimization Reliability
模型服务 推理优化 稳定性
│ │ │
▼ ▼ ▼
oMLX/vLLM KV Cache Monitoring
Ollama Prefix Cache Benchmark
llama.cpp MTP 24/72h test
│ Spec Decode
│ Quantization
▼
Inference Runtime
│
┌─────┴─────┐
▼ ▼
MLX-LM llama.cpp
│
▼
MLX
│
▼
Apple Silicon / GPU
│
▼
Qwen
一句话：
模型负责“想什么”，Runtime 负责“怎么算”，Inference Engine/Server 负责“怎么高效地服务”，Inference Engineering 负责“把整个系统做到最好”。
2. 四个最容易混淆的概念
以后只要不确定 terminology，先回到这四个概念。
概念
中文
核心问题
Model
模型
AI 要计算什么？
Runtime
推理运行时
怎么把模型跑起来？
Inference Engine / Server
推理引擎/服务
怎么高效地服务请求？
Inference Engineering
推理工程
怎么把整个系统做到最好？
3. Model —— 模型层
例如：
-
Qwen3.8-27B
-
Qwen 35B
-
Llama
-
DeepSeek
-
Mistral
它们是：
模型本身。
模型决定：
-
参数规模
-
Architecture
-
Reasoning capability
-
Context length
-
Tokenizer
-
Model quality
例如：
Qwen3.8-27B
│
▼
Model
│
▼
需要 Runtime 执行
4. Compute Framework —— 计算框架
这是比 Runtime 更底层的一层。
典型：
技术
主要硬件
MLX
Apple Silicon
PyTorch
NVIDIA / AMD / CPU / Apple
CUDA
NVIDIA
Metal
Apple
ROCm
AMD
MLX
记住：
MLX = Apple Silicon 机器学习计算框架
不是 Ollama 的替代品。
它更接近：
MLX
│
├── Tensor Operations
├── GPU computation
├── Memory
└── Apple Silicon optimization
5. Inference Runtime —— 推理运行时
这是：
真正执行模型计算的运行环境。
它解决：
模型权重
↓
加载
↓
计算
↓
Token
↓
生成
典型：
-
llama.cpp
-
MLX-LM
-
ONNX Runtime
-
TensorRT 等
6. Inference Engine —— 推理引擎
推理引擎比单纯 Runtime 更关注：
如何高效运行大量推理请求。
主要解决：
-
Scheduling
-
Batching
-
Continuous Batching
-
KV Cache
-
Prefix Cache
-
Streaming
-
Concurrency
-
Memory management
-
API serving
典型：
-
vLLM
-
SGLang
-
TensorRT-LLM
-
oMLX
7. Inference Server —— 推理服务器
它解决：
“应用怎么访问模型？”
例如：
Claude Code
│
│ HTTP API
▼
Inference Server
│
▼
Inference Engine
│
▼
Model
典型 API：
POST /v1/chat/completions
或者：
Anthropic Messages API
所以：
Server 是模型向外提供服务的入口。
8. Ollama 到底属于哪里？
记住：
Ollama 是一个“整合型本地 LLM 平台”。
它横跨多个层：
Ollama
│
┌──────────┼──────────┐
▼ ▼ ▼
Model Manager Runtime Server
│ │ │
下载模型 执行推理 API
它最大的优势：
简单。
适合：
-
本地聊天
-
快速测试
-
开发
-
简单 API
-
本地模型管理
但是：
Ollama ≠ 完整 Inference Engineering。
9. oMLX 到底属于哪里？
这个非常重要。
oMLX 是针对 Apple Silicon 的 LLM inference server / serving system。
它建立在 MLX/MLX-LM 生态之上。
大致：
Apple Silicon
│
▼
MLX
│
▼
MLX-LM
│
▼
oMLX
│
┌────┼───────────────┐
▼ ▼ ▼
API KV Cache Scheduling
Prefix Cache Batching
SSD Cache
所以：
MLX 是基础计算框架。
MLX-LM 是 LLM 推理层。
oMLX 是更完整的 LLM inference serving system。
对于：
Mac Studio + Qwen + Claude Code + Agentic Coding
oMLX 特别值得关注。
10. llama.cpp 到底是什么？
最简单的记法：
llama.cpp = 高效、跨平台的 LLM inference runtime，同时提供 server 能力。
所以它会跨两个分类：
llama.cpp
│
├── Inference Runtime
│
└── llama-server
│
└── API Server
这也是为什么你会看到不同文章把 llama.cpp 称为：
-
Runtime
-
Inference Engine
-
Inference Server
都不完全错。
11. vLLM 是什么？
记住：
vLLM = 高性能 LLM inference engine / serving system。
重点：
-
GPU utilization
-
Continuous batching
-
KV Cache
-
高并发
-
throughput
-
scheduling
更偏：
服务器 / 数据中心
而不是：
Mac 本地个人使用
12. 最终术语表
以后看到术语，可以直接查这里。
英文
中文
简单解释
Model
模型
Qwen/Llama 等
Model Weights
模型权重
模型参数
Runtime
运行时
执行模型
Backend
后端
底层计算实现
Compute Framework
计算框架
MLX/PyTorch
Inference Engine
推理引擎
高效执行推理
Inference Server
推理服务器
给应用提供 API
Model Serving
模型服务
把模型作为服务提供
API Endpoint
API 接口
应用调用模型的位置
Context
上下文
当前模型看到的信息
Context Window
上下文窗口
模型能处理的最大上下文
KV Cache
KV 缓存
保存 Attention 中间状态
Prefix Cache
前缀缓存
复用重复 Prompt
Quantization
量化
降低模型精度/内存
MTP
多 Token 预测
一次预测多个后续 Token
Speculative Decoding
投机解码
小模型帮助大模型加速
Batching
批处理
一次处理多个请求
Continuous Batching
连续批处理
动态加入/退出请求
Scheduling
调度
决定谁什么时候运行
Routing
路由
决定使用哪个模型
Streaming
流式输出
Token 生成一个个返回
Throughput
吞吐
单位时间生成多少 Token
Latency
延迟
请求需要多久
TTFT
首 Token 时间
First Token 到达时间
TPOT
每 Token 时间
Token 之间的平均时间
Token/s
每秒 Token
推理速度
Concurrency
并发
同时多少请求
Memory Footprint
内存占用
模型消耗多少内存
Cache Hit
缓存命中
成功复用 Cache
Cache Miss
缓存未命中
必须重新计算
Prefill
预填充
处理输入 Prompt
Decode
解码
生成输出 Token
Agentic Inference
Agent 推理
Agent 多轮调用模型
Benchmark
基准测试
测量性能
Reliability
可靠性
长时间稳定运行
Observability
可观测性
日志、指标、Tracing
13. Prefill vs Decode
这是以后做性能优化必须懂的。
Prompt
│
▼
PREFILL
│
▼
KV Cache
│
▼
DECODE
│
┌───────┼───────┐
▼ ▼ ▼
Token Token Token
1 2 3
Prefill
处理输入：
“模型阅读了多少内容？”
通常影响：
TTFT
Decode
生成输出：
“模型每秒能生成多少 Token？”
通常关注：
tokens/sec / TPOT
14. KV Cache
这是 Inference Engineering 最核心的概念之一。
没有 Cache：
Prompt
↓
每次重新计算
↓
Generate
有 KV Cache：
Prompt
↓
Compute
↓
KV Cache
↓
下一次请求复用
↓
继续 Generate
特别是 Agent：
System Prompt
+
Tool Definitions
+
Project Context
+
Previous Messages
大量内容会重复。
因此 KV Cache 非常重要。
15. Prefix Cache
Prefix Cache 可以简单理解：
如果两个请求开头完全一样，就不要重复计算。
例如：
Request 1:
[System][Tools][Project]
↓
Cache
Request 2:
[System][Tools][Project][New Task]
↓
Reuse Cache
对于：
Claude Code / Coding Agent
尤其有价值。
16. Speculative Decoding
基本思想：
大模型
Qwen 35B
▲
│ verify
│
小模型
Qwen 3B/7B
│
▼
猜测多个 Tokens
小模型：
“我猜接下来是 A B C D。”
大模型：
“让我验证。”
如果猜对很多：
大模型可以更快生成。
17. MTP
MTP = Multi-Token Prediction
核心思想：
模型尝试一次预测多个未来 Token。
它和 Speculative Decoding 有相似目标：
提高生成速度。
但实现机制不同。
以后看到：
MTP
Speculative Decoding
Draft Model
Draft Tokens
都应该想到：
Inference Acceleration
18. Quantization
量化：
FP16
↓
INT8
↓
INT4
目的：
-
降低内存
-
提高速度
-
允许更大的模型
-
提高本地部署能力
但：
速度、内存、质量之间需要平衡。
19. 最重要的性能指标
以后 benchmark 不要只看：
“多少 tok/s？”
至少看：
指标
意义
TTFT
用户等多久看到第一个 Token
Prefill tok/s
处理 Prompt 多快
Decode tok/s
生成多快
TPOT
Token 之间间隔
Throughput
整体吞吐
Concurrency
并发能力
Memory
内存占用
Cache Hit Rate
Cache 使用效率
Error Rate
API 错误
Crash Rate
崩溃
Uptime
稳定运行时间
20. Agentic Coding 的完整流程
这是你以后最应该参考的 Process Map。
Claude Code
│
▼
User Request
│
▼
Context Build
│
┌────────────┴────────────┐
▼ ▼
System Prompt Project Files
│ │
└────────────┬────────────┘
▼
Prefix Cache
│
▼
Router
│
┌────────┴────────┐
▼ ▼
Qwen 27B Qwen 35B
│ │
└────────┬────────┘
▼
Inference Server
│
▼
Runtime
│
▼
Hardware
│
▼
Token Output
│
▼
Tool Call
│
▼
Execute Tool
│
▼
New Result
│
▼
Update Context
│
▼
KV Cache
│
▼
LLM 再次推理
│
▼
...
21. 你的本地 AI Stack 可以这样理解
你现在的核心环境：
Mac Studio
│
▼
Apple Silicon
│
┌────────┴────────┐
▼ ▼
MLX llama.cpp
│
MLX-LM
│
▼
oMLX
│
▼
Qwen3.8-27B
│
▼
Claude Code
│
▼
Agentic Coding
同时：
Ollama
│
└── 另一条 inference stack
因此你真正要比较的不是：
“Ollama vs MLX”
而应该是：
“不同 Inference Stack 在我的 Agentic Coding workload 下表现如何？”
22. 你的四条测试路线
建议长期保留：
Stack A — Ollama
Claude Code
↓
Ollama
↓
Ollama Runtime
↓
Qwen
↓
Apple Silicon
Stack B — oMLX
Claude Code
↓
oMLX API
↓
oMLX
↓
MLX / MLX-LM
↓
Qwen
↓
Apple Silicon
Stack C — llama.cpp
Claude Code
↓
llama-server
↓
llama.cpp
↓
Qwen / GGUF
↓
Apple Silicon
Stack D — MLX-LM
Application
↓
MLX-LM
↓
MLX
↓
Apple Silicon
它更适合：
研究、实验、底层调优
而不是直接作为完整 Agent Server。
23. 出问题的时候，先定位是哪一层
这是以后 troubleshooting 最有用的一张图。
Claude Code
│
X ← API failed?
│
Inference Server
│
X ← Scheduling / batching?
│
Inference Engine
│
X ← KV / cache?
│
Runtime
│
X ← MLX / llama.cpp?
│
Backend
│
X ← Metal / GPU?
│
Hardware
如果 API failed
先查：
Server / API layer
如果 model crashes
查：
Runtime / memory / model compatibility
如果越来越慢
查：
Context / KV Cache / Memory pressure
如果 tok/s 很低
查：
Runtime / backend / quantization / hardware utilization
如果长时间后 crash
查：
Memory / Cache / fragmentation / leak / server reliability
24. Troubleshooting Checklist
当出现：
API Failed
□ Server 是否运行？
□ Port 是否正确？
□ API endpoint 是否正确？
□ OpenAI/Anthropic API format 是否匹配？
□ Streaming 是否正常？
□ Tool calling 是否兼容？
Crash
□ RAM 是否耗尽？
□ Swap 是否暴涨？
□ Context 是否太长？
□ KV Cache 是否太大？
□ Model 是否正确量化？
□ Runtime 是否支持该模型？
□ Server 是否有 crash log？
性能越来越慢
□ Context 是否越来越长？
□ KV Cache 是否增长？
□ Prefix Cache 是否命中？
□ Memory pressure？
□ Swap？
□ Thermal throttling？
□ Batch 是否合理？
25. Inference Engineering 的完整 Process Map
以后你不知道“我到底应该从哪里开始”，就走这张图：
① 定义 Workload
│
▼
② 选择 Model
│
▼
③ 选择 Runtime
│
▼
④ 选择 Inference Engine
│
▼
⑤ 建立 API
│
▼
⑥ 接入 Agent
│
▼
⑦ 测量 Baseline
│
▼
┌──────────┴──────────┐
▼ ▼
性能太慢 不稳定
│ │
▼ ▼
Cache / Decode Memory
Quantization Context
Batching API
Scheduling Runtime
│ │
└──────────┬──────────┘
▼
⑧ 优化
│
▼
⑨ Benchmark
│
▼
⑩ Stress Test
│
▼
⑪ 24/72 Hour
│
▼
⑫ Production
26. 以后看到一个新工具，怎么判断它是什么？
问它五个问题：
Q1
它负责执行模型吗？
如果是：
Runtime
Q2
它负责 batching / scheduling / cache / concurrency 吗？
如果是：
Inference Engine
Q3
它提供 API 给应用调用吗？
如果是：
Inference Server
Q4
它负责下载、管理、切换模型吗？
如果是：
Model Manager
Q5
它是不是在优化整个系统？
如果是：
Inference Engineering
27. 最终分类速查表
工具/概念
最准确定位
记忆方式
Qwen
Model
模型
MLX
Compute Framework / Backend
计算基础
MLX-LM
LLM Runtime / Library
MLX 上跑 LLM
llama.cpp
Runtime + Server
高效本地推理
Ollama
Runtime + Model Manager + Server
最方便
oMLX
Apple Silicon Inference Server/Engine
Mac 高性能推理
vLLM
Inference Engine + Server
服务器高吞吐
SGLang
Inference Engine + Server
高性能/Agent
TensorRT-LLM
NVIDIA Inference Engine
NVIDIA 极致优化
KV Cache
Optimization
避免重复计算
Prefix Cache
Optimization
复用 Prompt 前缀
MTP
Acceleration
多 Token 预测
Speculative Decoding
Acceleration
小模型辅助大模型
Quantization
Optimization
降低内存/提高效率
Batching
Serving Optimization
多个请求一起算
Routing
System Design
决定用哪个模型
Scheduling
System Design
决定谁先算
Benchmark
Engineering
测性能
Stress Test
Engineering
测稳定性
Inference Engineering
完整工程体系
全部串起来
28. 最后记住这张“脑图”
┌─────────────┐
│ MODEL │
│ Qwen │
└──────┬──────┘
│
▼
┌────────────────┐
│ Compute │
│ MLX / CUDA │
└───────┬────────┘
│
▼
┌──────────────────┐
│ Runtime │
│ MLX-LM │
│ llama.cpp │
└────────┬─────────┘
│
▼
┌─────────────────────┐
│ Inference Engine │
│ oMLX / vLLM / SGLang│
└──────────┬──────────┘
│
▼
┌────────────────────┐
│ Inference Server │
│ API / Streaming │
└─────────┬──────────┘
│
▼
Claude Code
│
▼
AI Agent
│
▼
┌────────────────────┐
│ Optimization │
│ KV Cache │
│ Prefix Cache │
│ Quantization │
│ MTP │
│ Speculative Decode │
│ Batching │
└─────────┬──────────┘
│
▼
┌────────────────────┐
│ Engineering │
│ Benchmark │
│ Monitoring │
│ Reliability │
│ Stress Test │
└─────────┬──────────┘
│
▼
★ INFERENCE ENGINEERING ★
最核心的一句话
Ollama、oMLX、llama.cpp、MLX-LM、vLLM 是“构建推理系统的工具和组件”；KV Cache、Prefix Cache、量化、MTP、Speculative Decoding 是“推理优化技术”；而把 Model、Runtime、Engine、Server、Cache、Scheduling、Hardware、Agent、Benchmark 和 Reliability 全部结合起来，并针对具体 workload 持续优化——这才叫 Inference Engineering（推理工程）。
对于你目前的 Mac Studio + Apple Silicon + Qwen3.8-27B + Claude Code + Agentic Coding，最值得建立的思维方式就是：
不要问“哪个工具最好？”
而要问：
“针对我的 workload，哪一套 inference stack 能在速度、Context、KV Cache、内存、API 稳定性、Agent compatibility 和 72 小时可靠性之间取得最好的平衡？”
这就是从 “会用本地 LLM” 进入 “真正做 Inference Engineering” 的分界线。
学习地图
LLM 推理工程学习路线
阶段一：基础知识层
- 理解 Model（模型）的概念——Qwen、Llama 等决定 AI "想什么"
- 掌握核心参数：参数量、架构、上下文长度、Tokenizer、Model Quality
- 了解 Compute Framework（计算框架）的作用与硬件对应关系
阶段二：Runtime 与 Engine
- 理解 Inference Runtime——MLX-LM、llama.cpp 等执行模型计算的运行环境
- 学习 Inference Engine 的概念——vLLM、oMLX 如何高效服务批量推理请求
- 掌握 Serving/Server API 层的概念（OpenAI 格式接口、流式输出）
阶段三：优化技术层
- KV Cache 原理与 Prefix Cache 的复用机制
- Quantization（INT8/INT4 量化对性能的影响）
- Speculative Decoding（小模型辅助大模型加速生成）
- MTP（多 Token 预测）与 Continuous Batching
- Prefill vs Decode 两个阶段的区别
阶段四：性能评估与调优
- 关键指标体系：TTFT、TPOT、Decode tok/s、Throughput、Cache Hit Rate
- 监控 Observability——日志、指标、追踪
- 构建 Benchmark（基准测试）和 Stress Test（压力测试）流程
阶段五：系统设计与稳定性
- Agent 推理工作流与 Routing / Scheduling 设计
- 长时间运行稳定性（24/72h stress testing）
- 分层排错方法论——定位问题在 API、Runtime、引擎还是硬件层
动手实践——分步指南
-
安装本地 LLM Runtime 环境 选择一种推理栈并安装（Mac Studio 推荐 MLX/oMLX，通用推荐 llama.cpp）
-
下载并加载一个开源模型 使用 Hugging Face 或本地方式获取 Qwen3.8-27B 等模型的权重文件
-
启动一个推理 API Server 运行 ollama serve、oMLX 或 llama-server，使其提供 /v1/chat/completions 接口
-
编写一个基本的推理调用脚本 通过 OpenAI 兼容 API 格式向本地 Server 发送第一个 prompt，验证输出
-
开启 KV Cache 监控 配置 oMLX/llama.cpp 的缓存指标，观察 Cache Hit Rate 和 Prefix Cache 命中情况
-
实验不同量化精度对性能的影响 使用 FP16、INT8、INT4 加载同一模型，对比 Token/s、内存占用和输出质量
-
开启流式输出（Streaming）模式 修改 API 调用参数 stream=true，观察 TTFT（首 Token 时间）的变化
-
设计一个 Agent 推理工作流 模拟 Claude Code 式的多轮交互——包含上下文构建 / Tool Call / KV Cache 复用
-
构建性能基准测试 记录不同场景下的 TTFT、Decode tok/s、Throughput 和并发能力
-
进行长时间压力测试 以 24-72h 周期运行推理服务，监控内存增长、Cache 碎片化和崩溃率
三大推荐资源
- 1Hugging Face Transformers 官方文档
大规模预训练模型推理与微调的基础文档，涵盖核心概念和 API 使用指南。
https://huggingface.co/docs/transformers
- 2
- 3MLX 官方开发者指南 (Apple Silicon)
Apple Silicon 机器学习计算框架的官方文档，涵盖张量操作、GPU 计算和 MLX-LM 推理入门。
https://ml-explore.github.io/mlx/build/html/overview.html
链接由 AI 推荐——使用前建议快速核实。