LLM 推理雷达

要解决的问题

LLM 推理加速领域的信息噪音极大。同一个 KV cache 改进方案可能同时出现在 arXiv、HF Daily Papers、作者推文和媒体转载里，工程团队很难快速判断哪些是可复现的方法，哪些只是标题党。更麻烦的是，性能数字普遍缺少基线模型、batch size、prompt/output 长度、prefill/decode 划分等关键上下文，直接拿来做技术选型风险很高。

技能如何工作

LLM Inference Radar 把「追踪前沿」拆成几个可执行的工作流程：

• Daily Brief：默认生成中文简报，至少 10 条去重后的条目，其中不少于 5 条论文/方法、3 条来自 Horizon Radar / Hidden Opportunity / Upstream Signal / Downstream Signal。优先算法/方法论文，而非常规工程发布。
• Paper Radar：对每篇论文强制回答六个问题——解决的是不是真推理问题、核心方法是什么、有无代码/checkpoint/benchmark script、硬件设置是否清楚、复现成本多高、是否关联 dLLM/VLM/agent/RL 等 horizon 负载。
• Open-Source & Infra Watch：不按 stars 排序，而是读 release note、merged PR、RFC、设计文档和 issue 讨论，判断更新属于「重大工程进展」「普通维护」「benchmark 更新」「RFC」「issue 暴露瓶颈」还是「集成信号」。
• Horizon & Transfer：当新负载出现时，分析推理形态、延迟/吞吐/内存/调度瓶颈，并把可迁移的已有技术写入 knowledge_base/transfer_matrix.md。
• Feedback Learning：把用户的硬约束、强偏好、弱偏好分别写入 references/config.yaml、taxonomy.yaml 或 watchlist.yaml，避免短期偏好过拟合。

来源优先级明确：arXiv、OpenReview、官方仓库、release note、设计文档是 primary source；X/Twitter、newsletter、知乎、微信文章只作为线索，需回溯到一手资料。找不到一手来源的条目会被标记为 early signal，不会给出强结论。

适用边界

这个技能是研究情报工具，不是 benchmark 本身。它无法替你验证论文里的实验是否真的正确，只能检查是否提供了 Docker/configs、benchmark scripts 和明确的硬件设置。多标签分类（serving / KV cache / agent runtime / long-context memory / VLM serving / RL scaling）意味着同一方法可能横跨多个领域，不代表领域边界已经清晰。Horizon transfer 本身具有推测性——transfer_matrix.md 里记录的是「可能迁移」和「待验证」，不是「已证明」。

另一个限制是信息时效。每日简报依赖当天的 arXiv 和社区动态，如果当天高质量论文不足 5 篇，技能会扩大搜索窗口并在简报中说明，但窗口拉长本身就可能引入旧闻。Feedback Learning 能记录你的偏好，但不会替你判断哪条 horizon 信号值得长期投入。