6种大型语言模型部署格式

你以为“模型越快越通用”，其实在生产里往往反过来：跑得越快，能跑它的机器就越少。很多团队一上来就追求极致性能，结果上线时发现只能跑在几块特定GPU上，扩容、迁移都异常痛苦。理解不同部署格式背后的取舍，是避免踩坑的第一步。下面这6种格式，基本覆盖了当下主流的LLM生产形态。

速度与兼容性的核心悖论

为什么“更快”反而限制了你

Google和Anthropic在LLM推理上的共识很简单：想要更快，就得在模型文件里提前锁死更多“硬件细节”。这些细节包括算子实现、内存布局、精度选择，甚至是针对某一代GPU的特殊优化指令。好处是推理时几乎不用再做复杂决策，直接按预先编排好的路径执行，速度自然上去。

代价也很直接：这些选择只对目标硬件友好，换一块卡、换一套驱动，性能可能立刻腰斩，甚至根本跑不起来。有用户反馈，在A100上用TensorRT编译的引擎，迁到L40S集群后完全无法加载，只能重新编译一遍。对需要多云部署或混合云的团队来说，这种锁定感会非常强烈。

据一些云厂商的内部数据，针对特定GPU编译的LLM推理引擎，延迟可以降低30%～60%，但可迁移性往往下降到“只能在1～2种机型上稳定运行”。

六种主流格式的整体地图

下图展示了生产环境中常见的六种LLM部署格式，从“最通用、最慢”到“最专用、最快”大致排成一条线：

六种LLM格式

越靠上，格式越接近原始权重，依赖Python和框架，几乎能在任何支持环境里跑，但性能上限受限。越往下，格式越“硬件化”，推理速度惊人，却把你牢牢绑在特定芯片或生态上。很多团队的真实路径是：先用上层格式快速验证，再逐步向下迁移到更激进的加速方案。

通用权重格式：灵活但不够快

Pickle / .pt：强大却有安全隐患

1）Pickle和PyTorch的.pt文件，本质上保存的是原始权重和一段“如何重建对象”的指令。它们可以在任何支持Python和对应框架的环境中运行，灵活性极高。缺点也很明显：推理速度不会超过底层框架本身的性能上限，所有优化都要依赖PyTorch等库来完成。

Pickle与safetensors

一个.pt文件其实是torch.load要执行的一系列指令，加载检查点时不仅会读数据，还可能执行任意Python代码。安全团队已经多次提醒：从不可信来源下载的.pt模型，理论上可以在加载瞬间执行恶意逻辑。对金融、医疗等高敏感行业来说，这种风险是不能忽视的。

Safetensors：更安全的“纯数字”容器

2）Safetensors的思路就干脆很多：只保存纯数字权重，按照内存布局顺序写入文件，打开时直接映射到内存，不重建复杂对象结构。这样一来，加载过程不再执行任意代码，安全性大幅提升，加载速度也更可控。有用户反馈，在同等硬件下，safetensors的加载时间比传统.pt缩短了20%～30%。

不过，safetensors依然需要Python、模型代码和分词器配合使用。它解决的是“安全和加载效率”的问题，而不是“极致推理性能”。对需要频繁热更新模型、又担心供应链攻击的团队，这种格式会更安心一些。我自己在做内部demo时，也更偏向用safetensors来做默认格式。

面向部署的格式：从桌面到跨框架

GGUF：让LLM跑在“没有框架”的机器上

3）GGUF是llama.cpp生态的核心格式，目标很明确：在一台没有安装任何机器学习框架的普通机器上，也能直接跑大模型。它把权重、分词器、聊天模板等运行所需的关键信息打包进一个文件里，llama.cpp或Ollama拿到就能推理，不需要额外的Python环境。

GGUF格式

这种设计特别适合边缘设备、个人电脑、甚至一些受限的企业内网环境。比如，一位朋友在没有独显的办公Mac上，用GGUF+llama.cpp跑了一个7B模型，虽然速度不算惊艳，但做代码补全已经够用。风险在于：GGUF高度绑定llama.cpp生态，算子支持和优化节奏完全跟着这个项目走，想用更激进的GPU优化时会有点受限。

ONNX：跨框架、跨硬件的“中间语”

