量化与模型转换工具链全景

§1 开篇：一个常见困惑

“我想在我的笔记本上运行 Llama-3.1-8B，它有一个 Intel iGPU (Iris Xe)。我在 Hugging Face 上找到了模型的 checkpoint，但接下来应该怎么做？”

这是社区中最常见的问题之一。你开始搜索，发现一堆工具名字：Optimum、NNCF、OpenVINO、llama.cpp、ONNX Runtime、TensorRT-LLM。每个都说自己能”量化”和”加速”。有的文档告诉你”先转 ONNX”，有的说”直接转 OpenVINO IR”，有的强调”GGUF 格式最通用”。你越看越困惑——它们之间是什么关系？是竞品还是上下游？我应该用哪个？

如果你有这样的困惑，这篇文章将为你提供清晰的解决框架。我们不会简单地列举工具名单，而是从 Pipeline 分层 的视角出发，理解每个工具在量化与模型转换流水线中的角色定位，然后通过对比矩阵和决策树，帮你为特定场景选择最佳工具组合。

§2 Pipeline 分层图

理解工具链的关键是认识到：量化和模型转换不是单一步骤，而是一个 四层 pipeline。不同工具在不同层发挥作用，有些工具只做一层的事，有些工具跨多层编排。下面是四层框架：

Layer 1: 算法库 (Algorithm Libraries)

这一层的工具只做一件事：修改权重的数值（量化、剪枝、知识蒸馏等），但输入输出格式保持一致。例如，输入一个 Hugging Face safetensors checkpoint，输出仍然是 safetensors，只是权重从 FP16 变成了 INT4。

典型工具：

AutoGPTQ / AutoAWQ：实现 GPTQ 和 AWQ 量化算法，输出 Hugging Face 兼容的量化模型
bitsandbytes：NF4 (4-bit NormalFloat) 量化，主要用于训练时 (QLoRA) 和推理时显存优化
llm-compressor：vLLM 官方推荐的量化工具（下面会详细讲）
NNCF (Neural Network Compression Framework)：Intel 开源的压缩算法库，支持 PTQ、QAT、剪枝、知识蒸馏
SmoothQuant：平滑 activation outlier，实现 W8A8 (weight + activation INT8) 量化

关键特征：纯算法，格式无关。它们不关心推理引擎是什么——你可以用 NNCF 量化模型，然后导出到 ONNX、OpenVINO、甚至 TensorRT。

Layer 2: 格式转换器 (Format Converters)

这一层的工具只做一件事：改变模型格式（从训练框架格式转为推理引擎格式），可选地做轻量级量化（如 FP32 → FP16 或简单的 INT8 对称量化）。

典型工具：

ov.convert_model：OpenVINO 的官方转换 API，从 PyTorch / TensorFlow / ONNX → OpenVINO IR (.xml + .bin)
convert_hf_to_gguf.py：llama.cpp 的官方转换脚本，从 Hugging Face checkpoint → GGUF 格式
trtllm-build：TensorRT-LLM 的构建工具，从 checkpoint → TensorRT engine (.plan 文件)。当配合量化选项使用时，它同时属于 Layer 4（见下文”推理引擎内置”）
optimum-cli export onnx：Hugging Face Optimum 提供的导出命令，从 Transformers → ONNX

关键特征：格式转换为主，量化为辅。很多转换器只做格式映射 (如 PyTorch Module → ONNX graph)，量化是可选的后处理步骤。

Layer 3: 编排器 (Orchestrators)

这一层的工具 不实现具体算法或格式转换逻辑，而是将 Layer 1 和 Layer 2 的工具串联成 pipeline，并提供搜索、评估、配置管理等高层功能。

典型工具：

Microsoft Olive：跨后端的模型优化编排器，核心抽象是 Pass + Workflow + Evaluator + Search Strategy。Pass 是单个优化步骤（如量化、图优化、Graph Capture），Workflow 是按顺序组合 Pass，Evaluator 负责评估结果（accuracy / latency），Search Strategy 负责自动搜参。Olive 自己不实现量化算法，而是调用 ONNX Runtime Quantization、TensorRT、OpenVINO 等底层工具。目标硬件覆盖 Qualcomm、AMD、Nvidia、Intel NPU/GPU/CPU。最新版本 olive-ai 0.11.0 (2026-01-29)。
Optimum Intel：半个编排器——封装了 ov.convert_model (Layer 2) + NNCF (Layer 1)，提供一键式 Hugging Face → OpenVINO IR 的量化转换流程。它不像 Olive 那样支持多后端，专注于 Intel 硬件栈。

