LLM 推理工程快速参考指南

2026/8/29 11:41:30

#knowledge#quantization#llm-inference#ollama#mlx#inference-engineering#kv-cache#speculative-decoding#runtime#inference-engine#vllm#llamacpp

本文系统梳理了 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

核心思想：

小模型先猜：

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 文章时的“坐标系”。

动手实践——分步指南

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 率的变化。观察上下文增长过程中缓存命中的衰减曲线，记录影响稳定性的关键因素。

三大推荐资源

1
Ollama Official Documentation
Ollama 官方模型库与文档，提供从安装、模型拉到 API 调用的完整入门指南，适合理解推理服务器的基础用法。
https://ollama.com/library
2
vLLM Documentation
vLLM 官方文档涵盖 PagedAttention、Continuous Batching、KV Cache 等核心技术原理，是高吞吐推理引擎的最佳入门资源。
https://docs.vllm.ai
3
HuggingFace AI Acceleration Guide
Transformers 高性能推理指南，介绍 Quantization、CUDA Graphs、模型并行等优化技术，覆盖从理论到实践的完整链路。
https://huggingface.co/docs/transformers/perf_infer_gpu_one

链接由 AI 推荐——使用前建议快速核实。