先看证据
不是又一个模型目录，而是请求级采购
Architect Financial Technologies推出Liquid Inference，定位为面向大语言模型推理的竞价路由服务。它面向希望沿用现有OpenAI或Anthropic格式客户端、同时在多个推理服务商之间选择的开发团队：客户端发出请求，平台再按买方规则挑选提供方。Architect称其为推理现货市场，核心变化是把原本按固定价目或双边合同采购的过程，改成服务商围绕单个请求报价。
这不只是把模型放进一个更大的目录。普通路由器可以替用户在可用服务间分配流量，而Liquid Inference把报价和买方约束放进同一次选择：规则先筛掉不合格的选项，剩下的报价再竞争。技术负责人因此要问的，不只是“能不能换一个API地址”，还包括团队原先由模型选择、供应商合同和运行策略共同承担的采购判断，有多少被交给了平台。
竞价发生在规则之后，最低价不是无条件胜出
按Architect公布的流程，服务商先为模型登记报价。买方请求到达后，平台根据单次成本上限、首token延迟、最低吞吐量、可用地区、零数据留存要求，以及服务商或模型白名单筛选报价；最后由符合条件的最低价中标。换句话说，系统不是在所有报价里无条件选最便宜的，而是在买方定义的可行范围内比价。
最高价格会在生成首个token前锁定，最终按实际计量用量收费，平台还会提供逐单记录，包括中标服务商、价格上限和最终费用等信息。这种设计能把一部分采购约束变成请求级配置，而不是留在采购文档里。但规则只能说明服务是否满足门槛，不能自动证明不同提供方的输出质量相当，也不能保证一次合格的延迟表现会长期稳定。若团队把模型质量视为成本之外的硬要求，仍需自行定义评估方法，并把结果纳入可路由的规则或供应商管理流程。
市场透明度不等于市场深度
Liquid Inference的一个差异化设计，是让账户持有人查看实时报价簿、按服务商和模型拆分的报价，以及已成交记录。对采购和平台团队来说，这类数据有机会把“某次调用花了多少钱”扩展成对报价变化和成交情况的观察，进而为预算、路由策略和供应商谈判提供依据。逐单记录也比单一账单更容易定位成本从何而来。
不过，能看见报价，不代表有足够多的有效报价。Architect称测试阶段已有数百项任务覆盖700多个模型，并列出7家首批合作服务商；这些是公司披露的测试与合作信息，并非独立验证的线上竞争程度。公开材料也没有交代报价更新频率、竞价窗口、同价时如何处理，或服务商登记的报价究竟如何对应每一条即时请求。没有这些细节，订单簿可以增加可见性，却不能单凭展示证明价格由充分竞争形成。
接入轻，责任关系却没有消失
对应用团队而言，兼容OpenAI和Anthropic格式意味着接入门槛可能较低，Architect也列出Claude Code、Cursor等工具的兼容性。服务商则可通过REST或WebSocket接口登记模型和报价，并经Stripe收款。若现有代码已经围绕兼容API构建，切换路由层比重写整套推理调用更容易；但“换基础URL”只描述了技术接入，不等于迁移没有运维和治理成本。
与OpenRouter的比较能说明产品取舍：Liquid Inference强调逐请求竞价、价格上限锁定和报价成交数据；素材列出的OpenRouter则支持500多个模型、80多家服务商，采用按价格加权的负载均衡。前者的卖点是把约束和报价放进每次选择，后者呈现的是更明确的模型与服务商覆盖规模。两者的公开信息并不足以证明谁在延迟、质量或总成本上更优，也不应把“竞价”直接等同于“更便宜”。
还有一个容易被“交易所”比喻遮住的边界：Architect的产品条款说明，用户向Architect购买推理服务，Architect再从独立服务商采购，底层服务商是其分包商，并不与买方直接签约。因此，技术团队在试用前应确认数据处理、故障升级、退款和供应商替换分别由谁负责，并记录不同路由条件下的质量与成本。Liquid Inference适合被当作可评估的采购与路由机制，而不是已经证明能自动优化一切的市场。