关键特征：组合复用，不重新发明轮子。编排器的价值在于降低工具链组装的复杂度，特别是在需要多种优化组合（如量化 + 剪枝 + 知识蒸馏）时。

Layer 4: 推理引擎内置 (Runtime-Integrated)

这一层的工具将 算法 + 格式 + 执行 强耦合，量化和推理引擎是同一个系统的不同组件，无法单独使用。

典型工具：

llama.cpp 的 llama-quantize：直接对 GGUF 文件执行 Q4_0、Q4_K_M、IQ2_XS 等量化方案，量化后的模型只能用 llama.cpp 推理
TensorRT-LLM 内置量化：在 trtllm-build 流程中嵌入量化选项 (--quant_mode int8_kv_cache 等)，产出的 .plan 文件只能用 TensorRT 推理
SGLang 量化：内置 AWQ/GPTQ/FP8 支持，但高度优化的 kernel 与 SGLang 的 RadixAttention 调度器绑定

关键特征：最高性能，最低通用性。格式和引擎强耦合意味着无法迁移到其他推理系统，但也意味着可以做极致的 co-design 优化（如 llama.cpp 的 K-quant 多级 scale 和 SIMD kernel 深度集成）。

下面的交互组件展示了完整的四层结构，点击每一层可以查看该层的工具列表和典型输入输出格式：

量化与转换工具链分层地图

四层架构：从算法库到推理引擎内置方案

算法库

定义

只做数学转换，输入/输出通常同格式，只改权重数值

通用 I/O 契约

输入：模型权重（HF safetensors / PyTorch / ONNX / OpenVINO IR）→ 输出：同格式权重（量化后）

包含工具

AutoGPTQAutoAWQbitsandbytesNNCFllm-compressorModelOpt

§3 四大生态巡览

理解了分层框架，我们按硬件阵营巡览主流工具生态。每个阵营都有自己的”全栈解决方案”，从算法库到推理引擎形成闭环。

§3.1 Intel 阵营

Intel 的模型优化栈由三件套组成：Optimum Intel (编排器) + NNCF (算法库) + OpenVINO Converter (ov.convert_model，格式转换器)。Optimum Intel 封装了后两者，提供一键式 Hugging Face → OpenVINO IR 的量化流程，特别是集成了 NNCF 的 accuracy-aware quantization (通过 quantize_with_accuracy_control API)。

需要注意的是，Intel Neural Compressor (INC) 和 NNCF 是不同产品线而非竞品。INC v3.7 (2025-12-25) 仍在活跃维护，主打 Gaudi AI 加速器 + Xeon/Core Ultra 原生栈，不以 OpenVINO 为目标后端，适合服务器和 Gaudi 集群部署。NNCF 的定位是 OpenVINO 优先的压缩算法库，也被 PyTorch (torch.compile)、ExecuTorch、Microsoft Olive 等生态集成。

Intel 生态的深度解析（如 NNCF 的算法矩阵、Optimum Intel 的具体用法、OpenVINO 的 IR 格式细节）将在下一篇《Intel 模型优化栈深潜》中展开。

§3.2 NVIDIA 阵营

NVIDIA 的工具链核心是 TensorRT-LLM (推理引擎) + NVIDIA Model Optimizer (ModelOpt，量化工具)。ModelOpt 的前身是内部代号 AMMO (Algorithmic Model Optimizer)，在 2024 年 5 月 v0.11 版本正式更名为 modelopt 包。2025 年 12 月，NVIDIA 再次将其品牌从 “TensorRT Model Optimizer” 更名为 “NVIDIA Model Optimizer”，去掉了 “TensorRT” 前缀，仓库也迁移到 NVIDIA/Model-Optimizer（旧 URL 仍可访问）。最新版本 ModelOpt 0.43.0 (2026-04-16)。