4）ONNX被设计成一种“交换格式”，让在一个框架里训练好的模型，可以在另一个没有安装该框架的环境中运行。它会把模型拆成一系列标准算子和执行顺序，保存成一个图结构文件。加载时，由ONNX Runtime或其他后端来决定具体跑在CPU、CUDA GPU还是NPU上。

ONNX格式

这种“操作定义清晰、硬件选择开放”的模式，让ONNX非常适合做企业级中间层：训练团队用PyTorch，推理团队可以在Windows服务器、Linux容器甚至移动端各自选择最合适的后端。数据显示，一些团队在迁移到ONNX Runtime后，在CPU推理场景中获得了约2～3倍的吞吐提升。不过，ONNX对新型算子的支持有时会滞后，遇到前沿模型结构时需要额外适配。

深度绑定硬件的格式：为极致性能而生

MLX：苹果芯片上的“一体化内存”玩法

5）MLX是苹果为自家芯片（尤其是M系列）打造的机器学习框架，核心优势在于CPU和GPU共享统一的内存池。MLX格式会明确权重的存放位置和访问方式，尽量避免在CPU和GPU之间来回复制数据，这在大模型推理中能省下不少时间和能耗。

MLX格式

这种优势只在苹果自家硬件上成立，对云端NVIDIA集群几乎没有帮助。有开发者在M2 Max上用MLX跑7B模型，实测每秒能生成20～30个token，日常开发体验非常顺滑。说实话，我也不太确定这个生态未来会不会像Metal那样成为“Mac开发标配”，但对已经重度使用Mac的个人开发者和小团队来说，MLX确实是个值得关注的方向。

TensorRT：把模型编译成GPU“专用机器码”

6）TensorRT是NVIDIA的高性能推理编译器，会把模型图编译成针对特定GPU架构优化过的“引擎文件”。在构建阶段，它会把算子融合、精度选择（如FP16、INT8）、内存分配、kernel调度等细节全部确定下来，并在目标显卡上做实际测试，挑出最快的执行路径。

TensorRT格式

结果就是：推理速度可以非常夸张。有公开案例显示，在同等硬件上，TensorRT-LLM相对原生PyTorch推理延迟可降低50%以上，吞吐提升数倍。不过，所有这些细节都在构建时锁死，引擎文件往往只能在同一代或兼容架构的GPU上加载。对需要频繁更换GPU型号、或多云部署的团队来说，这种强绑定是一把双刃剑。

有用户反馈，在A10G上编译的TensorRT引擎迁移到T4集群时完全不可用，只能重新构建，导致上线时间被迫延后一周。

如何按延迟预算选格式

一条简单但实用的决策规则

如果你没有特别极端的性能需求，一个相对安全的默认策略是：根据延迟预算，选择图表中尽可能靠上的格式。每往下一个层级，你都在用更强的硬件绑定换取更低的延迟。可以用一个简单的判断流程：

  • 延迟预算 > 1 秒：优先考虑safetensors + PyTorch / Transformers
  • 延迟在 200～1000 ms：可以评估ONNX、GGUF等更轻量的推理路径
  • 延迟 < 200 ms 且QPS高：再考虑TensorRT、MLX这类深度绑定硬件的方案
  • 需要多云或混合云：尽量停留在ONNX或更上层的格式
  • 需要本地桌面/边缘部署：GGUF + llama.cpp / Ollama是当前的热门组合

我自己的观察是：很多团队一开始就冲向TensorRT，结果在迭代模型、切换云厂商时被各种兼容性问题拖住。更稳妥的做法，是先用通用格式打磨好产品形态，再把最稳定的那部分流量迁到更激进的加速链路上。

风险与现实约束：别只看基准测试

现实世界里，部署格式的选择还会受到团队技能栈、合规要求、预算和组织结构的影响。有的团队缺乏C++和CUDA经验，维护TensorRT pipeline的成本远高于节省下来的GPU费用；有的行业对供应链安全极度敏感，会优先选择safetensors、ONNX这类更透明的格式。还有一个常被忽略的点：调试难度。

越往下层的格式，调试体验往往越差。ONNX图已经不太好读，TensorRT引擎出了问题，排查起来更像是在“黑盒里摸索”。如果你的团队还在频繁改模型结构、试新算子，过早锁定在底层格式，很可能会拖慢整体迭代节奏。这话听着有点扎心，但在不少大厂内部项目里已经被反复验证。

