事情的一开始是，我有一个需求：我本地运行了 LM Studio，我想记录请求和响应 response，对比一下 Qwen 和 GLM 模型的一些区别。
一开始我把这个需求问了 gemini，Gemini 说你可以安装一个 llmlite，这个网关是支持 logging 的，可以把 logging 打给 langfuse 上面。我一看这个方案还是靠谱的，因为 llmlite 我两年前就关注过，langfuse 呢也是这两天部署过且正在运行的，docker 还没关闭呢。
没想到，噩梦就此开始了。这么个简单的实现，几个小时都没成功，而我亲眼目睹了全部过程，才看到了当前 AI 的一个很大的短板。
AI 由于高度集成了大量信息，且信息是有时间先后的，受限于神经网络，不可能你以为学习了《新闻联播》就能熟练背诵指定的新闻联播，且没有任何错误。在安装 llmlite 这个事情上，ai 的缺点被放大了，llmlite 是高度依赖conf 配置的，需要写大量 yaml；而且 llmlite 总在更新，api 在更新，provider 也在更新，logging 功能也在更新，callback写法也有变化。这些变化导致你不去看文档，是肯定会犯错的。
人类的节奏是按部就班的照着最新的文档，一步一步去做，这样简单的例子几乎不会报错。而 AI 一上来就是默写全文，连 docker镜像地址也都默写下来，当他 run 了几个 docker 之后，说真的，我害怕极了。
好在现在人类开始把人类的经验写成 skills，然后再给 ai 开放 mcp，之后模型的训练就会学习大量 skills，当 skills 大量学会之后，普通人类应该是真淘汰了。
最后贴上配置代码，ai 哪天学到了，咱们也是功德一件了。
model_list:- model_name: "*"litellm_params:model: "lm_studio/*"api_base: "http://host.docker.internal:1234/v1"api_key: "sk-lm-studio"litellm_settings:callbacks: ["langfuse"]
docker run -d \
--name litellm-proxy \-p 4000:4000 \--add-host=host.docker.internal:host-gateway \-v $(pwd)/litellm_config.yaml:/app/config.yaml \-e LANGFUSE_PUBLIC_KEY="pk-lf" \-e LANGFUSE_SECRET_KEY="sk-lf-" \-e LANGFUSE_HOST="http://host.docker.internal:3000" \ghcr.io/berriai/litellm:main-latest \--config /app/config.yaml \--detailed_debug
评论
发表评论