调用链是：ModelOpt 产出量化模型 → TensorRT-LLM 编译成 engine。ModelOpt 支持多种量化方法（FP8、INT8、INT4 weight-only、AWQ、SmoothQuant），输出仍然是 PyTorch checkpoint 或 Hugging Face safetensors，但其中嵌入了量化 metadata (scale / zero-point / quantization scheme)。接下来用 trtllm-build 读取这些 metadata，编译成 TensorRT engine (.plan 文件)，这是 Layer 4 的典型流程——最终产物只能在 TensorRT-LLM 上运行。

需要强调的是，虽然 NVIDIA 的工具栈在 H100/A100 上有极致性能（特别是 FP8 Tensor Core 加速），但通用性较低——TensorRT engine 不能跨硬件迁移（甚至同一 GPU 架构的不同显卡也需要重新编译）。这与 ONNX、GGUF 等开放格式形成对比。

§3.3 HuggingFace 通用层

Hugging Face 生态是跨硬件的”中立层”，核心是 Optimum 这个 umbrella 项目，下面分出多个子包：

Optimum Intel (前面讲过)
Optimum NVIDIA (TensorRT 集成)
Optimum AMD (ROCm 集成)
Optimum Habana (Gaudi 集成)

除了 Optimum，Hugging Face 还维护或集成了多个量化工具：

bitsandbytes：NF4 (4-bit NormalFloat) 量化，主要用于 QLoRA 训练和 transformers 库的 .load_in_4bit() API
AutoGPTQ / AutoAWQ：社区维护的 GPTQ 和 AWQ 实现，输出 Hugging Face 兼容的量化模型
llm-compressor：这是 2024 年下半年崛起的新工具，值得重点介绍

llm-compressor 的官方定位是 “a Transformers-compatible library for applying various compression algorithms to LLMs for optimized deployment with vLLM”。它由 vLLM Project 和 Red Hat AI 共同维护，仓库在 vllm-project 组织下。vLLM 官方文档的量化章节明确写道：“To get started with quantization, see LLM Compressor”——这是 vLLM 的 first-party 量化路径。

支持的量化方法包括：

Activation 量化：W8A8 (int8 & fp8)、MXFP8 (experimental)
混合精度：W4A16、W8A16、MXFP8A16 (experimental)、NVFP4
算法：simple PTQ、GPTQ、AWQ、SmoothQuant、AutoRound

输出格式是 compressed-tensors，vLLM 原生加载，无需额外转换。最新版本 v0.10.0.1 (2026-03-13)，GitHub 3.1k stars。

需要注意的 caveat 是：vLLM 还支持加载其他格式的量化模型（AutoAWQ、GPTQModel、bitsandbytes、GGUF、FP8、ModelOpt、Quark、TorchAO 等）——llm-compressor 是官方推荐的首选路径，但不是唯一选择。

§3.4 ggml 阵营

ggml (Georgi Gerganov’s ML library) 是 llama.cpp 的底层张量库，也衍生出一个独立的生态。核心工具是：

convert_hf_to_gguf.py：从 Hugging Face checkpoint → GGUF 格式（Layer 2 转换器）
llama-quantize：对 GGUF 文件执行量化（Layer 4 引擎内置）

GGUF 格式和 llama.cpp 推理引擎是强耦合的典型——GGUF 的设计完全围绕 llama.cpp 的 kernel 优化（如 Q4_K_M 的 super-block 结构、IQ2_XS 的 vector quantization），其他推理引擎（如 ONNX Runtime、TensorRT）无法直接加载 GGUF。但这种强耦合也带来了极高的灵活性：llama.cpp 支持 30+ 种量化类型（Q4_0、Q4_K_M、Q5_K_S、Q6_K、IQ2_XXS、IQ3_S 等），可以为不同显存/精度需求精细调参。

关于 llama.cpp 量化方案的深入解析（K-quant 的 super-block 设计、I-quant 的 codebook、混合精度策略），请参考我们之前的文章 llama.cpp 量化方案。

§3.5 跨后端编排器

Microsoft Olive 是 Layer 3 编排器的典型代表。它的官方定位是 “AI Model Optimization Toolkit for the ONNX Runtime”，但实际支持的后端不限于 ONNX Runtime——还包括 TensorRT、OpenVINO、DirectML、Qualcomm QNN、AMD ROCm 等。

Olive 的核心抽象是：

