跳到主要内容

成本优化

按时间浏览全部文档。

长上下文推理越跑越贵?On-Demand Attention 让模型「需要时才回看历史」

长上下文推理越跑越贵?On-Demand Attention 让模型「需要时才回看历史」

长上下文和 Agent 推理贵,根因之一是全注意力每生成一个 token 都要重读不断变长的历史。arXiv 新论文 On-Demand Attention(ODA)默认用局部注意力,靠一个轻量『召回头』预测『这一步要不要回看全局』,只在有用时才触发全局读取。从接入方视角看,它是同档模型下不同供应商『每 token 成本/延迟』会拉开差距的隐性变量。

用模型「自报置信度」决定要不要换更强模型?受控测试:能用,但别全信

用模型「自报置信度」决定要不要换更强模型?受控测试:能用,但别全信

想靠模型自己报的置信度来决定「这条查询要不要升级到更贵的模型」?一份受控测试显示:直接口头报的置信度出奇地准(AUROC 0.956),比三次采样投票(约 0.77)强得多;但它很脆——换个问法,4%–9% 的路由决策就翻了。给置信度路由的落地建议。

评估一个 Agent 模型要烧 1 万美元、跑 2.7 天:20 个任务的迷你集把选型成本压到 1/40

评估一个 Agent 模型要烧 1 万美元、跑 2.7 天:20 个任务的迷你集把选型成本压到 1/40

在 APEX-Agents 上评估一个前沿模型约花 1.09 万美元、跑 2.7 天,让'持续选型'贵到做不起。DualViewEval 用 20 个任务的迷你集加 6 个过程信号,把 Agent 评估压缩 24–40 倍、误差还更低。本文拆解方法,并给出 LoopRouter 的选型与路由落地视角。

为省钱剪枝的小模型,还能可靠调工具吗?先看架构再决定

为省钱剪枝的小模型,还能可靠调工具吗?先看架构再决定

剪枝能压低大模型部署成本,却会先削弱工具调用里最具体的部分(设备、参数、取值)。一项跨 4 个模型、1.95 万条实例的研究显示:稠密模型剪枝「安全区窄、掉得急」,MoE 能扛更多剪枝;剪太狠还会让模型系统性拒答。从 Agent 接入与模型路由视角给出选型建议。

给大模型喂新知识,该放进上下文、参数还是 KV 缓存?一张成本-质量决策表

给大模型喂新知识,该放进上下文、参数还是 KV 缓存?一张成本-质量决策表

同一批文档,放进上下文窗口、微调进参数、还是编码成 KV 缓存(Cartridges/Compaction),准确率和成本差很多。一项受控对比显示:KV 缓存的 Cartridges 在真实检索场景领先微调 29 分,但会带来最高 13% 的灾难性遗忘。从企业接入与成本治理视角给出选型建议。

本地跑大模型多久回本?先算清这 5 个变量,再决定自建还是走 API

本地跑大模型多久回本?先算清这 5 个变量,再决定自建还是走 API

「买台机器自己跑模型」到底几个月回本,取决于日均 token 量、输入输出比、电费、API 单价,以及一个最容易被忽略的变量——API 价格还在往下掉。本文拆解这套回本测算的框架,并给出 LoopRouter 视角:多数团队的最优解不是二选一,而是本地与 API 之间按任务路由。