AI/LLM 结果都是实时生成的吗？

[webdriver]

现在每天大量的人查询LLM，按照统计学应该有很多查询都是一样的关键字，那么问题是：现在的AI/LLM有没有有效的缓存机制，使得这些类似查询不需要每次都消耗宝贵的tokens，而是通过缓存输出最终结果？

有谁有此类研究/实操经验？

[牛河梁]

说个笑话。老牛一发小是名中医。由政府资助的工作室。当年他还没当上正教授的时候去参加全国学术研讨。学回来的一不传之密。就是诊病之前，先为病人占一卦。

老牛相信，哪怕遇到一摸一样的问题。AI/LLM也会往里面加点盐。

[fantasist]

你要的是传统search。
LLM本身生成就带有随机性，主要由temperature控制。不适合强行cache住某个response。

[Caravel]

现在每天大量的人查询LLM，按照统计学应该有很多查询都是一样的关键字，那么问题是：现在的AI/LLM有没有有效的缓存机制，使得这些类似查询不需要每次都消耗宝贵的tokens，而是通过缓存输出最终结果？

有谁有此类研究/实操经验？

cache大量数据也需要耗费能量

况且很难找到完全一样的query

[webdriver]

cache大量数据也需要耗费能量

况且很难找到完全一样的query

有根据吗？我咋觉得大多数人平常的查询基本相同呢？即使是很复杂的查询，分接下来也许就是几个小问题的组合

[Caravel]

有根据吗？我咋觉得大多数人平常的查询基本相同呢？即使是很复杂的查询，分接下来也许就是几个小问题的组合

llm是有context的，你的一次对话得全部得一样，结果才可以复用

[fantasist]

有根据吗？我咋觉得大多数人平常的查询基本相同呢？即使是很复杂的查询，分接下来也许就是几个小问题的组合

你大概关心的是RAG类产品，查询query先被rewrite成一堆sub query，用来找context，这部分可以cache。但之后的rerank和summarization等步骤不太能被cache，除非原始query是perfect match。
LLM inference engine主要是做prefix cache，能减少system prompt的处理消耗，但完整的结果很难cache。

[libaliu]

楼主估计没有了解当前LLM的基础模型Transformer。简单地说基于前面的若干个token t-1,...t-n（n是context的长度）找到可能性最大的几个token，然后再从这几个token中，按照一定的分布率（由temperature参数控制，取值越大随机性越强）选一个当作输出token t。这个token t 和以前的n-1个合并一起，再次调用Transformer模型，得到token t+1。反复如此，得到一个完全的输出。

所以LLM的结果每次都是实时生成的。

[牛河梁]

Subquery那一层（Expert？Module？Agent？）可以cache。举例说调用Web search，结果显然是cached了的。

你大概关心的是RAG类产品，查询query先被rewrite成一堆sub query，用来找context，这部分可以cache。但之后的rerank和summarization等步骤不太能被cache，除非原始query是perfect match。
LLM inference engine主要是做prefix cache，能减少system prompt的处理消耗，但完整的结果很难cache。

[牛河梁]

有根据吗？我咋觉得大多数人平常的查询基本相同呢？即使是很复杂的查询，分接下来也许就是几个小问题的组合

Hit rate低cache就没有意义。Prompt每增加一个token，hit rate都断崖式下降。1000个token和零没有区别。

[fantasist]

Subquery那一层（Expert？Module？Agent？）可以cache。举例说调用Web search，结果显然是cached了的。

这步学名叫retrieval

[noktard]

肯定的

Yes, the responses from a large language model (LLM) like me are generated in real time. Here's a breakdown:
No pre-written answers: Unlike a database, I don’t retrieve a stored answer. Each reply is generated dynamically based on your input.
Token-by-token generation: The model predicts the next word (or “token”) one at a time until the response is complete. This is why longer answers can take a moment to appear.
Context-dependent: The response depends on the conversation history, so even the same question may get slightly different answers depending on prior messages.
External tools: If an LLM query uses external tools (like browsing or APIs), part of the result might come from a live lookup, but the final output is still assembled in real time.
说句不好听的，有了chatGPT之后，大多数人都跟傻子差不多

[牛河梁]

这步学名叫retrieval

城会玩。西爱死就是喜欢发明新名词。

[牛河梁]

你要的是传统search。
LLM本身生成就带有随机性，主要由temperature控制。不适合强行cache住某个response。

琐男们不了解随机（算法）的强大。哪怕是（鸣笑）西爱死大师学位，老牛敢说99%以上也不了解。也许90%以上的西爱死永久脑残也不清楚。

现在的AI之所以强大，一半功劳在于对计算机而言貌似随机的prompt输入。这是药引。

随机是尖端技术/思想。曼哈顿工程里就很有名。

[fantasist]

城会玩。西爱死就是喜欢发明新名词。

不是新词啊，搜广推做的就是retrieval，有二十年以上了

[verdelite]

不能复用就是大问题。这需要解决。

[webdriver]

1+1 = 2 或者类似的问题，还要每次让DS/GROK去解释一下怎么得到的，是不是挺浪费的？

[magagop]

1+1 = 2 或者类似的问题，还要每次让DS/GROK去解释一下怎么得到的，是不是挺浪费的？

即使是1+1=2這種問題，context history不一樣，輸出結果也不一樣，這就是LLM的魅力。你說的cache，有類似的flash attention實現，不是緩存結果，而是規劃利用系統的memory hierarchy，來加速模型。你說的結果cache只能放在CPU DRAM裡面，如果hit rate過低，將會浪費大量系統內存。如果放在GPU HBM裡面，那是不可能的，因為GPU HBM非常緊張，沒空間放這種東西。如果做成Vector Datbase，放在硬盤上，那就是RAG，但對GPU提升性能沒有影響，因為HBM速度比硬盤快幾個數量級。所以我總說，不懂硬件底層的，最好不要出來設計AI系統，否則只能越改越糟。

[mmking]

不需要的，大部分回答都是垃圾

不能复用就是大问题。这需要解决。

[webdriver]

好多大牛啊。。。

话说我这个话题其实想知道的是不是有这样挣钱的机会，就是提供中间层服务（agent type/VAR）接受终端用户咨询，可以是非常专门的领域；后端与商用LLM的通讯是以token数量计费的，如果你自己的算法可以提供buffering/caching，那么可以节省不少实时查询的成本，毕竟你是知道终端用户们的需求，你的结果是相对确定的 -- 以前是专门定制的数据库/资料库，现在是LLM backed。