1. 嵌入式 Linux 上的 LiteLLM 先跑通再谈加一路远程模型在嵌入式 Linux 上按原文流程装好 LiteLLM再用 Ollama 托管 codegemma:2b你会得到一套完全离线的本地推理环境。这对延迟和数据隐私都很友好但瓶颈也很明显2B 参数的模型在写代码、做复杂指令跟随时会经常“答非所问”。想在不推翻现有架构的前提下补一个能力更强的模型你可以在 LiteLLM 的 config.yaml 里多加一条模型记录让它指向 https://taotoken.net/api ——TaoToken 会把请求转发到对应的模型。做法很简单先去 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 注册并创建 API Key然后在原来的配置里追加一段 litellm_paramsLiteLLM 就会同时暴露本地 Ollama 模型和经 TaoToken 统一接入的模型测试脚本里的 base_url 都不用改照样是 http://localhost:4000。1.1 原文方案做了什么原文的思路是在资源受限的嵌入式设备上用 LiteLLM 作为代理层用 Ollama 在本地托管轻量模型两者通过 config.yaml 绑定关系。具体来说你会在嵌入式 Linux 上完成这几件事安装 Python 3.7、pip、venv然后创建一个虚拟环境用pip install litellm[proxy]安装 LiteLLM 的代理组件安装 Ollama并拉取codegemma:2b这类小型模型编写~/litellm_config/config.yaml把codegemma映射到ollama/codegemma:2b用litellm --config ~/litellm_config/config.yaml启动代理用 OpenAI SDK 请求http://localhost:4000完成验证。这套链路非常适合嵌入式场景因为本地模型不依赖公网哪怕断网也能继续工作。但本地模型的能力上限就摆在那里一旦遇到需要更强推理的任务你还是得有一条通往云端大模型的备用通道。1.2 为什么偏偏是 TaoToken很多开发者会想既然 LiteLLM 本身支持各类模型那我直接在 config.yaml 里写 OpenAI 的 api_base 不就行了能行但你需要处理各家模型供应商的独立 Key、独立模型命名、独立计费规则。TaoToken 把这些统一成了一个入口你只需要一把 Key、一个 Base URL就能按需选择不同模型。对嵌入式 Linux 来说好处更明显——你不用在设备上保存一堆供应商密钥也不用因为某个模型调整接口格式而反复改配置。而且接入 TaoToken 并不会冲击原有的本地模型。你不需要删掉 Ollama也不需要让 LiteLLM 只走远程通道。两套模型可以共存本地 codegemma 继续处理离线请求远程模型通过 TaoToken 补齐能力路由由 LiteLLM 统一管理。2. 把原文基础环境准备好同时拿到 TaoToken 的 Key在动 config.yaml 之前先确认嵌入式设备上已经具备原文所要求的运行环境。这一步不要跳过因为 LiteLLM 和 Ollama 对 Python 版本、系统依赖都有最低要求。2.1 安装 LiteLLM 和依赖假设你的设备是 Debian 系嵌入式 Linux先更新软件源再安装 Python 3-pip 和 venvsudo apt-get update sudo apt-get install python3-pip python3-venv -y检查 pip 和 venv 是否可用pip --version dpkg -s python3-venv | grep Status: install ok installed如果 venv 未安装执行sudo apt install python3-venv -y。然后创建并激活虚拟环境python3 -m venv litellm_env source litellm_env/bin/activate在虚拟环境里安装 LiteLLM 的代理组件pip install litellm[proxy]此时litellm命令已经可用。后续所有操作包括启动代理都要在litellm_env这个虚拟环境下进行。2.2 用 Ollama 托管 codegemma:2bOllama 专门用于在本地托管大语言模型安装脚本会帮你把服务跑起来curl -fsSL https://ollama.com/install.sh | sh然后拉取原文用到的轻量模型ollama pull codegemma:2b拉取完成后Ollama 默认在http://localhost:11434上监听。这个地址就是之后 config.yaml 里本地模型 api_base 的值。2.3 从 TaoToken 创建 Key 并记录模型别名现在去 TaoToken 注册并登录。在控制台左侧找到 API Keys 页面创建一个新的 Key创建后立刻复制保存因为页面不会第二次明文显示。这个 Key 就是后面配置文件里的YOUR_API_KEY。同时去模型广场看一下你需要使用的模型别名。TaoToken 的模型 ID 以其后台显示为准不同时间列表可能不同不要凭记忆填一个名字。LiteLLM 在转发 OpenAI 兼容请求时模型名要写成openai/模型ID的形式其中“模型ID”就是 TaoToken 后台给出的别名。如果你打算用 TaoToken 的对话模型就先在模型广场搜到对应 ID复制到本地记事本下一步直接粘贴到 config.yaml。3. 在 config.yaml 里加一条走 TaoToken 的模型记录原文的配置文件很简单只包含本地模型。我们要做的是保留这一段再追加一个新的 model_list 条目。3.1 原文的 config.yaml 结构进入配置目录并创建文件mkdir -p ~/litellm_config nano ~/litellm_config/config.yaml原文配置的核心内容是model_list: - model_name: codegemma litellm_params: model: ollama/codegemma:2b api_base: http://localhost:11434这段配置表示对外提供codegemma这个模型名LiteLLM 收到请求后把它转发到 Ollama 的codegemma:2b。3.2 追加 TaoToken 的 litellm_params在同一个 model_list 下面再增加一个模型条目。注意 YAML 缩进必须保持一致每个列表项用- model_name开头。下面是完整的 config.yaml 示例model_list: - model_name: codegemma litellm_params: model: ollama/codegemma:2b api_base: http://localhost:11434 - model_name: taotoken-model litellm_params: model: openai/YOUR_MODEL_ID_FROM_TAOTOKEN api_base: https://taotoken.net/api api_key: YOUR_API_KEY这里有几个关键点model_name: taotoken-model是 LiteLLM 对外暴露的名字你的测试脚本里modeltaotoken-model即可不用填复杂 IDlitellm_params.model里的openai/前缀告诉 LiteLLM这是一个 OpenAI 兼容接口后面的YOUR_MODEL_ID_FROM_TAOTOKEN必须替换成 TaoToken 模型广场给出的模型 IDapi_base是https://taotoken.net/api末尾不要加/v1api_key填你在 TaoToken 控制台创建的那把 Key也就是YOUR_API_KEY。保存文件后可以用 Python 快速验证 YAML 是否合法python3 -c import yaml; print(yaml.safe_load(open(/home/user/litellm_config/config.yaml)))如果打印出 Python 字典结构说明格式正确。注意把路径换成你自己的实际路径。3.3 为什么这样加不影响原方案LiteLLM 的 model_list 天然支持多个模型并行。新增的 TaoToken 条目和 Ollama 条目互不干扰LiteLLM 代理启动后会自动同时注册这两条路由。你不需要修改任何代码也不需要重启 Ollama。本地模型仍走http://localhost:11434远程模型走https://taotoken.net/api两者都对外表现为http://localhost:4000上的一个模型名。对于调用方来说只是多了一个可选的模型 ID。4. 启动代理用原测试脚本分别请求两条模型通道配置改好之后启动方式与原文完全一致。验证阶段也沿用原来的 OpenAI SDK 脚本只是把需要测试的模型名放进循环里。4.1 启动 LiteLLM 代理确保虚拟环境已激活然后运行litellm --config ~/litellm_config/config.yaml启动日志里会出现监听地址http://0.0.0.0:4000以及注册的模型路由。看到类似/chat/completions的路由信息就说明代理已经就绪。如果你的设备有防火墙需要放行 4000 端口否则同一局域网内的其他设备无法访问。4.2 用原来的测试脚本请求两个模型原文测试脚本的核心是base_urlhttp://localhost:4000这个地址保持不变。下面这段脚本会依次请求本地模型和经 TaoToken 接入的远程模型import openai client openai.OpenAI( api_keyanything, base_urlhttp://localhost:4000 ) models_to_test [codegemma, taotoken-model] for model in models_to_test: try: resp client.chat.completions.create( modelmodel, messages[ {role: user, content: 用一句话解释什么是嵌入式系统} ] ) print(model, 回复, resp.choices[0].message.content) except Exception as e: print(model, 请求失败, e)运行脚本python3 ./test_script.py预期结果是codegemma返回本地 Ollama 生成的内容taotoken-model返回经 TaoToken 转发的远程模型内容。两条通道共用同一个端口和同一套 OpenAI SDK只是model字段不同。4.3 确认请求确实经过了 TaoToken如果你在 TaoToken 控制台能看到对应模型的调用记录就能确定流量确实走到了 TaoToken而不是被本地代理直接忽略。这一点很重要因为有些嵌入式设备会配置代理环境变量导致 LiteLLM 把请求发到了别的地址。验证时可以把本地 Ollama 停掉再单独请求taotoken-model如果仍然能返回结果说明远程通道独立工作不依赖本地模型。5. 嵌入式环境下接入 TaoToken 的典型报错对照第一次混跑最常遇到的问题集中在 Key、模型 ID、Base URL 三件事上。下面按报错现象给出排查方向。5.1 401 认证失败Key 没复制对或权限不足请求taotoken-model时如果返回 401先检查 config.yaml 里的api_key是否完整。TaoToken 的 Key 通常在创建时只显示一次粘贴时不要带上空格。还要确认这把 Key 的状态是启用并且没有在别的服务里误删。5.2 model not found 或 404模型 ID 与后台不一致LiteLLM 在转发时会把openai/你填的ID传给 TaoToken如果模型广场里根本没有这个名字就会返回 404。解决方法是回到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 模型广场搜索你要用的模型复制它的准确 ID再替换掉 config.yaml 里的YOUR_MODEL_ID_FROM_TAOTOKEN。注意大小写和连字符比如某些模型名是claude-3-5-haiku少一个字母都不行。5.3 api_base 末尾多了 /v1 或写成了 httpLiteLLM 对 OpenAI 兼容接入比较宽容但https://taotoken.net/api不要改成https://taotoken.net/api/v1。有些官方库默认会在 Base URL 后拼/v1而 TaoToken 的 Base URL 已经包含完整路径。如果你在配置里加了/v1反而会出现路径重复。另外嵌入式设备上如果用了代理环境变量注意确认https://taotoken.net/api没有走内网代理而超时。5.4 本地 Ollama 和 LiteLLM 同时跑导致内存不足嵌入式设备内存本来就紧张Ollama 加载 2B 模型后再跑 LiteLLM 代理剩余内存可能不够。TaoToken 远程通道本身几乎不占用内存因为计算发生在远端。如果设备卡死可以考虑给 Ollama 设置环境变量OLLAMA_MAX_LOADED_MODELS1或者临时停掉 Ollama只保留 TaoToken 通道测试。等确认稳定后再按需启动本地模型。6. 把原文的性能优化设置同时作用于两种模型原文在“优化性能”部分提到了限制 max_tokens 和管理并发请求。这两招在混跑模式下依然有效而且可以统一应用。6.1 max_tokens 同时约束本地和远程在请求远程模型时如果没有限制 max_tokens大模型可能会生成长文占用不必要的等待时间和 Token 额度。嵌入式设备上建议显式设置resp client.chat.completions.create( modeltaotoken-model, messages[{role: user, content: 写一个快速排序}], max_tokens500 )这样本地模型和远程模型都会遵守相同的输出长度限制LiteLLM 不会额外处理这个参数而是直接透传给后端。6.2 并发请求数按原文方式调整原文用了类似下面的命令启动代理litellm --config ~/litellm_config/config.yaml --num_requests 5这个限制对 model_list 里的所有模型都生效。如果你同时有多个嵌入式设备在请求可以把并发数调低避免瞬时大量请求打爆 TaoToken 或本地 Ollama。TaoToken 那边也有自己的限流策略以实际返回的 429 为准此时你的 LiteLLM 日志会记录响应状态方便你调整num_requests。6.3 两条通道的取舍策略实际使用时不一定每次都同时跑两个模型。你可以在应用层做简单路由对延迟敏感、可离线的任务走codegemma对推理要求高、允许联网的任务走taotoken-model。这样既保留原文的离线能力又能借助 TaoToken 扩展模型上限。LiteLLM 本身也支持设置默认模型但保持显式指定更清晰也不容易把请求发错地方。7. 跑通之后去 TaoToken 控制台对一下这次调用当taotoken-model能正常回复后建议先打开 TaoToken 模型对话用同一把 Key 手动发一条消息。这个页面的作用是把“Key 是否有效”和“模型 ID 是否准确”这两件事拆开验证如果页面里选择同样模型能对话说明问题一定出在 LiteLLM 配置而不是 Key 或模型。确认没问题后回到 控制台 API Keys 查看这把 Key 的当前状态同时注意调用记录里的模型名、Token 数和响应时间。如果你打算长期通过 LiteLLM 调用远程模型可以看看 Coding Plan 是否比按量计费更划算。至于模型别名是否改过版最后再到 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 的模型广场核对一次确保 config.yaml 里的 ID 不是被废弃的历史名称。整个接入过程不改变原文的 LiteLLM 部署方式也不影响本地 Ollama 模型。你只是在 model_list 里多放了一条记录让嵌入式设备同时具备本地轻量推理和远程高质量推理两种能力。以后想换更强的模型不需要重装任何组件改模型 ID 后重启 LiteLLM 即可。这份配置文件和原测试脚本也能在重启后继续复用省去反复改代码的功夫。