oss-llmops-stack

图1：开源 LLMOps 技术栈架构概览

背景：一个 AI 应用团队的真实困境

2024 年下半年，某团队在三个月内从 OpenAI 切换到 Claude，又因为成本问题引入了 AWS Bedrock Nova。代价是：代码里散布着十几种不同的 API 调用方式、Prompt 散落在各个服务中无法统一管理、没人知道每个月在 LLM 上到底花了多少钱。这就是当前 AI 应用团队最真实的痛——LLM 选型频繁变动、缺乏统一基础设施。

langfuse/oss-llmops-stack 正是为解决这一问题而生。它由 Langfuse 团队（YC W24 孵化项目）牵头维护，将 LiteLLM Proxy 和 Langfuse 两大成熟工具深度整合，打造了一套开源、生产级、可私有部署的 LLMOps 技术栈。MIT 许可证，完全透明，代码可控。

+

核心组件：双引擎协同

LiteLLM Proxy：LLM 的「万能转接头」

LiteLLM Proxy 是整个栈的流量入口。它接受标准 OpenAI 格式的请求，底层实际可以路由到 OpenAI、Anthropic Claude、AWS Bedrock/Vercel/Google Vertex 等 100+ 种 LLM 提供商。

这意味着：业务代码只需要写一套 openai.chat.completions.create() 调用，切换模型只需改一行配置。对于需要同时使用多个模型的团队（比如主调用 GPT-4 做推理、用 Claude 做翻译、Bedrock Nova 做批量任务），这是真正的工程效率提升。

LiteLLM Proxy 的核心能力包括：

• 智能路由：按模型、用户或 token 用量自动选择最优提供商
• 限流保护：防止突发流量压垮单一 API 提供商
• PII 脱敏：自动识别和遮蔽敏感信息，避免日志泄漏
• 响应缓存：相同 Prompt 命中缓存，减少 API 费用
• 成本追踪：内置按请求/token 计费逻辑

Langfuse：LLM 的「仪表盘 + 质检员」

Langfuse 是可观测性层，负责记录每次 LLM 调用的完整上下文——输入 Prompt、模型选择、响应内容、延迟、Token 消耗——并以可视化的方式呈现。它不是简单的日志工具，而是具备以下深度能力：

• 分布式追踪（Tracing）：每个 LLM 调用链路可追溯到具体的用户会话和业务事件
• 提示词版本管理（Prompt Management）：同一个 Prompt 的多个版本共存，支持一键回滚到任意历史版本，发布前可在 Playground 在线测试效果
• 评估基准（Evaluations）：内置评测框架，可对 LLM 输出质量打标签、设阈值，持续监控质量趋势
• Playground：在线调试界面，无需写代码即可尝试不同 Prompt 和模型组合
• 成本分析：按用户、项目、模型维度统计 LLM 花费，发现异常用量

集成原理：LiteLLM + Langfuse 的深度联动

LiteLLM 和 Langfuse 之间的集成是这套栈最有技术含量的部分。LiteLLM 内置了 Langfuse 作为 success_callback：

litellm_settings:
  success_callback: ["langfuse"]

这意味着：LiteLLM 每处理一个 LLM 请求，自动将追踪数据异步推送到 Langfuse，无需在业务代码中手动埋点。开发者只需引入 Langfuse 的 SDK（Python、JS/TS、Langchain 等），在应用层开启异步追踪回调，两者即可无缝协作。

图2：LiteLLM Proxy 与 Langfuse 的追踪回调集成

一键部署：docker-compose 拆解

这套栈的 docker-compose.yml 定义了 6 个核心服务：

部署只需三步：

git clone https://github.com/langfuse/oss-llmops-stack
cd oss-llmops-stack/docker-compose
docker compose up

约 10 分钟后，Langfuse Web UI 在 http://localhost:3000 可访问，LiteLLM Proxy 在 http://localhost:4000 提供统一 API。硬件需求仅 4GB RAM、10GB 磁盘，无需 GPU——因为调用的是远程 LLM API，本地只做路由和追踪。

适用场景与局限

适合的场景：

• 需要同时使用多个 LLM 提供商，不想维护多套 SDK 的团队
• 对数据隐私有严格要求、不能使用云端 Langfuse 的企业（金融、医疗、政府）
• 希望建立 LLMOps 规范，追踪 Prompt 迭代和模型质量趋势的中型 AI 产品团队

需要注意的局限：

• 成本双付：调用 LLM 的费用由用户自己承担（按各提供商定价），基础设施本身也需要自托管的服务器成本
• 调试门槛：LiteLLM 配置（YAML 模型路由）需要一定学习成本，不适合完全零基础的开发者
• 规模化运维：6 个服务意味着运维复杂度，对小团队来说比单服务方案更重
• Langfuse Cloud vs 自托管：Langfuse 商业云版功能更丰富，自托管版本缺少某些高级特性（如团队协作、SAML SSO）

行业意义：对抗 LLM 供应商锁定

2024 年 LLM 市场竞争异常激烈，GPT-4o、Claude 3.5 Sonnet、Gemini 2.0、Bedrock Nova 你方唱罢我登场。供应商锁定（Vendor Lock-in）成为每个 AI 团队的核心焦虑。

oss-llmops-stack 的价值在于：它用一层标准化的抽象（OpenAI API 格式），让团队可以随时以最小代价切换底层模型。加上 Langfuse 的 Prompt 版本管理，Prompt 本身也变成了可移植的资产，不再绑定于某一个模型。

从数据看，Langfuse 本身在 GitHub 上已有 18k+ stars，LiteLLM 超过 25k stars，这两个成熟项目的组合让这套栈的技术可靠性远超初创项目。

总结：如果你正在构建多模型 AI 应用、对数据隐私有要求、或者想建立专业的 Prompt 迭代流程，这套开源栈值得优先考虑。