十月七日到八日，做永续合约出身的 Architect Financial Technologies 上线了一个叫 Liquid Inference 的东西：一个 LLM 路由，但它不是按延迟或权重静态分流，而是对每一个请求跑一场实时拍卖。推理供应商实时出价，买方（调用方）设好性能、地域、数据合规规则等约束，最后按「满足规则的最低出价」成交。它把金融市场里那套订单簿和竞价，直接搬过来给推理定价。
静态路由和现场拍卖，差在哪？
常见的 LLM 网关——无论是 OpenRouter 还是自建 proxy——分流逻辑大致是固定的：按模型标签、按健康检查、按预设权重轮询，出了问题再 fallback。它假设「哪个便宜、哪个快」是已知的、静态的。Liquid Inference 的赌注是这个假设错了：不同供应商在不同时刻、不同地域、不同负载下的真实成本和可用性一直在波动，静态权重永远追不上。于是它让供应商对每一个待派的请求报价，像交易所撮合订单一样，把这个请求实时分给当下最划算、又合规的那家。
一场拍卖要在毫秒级跑完，技术上怎么撑住？
难点在延迟。普通拍卖是分钟级的，推理请求是毫秒级的，你不可能真的让几个供应商来回讨价还价。它的实现思路是：供应商持续在后台挂出对某类请求的报价（带性能、地域、数据处理规则等约束），买方请求进来时，引擎在这些「挂单」里做一轮匹配排序，挑出满足约束的最低价成交。本质上不是实时拉锯，而是把一个持续报价的订单簿拿来对单个请求做即时撮合。Architect 还拿它和 OpenRouter、Hugging Face 的托管做对比，把「每请求竞价」当成核心卖点。
这是降本神器，还是又一个金融化噱头？
看好的一面：当推理供应商足够多、价格足够波动，这种市场化定价确实能把碎片化的闲置算力变现，买方也能压成本。存疑的一面：拍卖机制引入了新的复杂度——报价的真实性、供应商为了中标而牺牲质量的动机、以及合规约束在撮合里能不能真的被强制执行，都是问号。对开发者，眼下更实际的用法是把它当又一个带价格发现的网关，先在非关键链路上试，别一上来就把核心业务绑在一个金融化的路由上。
去论坛讨论
前往 silicon-agi.com 论坛 参与讨论