在与20多个在生产环境中运行LLM的团队交流后，三个痛点反复出现
摘要
基于与20多个团队的对话，作者指出了在生产中使用LLM时反复出现的三个痛点：仅企业版提供的基础功能、缺乏代理可观测性、以及新模型支持缓慢。
在多个子论坛发帖并与使用OpenAI/Anthropic/Gemini进行生产的团队交流后，有几个痛点独立地反复出现：
**1. "基础功能不应仅限企业版"**
使用提醒、团队权限、成本可见性、数据导出——所有这些都被锁定在昂贵的企业版计划中。5到50人的团队被迫为不需要的功能付费，只为获取基础服务。
**2. 代理可观测性缺口**
大多数网关将代理调用当作普通API调用处理。但当一个任务触发跨多个模型的数十次递归调用时，你无法追踪发生了什么，也无法将成本归因到特定工作流。你只会收到一张账单。
**3. 新模型支持滞后**
每次有新型号发布，就会进入等待期。需要数天或数周才能通过你的网关使用它。在2025年，这太慢了。
解决方案不是另一个功能齐全的网关，而是一个轻量级层，解决这三个问题且无需企业版定价——通过透明代理快速支持新模型、提供工作流级别的成本可见性，以及无需IT部门即可实现的团队管控。
我实际上正在开发一个朝这个方向发展的工具——如果你感兴趣，我在本周的项目展示帖中放了一个链接。
**我还遗漏了什么？你有什么要补充到这份清单上的吗？**
相似文章
在生产环境中调用LLM API时，最常见的问题是什么？
讨论生产环境中调用LLM API时常见的错误，包括速率限制、格式不匹配、响应格式错误、上下文溢出、模型弃用以及静默失败，并引用Datadog的统计数据及相关论文。
你的LLM提示词有200行。你真的知道智能体遵从了多少吗？
本文讨论了在生产环境中评估和监控基于LLM的智能体所面临的挑战，涵盖离线评估、提示工程陷阱、可观测性工具、审查队列、标注、聚类、主题分类，以及将人工审查、LLM作为评判和小型分类器进行成本分层的方法。
LLM的有效用例
本文分享了LLM在软件工程中的实际应用案例，包括通过RAG搜索客户对话、从日志中排查API故障以及内容精简。重点强调了效率提升和减少手动筛选工作。
本地LLM伙伴
一位拥有45年经验的开发者正在构建一个本地优先的LLM框架，包含多智能体逻辑，即将在GitHub上开源，并向社区询问哪些功能能改善他们的本地LLM体验。
我们一直在分析人们如何在法律与合规任务中使用LLM（GDPR、AI法案等）。
对LLM在法律与合规任务中使用的分析显示，模型常常生成自信但无法验证的引用，引发了对AI输出可靠法律依据的质疑。