1. LiteLLM 示例跑不起来401 通常卡在 api_base 这一个参数上很多开发者是照着类似这样的代码起步的from langchain_community.chat_models import ChatLiteLLM from langchain_core.messages import HumanMessage from langchain_core.callbacks import CallbackManager, StreamingStdOutCallbackHandler chat ChatLiteLLM( modelgpt-3.5-turbo, streamingTrue, verboseTrue, callback_managerCallbackManager([StreamingStdOutCallbackHandler()]) ) messages [HumanMessage(contentTranslate this sentence from English to French. I love programming.)] response chat(messages) print(response.content)这段代码本身没什么大问题但它默认去读取的环境变量或默认走的 Base URL未必是你手头那把 API Key 真正对应的地址。于是本地一跑经常看到这样的报错LiteLLMException: AuthenticationResponseError: status_code: 401, body: {error: {message: Unauthorized, type: authentication_error, code: invalid_api_key}}第一次遇到 401 的人第一反应往往是「我的 Key 是不是复制错了」。但多数时候 Key 没错真正错的是两个位置一是 LiteLLM 该从哪里读 Key二是该把请求发到哪个 Base URL。这两点只要有一个对不上LiteLLM 就会拿着一个无效地址去换 token结果自然是 401 Unauthorized。TaoToken 是一款统一接入多种模型服务的 API 通道它把各家模型的接口差异收敛成一个兼容 OpenAI 格式的入口。使用 TaoToken 时官网首页和 API 接口地址是两回事官网落地页 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 用来注册、创建 Key、查看模型广场和用量真正填进 LiteLLM 的 Base URL 是 https://taotoken.net/api末尾不要加 /v1也不要加任何 UTM 参数。把这两件事分开401 就解决了一大半。2. 401 的本质Key 没到该到的地方LiteLLM 读取 Key 的方式有三种很多教程只提其中一种容易让人忽略另外两种。默认情况下ChatLiteLLM 会去读环境变量OPENAI_API_KEY当 model 以gpt-开头时或ANTHROPIC_API_KEY当 model 以claude-开头时。如果这两个变量没设置它可能直接传一个空字符串出去服务端校验不过立刻返回 401。另一种常见情况是设置了环境变量但变量名对不上。例如你把 Key 放在LITELLM_KEY或OPENAI_API_BASE里而 ChatLiteLLM 读取的却是OPENAI_API_KEY两者不一致请求照样以未认证身份发出。这时候需要明确告诉 LiteLLM我的 Key 是这一把请从api_key参数里取不要自己去猜环境变量。chat ChatLiteLLM( modelgpt-3.5-turbo, api_keyYOUR_API_KEY, # 从 TaoToken 控制台创建 api_basehttps://taotoken.net/api, # 注意末尾没有 /v1 streamingTrue, verboseTrue, callback_managerCallbackManager([StreamingStdOutCallbackHandler()]) )API Key 占位符YOUR_API_KEY需要替换成你在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建的真实 Key。创建时不要勾选「官网落地页」当成接口地址也不要把 Key 填到浏览器地址栏里它只会出现在代码、环境变量或配置文件中。3. 把 Base URL 写对不要填官网首页LiteLLM 的核心原理是统一封装不同厂商的 API 协议。当你指定api_base之后LiteLLM 实际上是在这个地址的基础上去拼路径例如补上/chat/completions或/models。如果你把api_base填成https://taotoken.net或https://taotoken.net/LiteLLM 会请求到https://taotoken.net/chat/completions而 TaoToken 的 API 服务挂在https://taotoken.net/api下于是请求落到了不存在的路径上最常见的结果就是 401 或 404。正确写法是api_basehttps://taotoken.net/api对比一下使用位置地址官网注册、创建 Key、查看用量https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endLiteLLM 的api_basehttps://taotoken.net/api环境变量OPENAI_API_BASEhttps://taotoken.net/api「官网落地页」和「API 接口地址」在 TaoToken 的产品设计里本来就是两个东西。落地页带 UTM 参数方便追踪来源而接口地址是纯文本的 URL不能带任何 UTM 参数。把两者混用是除 Key 没填对之外最常见的 401 诱因。3.1 环境变量方式如果不想在代码里硬编码 Key可以用环境变量方式。在项目根目录新建.env文件OPENAI_API_BASEhttps://taotoken.net/api OPENAI_API_KEYYOUR_API_KEY然后用 python-dotenv 加载from dotenv import load_dotenv load_dotenv() from langchain_community.chat_models import ChatLiteLLM from langchain_core.messages import HumanMessage from langchain_core.callbacks import CallbackManager, StreamingStdOutCallbackHandler chat ChatLiteLLM( modelgpt-4o-mini, # 以 TaoToken 模型广场实际列表为准 streamingTrue, verboseTrue, callback_managerCallbackManager([StreamingStdOutCallbackHandler()]) ) messages [HumanMessage(contentTranslate this sentence from English to French. I love programming.)] response chat(messages) print(response.content)注意.env文件里的变量名不要写错。LiteLLM 在读取模型名以gpt-开头的 provider 时主要认OPENAI_API_KEY和OPENAI_API_BASE。如果你在代码里同时传了api_key和api_base参数则以参数为准环境变量只作为兜底。3.2 同步调用和异步调用验证配置改完之后重跑原文的response chat(messages)可以看到正常返回。同步验证通过后再用异步方法确认流式输出日志import asyncio async def async_translate(): response await chat.agenerate([messages]) print(response.generations[0][0].message.content) asyncio.run(async_translate())流式回调打印在verboseTrue时会自动输出到控制台。若此处仍报 401先检查YOUR_API_KEY是否被误替换成含换行符的文本很多 Key 复制时末尾多一个空格LiteLLM 不会帮你 trim服务端校验直接失败。4. Langchain 消息结构不用改还是 HumanMessage 那一套TaoToken 的接口兼容 OpenAI 格式所以 Langchain 侧的ChatLiteLLM完全按原来的方式使用。HumanMessage的内容会被序列化成 messages 数组TaoToken 再转发给后端对应的模型服务。对于上层应用来说感知不到模型切换的差异。这一点在实际项目里很有价值。比如客服系统需要中英互译你只需要在配置层切换模型 ID不需要动业务代码。原文中的messages [HumanMessage(content...)]保持不变唯一需要确认的是model名称是否在 TaoToken 模型广场上真实存在。以模型广场为准不要轻信网上的旧教程里写死的某个模型 ID。你可以打开 TaoToken 模型广场看看当前上架的模型 ID 列表再填。另外Langchain 的消息类型还包括SystemMessage、AIMessage。对于翻译类任务SystemMessage 可以指定角色from langchain_core.messages import SystemMessage, HumanMessage messages [ SystemMessage(contentYou are a professional translator between English and French.), HumanMessage(contentI love programming.) ]这样改动并不违反原文的主路径反而更贴合 Langchain 的消息管理设计。如果模型 ID 写错LiteLLM 通常会返回 404 或 400这时去模型广场核对 ID 即可。5. 排障顺序从 401 到 200 的检查清单如果重跑之后仍然报错按下面顺序逐项排查不要从头开始改代码。第一确认 Key 是在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end 创建的并且没有复制多余字符。可以在代码里临时打印api_key[:5]和api_key[-5:]看看是否有空格或换行。第二确认api_base是https://taotoken.net/api不是https://taotoken.net也不是https://taotoken.net/api/v1。LiteLLM 自己会拼接路径你不需要手动加/v1。第三确认模型 ID 是模型广场上当时存在的。网上的示例代码里写的模型 ID 可能已经下架或替换以 TaoToken 模型广场为准。第四确认没有把 UTM 链接填进环境变量。UTM 参数只用于官网追踪不能出现在OPENAI_API_BASE或api_base里。第五确认网络环境能正常访问 TaoToken 的 API 域名。如果你所在的网络对境外接口有限制尽量不要把这种限制归类到代码问题里先在线下或本地网络环境验证一次。用一个 curl 做快速连通性检查也很有用curl https://taotoken.net/api/models \ -H Authorization: Bearer YOUR_API_KEY如果这个请求返回 200 和模型列表说明 Key 和网络都没问题问题必然出在 LiteLLM 配置上。如果返回 401说明 Key 本身无效或已过期回到控制台重新创建一把。配置全部改完后去看 TaoToken 控制台用量 里是否多出一条本次调用的记录这是验证接口连通最直观的方式。需要长期跑翻译、生成类任务的话可以顺便看看 Coding Plan 的用量是否足够在 API Keys 页面可以随时新建或撤销 Key。LiteLLM 与 Langchain 的完整接入参数也可以对照 TaoToken 接入文档 再核对一遍文档里对环境变量和 Base URL 的写法有更细的说明。总的来说这次踩坑的路径很清楚先确认 Key 从哪儿来再确认 Base URL 填哪儿最后用 curl 定位是网络问题还是代码问题。TaoToken 的兼容通道设计得比较直接按「官网注册拿 Key、接口地址填 api」这套规则走Lanchain 原本的消息结构一行都不用改。