如何用 LiteLLM 搞定大规模文本分析与提取完整实战指南【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm把几百份 PDF 合同、操作手册丢给大模型批量分析听起来不难但如果你要同时对接好几家模型厂商每家 API 格式还不一样很快就会写出大量重复代码。LiteLLM 是一个开源 AI 网关可以用统一的 OpenAI 接口调用 100 种 LLM自带成本追踪和日志另外还内置了 PDF 文本提取和 OCR 能力从拿到文本到分析完一条线就能走完。为什么这类任务值得用 LiteLLM这一节说清楚它比你自己写适配层省事在哪四个点统一 LLM 接口Bedrock、Azure、OpenAI、Anthropic、Cohere 等 100 模型都走同一个completion()调用换供应商只需要改模型名字符串不用动代码。内置文本提取PDF 文本提取直接用 pypdf 完成扫描件支持走 Azure AI OCR 或 Vertex AI OCR 做识别多语言文档也没问题。成本与预算控制每次调用自动统计成本配合代理可以给每个 key、每个团队设预算上限和告警。可以当网关部署以代理模式跑起来之后多实例负载均衡、限流、重试都是现成的。安装只需两步克隆下来装一下就能用。PDF 依赖 pypdf 和数据处理用的 polars 都已经声明在项目依赖里不用单独再装git clone https://gitcode.com/GitHub_Trending/li/litellm cd litellm pip install -e .注意如果你只想调 SDK直接pip install litellm就够了上面克隆仓库的方式适合还要跑代理、或者想顺手读源码的场景。三种文本提取方式各管一摊文本来源不同走的路径不一样下面的选择基本不用你写解析代码。1. 原生 PDFPDF 文本提取。仓库自带extract_text_from_pdf先用 pypdf 逐页抽取取不到内容时自动回退到 PyPDF2最后把纯文本按页拼接返回。实现就在 litellm/rag/ingestion/出问题时看一眼源码就能定位。2. 扫描件和带图层的文档。如果 PDF 是扫描版直接抽文本会得到空结果这时切换到 OCR。LiteLLM 提供litellm.ocr()入口可选 Azure AI OCR 的文档智能服务也可以走 Vertex AI OCR后者对多语言场景更友好。代码在 litellm/ocr/。3. 纯图片。图片里的文字可以走 OCR 服务先转成文本再喂给普通模型也可以直接发给多模态模型让它自己读。前者便宜可控后者省事按你的场景选。搭一条最小分析管道分块 批量分析长文本喂不进模型的上下文窗口所以大规模文本分析的第一步永远是分块。仓库里有按段落边界切分的RecursiveCharacterTextSplitter在 litellm/rag/text_splitters/想快速跑通的话按固定长度切片也完全够用from litellm import completion chunks [text[i:i3000] for i in range(0, len(text), 3000)] results [] for chunk in chunks: resp completion( modelgpt-4o-mini, messages[{role: user, content: f请提取要点并总结\n{chunk}}], ) results.append(resp.choices[0].message.content)跑完把每个 chunk 的结果合并落盘就行。建议顺手记录已处理的文件名和 chunk 序号中途失败可以断点续跑不用整批重来。上量之后用代理跑起来看板盯着文档量上千、要并发发请求时就该把 LiteLLM 当代理服务器运行了一份配置文件里定义模型、key 和限流策略后面挂多实例做负载均衡和重试业务侧只连网关一个地址。启动后自带管理面板请求日志、花费统计、审计日志都在里面想要更细的观测接上 Langfuse每次 completion 调用都会自动上报一条 trace能看到执行时间、token 用量和成本排查哪批文本的提取质量掉了非常直观避坑与省钱建议分块大小先定对。每块超过模型上下文窗口直接报错大文档建议从 2000~3000 字符一块起步跑完再看效果微调。模型分级用。分类、抽取这类难度低的环节用小模型最后做归纳总结的环节再上贵的模型成本差往往就出在这里。打开缓存。相同模板处理重复文档时缓存能省掉大量重复请求的开销。设预算上限。代理跑起来后给 key 或团队配置预算和告警花超了第一时间能看到。先验提取质量。扫描件抽样看几页确认 OCR 结果不是空或乱码再进 LLM 环节否则模型只能对着垃圾输入瞎编。下一步建议先用你真实业务里的 10 份文档把这条管道跑通、确认输出质量再放量到全量别一上来就全批跑。想深入的话看 litellm/rag/ingestion/ 的文本提取实现和 litellm/ocr/ 的 OCR 入口要配观测直接打开 cookbook/logging_observability/ 里的 Langfuse 集成示例照着装。【免费下载链接】litellmThe fastest, litest AI Gateway. Rust core with Python SDK. Call 100 LLM APIs in OpenAI (or native) format with cost tracking, guardrails, load balancing, and logging [Bedrock, Azure, OpenAI, Anthropic, OpenAI, VertexAI, vLLM, Nvidia NIM]项目地址: https://gitcode.com/GitHub_Trending/li/litellm创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考