Pass：单个模型优化步骤，例如模型压缩、图捕获 (Graph Capture)、量化、图优化
Workflow：按顺序排列的 Pass 序列（如：INT8 量化 → 冗余算子删除 → 常量折叠）
Evaluator：评估优化结果，支持 accuracy、latency、throughput、memory 等指标
Search Strategy：自动搜参，尝试不同 Pass 组合和超参数，找到 Pareto 最优解

Olive 内置了 40+ 优化组件，覆盖量化（ONNX Runtime PTQ、TensorRT INT8、OpenVINO INT8）、剪枝、知识蒸馏、算子融合、内存规划等。它的核心价值不是实现新算法，而是 组合复用现有工具，并提供自动搜索框架——例如自动尝试 “FP16 baseline vs INT8 PTQ vs INT8 QAT”，在 accuracy 损失 < 1% 的约束下找到最快的方案。

最新版本 olive-ai 0.11.0 (2026-01-29)。目标硬件覆盖 Qualcomm (Snapdragon)、AMD (ROCm)、Nvidia (TensorRT)、Intel NPU/GPU/CPU。

§3.6 移动/边缘阵营（简略）

移动和边缘设备有各自的工具生态，这里简单列举（详细展开会在未来的”边缘部署”专题中讲解）：

Apple coremltools 9.0 (2025-11-10)：支持 INT4/INT8 线性量化、1–8 bit palettization (lookup table 查找表)、sparsity（稀疏性），以及多种联合压缩组合（稀疏 + 量化、稀疏 + palettization）。W8A8 模式可利用 Apple Silicon 的 INT8 算力加速。需要注意的是，coremltools 没有专门的 LLM 量化 API——它提供的是通用的 weight-only 量化 + palettization + sparsity 功能，transformer/LLM 工作流可以使用这些通用能力（以 OPT、BERT 为例）。输出格式是 CoreML (.mlmodel)，在 iOS/macOS 上通过 Core ML 推理引擎执行。
AMD Quark 0.11.1 (2026-02-19)：AMD 官方的跨平台量化工具，支持 PyTorch (Eager / FX Graph / QAT) 和 ONNX (via ONNX Runtime Quantization) 两条路径。目标硬件覆盖 Ryzen AI NPU（NPU_CNN / NPU_Transformer 两种模式）、AMD Instinct GPU（ROCm，包括 MI300X）及 CPU；也能通过 CUDA/HIP 在 NVIDIA 硬件上校准。算法支持非常全面：PTQ、QAT、SmoothQuant、AWQ、GPTQ、QuaRot、Qronos、CLE、BiasCorrection、AdaQuant、AdaRound；校准方法包括 MinMax、Percentile、MSE、Entropy。v0.11.1 的亮点功能是 “file-to-file quantization for ultra-large models” (超大模型的文件到文件量化，支持 weight-only + dynamic activation)。
Google AI Edge Torch 0.8.0 (2026-01-26)：PyTorch → LiteRT (TFLite) 的官方转换桥梁，面向 Android / iOS / IoT 设备。输出格式是 .tflite flatbuffer，由 LiteRT runtime 执行（LiteRT 是 TensorFlow Lite 的新品牌名）。目标硬件覆盖广泛的 CPU，以及初步的 GPU 和 NPU 支持（文档未单独点名 Edge TPU，而是泛指 NPU）。有两个组件：PyTorch 转换器（Beta）和 Generative API（Alpha，针对 LLM 的模型改写与量化）。需要强调的是，Generative API 仍在 Alpha 阶段，稳定性和功能完整度尚未达到生产级别。

§4 六维度对比矩阵

了解了主流生态，接下来用六个维度对比工具特性，帮助你为具体需求筛选候选方案。

六个对比维度

定位：算法库 / 格式转换器 / 编排器 / 推理引擎内置（对应前面的 Layer 1-4）
输入格式：Hugging Face checkpoint / PyTorch state_dict / ONNX / TensorFlow SavedModel / 自定义格式
输出格式：这是最关键的维度，决定了下游推理引擎的选择
支持的量化方法：GPTQ / AWQ / SmoothQuant / NF4 / K-quant / FP8 / INT4 weight-only / W8A8 / etc.
目标硬件：CPU / NVIDIA GPU / Intel GPU/NPU / AMD GPU/NPU / Apple Silicon / ARM Mobile / Gaudi / Qualcomm
在 pipeline 中的位置：独立使用 / 被上层工具封装调用

