原贴链接

无有效内容可翻译（帖子仅为一个图片链接）

讨论总结

原帖介绍了功能调用模式的改变，在评论中，一部分人对原帖内容存在疑惑，如对反向代理相关操作不理解。有人询问关于LLM调用方面的问题，包括用小LLM替代初始LLM调用的情况，且提及小LLM的优势和传统方式的弊端。还有人认可原帖的新方法并提出在单GPU机器本地运行和Kubernetes部署的技术问题并得到解答。同时也有反对的声音，质疑Arch Gateway的意义，也有人指出功能调用模式改变对接入API和构建代理体验有积极影响。

主要观点

  1. 👍 原帖内容涉及将某些操作上移到反向代理
    • 支持理由：AdditionalWeb107详细解释了网关在处理用户提示时的操作，将原本繁琐操作推到反向代理
    • 反对声音：无
  2. 🔥 存在一种用小LLM调用替代初始LLM调用的方式
    • 正方观点：AdditionalWeb107解释小LLM能检测下游API处理用户提示能力并做相关操作，运行时间短且成本低
    • 反方观点：crazyhorror表示不理解这样做为何比单次LLM调用更好
  3. 💡 认可原帖中的新方法并提出在单GPU机器本地运行和Kubernetes部署的技术问题
    • 支持理由：评论者认可新方法并基于实际应用场景提出运行和部署的疑问，得到了相应解答
    • 反对声音：无
  4. 👎 认为看到的东西（Arch Gateway）是无意义的
    • 支持理由：if47直接表达看到的东西很“扯淡”，质疑Arch Gateway意义
    • 反对声音：无
  5. 🤔 功能调用模式的改变影响重大，有助于接入现有API和构建代理体验
    • 支持理由：KitchenCertain2645认为这种改变可能对接入API和构建代理体验产生很大影响
    • 反对声音：无

金句与有趣评论

  1. “😂 I lost you here — “…can be pushed upstream to the reverse proxy. Which calls…””
    • 亮点：表达对原帖部分内容的疑惑，是很多人阅读技术类文章可能会遇到的情况。
  2. “🤔 Yes. A highly - optimized LLM with the ability to detect which endpoint API downstream can handle the user prompt.”
    • 亮点：点出小LLM的重要能力，是小LLM替代初始LLM调用的关键因素。
  3. “👀 Nice approach.”
    • 亮点：简单直接地表达对原帖新方法的认可态度。
  4. “😒 The most BS thing I’ve seen today, what’s the point of Arch Gateway?”
    • 亮点：简洁地表达否定态度并提出质疑。
  5. “💡 this could make a big difference in me being able to plug in existing APis and make an agentic experience.”
    • 亮点：指出功能调用模式改变在接入API和构建代理体验方面的潜在积极影响。

情感分析

总体情感倾向比较多元，既有认可新方法的积极态度，也有质疑Arch Gateway意义的消极态度，还有对部分内容表示疑惑的中立态度。主要分歧点在于对原帖中提到的一些概念（如Arch Gateway）的评价以及小LLM替代初始LLM调用是否更优。可能的原因是大家从不同的技术背景和应用需求出发看待这些问题。

趋势与预测

  • 新兴话题：小LLM在更多场景下替代初始LLM调用的可能性及影响。
  • 潜在影响：如果功能调用模式的改变被广泛应用，可能会对相关技术在接入API和构建代理体验方面带来革新。

详细内容：

标题：创新的函数调用模式引发Reddit热议

在Reddit上，一则题为“I flipped the function-calling pattern on its head. More responsive and less boiler plate for common agentic scenarios.”的帖子吸引了众多关注，获得了大量的点赞和评论。

这篇帖子主要讨论了一种新的函数调用模式，即把通常复杂的应用流程中的某些部分推到上游的反向代理（网关）去处理。例如，当用户输入“give me sales figures for the Wisconsin branch for the past 7 days”这样的提示时，网关会解析提示、提取相关参数，并触发指定的后端函数（API）来执行特定任务。

讨论的焦点集中在这种新模式的优势和可行性上。有人表示疑惑，希望能进一步阐述，比如[SatoshiNotMe]就说：“I lost you here — “…can be pushed upstream to the reverse proxy. Which calls…” Can you elaborate? Thanks”。[AdditionalWeb107]进行了详细的解释，称这种方式将应用业务逻辑中的繁琐流程推到了上游的反向代理，技术上网关有一个架构——路由器（2M LoRA LLM）来决定是否触发架构——函数LLM进行解析、处理和调用APIs。

有人认为这种模式是用较小的LLM替换了初始的LLM调用，比如[fractalcrust]问道：“so the initial LLM call is replaced with a call to a smaller LLM?”[AdditionalWeb107]给予了肯定回答。

但也有人提出质疑，像[crazyhorror]就表示：“I dont see why this is better than a single LLM call. Seems like it turns 1 inference call into 2?”[AdditionalWeb107]回应称，传统方式也需要两次LLM调用，并且新模式中的小LLM运行速度快、成本低。

还有人提出了关于本地运行和在kubernetes上部署的问题，如[mnze_brngo_7325]问道：“Is it feasible/recommended to run locally on a single - GPU (24G) machine? Some of your models (e.g. guard) seem to be optimized for CPU. How would you deploy this on kubernetes? Do you provide a helm chart? Don’t see explicit mentioning of kubernetes in the docs.”[AdditionalWeb107]回答称目前Arch - Function托管在云端以控制延迟，未来会提供本地运行的选项，也会发布helm chart和在kubernetes上部署的指南。

有人对这种新模式给予了肯定，如[KitchenCertain2645]认为：“this could make a big difference in me being able to plug in existing APis and make an agentic experience.”

争议点在于这种新模式是否真的比传统方式更具优势。支持者认为它更高效、成本更低，反对者则质疑其复杂性和实际效果。讨论中的共识是大家都在关注这种新模式在实际应用中的表现和可行性。

总的来说，这个关于创新函数调用模式的讨论充满了各种观点和思考，为相关技术的发展和应用提供了有价值的参考。