58 tokens/s从何而来lift-oQ8推理性能优化与实测分析【免费下载链接】lift-oQ8项目地址: https://ai.gitcode.com/hf_mirrors/mlx-community/lift-oQ8lift-oQ8 是一个在 Apple Silicon 上以58 tokens/s高速推理的 MLX 量化视觉语言模型专为 PDF、图片到结构化 JSON 的抽取任务打造。它基于 9B 参数的 qwen3_5 架构通过 oQ 混合精度量化把模型体积压缩到 9.7GB同时将推理性能做到了 bf16 原版的近两倍。这篇文章将拆解 58 tokens/s 究竟从何而来并附上完整的实测对比和部署指南。lift-oQ8是什么一个为文档→JSON而生的视觉语言模型先回答它是什么lift-oQ8 是 Datalab 开源的 lift 模型的 MLX 社区转换版核心能力是结构化抽取Structured Extraction——输入一张发票、合同或报表图片输出符合指定 JSON Schema 的结构化数据。 输入PDF 页面 / 图片️ 输出schema 约束的 JSON字段级、表格级 基座qwen3_5 9B32 层混合注意力架构 运行平台Apple SiliconM 系列芯片 mlx-vlm官方 FP16 原版在 Datalab 225 份文档基准上取得 90.2% 字段级准确率而 lift-oQ8 在保持接近精度的前提下把文件体积从 18GB 砍到9.7GB推理速度从 31 t/s 提升到58 t/s。模型全貌可以直接查看仓库根目录的 README.md。58 tokens/s从何而来三大优化支柱拆解支柱一oQ数据驱动混合精度量化≈8.6 bits/weight传统量化通常给整个模型统一位宽比如全 4bit 或全 8bit。**oQ数据驱动量化**的思路更聪明让数据决定每一层的精度——对输出影响大的敏感层保留更高精度不敏感的层压低位数。最终 lift-oQ8 的平均位宽只有≈8.6 bits/weight却保留了接近 8bit 的稳定性。对比一组直观数字指标bf16 原版lift-oQ8平均位宽16 bit≈8.6 bit文件体积18 GB9.7 GB峰值内存19.9 GB12.3 GB生成速度31 t/s58 t/s体积几乎减半速度翻倍。量化的具体配置group_size64、8bit 仿射量化都写在 config.json 的quantization_config字段中想复现转换过程的同学可以对照查看。支柱二混合注意力架构——线性注意力轻装上阵58 t/s 的另一半功劳来自模型架构本身。lift 的 32 个隐藏层中有24 层是线性注意力linear attention类似 Mamba 的状态空间设计只有 8 层是标准全注意力每 4 层插入一层⚡ 线性注意力解码时状态大小固定不随上下文长度膨胀长文档推理又快又省内存 全注意力负责关键的全局信息交互保证抽取质量从 config.json 的layer_types可以清楚看到这种 3 线性 1 全注意力 的循环排布。混合设计让模型天然适合长文档结构化抽取配合约 26 万 token 的上下文窗口处理超长 PDF 也不在话下。支柱三Apple Silicon 统一内存 mlx-vlm 运行时最后一块拼图是运行环境。MLX 是苹果官方的机器学习框架直接调用 Metal 加速 统一内存架构CPU/GPU 共享内存模型无需在显存与内存间反复搬运⚙️ mlx-vlm 运行时针对视觉语言模型解码做了专门优化 实测硬件MacBook Pro M5 Max128GB / 40 核 GPU三者叠加才有了单图发票抽取 58 t/s 的成绩。需要说明的是这是官方标注的参考值而非严格基准实际速度会因硬件型号、图片大小和输出长度浮动。七档量化实测对比如何选到最适合你的版本mlx-community 为 lift 发布了一整条 oQ 量化变体从 16bit 到 3.5bit 覆盖精度优先到速度优先的全谱系变体量化方法平均位宽体积峰值内存生成速度lift-bf16bf161618 GB19.9 GB31 t/slift-oQ8oQ≈8.69.7 GB12.3 GB58 t/slift-oQ6oQ≈67.7 GB9.4 GB73 t/slift-oQ5oQ≈56.7 GB8.4 GB83 t/slift-oQ4oQ≈4.65.6 GB7.2 GB100 t/slift-oQ3.5oQ≈44.9 GB6.5 GB109 t/slift-oQ3oQ≈3.54.6 GB6.2 GB119 t/s选择建议 精度优先 / 生产环境选 lift-oQ8精度与速度的最佳平衡点⚡ 内存有限 / 追求速度oQ4 或 oQ3.5100 t/s 体验极佳适合对格式要求宽松的场景 先试后买从 oQ5 起步速度、精度、体积都足够日常使用如何复现 58 tokens/s三步快速上手第一步准备环境一台 Apple Silicon MacM 系列芯片建议 16GB 以上内存安装好uv工具即可。模型权重会自动下载也可以直接git clone https://gitcode.com/hf_mirrors/mlx-community/lift-oQ8获取本仓库的模型文件。第二步一行命令完成图片结构化抽取不需要写任何代码用 mlx-vlm 自带的命令行工具就能跑uvx --from mlx-vlm mlx_vlm.generate \ --model mlx-community/lift-oQ8 \ --image invoice.png \ --prompt Extract the invoice as JSON. \ --max-tokens 800把invoice.png换成你自己的发票或单据图片模型就会输出对应的 JSON 字段。第三步启动 OpenAI 兼容服务器用 JSON Schema 约束输出批量处理场景推荐服务器模式mlx_vlm.server会在解码阶段通过 llguidance 强制校验 JSON Schema保证输出一定合法、类型正确uvx --from mlx-vlm mlx_vlm.server --model mlx-community/lift-oQ8 --port 8080之后像调用 OpenAI API 一样传入图片和 schema返回内容就是可直接解析的结构化结果。服务端配置集中在 generation_config.json对话模板在 chat_template.jinja权重分片索引在 model.safetensors.index.json想深入研究的可以对照这些文件。实测中的关键细节与避坑指南⚠️ eos 修复为什么官方版本会停不下来这个仓库做了一个关键修复上游模型的generation_config只设置了eos_token_id: 248044但对话收尾用的是|im_end|token 248046导致 MLX 服务器永远等不到结束符、疯狂输出。本仓库的 generation_config.json 已把两个 token 都加上如果你从源模型重新转换记得要重新应用这个修复。 精度说明官方 FP16 原版在 Datalab 基准上是 90.2% 字段级 / 20.9% 整文档准确率。所有 oQ 变体在简单测试发票上都能正确抽取但低位数版本在更复杂、更刁钻的文档上可能会精度退化官方并未做大规模复测——正式上线前建议用自己的真实文档压测一轮。总结性能与精度的平衡艺术58 tokens/s 不是魔法而是三层优化叠加的结果oQ 数据驱动量化把权重压到 8.6bit混合注意力架构让长文档解码轻装上阵Apple Silicon 统一内存 mlx-vlm把硬件潜力释放到极致。如果你正在做发票识别、合同解析、单据录入这类文档到结构化数据的需求lift-oQ8 是一个高性价比的选择本地运行、数据不出机器、速度接近实时。从 README.md 出发几分钟就能跑通第一张发票的抽取。【免费下载链接】lift-oQ8项目地址: https://ai.gitcode.com/hf_mirrors/mlx-community/lift-oQ8创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考