“Gemini的缓存系统是坏的。”Theo在推文串里给出的判断很直接:Google这款模型的定价明显偏高,原因不在算力单价,而在缓存机制没能把数据留住。
![]()
他给出的关键数字是27%的缓存未命中率。也就是说,超过四分之一的请求没有被缓存接住,被系统当成全新请求重新处理了一遍。
重复计算带来的就是重复付费。同一份数据本可以复用,却要再走一遍完整流程,运营成本因此被推高。Theo的结论是,相比缓存机制正常工作的竞争对手,Gemini在这项开销上处于明显劣势。
缓存这件事在LLM服务里不显眼,却直接决定单位请求的真实成本。命中率高,历史上下文可以复用;命中率低,每一次调用都接近从零开始。27%的缺口落在计费表上,就是实打实的额外支出。
Theo的批评指向的是成本效率,而非模型能力本身。他把问题定位在工程层面:缓存没能有效保留数据,导致高比例请求被当作新请求对待,最终形成重复的计算 effort 和显著上升的运营成本。
对使用方来说,这类成本不会写在价目表的显眼位置,而是藏在每一次未命中的调用里。Theo给出的判断是,这套缓存机制的问题让Gemini相对竞品的价格优势难以成立。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.