输出格式的关键区分

这里需要重点理解 推理格式 (inference-ready format) 和 中间格式 (intermediate format) 的区别：

推理格式（可直接加载执行）：

OpenVINO IR (.xml + .bin)：OpenVINO 推理引擎专用
TensorRT engine (.plan)：TensorRT / TensorRT-LLM 专用
GGUF：llama.cpp 专用
ONNX (.onnx)：ONNX Runtime / ORT 衍生引擎（如 ONNX Runtime Mobile）
CoreML (.mlmodel)：Apple Core ML 引擎专用
LiteRT (TFLite) (.tflite)：Google LiteRT runtime 专用

中间格式（需要再转一次才能推理）：

GPTQ / AWQ 产出的 Hugging Face safetensors：虽然是量化后的模型，但仍然是 PyTorch 格式，需要 Hugging Face transformers 库加载，或者转成其他格式（如 ONNX、OpenVINO）后部署
PyTorch state_dict / checkpoint：训练格式，需要转换

下面的交互组件展示了 15-20 个主流工具在六个维度上的对比矩阵。你可以用顶部的筛选条快速找到符合需求的工具（例：“只看输出 GGUF 的”、“只看支持 AWQ 的”、“只看 Intel GPU 的”）：

量化工具矩阵浏览器

17 个工具 × 6 个维度，交互式筛选

量化方法

目标硬件

输出格式

工具名称	定位	输入格式	输出格式	量化方法	目标硬件	Pipeline 位置
AutoGPTQ	algorithm-lib	HF-safetensors, PyTorch	HF-safetensors	GPTQ	NVIDIA-GPU, Intel-CPU, Intel-GPU	standalone
AutoAWQ	algorithm-lib	HF-safetensors	HF-safetensors	AWQ	NVIDIA-GPU, Intel-CPU	standalone
bitsandbytes	algorithm-lib	PyTorch (runtime)	PyTorch (runtime)	NF4, FP4, INT8	NVIDIA-GPU	standalone (runtime)
NNCF	algorithm-lib	PyTorch, TorchFX, ONNX, OpenVINO-IR	same as input (compressed)	PTQ, WOQ, QAT, Sparsity, WO-QAT+LoRA	Intel-CPU, Intel-GPU, Intel-NPU	standalone or wrapped by Optimum Intel
llm-compressor	algorithm-lib	HF-safetensors	HF-safetensors (compressed-tensors)	W8A8, W4A16, AWQ, GPTQ, SmoothQuant, AutoRound, INT8, FP8	NVIDIA-GPU, AMD-GPU	standalone (vLLM first-party)
ModelOpt (NVIDIA)	algorithm-lib	PyTorch	PyTorch (annotated)	FP8, INT8, INT4, AWQ, SmoothQuant	NVIDIA-GPU	wrapped by TensorRT-LLM
AMD Quark	algorithm-lib	PyTorch, ONNX	same as input (compressed)	PTQ, QAT, AWQ, GPTQ, SmoothQuant, QuaRot	AMD-Ryzen-AI-NPU, AMD-Instinct-GPU, CPU	standalone
coremltools (Apple)	converter + algorithm-lib	PyTorch, TensorFlow	CoreML	INT4, INT8, palettization	Apple-Silicon	standalone
convert_hf_to_gguf.py	converter	HF-safetensors	GGUF (FP16/BF16/F32)	none	any	standalone, feeds llama-quantize
ov.convert_model	converter	PyTorch, ONNX, TensorFlow	OpenVINO-IR (FP32/FP16)	none	any	standalone
torch.onnx.export	converter	PyTorch	ONNX	none	any	standalone
optimum-cli export onnx	converter	HF-checkpoint	ONNX (+ optional INT8)	INT8	any	wraps torch.onnx.export
Google AI Edge Torch	converter	PyTorch	LiteRT/TFLite	INT8, INT4	mobile-CPU, mobile-GPU, mobile-NPU	standalone
Microsoft Olive	orchestrator	HF-checkpoint, PyTorch, ONNX	ONNX, OpenVINO-IR, TensorRT-engine	delegates to backend (40+ passes)	Intel-CPU, Intel-GPU, AMD-GPU, NVIDIA-GPU	top-level orchestrator
Optimum Intel	orchestrator	HF-checkpoint	OpenVINO-IR (FP16/INT8/INT4)	WOQ, PTQ, AAQ	Intel-CPU, Intel-GPU, Intel-NPU	wraps NNCF + ov.convert_model
llama.cpp llama-quantize	engine-builtin	GGUF (FP16)	GGUF (Q2_K…Q8_0)	Q2_K, Q3_K_S, Q3_K_M, Q3_K_L, Q4_K_S, Q4_K_M, Q5_K_S, Q5_K_M, Q6_K, Q8_0, IQ1_S, IQ2_XXS	CPU, NVIDIA-GPU, Apple-Silicon, Intel-GPU, AMD-GPU	engine-builtin
TensorRT-LLM	engine-builtin	HF-checkpoint, ModelOpt output	TensorRT-engine	FP8, INT8, INT4, AWQ, SmoothQuant	NVIDIA-GPU	engine-builtin

