lift 双推理后端深度对比:HuggingFace 本地 vs vLLM 服务器该如何选

📅 发布时间:2026/10/16 21:26:35
lift 双推理后端深度对比:HuggingFace 本地 vs vLLM 服务器该如何选
【免费下载链接】liftExtract structured data from documents quickly and accurately.项目地址https://gitcode.com/gh_mirrors/lift21/lift点击查看免费下载lift 是一个文档结构化数据提取工具给它一份 PDF 或图片再传一个 JSON schema它就返回一份与 schema 严格对齐的 JSON 对象。它内置 9B 视觉模型并提供两种推理后端——HuggingFace 本地推理与vLLM 服务器推理前者零配置单机即跑后者面向生产环境的高吞吐服务。本文从原理、启动方式到基准数据全面对比这两种后端帮你快速做出选择。先看懂lift 是怎么工作的lift 的核心流程非常直接把 PDF 渲染成页面图片支持page_range只取部分页将页面图片 schema 提示词一起发给视觉模型模型一次性返回匹配 schema 的 JSON支持跨页取值、长列表等复杂场景两个后端共用同一个模型权重默认datalab-to/lift在 lift/settings.py 中定义和同一套 schema 解析逻辑lift/extract.py区别只在于谁来跑这个模型。双推理后端一张表看懂统一入口是 lift/model/init.py 中的InferenceManagerCLI 通过--method [hf|vllm]切换默认vllm见 lift/scripts/extract_cli.py维度HuggingFace 本地hfvLLM 服务器vllm运行形态进程内直接跑模型独立服务OpenAI 兼容 API安装依赖lift-pdf[hf]含 torch、transformers基础包lift-pdf即可更轻量吞吐量低逐条串行生成高最高 64 并发 连续批处理输出保证自由生成靠后处理解析schema 约束解码保证 JSON 合法容错机制无重试内置自动重试重复 token 检测、退避等待关键配置TORCH_DEVICE、TORCH_ATTNVLLM_API_BASE、VLLM_MODEL_NAME适用场景单机尝鲜、调试、小批量生产部署、大批量、多服务共享HuggingFace 本地后端最简单的上手方式工作原理lift/model/hf.py 用 transformers 的AutoModelForImageTextToText在进程内加载权重bfloat16 精度device_map自动分配或用TORCH_DEVICE固定到指定 GPU直接调用model.generate()生成结果。没有服务、没有 Docker、没有网络调用。启动步骤pip install lift-pdf[hf] lift_extract input.pdf ./output --schema schema.json --method hf官方还建议在 HuggingFace 后端上安装 flash attention 以获得更好性能见 README.md。优点✅零依赖最简部署、调试方便、无需管理任何服务代价⚠️9B 模型加载约需 20GB 显存且无并发、无约束解码、无重试机制。vLLM 服务器后端生产级答案一条命令拉起推理服务lift_vllm # 默认按 H100 配置 lift_vllm --gpu a100-80 # 按你的显卡调参vllm_launcher.py 会启动一个 Docker 容器vllm-openai:v0.22.0并根据显卡显存自动缩放max-num-seqs与max-num-batched-tokens。内置支持 10 种显卡h100、a100-80、a100/a100-40、l40s、a10、l4、4090、3090、t4——即使只有 24GB 显存的 4090/3090 也能跑。服务默认监听http://localhost:8000/v1lift/settings.py 中VLLM_API_BASE改成远端地址即可让客户端连接远程 vLLM 服务器。内置的三重增强lift/model/vllm.py 相比本地后端多了三样东西schema 约束解码请求携带response_format{type: json_schema, ...}由服务端解码器保证输出一定是符合 schema 的合法 JSON高并发ThreadPoolExecutor最高 64 个并发请求配合 vLLM 的 continuous batching 吞吐拉满智能重试检测到重复 token 或请求失败时自动重试每次重试提高 temperature默认最多 6 次。客户端调用lift_extract input.pdf ./output --schema schema.json # 默认 methodvllmPython 侧同样默认走 vllm见 lift/extract.py如需复用已加载的本地模型可传InferenceManager(methodhf)from lift import extract result extract(document.pdf, schema.json) data result.extraction # 与 schema 对齐的 dict基准数据准确率和延迟表现如何官方在 225 份文档每份 6–64 页、约 1.1 万个计分项上做了对比测试其中 lift 由单卡 vLLM 服务提供模型规模字段准确率整文档准确率中位延迟Datalab API—95.9%44.4%30.8sGemini Flash 3.5—91.3%40.0%28.1slift9B90.2%20.9%9.5sAzure Content Understanding—83.4%22.2%73.7sNuExtract34B81.5%8.4%8.3sQwen3.5-9B9B76.3%24.0%16.8slift 以 9.5 秒的中位延迟位居本地模型第二快字段准确率 90.2% 超过 Qwen3.5-9B 近 14 个百分点。 注意延迟会随硬件和负载变化以上为相对参考值。schema 写法也影响效果——建议保持简单类型避免enum、anyOf、$ref等结构见 README.md 的 Schemas 一节仓库自带 lift/schemas/invoice.json 和 lift/schemas/Paper.json 可直接参考。如何选择5 条实用决策清单 没有 GPU 服务器只想快速尝鲜/调试 schema→ 用hf本地后端一条命令出结果单机处理几十上百份文件→ 用vllm并发 批处理比串行快得多多个应用/多台机器共享同一模型→ 只能选vllm设置VLLM_API_BASE指向远端服务即可输出必须是合法 JSON不容忍解析失败→ 选vllmschema 约束解码 自动重试是本地后端没有的只有 24GB 显存的消费级显卡4090/3090→vllm启动器会自动降配开箱即用。推荐路径新手先用--method hf验证 schema 是否正确、效果是否符合预期业务上量后切换到lift_vllm生产服务代码层面只需改一个参数其余调用方式完全一致。两种后端殊途同归模型是同一个schema 是同一份——你选的从来不是哪个模型更好而是我的场景需要多少吞吐与保证。赞分享【免费下载链接】liftExtract structured data from documents quickly and accurately.项目地址https://gitcode.com/gh_mirrors/lift21/lift点击查看免费下载相关推荐DeepSeek-LLM推理框架对比vLLM vs HuggingFace TransformersDeepSeek LLM推理框架对比vLLM vs HuggingFace Transformers 还在为大语言模型推理效率发愁一文带你掌握DeepSee人工智能大模型基础模型模型评测如何选择ArrayFire后端CUDA vs OpenCL vs oneAPI vs CPU性能对比如何选择ArrayFire后端CUDA vs OpenCL vs oneAPI vs CPU性能对比 ArrayFire是一个高性能并行计算软件库提供简单易科学计算计算机视觉机器学习图像处理flops-counter.pytorch双后端深度解析pytorch vs aten性能对比flops counter.pytorch双后端深度解析pytorch vs aten性能对比 在深度学习模型开发中准确评估模型的计算复杂度和参数量是优化性创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考