1. 引言上一篇文章《大模型边缘部署全景图》里我们把边缘部署的完整链路梳理了一遍从模型准备、量化压缩到推理引擎选型、设备侧服务发布再到性能验证、观测排障、OTA 发布与安全合规。整条链路里模型准备与导出是第一步也是最容易被低估的一步——很多项目在推理引擎上反复调优最后发现瓶颈其实出在模型格式选错了。这一篇我们聚焦链路的第一环ONNX 和 GGUF 到底怎么选。我会从格式的定位、适用场景、转换流程、量化支持、生态成熟度几个维度展开并给出可落地的选型建议。2. 为什么模型格式如此重要模型训练完成后PyTorch 的.pt/.pth权重文件并不能直接拿到边缘设备上跑。原因有三运行时依赖重PyTorch 推理需要完整的 Python 环境和 Torch 库边缘设备往往资源受限装不下。算子不通用训练框架的算子实现与端侧推理引擎的算子集合不一致直接加载会报「算子不支持」。优化空间小原始权重没有经过图优化、算子融合、量化校准推理性能远未达到硬件上限。所以模型导出本质上是一次「格式转换 图优化 量化准备」的组合动作。选对格式后续的量化、编译、部署都会顺畅很多选错格式后面每一步都在还债。3. ONNX跨框架、跨硬件的「通用交换格式」3.1 ONNX 是什么ONNXOpen Neural Network Exchange是一个开放、中立的模型表示格式由微软、Facebook 等发起现由 Linux Foundation 旗下的 ONNX 社区维护。它的核心定位是「模型交换」让模型可以在 PyTorch、TensorFlow、PaddlePaddle 等框架之间迁移并统一交给 ONNX Runtime 等推理引擎执行。3.2 核心优势框架中立PyTorch、TensorFlow、PaddlePaddle 都能导出 ONNX一次导出多处复用。生态成熟ONNX Runtime、OpenVINO、TensorRT、ONNX-ML 等主流引擎都原生支持。量化路径清晰配合 onnxruntime 的量化工具可以方便地做 INT8 / INT16 量化。图优化友好ONNX 图结构规整便于做算子融合、常量折叠等静态优化。3.3 典型适用场景需要跨框架迁移或多引擎对比的项目。目标设备是x86 CPU、ARM CPU、GPU、NPU等多样硬件希望一套模型多处部署。需要借助OpenVINO / TensorRT做进一步编译优化的场景它们都以 ONNX 为常见输入。3.4 转换示例PyTorch → ONNXimporttorchimporttorchvision.modelsasmodels modelmodels.resnet18(pretrainedTrue)model.eval()dummy_inputtorch.randn(1,3,224,224)torch.onnx.export(model,dummy_input,resnet18.onnx,input_names[input],output_names[output],dynamic_axes{input:{0:batch},output:{0:batch}},opset_version17,)导出后用onnxruntime验证importonnxruntimeasort sessort.InferenceSession(resnet18.onnx,providers[CPUExecutionProvider])importnumpyasnp xnp.random.randn(1,3,224,224).astype(np.float32)outsess.run(None,{input:x})print(out[0].shape)4. GGUF为 CPU 推理和量化而生的「本地优先」格式4.1 GGUF 是什么GGUFGPT-Generated Unified Format是llama.cpp 项目推出的模型格式前身是 GGML。它的设计目标非常明确让大模型能在普通 CPU 上高效运行尤其适合资源有限的本地设备。4.2 核心优势单文件自包含权重、分词器、超参数、元数据全部打包在一个文件里分发方便。量化支持极佳原生支持 Q4_K_M、Q5_K_M、Q8_0 等 K-quant 量化方案CPU 上效果出色。内存友好支持 mmap 内存映射加载启动快、内存占用低。与 llama.cpp 深度绑定llama.cpp 生态含各种绑定、Server、CLI直接消费 GGUF。4.3 典型适用场景目标设备是普通 CPU / 低功耗 ARM 设备如树莓派、开发板、老旧笔记本。需要快速跑通一个 1B ~ 7B 量级的模型做原型验证。希望开箱即用不想折腾复杂的编译和算子适配。4.4 转换示例HuggingFace → GGUF使用 llama.cpp 提供的转换脚本# 克隆 llama.cppgitclone https://github.com/ggerganov/llama.cppcdllama.cpp# 安装依赖pipinstall-rrequirements.txt# 将 HuggingFace 模型转换为 FP16 GGUFpython convert_hf_to_gguf.py\--outfilemodels/qwen2.5-1.5b-f16.gguf\--outtypef16\Qwen/Qwen2.5-1.5B-Instruct# 进一步量化为 Q4_K_M./llama-quantize\models/qwen2.5-1.5b-f16.gguf\models/qwen2.5-1.5b-q4_k_m.gguf\Q4_K_M预期输出转换阶段INFO: Loading model... INFO: Writing GGUF... INFO: Model converted successfully Output: models/qwen2.5-1.5b-f16.gguf (3.09 GB)量化阶段预期输出llama_model_quantize_internal: model size 3.09 GB llama_model_quantize_internal: quant size 1.02 GB llama_model_quantize_internal: hist: 0.123 0.456 0.789 ... main: build successful.4.5 量化前后对比收益与代价一目了然以 Qwen2.5-1.5B-Instruct 为例在Intel i5-12400 / 16GB RAM / Windows 11环境下实测格式文件大小推理速度精度损失FP163.09 GB基准0%Q8_01.67 GB1.2x0.1%Q4_K_M1.02 GB1.8x~1%Q2_K0.65 GB2.3x~3%可以看到Q4_K_M 是性价比最高的档位体积压缩到 1/3速度提升近一倍精度损失仅约 1%对绝大多数对话、问答场景完全够用。Q2_K 虽然体积最小但 3% 的精度损失在复杂推理任务上可能明显感知建议谨慎使用。5. ONNX vs GGUF一张表看懂差异维度ONNXGGUF定位跨框架、跨硬件的通用交换格式面向 CPU 推理的本地优先格式主导方ONNX 社区Linux Foundationllama.cpp 社区典型引擎ONNX Runtime、OpenVINO、TensorRTllama.cpp 及其绑定量化支持INT8 / INT16需配合工具链K-quantQ4/Q5/Q8原生支持单文件自包含否通常需配套配置是权重分词器元数据一体内存映射加载部分支持原生支持 mmap跨框架迁移极强弱主要面向 llama.cpp 系硬件覆盖面x86/ARM/GPU/NPU 广以 CPU 为主GPU 支持有限适合模型规模中小模型、视觉/多模态1B~70B 大语言模型生态成熟度极高工业级高但集中在 LLM 推理6. 选型决策树是是否是否否视觉/多模态/传统模型模型类型是 LLM 吗?目标设备以 CPU 为主?选 GGUF llama.cpp需要 GPU/NPU 加速?选 ONNX TensorRT/OpenVINOGGUF 或 ONNX 均可按生态偏好选 ONNX ONNX Runtime决策逻辑先判断模型类型再根据目标设备的算力形态CPU / GPU / NPU选择格式。核心原则——LLM 且以 CPU 为主选 GGUF需要多硬件覆盖或进一步编译优化选 ONNX。7. 常见误区与避坑建议误区一GGUF 只能跑 CPU。实际上 llama.cpp 也支持部分 GPU 加速但 CPU 是它的主场GPU 场景优先考虑 ONNX TensorRT。误区二ONNX 一定比 GGUF 快。在纯 CPU 跑 LLM 时GGUF llama.cpp 往往更快ONNX 的优势在于多硬件覆盖和工业级优化。误区三导出一次就完事。模型导出后一定要做精度对比导出前后输出差异和算子兼容性检查否则部署阶段会踩坑。精度对比很简单跑一遍同一输入、对比输出差异即可importnumpyasnp# PyTorch 输出pt_outmodel(dummy_input).detach().numpy()# ONNX Runtime 输出onnx_outsess.run(None,{input:x})[0]# 计算最大绝对误差print(f最大误差:{np.max(np.abs(pt_out-onnx_out)):.6f})一般最大误差在1e-4量级以内都算正常如果误差达到1e-2以上说明导出配置或算子实现有问题需要排查。避坑建议导出 ONNX 时注意opset_version与目标引擎的兼容性转换 GGUF 时确认tokenizer配置正确否则生成乱码。8. 小结与下一步这一篇我们厘清了 ONNX 和 GGUF 的定位差异ONNX 是「通用交换格式」适合跨框架、多硬件、需要进一步编译优化的场景GGUF 是「CPU 优先格式」适合快速在普通设备上跑通 LLM。选型时先问自己三个问题模型是不是 LLM目标设备以 CPU 还是 GPU/NPU 为主是否需要跨框架迁移下一篇我们将深入量化与压缩聊聊 INT8 / INT4 到底能带来多少收益、又需要付出什么代价以及如何做量化校准和精度评估。关注专栏「前沿部署工程师 FED」持续跟进大模型边缘部署全链路实战。下一篇量化与压缩——INT8/INT4 的收益和代价收藏 不迷路欢迎在评论区交流你的选型心得。 
长河君 · 2026/10/14 5:01:03 · 阅读 1.2k 模型准备与导出：ONNX、GGUF 到底怎么选
1. 引言上一篇文章《大模型边缘部署全景图》里我们把边缘部署的完整链路梳理了一遍从模型准备、量化压缩到推理引擎选型、设备侧服务发布再到性能验证、观测排障、OTA 发布与安全合规。整条链路里模型准备与导出是第一步也是最容易被低估的一步——很多项目在推理引擎上反复调优最后发现瓶颈其实出在模型格式选错了。这一篇我们聚焦链路的第一环ONNX 和 GGUF 到底怎么选。我会从格式的定位、适用场景、转换流程、量化支持、生态成熟度几个维度展开并给出可落地的选型建议。2. 为什么模型格式如此重要模型训练完成后PyTorch 的.pt/.pth权重文件并不能直接拿到边缘设备上跑。原因有三运行时依赖重PyTorch 推理需要完整的 Python 环境和 Torch 库边缘设备往往资源受限装不下。算子不通用训练框架的算子实现与端侧推理引擎的算子集合不一致直接加载会报「算子不支持」。优化空间小原始权重没有经过图优化、算子融合、量化校准推理性能远未达到硬件上限。所以模型导出本质上是一次「格式转换 图优化 量化准备」的组合动作。选对格式后续的量化、编译、部署都会顺畅很多选错格式后面每一步都在还债。3. ONNX跨框架、跨硬件的「通用交换格式」3.1 ONNX 是什么ONNXOpen Neural Network Exchange是一个开放、中立的模型表示格式由微软、Facebook 等发起现由 Linux Foundation 旗下的 ONNX 社区维护。它的核心定位是「模型交换」让模型可以在 PyTorch、TensorFlow、PaddlePaddle 等框架之间迁移并统一交给 ONNX Runtime 等推理引擎执行。3.2 核心优势框架中立PyTorch、TensorFlow、PaddlePaddle 都能导出 ONNX一次导出多处复用。生态成熟ONNX Runtime、OpenVINO、TensorRT、ONNX-ML 等主流引擎都原生支持。量化路径清晰配合 onnxruntime 的量化工具可以方便地做 INT8 / INT16 量化。图优化友好ONNX 图结构规整便于做算子融合、常量折叠等静态优化。3.3 典型适用场景需要跨框架迁移或多引擎对比的项目。目标设备是x86 CPU、ARM CPU、GPU、NPU等多样硬件希望一套模型多处部署。需要借助OpenVINO / TensorRT做进一步编译优化的场景它们都以 ONNX 为常见输入。3.4 转换示例PyTorch → ONNXimporttorchimporttorchvision.modelsasmodels modelmodels.resnet18(pretrainedTrue)model.eval()dummy_inputtorch.randn(1,3,224,224)torch.onnx.export(model,dummy_input,resnet18.onnx,input_names[input],output_names[output],dynamic_axes{input:{0:batch},output:{0:batch}},opset_version17,)导出后用onnxruntime验证importonnxruntimeasort sessort.InferenceSession(resnet18.onnx,providers[CPUExecutionProvider])importnumpyasnp xnp.random.randn(1,3,224,224).astype(np.float32)outsess.run(None,{input:x})print(out[0].shape)4. GGUF为 CPU 推理和量化而生的「本地优先」格式4.1 GGUF 是什么GGUFGPT-Generated Unified Format是llama.cpp 项目推出的模型格式前身是 GGML。它的设计目标非常明确让大模型能在普通 CPU 上高效运行尤其适合资源有限的本地设备。4.2 核心优势单文件自包含权重、分词器、超参数、元数据全部打包在一个文件里分发方便。量化支持极佳原生支持 Q4_K_M、Q5_K_M、Q8_0 等 K-quant 量化方案CPU 上效果出色。内存友好支持 mmap 内存映射加载启动快、内存占用低。与 llama.cpp 深度绑定llama.cpp 生态含各种绑定、Server、CLI直接消费 GGUF。4.3 典型适用场景目标设备是普通 CPU / 低功耗 ARM 设备如树莓派、开发板、老旧笔记本。需要快速跑通一个 1B ~ 7B 量级的模型做原型验证。希望开箱即用不想折腾复杂的编译和算子适配。4.4 转换示例HuggingFace → GGUF使用 llama.cpp 提供的转换脚本# 克隆 llama.cppgitclone https://github.com/ggerganov/llama.cppcdllama.cpp# 安装依赖pipinstall-rrequirements.txt# 将 HuggingFace 模型转换为 FP16 GGUFpython convert_hf_to_gguf.py\--outfilemodels/qwen2.5-1.5b-f16.gguf\--outtypef16\Qwen/Qwen2.5-1.5B-Instruct# 进一步量化为 Q4_K_M./llama-quantize\models/qwen2.5-1.5b-f16.gguf\models/qwen2.5-1.5b-q4_k_m.gguf\Q4_K_M预期输出转换阶段INFO: Loading model... INFO: Writing GGUF... INFO: Model converted successfully Output: models/qwen2.5-1.5b-f16.gguf (3.09 GB)量化阶段预期输出llama_model_quantize_internal: model size 3.09 GB llama_model_quantize_internal: quant size 1.02 GB llama_model_quantize_internal: hist: 0.123 0.456 0.789 ... main: build successful.4.5 量化前后对比收益与代价一目了然以 Qwen2.5-1.5B-Instruct 为例在Intel i5-12400 / 16GB RAM / Windows 11环境下实测格式文件大小推理速度精度损失FP163.09 GB基准0%Q8_01.67 GB1.2x0.1%Q4_K_M1.02 GB1.8x~1%Q2_K0.65 GB2.3x~3%可以看到Q4_K_M 是性价比最高的档位体积压缩到 1/3速度提升近一倍精度损失仅约 1%对绝大多数对话、问答场景完全够用。Q2_K 虽然体积最小但 3% 的精度损失在复杂推理任务上可能明显感知建议谨慎使用。5. ONNX vs GGUF一张表看懂差异维度ONNXGGUF定位跨框架、跨硬件的通用交换格式面向 CPU 推理的本地优先格式主导方ONNX 社区Linux Foundationllama.cpp 社区典型引擎ONNX Runtime、OpenVINO、TensorRTllama.cpp 及其绑定量化支持INT8 / INT16需配合工具链K-quantQ4/Q5/Q8原生支持单文件自包含否通常需配套配置是权重分词器元数据一体内存映射加载部分支持原生支持 mmap跨框架迁移极强弱主要面向 llama.cpp 系硬件覆盖面x86/ARM/GPU/NPU 广以 CPU 为主GPU 支持有限适合模型规模中小模型、视觉/多模态1B~70B 大语言模型生态成熟度极高工业级高但集中在 LLM 推理6. 选型决策树是是否是否否视觉/多模态/传统模型模型类型是 LLM 吗?目标设备以 CPU 为主?选 GGUF llama.cpp需要 GPU/NPU 加速?选 ONNX TensorRT/OpenVINOGGUF 或 ONNX 均可按生态偏好选 ONNX ONNX Runtime决策逻辑先判断模型类型再根据目标设备的算力形态CPU / GPU / NPU选择格式。核心原则——LLM 且以 CPU 为主选 GGUF需要多硬件覆盖或进一步编译优化选 ONNX。7. 常见误区与避坑建议误区一GGUF 只能跑 CPU。实际上 llama.cpp 也支持部分 GPU 加速但 CPU 是它的主场GPU 场景优先考虑 ONNX TensorRT。误区二ONNX 一定比 GGUF 快。在纯 CPU 跑 LLM 时GGUF llama.cpp 往往更快ONNX 的优势在于多硬件覆盖和工业级优化。误区三导出一次就完事。模型导出后一定要做精度对比导出前后输出差异和算子兼容性检查否则部署阶段会踩坑。精度对比很简单跑一遍同一输入、对比输出差异即可importnumpyasnp# PyTorch 输出pt_outmodel(dummy_input).detach().numpy()# ONNX Runtime 输出onnx_outsess.run(None,{input:x})[0]# 计算最大绝对误差print(f最大误差:{np.max(np.abs(pt_out-onnx_out)):.6f})一般最大误差在1e-4量级以内都算正常如果误差达到1e-2以上说明导出配置或算子实现有问题需要排查。避坑建议导出 ONNX 时注意opset_version与目标引擎的兼容性转换 GGUF 时确认tokenizer配置正确否则生成乱码。8. 小结与下一步这一篇我们厘清了 ONNX 和 GGUF 的定位差异ONNX 是「通用交换格式」适合跨框架、多硬件、需要进一步编译优化的场景GGUF 是「CPU 优先格式」适合快速在普通设备上跑通 LLM。选型时先问自己三个问题模型是不是 LLM目标设备以 CPU 还是 GPU/NPU 为主是否需要跨框架迁移下一篇我们将深入量化与压缩聊聊 INT8 / INT4 到底能带来多少收益、又需要付出什么代价以及如何做量化校准和精度评估。关注专栏「前沿部署工程师 FED」持续跟进大模型边缘部署全链路实战。下一篇量化与压缩——INT8/INT4 的收益和代价收藏 不迷路欢迎在评论区交流你的选型心得。