提示：同一维度内为「或」逻辑，跨维度为「与」逻辑。匹配的单元格会高亮显示。

§5 相关但易混淆：微调期的量化技术

在讨论量化工具链时，经常会遇到 LoRA 和 QLoRA 这两个名词。它们和本文讲的推理量化工具链有什么关系？这里澄清三点：

LoRA 不是量化

LoRA (Low-Rank Adaptation) 是一种 参数高效微调 (PEFT) 方法，不是量化技术。它的核心思想是：冻结预训练模型的原始权重 $W$ ，只训练两个低秩矩阵 $A$ 和 $B$ （维度是 $d \times r$ 和 $r \times d$ ，其中 $r \ll d$ ），推理时将它们合并： $W' = W + \alpha \cdot AB$ 。训练的参数量仅为原模型的 0.1-1%，可以在消费级 GPU 上微调大模型。

LoRA 的目标是”少改参数”，不是”降低精度”——原始权重 $W$ 和 LoRA adapter $(A, B)$ 都是 FP16 或 BF16。

QLoRA = 量化基础权重 + LoRA 训练

QLoRA (Quantized LoRA) 是 LoRA 的进阶版本，专门为显存受限场景设计。关键技术点：

冻结的基础权重用 NF4 量化存储（4-bit NormalFloat，bitsandbytes 实现），只在需要时 dequantize 到 FP16 参与前向传播
LoRA adapter 用 FP16 训练，梯度也是 FP16
量化的唯一目的是节省训练时显存（因为基础权重占大头），不是为了推理加速

QLoRA 训练完成后，你会得到一个 LoRA adapter checkpoint（通常几十到几百 MB）。接下来有两种推理路径：

路径 A：推理时继续用 NF4 量化的基础模型 + FP16 adapter，显存省但推理速度一般
路径 B：用 peft.merge_and_unload() 将 adapter 合并回基础模型，得到完整的 FP16 checkpoint，然后用本文讲的 PTQ 工具（如 llm-compressor、NNCF、llama-quantize）再做推理量化

路径 B 是将 QLoRA 训练和推理量化衔接的标准做法。

QLoRA 训出的模型可以转 GGUF

一个典型的完整流程：

用 QLoRA 在自定义数据集上微调 Llama-3.1-8B（基础模型用 NF4 量化）
训练完成后 peft.merge_and_unload() 得到完整 FP16 checkpoint
用 convert_hf_to_gguf.py 转成 GGUF 格式
用 llama-quantize 做 Q4_K_M 或 Q5_K_M 量化
部署到本地 llama.cpp 推理

这说明 QLoRA 和推理量化工具链不是互斥的，而是可以串联的。QLoRA 解决”如何低成本微调大模型”，推理量化工具链解决”如何低成本部署大模型”。

强调：本节不讲 LoRA / QLoRA 的训练细节（那是微调专题的内容），只澄清”它算不算量化工具”——答案是 QLoRA 是训练期的显存优化技术，不属于推理量化工具链，但两者可以衔接。

§6 选型决策树

有了分层框架、生态地图、对比矩阵，最后我们需要一个决策流程，快速缩小候选工具范围。决策基于三个关键问题：

