1. 项目概述LiteLLM 是什么它解决的到底是什么问题LiteLLM 这个名字乍一听像是某个轻量级编程语言或小众框架但其实它是一个在大模型应用开发圈子里迅速走红的开源工具库。我第一次在某次技术分享会上听到这个词时台下已经有好几位开发者在笔记本上快速记下——不是因为名字酷而是因为主持人刚演示完一个三行代码就把 OpenAI、Anthropic、Google Gemini、Cohere 甚至本地部署的 Ollama 模型全部“统一封装”的操作全场安静了三秒。LiteLLM 的核心价值就藏在这三秒里它不训练模型不优化推理速度也不做 UI 界面但它把当前碎片化到令人头疼的大模型调用生态硬生生拧成了一根能直接插进你现有代码里的标准接口线。简单说LiteLLM 是一个统一的 LLM 抽象层Unified LLM Abstraction Layer。它的存在直指当下工程落地中最真实的痛点你写了个客服对话系统初期用 GPT-4 效果惊艳客户一夸马上要上线结果第二天运营反馈成本太高得切到 Claude-3 Haiku第三天法务说不能出海得换本地部署的 Qwen2-7B第四天产品说用户抱怨响应慢得加个缓存流式返回……如果你没用 LiteLLM这意味着你要改至少四次import、六次client.chat.completions.create()调用逻辑、八处参数映射temperature 怎么传max_tokens 字段名是 max_tokens 还是 max_lengthstop_sequences 是数组还是字符串还得为每个 provider 单独处理 token 计数、错误码、流式 chunk 解析——而这些工作90% 都是重复劳动且极易出错。它不是替代 OpenAI SDK 的“更高级封装”而是反向构建了一套“最小公约数协议”只要模型支持文本生成chat completionLiteLLM 就能把它拉进同一个调用范式里。你写的代码里永远只有litellm.completion()这一个入口后面跟的是modelgpt-4、modelclaude-3-haiku-20240307、modelollama/llama3或者modelazure/gpt-4o——模型名就是路由键背后自动匹配 provider、认证方式、API 地址、参数转换规则和响应解析逻辑。这种设计思想和当年 Linux 内核抽象块设备block device让 SSD/HDD/NVMe 全部通过/dev/sdX访问如出一辙硬件千差万别但上层应用只需认准一个接口。对一线开发者而言LiteLLM 的价值链条非常清晰降低多模型切换的边际成本 → 提升 A/B 测试与灰度发布的可行性 → 增强系统抗供应商风险能力 → 最终让模型真正成为可调度、可替换、可监控的基础设施组件而非绑定死的黑盒依赖。它不解决“怎么让模型更聪明”但解决了“怎么让聪明的模型真正用起来”。这也是为什么它能在 GitHub 上半年内星标破 2 万且 PR 合并活跃度远超多数同类工具——因为写它的开发者每天都在真实踩坑。2. 核心设计思路与方案选型逻辑为什么是抽象层而不是代理或网关很多人第一反应是“这不就是个 API 网关吗自己搭个 Nginx 转发不就行了”或者“用 FastAPI 写个中间服务再做个路由表好像也差不多”——这种想法很自然但恰恰暴露了对 LiteLLM 定位的根本误判。它压根不是网络层的流量调度器而是一个运行时的语义适配器Semantic Adapter。理解这一点是掌握其设计精髓的关键。2.1 抽象层 vs. 网关本质差异在于“何时介入”与“介入深度”我们来拆解一个典型请求的生命周期传统网关路径你的代码 → HTTP Client → Nginx转发→ OpenAI API网关只管把/v1/chat/completions这个路径按规则转到https://api.openai.com/v1/chat/completions。它完全不知道messages数组里每个 dict 的role是system还是user也不知道temperature0.7在 Anthropic 里要映射成temperature: 0.7而在 Google Gemini 里得变成generationConfig: { temperature: 0.7 }更不会帮你把 OpenAI 返回的choices[0].message.content提取出来再塞进 Anthropic 返回的content[0].text字段里。LiteLLM 路径你的代码 → litellm.completion() → 内置 provider router → 参数标准化 → HTTP Client → OpenAI API → 响应反标准化 → 统一返回格式它在代码调用层面就完成了语义对齐。你传进去的是 Python dict它内部先做一次“归一化”把所有 provider 的输入字段max_tokens,max_length,max_gen_len…统一映射到 LiteLLM 自己定义的max_tokens把stop、stop_sequences、stop_words全部收口为stop再根据model参数查表决定该走哪个 provider 的专用适配器。响应阶段同理不管后端返回多乱的 JSON 结构LiteLLM 都会把它规整成response.choices[0].message.content这个标准字段连usage里的prompt_tokens、completion_tokens都给你算好、对齐、补全比如某些 provider 不返回 token 数LiteLLM 会用 tiktoken 本地估算。提示LiteLLM 的completion()函数签名里model是必填参数而api_base、api_key、api_version全是可选。这意味着你可以把所有敏感配置尤其是 Azure 的api_version这种易错字段集中管理代码里只留干净的modelazure/gpt-4o彻底告别“改一个模型翻十页文档查参数”的窘境。2.2 为什么不用代理服务——延迟、可观测性与调试成本的硬约束有人会说“那我起个独立服务比如用 LangChain 的ChatModel封装一层不也一样”理论上可行但工程实践里有三座大山额外网络跳转带来的确定性延迟本地开发时可能不明显但一旦部署到 K8s 集群你的应用 Pod → LiteLLM Proxy Pod → OpenAI API多一次跨 Pod 网络调用P99 延迟至少增加 15~30ms。而 LiteLLM 是纯 Python 库零网络开销litellm.completion()调用和原生 SDK 基本持平。可观测性断层代理服务让你丢失了最宝贵的上下文——调用栈。当一个请求超时你是要查代理日志还是查应用日志代理层看到的是“HTTP 504”但应用层其实早就在timeout30参数里设定了超时问题根源可能是你传错了model导致路由到一个根本不存在的 endpoint。LiteLLM 把所有错误都抛回给调用方堆栈里清清楚楚写着File xxx.py, line 42, in generate → litellm.completion(...)配合litellm.set_verbose(True)你能看到每一行 HTTP 请求/响应的完整 trace包括 headers、body、耗时比抓包还直观。调试地狱你想验证一个新模型是否兼容代理方案得改配置、重启服务、再调接口LiteLLM 方案只需改一行代码modelgroq/llama3-70b-8192CtrlS保存curl重试——快得像改 CSS 变量。2.3 “轻量”二字的真正含义不碰模型只管管道LiteLLM 的 GitHub README 第一行就写着“Call any LLM API using the OpenAI format.” 这句话信息量极大。“使用 OpenAI 格式”不是说它模仿 OpenAI而是以 OpenAI 的 chat completion 接口为事实标准de facto standard其他所有 provider 都向它对齐。这个选择极其务实OpenAI 的接口设计经过海量生产验证字段语义清晰messages,temperature,top_p,stream社区工具链如 LangChain、LlamaIndex默认都基于它构建。LiteLLM 不去挑战这个事实标准而是做它的“翻译官”。它刻意回避了所有高风险、高复杂度的领域不做模型量化quantization或推理优化inference optimization——那是 vLLM、TGI 的事不做 RAG 管道编排retrieval-augmented generation orchestration——那是 LlamaIndex 的地盘不做 Agent 框架agent framework——那是 LangChain/CrewAI 的战场。它只专注一件事确保litellm.completion(modelxxx, messages[...])这个函数调用在任何合法 model 名下都能返回结构一致、字段可用、错误可捕获的结果。这种“极度克制”的设计哲学正是它能在半年内支持 100 provider截至 2024 年中却依然保持核心代码 5000 行的关键——没有抽象就没有泄漏There is no abstraction without leakage。3. 核心功能实操详解从零开始跑通第一个多模型路由现在我们动手实操。假设你正在开发一个内部知识库问答机器人需求明确初期用 GPT-4 快速验证效果后续必须能无缝切换到公司自建的 Ollama 服务运行 Qwen2-7B且所有日志、监控、限流策略都要统一。下面是我实际在某项目中使用的最小可行配置已脱敏验证。3.1 环境准备与依赖安装# 创建干净虚拟环境强烈建议避免依赖冲突 python -m venv litellm-env source litellm-env/bin/activate # macOS/Linux # litellm-env\Scripts\activate # Windows # 安装核心库注意liteLLM 本身不强制依赖任何 provider SDK # 但调用特定 provider 时需手动安装对应 client pip install litellm # 如果要用 OpenAI额外装 pip install openai # 如果要用 Azure OpenAI额外装注意版本兼容性 pip install openai1.0.0 # 如果要用 Ollama额外装LiteLLM 内部用 requests 调用无需 ollama python lib # 但建议装一个用于本地测试 pip install ollama # 如果要用 Anthropic额外装 pip install anthropic注意LiteLLM 的设计原则是“按需加载”。你pip install litellm后不装openai也能跑modelollama/llama3因为 Ollama 走的是 HTTP 直连但若调用modelgpt-4时没装openai它会报ImportError: Please install openai package并提示你pip install openai。这种“懒加载”机制既减小了基础包体积又避免了无谓的依赖污染。3.2 最简调用三行代码验证多模型路由新建quick_start.pyimport litellm # 1. 设置 OpenAI key仅当调用 OpenAI 时需要 # litellm.api_key sk-... # 生产环境请用环境变量 # 2. 发送请求 —— 注意model 参数决定路由目标 response litellm.completion( modelgpt-3.5-turbo, # 切换这里即可换模型 messages[{role: user, content: 你好请用一句话介绍量子计算}] ) # 3. 统一提取结果无论后端是哪家字段都一样 print(模型回答, response.choices[0].message.content) print(总 token 数, response.usage.total_tokens)运行它python quick_start.py你会看到标准输出。现在只需把modelgpt-3.5-turbo改成modelollama/llama3前提是你的本地已运行ollama run llama3启动 Ollama 服务。LiteLLM 会自动识别ollama/前缀走内置的 Ollama 适配器发起POST http://localhost:11434/api/chat请求并把响应里的message.content映射到标准字段。整个过程你的业务代码messages[...]和response.choices[0].message.content一行都不用动。3.3 生产级配置环境变量驱动 多模型 fallback真实项目绝不会把 API Key 写死在代码里。LiteLLM 原生支持环境变量注入且优先级高于代码内赋值。这是生产部署的黄金配置# .env 文件用 python-dotenv 加载 OPENAI_API_KEYsk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx AZURE_API_KEYxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx AZURE_API_BASEhttps://your-resource.openai.azure.com AZURE_API_VERSION2024-02-01 OLLAMA_API_BASEhttp://localhost:11434Python 代码改为from dotenv import load_dotenv import litellm load_dotenv() # 自动加载 .env # 定义 fallback 链主用 gpt-4失败则降级到 claude-3-haiku再失败用本地 llama3 fallback_models [ gpt-4-turbo, claude-3-haiku-20240307, ollama/llama3 ] try: response litellm.completion( modelfallback_models, messages[{role: user, content: 解释下 Transformer 架构的核心思想}], timeout30, # 统一超时控制 num_retries2 # 每个模型最多重试2次 ) print(✅ 成功调用, response.model) print(回答, response.choices[0].message.content) except Exception as e: print(❌ 全部模型调用失败, str(e))这段代码的价值在于它把“模型可用性”从运维问题变成了代码可声明、可测试、可监控的逻辑。你不需要写三套重试逻辑LiteLLM 内置的fallback机制会按顺序尝试每个 model自动处理AuthenticationErrorkey 错、RateLimitError被限流、Timeout网络超时等常见异常并记录详细 trace。我在某次 Azure 服务临时抖动时亲眼看到日志里打印出INFO:litellm:Trying model: gpt-4-turbo - Error: litellm.RateLimitError:... INFO:litellm:Trying model: claude-3-haiku-20240307 - Success!故障自愈过程完全透明业务无感。3.4 高级技巧自定义模型映射与私有模型注册当你要接入一个 LiteLLM 尚未官方支持的新模型比如某家国产大模型的私有 API或者想给现有模型起个业务友好名如modelprod-chat代表生产环境主用模型可以用litellm.register_model()# 注册一个自定义模型映射到 Azure 的某个部署 litellm.register_model({ model_name: prod-chat, # 你在代码里用的名字 litellm_params: { model: azure/gpt-4o, # 实际调用的模型 api_base: https://my-prod-resource.openai.azure.com, api_version: 2024-06-01, api_key: os.getenv(PROD_AZURE_KEY) # 单独的密钥 } }) # 现在就可以用业务名调用了 response litellm.completion( modelprod-chat, # 干净 messages[{role: user, content: 总结会议纪要}] )更进一步如果你的私有模型 API 结构和主流 provider 差异很大比如 body 是 XML或需要特殊 headerLiteLLM 还提供custom_llm_provider机制允许你传入一个完全自定义的函数来处理请求/响应。不过绝大多数场景用register_modellitellm_params已足够灵活。4. 深度原理剖析参数映射、Token 计数与流式响应的底层实现LiteLLM 的“魔法”看似简单但要让它在 100 provider 间稳定工作背后是一套精密的参数对齐与错误容错体系。理解这些细节能帮你避开大量隐形坑。4.1 参数映射表为什么temperature在所有模型里都有效LiteLLM 的核心是维护一张巨大的“参数映射表”parameter mapping table。这张表不是硬编码在源码里而是以 provider 为维度用 Python dict 结构化定义。以 OpenAI 和 Anthropic 为例LiteLLM 标准参数OpenAI 字段名Anthropic 字段名Google Gemini 字段名备注temperaturetemperaturetemperaturegenerationConfig.temperature三家都叫 temperature直接透传top_ptop_ptop_pgenerationConfig.topP同上max_tokensmax_tokensmax_tokensgenerationConfig.maxOutputTokensGemini 需要嵌套stopstopstop_sequencesgenerationConfig.stopSequences字段名、类型数组/字符串均不同当你调用litellm.completion(modelanthropic/claude-3-haiku, temperature0.5, max_tokens512)时LiteLLM 内部会查model前缀定位到anthropicprovider读取anthropic的映射规则将temperature→temperaturemax_tokens→max_tokens构造 Anthropic 所需的 JSON body{model: claude-3-haiku-20240307, messages: [...], temperature: 0.5, max_tokens: 512}发起 HTTP POST。这个过程对开发者完全透明。但关键点在于LiteLLM 的映射表是“有损压缩”的。比如presence_penalty这个 OpenAI 特有参数在 Anthropic 里没有对应概念LiteLLM 会静默忽略它并记录 warning 日志而不是报错中断。这种“尽力而为”的设计保证了代码的健壮性——你写一个通用函数传presence_penalty0.2它在 GPT 模型下生效在 Claude 下被忽略但绝不崩溃。4.2 Token 计数如何做到跨模型的usage字段可信response.usage.total_tokens是评估成本和性能的关键指标。但各家 provider 的 token 计算方式天差地别OpenAI 使用tiktoken库按cl100k_base编码Anthropic 使用自己的anthropic-tokenizer算法略有不同Ollama 默认不返回 token 数需本地估算某些国产模型 API 根本不提供usage字段。LiteLLM 的解决方案是分层兜底优先信任 provider 原生返回如果响应里有usage字段如 OpenAI直接提取次选本地估算如果 provider 没返回如 OllamaLiteLLM 会调用tiktoken.encoding_for_model(gpt-3.5-turbo)对messages和response.content分别编码计数注意这里用gpt-3.5-turbo编码器是经验性选择因 cl100k_base 覆盖最广误差通常 5%最后保底填充如果连估算都失败极罕见usage字段会被设为{prompt_tokens: 0, completion_tokens: 0, total_tokens: 0}避免字段缺失导致业务代码报错。你可以通过litellm.token_counter()函数手动触发估算用于预估成本from litellm import token_counter messages [{role: user, content: 长文本...}] # 估算输入 token 数用 gpt-3.5-turbo 编码器 input_tokens token_counter(modelgpt-3.5-turbo, messagesmessages) print(f预计输入 token{input_tokens})4.3 流式响应Streaming如何统一处理千奇百怪的 chunk 格式流式返回是提升用户体验的核心。但各家的 stream chunk 结构五花八门OpenAIdata: {id:..., choices:[{delta:{content:世}}]}Anthropicevent: message_start\n data: {type:message_start,message:{id:...,content:[]}}event: content_block_delta\n data: {type:content_block_delta,delta:{text:界}}Google Gemini{candidates:[{content:{parts:[{text:你好}]}}]}非 event-streamLiteLLM 的流式 API (streamTrue) 统一返回一个generator每次 yield 一个标准LiteLLMStreamingObject其结构恒为{ choices: [{ delta: {role: assistant, content: 世界}, finish_reason: None # 或 stop, length, tool_calls }] }实现原理是LiteLLM 启动一个后台线程监听原始 HTTP stream按 provider 规则解析每一个 chunk然后实时组装成标准格式推送给 generator。这意味着你的前端 JavaScript 代码可以写死一套处理逻辑const response await fetch(/api/chat, { method: POST, body: JSON.stringify({ model: gpt-4, messages }) }); const reader response.body.getReader(); while (true) { const { done, value } await reader.read(); if (done) break; const chunk new TextDecoder().decode(value); // chunk 是标准 LiteLLM 流式 JSON直接 parse const parsed JSON.parse(chunk); appendToUI(parsed.choices[0].delta.content); // 统一处理 }无论后端是 GPT、Claude 还是本地 Llama3前端代码完全不用改。这种“协议一致性”是 LiteLLM 最被低估的价值之一。5. 实战避坑指南那些文档里不会写的血泪教训LiteLLM 上手极快但真正在复杂项目里长期稳定运行有几个深坑必须提前知道。这些都是我在三个不同规模项目中踩过、记录、验证过的经验。5.1 坑一Azure OpenAI 的api_version必须精确匹配否则 404 静默失败Azure OpenAI 的api_version是 URL 路径的一部分例如https://xxx.openai.azure.com/openai/deployments/gpt-4o/chat/completions?api-version2024-02-01。LiteLLM 会严格按你传入的api_version拼接 URL。但问题在于Azure 控制台里显示的“最新版”和实际可用的api_version并不总是一致。我曾遇到过控制台显示“2024-05-01-preview”但实际调用返回 404降级到2024-02-01才成功。正确姿势永远从 Azure OpenAI 的官方文档不是控制台查最新稳定版在代码里显式指定api_version不要依赖环境变量模糊匹配开启litellm.set_verbose(True)第一时间看到请求 URL确认api-version参数是否拼对。5.2 坑二Ollama 模型名大小写敏感且必须已pull到本地Ollama 的模型名是username/model:tag格式如library/llama3:latest。LiteLLM 会原样传递给http://localhost:11434/api/chat。但如果你本地没ollama pull library/llama3Ollama 服务会返回 404而 LiteLLM 默认会把这个 404 当作ModelNotFoundError并尝试 fallback 到下一个模型——这可能导致你误以为“主模型不可用”其实是本地根本没拉镜像。排查技巧先用curl http://localhost:11434/api/tags查看本地已加载模型列表确保modelollama/llama3中的llama3和api/tags返回的name字段完全一致包括大小写在litellm.completion()调用前加一行litellm.validate_environment(modelollama/llama3)它会主动检查连接和模型可用性。5.3 坑三fallback机制的“重试”不是万能的小心雪崩fallback_models[gpt-4, claude-3-haiku]听起来很美但要注意LiteLLM 的 fallback 是串行、阻塞式的。如果gpt-4因网络问题卡住 30 秒它会等满 30 秒再试claude-3-haiku。在高并发场景下这会导致线程池被占满引发级联超时。安全方案为每个模型设置独立timeout且逐级递减litellm.completion( model[gpt-4-turbo, claude-3-haiku], timeout[15, 8], # gpt-4 最多等15秒claude 最多等8秒 num_retries1 )更激进的做法用asyncioasync_litellmLiteLLM 提供的异步版本并行发起请求谁先返回用谁。但这需要重构调用逻辑适合对延迟极度敏感的场景。5.4 坑四litellm.completion()不是线程安全的多线程下api_key会混乱这是最隐蔽的坑。LiteLLM 的全局litellm.api_key是一个模块级变量。如果你在多线程环境如 Flask/Gunicorn 多 worker里用litellm.api_key key1设置了 key然后另一个线程执行litellm.api_key key2两个线程会互相覆盖结果就是本该用 key1 调用 GPT 的请求可能被错误地用 key2 发出去导致 401。唯一可靠解法永远用api_key参数传入而不是设全局变量。# ❌ 危险多线程下会冲突 litellm.api_key os.getenv(OPENAI_KEY) response litellm.completion(modelgpt-4, messages[...]) # ✅ 安全每个请求携带自己的 key response litellm.completion( modelgpt-4, messages[...], api_keyos.getenv(OPENAI_KEY) # 显式传入 )LiteLLM 文档里其实提到了这点但藏在 FAQ 末尾很多开发者第一次部署就栽在这里。5.5 坑五set_verbose(True)是调试神器但生产环境必须关掉开启 verbose 后LiteLLM 会在stdout打印每一条 HTTP 请求/响应的完整 body包括 headers 和 raw JSON。这在开发时 invaluable但生产环境绝对禁止日志体积爆炸一个 2000 token 的响应body 就有 10KB敏感信息泄露API Key 可能出现在 headers 里虽然 LiteLLM 会打码但仍有风险I/O 阻塞大量日志写入会拖慢主线程。最佳实践开发/测试环境litellm.set_verbose(True)CI/CD 测试用pytestcaplog捕获日志做断言生产环境litellm.set_verbose(False)改用结构化日志如structlog记录关键事件model_used,latency_ms,status_code。6. 进阶应用场景超越“多模型路由”的工程价值LiteLLM 的定位常被简化为“多模型路由”但真正用熟的团队早已把它当作基础设施的“神经中枢”。以下是几个超出基础用法的实战案例。6.1 场景一统一成本监控与预算告警每个模型的 token 成本差异巨大GPT-4 Turbo 约 $10/百万 input tokensClaude-3 Haiku 只要 $0.25/百万而本地 Ollama 是零成本只算电费。LiteLLM 的response.usage字段配合model名称可以构建精准的成本仪表盘。我们团队的做法在litellm.completion()调用外层加一个装饰器def track_cost(func): def wrapper(*args, **kwargs): start_time time.time() response func(*args, **kwargs) cost_usd calculate_cost( modelresponse.model, prompt_tokensresponse.usage.prompt_tokens, completion_tokensresponse.usage.completion_tokens ) log_to_prometheus(llm_cost_usd_total, cost_usd) log_to_elk(llm_call, { model: response.model, prompt_tokens: response.usage.prompt_tokens, completion_tokens: response.usage.completion_tokens, latency_ms: (time.time() - start_time) * 1000, cost_usd: cost_usd }) return response return wrappercalculate_cost()是一个简单的字典映射表维护各模型单价结合 Prometheus Grafana实时看板显示“今日 GPT-4 消耗 $23.5占总成本 68%Claude 占 22%Ollama 占 10%”。这套系统上线后我们发现一个隐藏问题客服场景中用户常发大段截图 OCR 文本5000 tokensGPT-4 的prompt_tokens成本飙升。于是立即推动产品优化前端加字符数限制 自动摘要预处理。没有 LiteLLM 的统一usage这种精细化成本治理根本无从谈起。6.2 场景二A/B 测试框架的底层支撑想验证“用 GPT-4 还是 Claude-3 做代码解释用户满意度更高”——传统做法是写两套接口前端随机分流后端分别调用。LiteLLM 让这事变得像开关一样简单# 配置中心动态获取实验策略 exp_strategy get_experiment_config(code_explanation_model) if exp_strategy gpt4: model gpt-4-turbo elif exp_strategy claude: model claude-3-haiku-20240307 else: model ollama/codellama response litellm.completion( modelmodel, messages[...], metadata{experiment_id: code_exp_v1} # 透传元数据用于日志分析 )关键是metadata参数LiteLLM 会把它原样塞进response._hidden_params一个私有字段你可以在日志里提取关联用户 ID、session ID、实验分组用 SQL 做漏斗分析。我们两周内就跑完一轮实验结论清晰Claude 在代码解释的准确率上高 12%但 GPT-4 的响应速度平均快 1.8 秒。最终选择了折中方案用 Claude 做首次解释GPT-4 做补充润色——这个决策完全建立在 LiteLLM 提供的标准化、可计量的实验能力之上。6.3 场景三离线环境下的“模型沙箱”某客户要求所有数据不出内网但又要体验多模型效果。我们用 LiteLLM Ollama LM Studio 搭建了一个“模型沙箱”在离线服务器上用ollama run qwen2:7b、ollama run phi3:mini等命令拉取多个轻量模型用litellm --host 0.0.0.0 --port 4000启动 LiteLLM 的 proxy 模式注意这是 LiteLLM 的可选模式非核心库功能前端 Web App 通过http://sandbox-server:4000/v1/chat/completions调用model参数传ollama/qwen2:7b或ollama/phi3:mini所有流量不经过公网模型全部本地运行。这个沙箱成了客户技术团队的“游乐场”他们可以自由对比不同模型在自家