选格式时，不妨多问一句：一年后我们还会用同一套硬件和模型吗？如果答案是否定的，就要谨慎对待那些“看起来很香”的极致优化方案。

延伸学习：从格式到完整LLMOps

如果你想把“模型格式”放进更大的LLMOps全景里看，会发现它只是推理与服务阶段的一块拼图。数据准备、训练、评估、监控、回滚、A/B测试，每一环都可能影响你最终的格式选择。比如，是否需要在线A/B不同版本模型，就会影响你是否方便维护多套TensorRT引擎。

我们在一套系统化的LLMOps课程里，把这些环节拆开讲清楚，从基础概念到生产级实践都有覆盖：

这些判断方法在不少真实项目里都被反复验证过，适合在你做关键架构决策前翻出来对照一遍。如果你正卡在“选哪种格式上线”这种问题上，这篇内容往往比随手问几个人更系统，也更少带个人偏见。

祝你在下一次部署LLM时，能更笃定地说出：我们为什么选这种格式。

常见问题

Q：小团队做内部助手，应该优先选哪种LLM部署格式？

A：大多数小团队做内部助手，优先选safetensors + PyTorch或Transformers会更稳妥。原因是这套组合生态成熟、文档丰富，调试和迭代成本低，而且可以直接复用Hugging Face等社区资源。性能上，通过合理的batch、KV缓存和量化，已经能满足大部分内部问答、代码助手场景。建议先用这种通用格式把产品形态跑顺，再根据实际瓶颈考虑是否迁移到ONNX或TensorRT等更激进的方案。

Q：ONNX和TensorRT在生产里怎么选，差别到底有多大？

A：如果你需要跨平台、跨云部署，ONNX通常是更合适的中间层选择；如果你的业务高度集中在NVIDIA GPU上，并且对延迟和吞吐有极致要求，TensorRT会更有优势。ONNX的好处是可移植性强，支持CPU、GPU、甚至部分NPU后端，适合做统一模型格式；TensorRT则通过算子融合、精度压缩和kernel调优，把性能压到极致。建议做一次小规模AB测试：在同一模型和硬件上，对比两者的延迟、吞吐和维护成本，再决定是否值得承受TensorRT带来的硬件锁定。

Q：GGUF适合用在正式生产环境吗，还是更偏向玩具/桌面？

A：GGUF完全可以用在正式生产环境，尤其是边缘部署、本地隐私场景和轻量级API服务。它的优势是依赖少、部署简单，可以在没有Python和大型框架的环境中直接运行，降低了运维复杂度。判断标准是你的场景是否需要高度可扩展的GPU集群和复杂监控，如果主要是单机或小规模节点，GGUF+llama.cpp/Ollama是很实用的组合。需要注意的是，生态和算子支持节奏受llama.cpp项目影响，遇到前沿模型结构时可能需要等待社区适配。

Q：在Mac上开发LLM应用，用MLX和用PyTorch差别大吗？

A：在苹果芯片上，MLX通常能更好地利用统一内存和GPU资源，相比PyTorch在某些模型上会有更流畅的交互体验。原因是MLX专门针对M系列芯片做了内存布局和算子优化，减少了CPU/GPU之间的数据拷贝。PyTorch在Mac上也能用Metal后端，但优化深度和生态整合度略逊一筹。建议做一个简单对比：选一个你实际要用的模型，在相同Mac上分别用MLX和PyTorch跑推理，比较加载时间、token生成速度和显存占用，再决定是否迁移到MLX生态。

Q：如何判断自己是否“过早”使用了TensorRT这类底层格式？

A：一个简单信号是：你还在频繁改模型结构、尝试新算子，却已经花大量时间在维护TensorRT引擎和兼容性问题上。原因在于底层格式对模型结构变更非常敏感，每次调整都可能需要重新构建和测试引擎，拖慢整体迭代节奏。如果你发现团队一半时间在“修引擎”，而不是优化产品体验，就说明可能用早了。建议先把模型结构和业务需求稳定在一个相对成熟的版本，再把最核心、最稳定的流量迁移到TensorRT，把它当成“性能加速层”，而不是“默认起点”。