Q1: 目标硬件是什么？

这是第一优先级问题，因为硬件决定了生态圈：

Intel CPU / iGPU / Arc GPU：Intel 阵营 (Optimum Intel + NNCF + OpenVINO)
NVIDIA GPU (consumer / datacenter)：NVIDIA 阵营 (TensorRT-LLM + ModelOpt) 或 HuggingFace 通用层 (vLLM + llm-compressor)
Apple Silicon (M1/M2/M3/M4)：Apple coremltools (移动/边缘) 或 llama.cpp (通用)
AMD GPU (ROCm)：AMD Quark + ONNX Runtime，或 vLLM (ROCm 后端)
纯 CPU (x86 / ARM)：llama.cpp (首选) 或 ONNX Runtime
移动设备 (Android / iOS)：Google AI Edge Torch (Android) / Apple coremltools (iOS)
边缘 NPU (Qualcomm / Rockchip / etc.)：厂商特定工具 + ONNX / TFLite

Q2: 对精度敏感度如何？

量化会带来精度损失，不同任务的容忍度不同：

宽松（UI 文案生成、闲聊机器人）：可以用 Q4_K_S、IQ2_XS 等激进量化，perplexity 增加 0.1-0.2 可接受
中等（通用对话、文档问答）：推荐 Q4_K_M、Q5_K_M，perplexity 增加 < 0.1
严格（代码生成、数学推理、医疗咨询）：推荐 Q6_K、Q8_0、FP8，或使用 accuracy-aware quantization

Q3: 是否需要 accuracy-aware 约束？

Accuracy-aware quantization (AAQ) 是指在量化过程中设置 accuracy 约束（如”推理精度不得低于 baseline 的 99%”），工具自动调整量化策略（如为敏感层保留高精度）。支持 AAQ 的工具：

NNCF：nncf.quantize_with_accuracy_control() API
Microsoft Olive：Evaluator + Search Strategy 组合
Intel Neural Compressor (INC)：PostTrainingQuantConfig(accuracy_criterion=...) API

如果你的场景对精度极度敏感，且愿意接受更长的量化时间（AAQ 需要在验证集上多次迭代），应该优先考虑支持 AAQ 的工具。

决策树示例

下面是一个具体的叶子节点示例：

场景：Intel iGPU + 严格精度要求 + 需要 accuracy-aware → 推荐方案：Optimum Intel + NNCF quantize_with_accuracy_control → 理由：NNCF 是 Intel 官方的压缩库，和 OpenVINO 集成最深；quantize_with_accuracy_control 会自动在验证集上迭代，找到满足精度约束的最激进量化策略（可能是部分层 INT8、部分层 FP16 的混合精度） → 输出格式：OpenVINO IR (.xml + .bin) → 推理引擎：OpenVINO Runtime

下面的交互组件实现了完整的决策树。点击每个问题的选项，逐步展开，最终到达推荐方案（包含工具组合、理由、跳转链接）：

工具选择决策树

3 个问题引导推荐

Q1: 目标硬件？

§7 过渡到下一篇

如果你在决策树中选择了 Intel 阵营，接下来就会面临 Optimum Intel、NNCF、OpenVINO Converter 三个工具的具体选择问题——它们之间是什么调用关系？什么时候直接用 NNCF，什么时候用 Optimum Intel 封装？NNCF 支持的 20+ 种算法 × 4 种后端（OpenVINO / PyTorch / TorchFX / ONNX）如何选？OpenVINO IR 格式的内部结构是什么？

这些问题将在下一篇 《Intel 模型优化栈深潜》 中详细解答。再下一篇（第三篇）则是 动手实践指南：从一个 Hugging Face checkpoint 出发，用 Optimum Intel + NNCF 执行 INT8 量化 + accuracy-aware tuning，输出 OpenVINO IR，并在 Intel iGPU 上部署推理，完整走通 end-to-end 流程。

如果你选择了其他阵营（如 NVIDIA、llama.cpp、移动端），我们后续也会推出对应的深潜和实践文章。整个 量化与模型转换工具链 系列的目标是：让你不仅知道”有哪些工具”，更理解”为什么这样设计”、“什么场景用什么”、“如何组合使用”——从困惑到清晰，从选型到落地。