<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Paper Daily · 系统与索引 Infra</title>
<link>https://paper-daily.com/</link>
<description>为搜索与推荐工程师挑选的每日 GenAI 论文：评分、卡片摘要与深度解读。</description>
<language>zh-CN</language>
<lastBuildDate>Thu, 29 Oct 2026 08:00:00 +0800</lastBuildDate>
<atom:link href="https://paper-daily.com/feeds/infra.xml" rel="self" type="application/rss+xml"/>
<generator>Paper Daily site builder</generator>
<ttl>360</ttl>
<item>
<title>Folding Attention Biases into Keys Makes Compacted KV Caches Run on Standard Kernels</title>
<link>https://paper-daily.com/papers/folding-attention-biases-keys-makes-compacted-kv-caches-run/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.36520</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;KV cache 压缩已能把长文档的缓存砍到十分之一，但效果最好的 Attention Matching 给每个保留的键向量加了一个偏置，vLLM 没有地方放它。这篇论文用读文档时产生的 query 为每个注意力头算出一个方向，让这些 query 在它上面的投影平均正好是 1，再把每个键向量沿它挪动一段与偏置成正比的距离，投影接近 1 的 query 看到的分数变化就约等于偏置。不改源码的 vLLM 在一张 T4 上同时装下的请求从 4 个变成 31 个。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.40 · 深度解读 13 分钟 · Utkarsh Kanwat · &lt;a href=&quot;https://arxiv.org/abs/2610.36520&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>WAKMan: Workload Aware KVCache Manager</title>
<link>https://paper-daily.com/papers/wakman-workload-aware-kvcache-manager/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.36355</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;vLLM 的前缀缓存该用哪种淘汰策略，取决于此刻的流量。agent 请求几秒后就带着同样的历史回来，默认的 LRU 正合适；热门系统提示和多轮对话的历史隔很久才回来，要靠优先保护反复被用的块的 S3FIFO 才留得住。作者在 20 种请求混合上实测，两种策略各有输赢。WAKMan 每 15 分钟把刚过去的流量在两套模拟缓存上各重放一遍，下一段时间用命中率更高的那套，平均比只用 LRU 多 5 个点的命中率。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.40 · 深度解读 11 分钟 · Suhas Kumar Morisetty, Vaibhavi Lokegaonkar, Sachin Mathew Varghese, Wesley Harris · &lt;a href=&quot;https://arxiv.org/abs/2610.36355&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Let the Gate Decide: Per-Lookup Precision for Quantized Conditional Memory in LLMs</title>
<link>https://paper-daily.com/papers/let-gate-decide-per-lookup-precision-quantized-conditional/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.35985</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;给大模型的 n-gram 记忆表做低比特量化时，把精度留给访问最多的行反而比随机挑还差。原因在门控：DeepSeek 的 Engram 这类条件记忆层查出的向量要乘一个门控，常见虚词的门控很小，罕见实体名的门控很大，量化误差按门控放大。GateRQ 把每行存成几级单比特残差码，每次查表先读第一级算出门控，再在同一个 batch 里按门控估出的重要度排序，排在最前的一小部分读到第三级，其次的读到第二级，其余停在第一级；各级的比例由事先定好的平均读取比特数预算决定。不重训模型，DeepSeek 最新的 Flash 模型每张 GPU 上的表从 23.6 GiB 降到 3.0 GiB，省下的显存让长上下文吞吐比 FP8 表明显更高。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.40 · 深度解读 16 分钟 · Tianqi Chen, Xunchao Li, Linchuan Xie, Guanghua Yu, Jianchen Zhu, Peisong Wang, Jian Cheng · &lt;a href=&quot;https://arxiv.org/abs/2610.35985&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Lossless Compression of Proximity Graph Indexes for Efficient Approximate Nearest Neighbors Search</title>
<link>https://paper-daily.com/papers/lossless-compression-proximity-graph-indexes-efficient/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.37176</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;向量检索的 HNSW 图索引里，向量本身已经常被量化压小，邻接表里的边反而成了内存大头，但边要在每次查询走图时现场解码，压缩不能拖慢查询。eBay 和比萨大学的这篇工作先离线给节点重新编号，让相邻节点的编号靠近，再用支持 SIMD 的整数压缩器 Stream VByte 现场解码。边存储最多省下 52.7%，延迟几乎不变；在 eBay 线上部署时，边存储最多减少 44.3%，查询延迟没有变差。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.30 · 深度解读 10 分钟 · Francesco Benocci, Leonard Dahlmann, Francesco Gargiulo, Tobias Heuer, Silvio Martinico, Franco Mar… · &lt;a href=&quot;https://arxiv.org/abs/2610.37176&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>TAO: Tool-Aware Joint Scheduling for LLM-Based Agentic Serving</title>
<link>https://paper-daily.com/2026-10-29/infra/#paper-arxiv:2610.37230</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.37230</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;agent 服务里，模型推理跑在 GPU 集群上，工具调用跑在分散的 CPU 上，现有调度器不看工具什么时候返回，也只用启发式规则决定哪些会话上 GPU、放在哪个节点。TAO 为每个会话和每个节点算三项：这个节点上缓存还能复用多少（随时间衰减），工具是否会在下个调度窗口内返回（按工具自己报告的进度或同类工具的历史耗时估算），会占多少 token。动态规划在容量限制下一起决定选谁、放哪，目标是让选中会话的缓存复用总量最大，平手时就绪的会话越多越好，再平手时偏向 token 多的。在 12 组模型、负载和并发设置里，首 token 平均延迟最多降低 36.3%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.10 · Shuhuai Li, Shengdong Ye, Dongdong Ge, Yinyu Ye, Jianghao Lin · &lt;a href=&quot;https://arxiv.org/abs/2610.37230&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>ResCom: Activation Residual Compensation for Large Language Model Quantization</title>
<link>https://paper-daily.com/2026-10-29/infra/#paper-arxiv:2610.35955</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.35955</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;权重和激活都量化到低比特后，同一个量化区间里的激活被取成同一个值，精度因此下降。ResCom 把激活被舍掉的残差拿回来补偿层输出误差。它在校准数据上统计残差的协方差，以及输出误差和残差的互协方差。先用前者把残差各维的尺度和相关性拉平，再对拉平后的互协方差矩阵做奇异值分解。取最能解释输出误差的几个方向，就直接得到低秩修正矩阵，不需要梯度训练。在 4 bit 权重和激活的 Llama-3-8B 上，五样本 GSM8K 准确率从 23.96% 提到 36.16%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.10 · Ning Yang, Bohan Cui, Zhuowen Liu, Yuting Wang · &lt;a href=&quot;https://arxiv.org/abs/2610.35955&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Lost in the bf16 Cast: Exporting Ternary Language Models Can Revert Most Low-Learning-Rate Code Changes</title>
<link>https://paper-daily.com/2026-10-29/infra/#paper-arxiv:2610.07853</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.07853</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;三值大模型发布时，导出流程先把潜在权重转成 bf16，这一步会悄悄抹掉小学习率微调学到的大部分改动。原因是微调更新的是高精度的潜在权重，只有潜在权重越过阈值（所在张量平均幅度的一半）时，对应的三值码才会改变；小学习率下，多数改动只比阈值多出一点点。而阈值附近 bf16 能表示的相邻数值隔得比这点改动还远，一转就把刚越过阈值的权重拉回原处。按文档流程导出后，Falcon-E-1B-Base 的 GSM8K 准确率从 58.79% 掉到 0.78%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.10 · Avichal Sahai, Nishant Raj, Animesh Srivastava · &lt;a href=&quot;https://arxiv.org/abs/2610.07853&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Memory-Enforced GPU Sharing in Kubernetes with NVIDIA CUDA 13.4</title>
<link>https://paper-daily.com/2026-10-29/infra/#paper-blog_rss:nvidia_developer_blog:https:%2F%2Fdeveloper.nvidia.com%2Fblog%2Fmemory-enforced-gpu-sharing-in-kubernetes-with-nvidia-cuda-13-4</link>
<guid isPermaLink="false">paper-daily:zh:blog_rss:nvidia_developer_blog:https://developer.nvidia.com/blog/memory-enforced-gpu-sharing-in-kubernetes-with-nvidia-cuda-13-4</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;很多 AI 任务只用得了一块 GPU 的一小部分，以往的共享方式里，轮流占用的时间片不限制显存，多进程并发的 MPS 也没有对应用透明的显存上限。NVIDIA 的这篇博客介绍 CUDA 13.4 新增的显存边界：任务申请多少就只能用多少，超出就分配失败，也可以设保底加可突发的上限。配套的开源 GPU Fractioning Operator 在 Kubernetes 节点上配置和监督 MPS，KAI Scheduler v0.18.0 负责按注解把分数 GPU 分给各个容器。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.00 · &lt;a href=&quot;https://developer.nvidia.com/blog/memory-enforced-gpu-sharing-in-kubernetes-with-nvidia-cuda-13-4/&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>LoRA on a Budget: Function-Aware Post-Hoc Compression for Adapter Fleets</title>
<link>https://paper-daily.com/2026-10-29/infra/#paper-arxiv:2610.36386</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.36386</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;同一个底座模型挂着大量 LoRA 适配器时，要在共享的秩预算下压缩它们，既要定每个适配器各层留多少秩，也要定预算在适配器之间怎么分。FRA 不用标注，拿一小批无标注输入，比较压缩前后适配器输出分布的差异（JS 散度），逐个截断模块测出这个差异，用动态规划拼出每个适配器的压缩曲线，再在整批适配器上做让最差者损失最小的分配。在 3 个公开集合共 78 个适配器上，预算紧时最差适配器的效果明显更好。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.00 · Shenghui Li, Thiemo voigt · &lt;a href=&quot;https://arxiv.org/abs/2610.36386&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Layerwise Repacking: Variable-Length Hybrid-Attention Training without an Extra Redistribution Pass</title>
<link>https://paper-daily.com/2026-10-29/infra/#paper-arxiv:2610.35989</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.35989</guid>
<pubDate>Thu, 29 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;混合注意力模型做变长训练时，最长的样本在全注意力层需要几十张卡组成的大序列并行组，稀疏注意力层在单机小组里就能平衡。复用大组会让稀疏层通信跨机，单独再切换分组又要多搬一次数据。全注意力层本来就要做一次全交换通信来交换注意力头，Layerwise Repacking 在这次交换里顺便把样本重新分到单机小组，隐状态留在小组里直到下一个全注意力层，端到端训练时间平均缩短 7.61%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.00 · Jiahao Zhang, Junwei Feng, Dongliang Huang, Xiaoling Zhou, Yiqiao Liao, Chengru Song · &lt;a href=&quot;https://arxiv.org/abs/2610.35989&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>HiLO: Towards Product-Level Graceful Degradation with a Quality-Aware, Load-Aware Control Framework</title>
<link>https://paper-daily.com/papers/hilo-product-level-graceful-degradation-quality-aware/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.34844</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;流量尖峰时每个服务各自降级，单个服务活下来了，整个产品效果却可能崩掉。微软的 HiLO 把降级从服务级提到产品级：事先定好几个经过验证的产品状态，每个状态规定每个服务降到哪一档，比如关掉某些特征、减少扇出或换更便宜的模型；运行时各服务上报负载，中央控制器据此选一个状态下发。降级的单位应该是产品，而不是服务。上线后经历了 9 次真实流量冲击。最高一次到基线峰值的 2.38 倍，Bing 的相关性指标 OneDCG（一种归一化排序质量分）最多只掉 0.425 个点，没有越过 0.5 个点的运营红线。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.75 · 深度解读 13 分钟 · Knut Magne Risvik, Zhuowei Li, Nirupam Purushothama, Hunter Su, Greg Dunham, Yan Reznikov · &lt;a href=&quot;https://arxiv.org/abs/2610.34844&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Failure-Resilient and Verifiable Distributed Approximate Nearest-Neighbor Retrieval</title>
<link>https://paper-daily.com/papers/failure-resilient-verifiable-distributed-approximate/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.34608</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;分布式向量库的副本能保证查得到，却不能保证查到的是真的：被攻破的副本可以返回签名合法、内容被篡改的近邻结果。TrustANN 在路由层之上加一层中间件，对每个分片，从副本回复里贪心挑出一组：数量达到设定下限，两两相似分够高（候选集合重合度加排序一致度），并覆盖设定数量的不同故障域（如可用区）；凑不齐就去找新的独立副本补，仍不够则明确返回未验证。副本在线不等于结果可信。在多节点测试里，被篡改结果被当成可信的比例从 100% 降到 0，正常负载下 p95 延迟只多 9.36%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.40 · 深度解读 12 分钟 · Abdullah Al-Mamun · &lt;a href=&quot;https://arxiv.org/abs/2610.34608&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Cross-Modal Data Co-Locality for Heterogeneous Storage Systems</title>
<link>https://paper-daily.com/papers/cross-modal-data-co-locality-heterogeneous-storage-systems/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.34595</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;一条多模态查询要先查文本向量、再取对应的图片向量，两次近邻检索都很快，慢的是两份向量分在不同存储层时的那次搬运。CoLoc 不改向量也不改索引，只调整数据放在哪一层：经常被同一条查询一起用到的向量尽量放在同一层。它优化的是数据放在哪，而不是在哪里搜。在四层存储测试中，需要跨层取数的查询从 73.04% 降到 0，多模态查询占一半时端到端延迟降低 24.8%，召回率不变。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.40 · 深度解读 12 分钟 · Abdullah Al-Mamun · &lt;a href=&quot;https://arxiv.org/abs/2610.34595&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>BellowsKV: One Latent for Many Layers, Expanded on Demand</title>
<link>https://paper-daily.com/papers/bellowskv-one-latent-many-layers-expanded-demand/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.35023</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;长上下文推理里最占显存的往往是每层各存一份的 KV 缓存（每个历史 token 的键和值）。BellowsKV 发现相邻几层的缓存彼此不像，但算出缓存的输入隐藏状态很像，所以共享输入：把每个 token 在相邻 n 层的隐藏状态拼起来，乘一个压缩矩阵，得到一份共享向量，替代这 n 层的缓存；每层另有一个还原矩阵，直接从共享向量算回本层的键和值。两种矩阵用校准数据按还原误差最小离线求一次，无需训练。该共享的是输入，而不是缓存。在 3 个模型上压到约 14 倍仍保留 97% 以上的准确率。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.35 · 深度解读 11 分钟 · Jiamu Zhang, Hanjie Chen · &lt;a href=&quot;https://arxiv.org/abs/2610.35023&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>ZipFusion: Fusing Lossless KV Decompression with Attention for Efficient LLM Decoding</title>
<link>https://paper-daily.com/papers/zipfusion-fusing-lossless-kv-decompression-attention/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.33719</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;无损压缩 KV 缓存的好处，大半被解压这一步吃掉了：以前的做法搬到显卡上先解压回原样，注意力每次仍读未压缩的数据。ZipFusion 于是让注意力直接读压缩数据，格式上只压缩 16 位浮点数里集中在小范围的指数位、尾数原样保留，注意力在寄存器里用几条整数加法和移位把指数拼回去，得到逐位相同的原值。无损压缩也能直接让解码变快。在 H100 上注意力算子比 FlashInfer 快约 1.25 倍，8K 上下文下整机解码吞吐比不压缩的 SGLang 高 26.3%，结果逐位一致。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.25 · 深度解读 11 分钟 · Yuetao Chen, Peng Wang, Hong Xu · &lt;a href=&quot;https://arxiv.org/abs/2610.33719&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Governing Enterprise AI Traffic at Scale: Design and Operation of a Policy-Driven, Multi-Vendor LLM Gateway on Envoy</title>
<link>https://paper-daily.com/papers/governing-enterprise-ai-traffic-scale-design-operation/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.35509</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;企业同时用多家大模型，每个应用各接各的，就会密钥满天飞、换模型要改代码、花钱没人管。PayPal 的 Cosmos 网关基于 Envoy 代理，把认证、预算、策略这类要查外部服务的慢决策放到代理外，把格式翻译和计 token 放在代理内，流式回复的每一块都不用等外部调用。网关的难点在治理，不在路由。它服务 1.2 万多名开发者、每天约 2000 亿 token，压测中只增加 4 毫秒中位延迟。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.20 · 深度解读 10 分钟 · Mithun Sasidharan, Srinivasan Manoharan, Rupesh Thakur, Abhinav TK, Ashwin Hegde, Anand Gautam · &lt;a href=&quot;https://arxiv.org/abs/2610.35509&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Prefetch-Steered Routing: Deterministic Cache-Aware Expert Selection for Offloaded Mixture-of-Experts Decoding</title>
<link>https://paper-daily.com/2026-10-28/infra/#paper-arxiv:2610.34721</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.34721</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;混合专家模型（MoE）放不进显存时，解码主要耗在拷贝专家权重上。偏向已驻留专家的路由能少拷贝，但配合异步预取，输出会随传输时机变化，评测就不代表线上模型。PSR 让路由只看一个确定性的逻辑缓存：在每层，用当前隐藏状态喂给下一层的路由器，预测它会选的专家，把其中 1 到 2 个写进逻辑缓存。逻辑缓存每层容量等于显存里的专家槽位数，满了就淘汰得分最低的，得分是路由器过去选中各专家的滑动平均；下一层路由时，缓存里的专家在路由打分上加一个固定奖励。它只由 token 历史决定，与拷贝何时完成无关；真实拷贝跟着它预取，只影响速度。先让输出确定。在 RTX 4090 上跑 OLMoE，比精确路由加 LRU 换出快 2.2 倍以上，分数持平。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.10 · Siming Huang · &lt;a href=&quot;https://arxiv.org/abs/2610.34721&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>推理加速新范式：火山引擎高性能分布式 KVCache （EIC）核心技术解读</title>
<link>https://paper-daily.com/2026-10-28/infra/#paper-web:volcengine-eic-20261008</link>
<guid isPermaLink="false">paper-daily:zh:web:volcengine-eic-20261008</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;多个推理实例各自重算同一段长前缀，是推理集群里很常见的浪费。火山引擎存储团队的弹性极速缓存 EIC 是一个面向大模型推理的分布式 KV 缓存服务，定位是把推理时算出的 KV cache 存到一个独立的分布式缓存层里，供多个推理实例共享和复用，减少重复计算长前缀。把 KV 缓存从单机显存里拿出来，做成共享的存储服务，是推理基础设施这两年的一个明确方向。做多实例推理服务、长上下文或多轮对话的团队可以把它当作产品形态参考。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.80 · &lt;a href=&quot;https://developer.volcengine.com/articles/7691218969801588777&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>3 Ways to Boost MoE Inference on NVIDIA DGX Spark</title>
<link>https://paper-daily.com/2026-10-28/infra/#paper-blog_rss:nvidia_developer_blog:https:%2F%2Fdeveloper.nvidia.com%2Fblog%2F3-ways-to-boost-moe-inference-on-nvidia-dgx-spark</link>
<guid isPermaLink="false">paper-daily:zh:blog_rss:nvidia_developer_blog:https://developer.nvidia.com/blog/3-ways-to-boost-moe-inference-on-nvidia-dgx-spark</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;单条请求解码大模型时，慢的往往不是计算而是读权重。英伟达在 DGX Spark 上优化混合专家模型 Ling-3.0-flash，剖析发现瓶颈，主要来自专家计算和输出层投影，所以三招都围绕少读权重、一次多出 token：换用更快的专家计算内核，把输出层在线量化到 8 位，再用模型自带的多 token 预测做投机解码。先剖析瓶颈，再对症减少权重读取。三者合用后在 GSM8K 上解码吞吐提升 42.5%，平均延迟降低 24.5%，准确率没有可测变化。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.65 · &lt;a href=&quot;https://developer.nvidia.com/blog/3-ways-to-boost-moe-inference-on-nvidia-dgx-spark/&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>How NVIDIA Minerva Turns Telemetry Chaos Into Peak GPU Yield</title>
<link>https://paper-daily.com/2026-10-28/infra/#paper-blog_rss:nvidia_developer_blog:https:%2F%2Fdeveloper.nvidia.com%2Fblog%2Fhow-nvidia-minerva-turns-telemetry-chaos-into-peak-gpu-yield</link>
<guid isPermaLink="false">paper-daily:zh:blog_rss:nvidia_developer_blog:https://developer.nvidia.com/blog/how-nvidia-minerva-turns-telemetry-chaos-into-peak-gpu-yield</guid>
<pubDate>Wed, 28 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;大规模训练里，一块发热偏高的显卡或一个性能悄悄下降的网口，就能拖慢整个同步训练任务，而这类灰色故障往往不触发任何固定阈值。英伟达的 Minerva 把显卡、网络、存储和任务的监控数据合成一张实时知识图，再用机器学习模型找出和同类相比异常的设备。之后沿知识图查哪些告警共享同一条依赖路径（比如同一台交换机连着的节点上跑的同一个任务），把它们合并成一个事件。按拓扑关联告警，比逐条看阈值更快找到根因。一个案例里 81 条告警被合并为 1 个事件，估计挽回约 54 小时集群可用时间。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.35 · &lt;a href=&quot;https://developer.nvidia.com/blog/how-nvidia-minerva-turns-telemetry-chaos-into-peak-gpu-yield/&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>C 2 KV: Compressed and Composable KV Cache Reuse for Efficient LLM Inference</title>
<link>https://paper-daily.com/papers/c-2-kv-compressed-composable-kv-cache-reuse-efficient-llm/</link>
<guid isPermaLink="false">paper-daily:zh:openalex:W7170093618</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;检索增强生成要把多篇检索到的文档拼进上下文，每次都从头算这些文档的 KV 缓存很贵，于是有方法把每篇文档的 KV 缓存存起来、用时直接拼接。但长文档的 KV 缓存很大，存储和读取本身成了瓶颈，直接压缩后再拼接，准确率又会明显下降。上海交大和阿里巴巴的这篇论文提出 C2KV，在冻结的原模型旁加一个轻量提取器：把几个可学习的压缩 token 接在文档后面一起读，只留下这几个 token 的 KV 当作这篇文档的缓存。缓存存的时候不带位置，拼接时再按新位置补上位置编码，所以能像积木一样任意组合。在长上下文下，推理最多快 17 倍，生成质量基本不变。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.30 · 深度解读 11 分钟 · Chuheng Du, Junyi Chen, Hanlin Tang, Kan Liu, Tao Lan · &lt;a href=&quot;https://doi.org/10.1145/3770855.3817715&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Where Rounding Happens Matters: Rounding-Location Alignment Stabilizes LLM Reinforcement Learning</title>
<link>https://paper-daily.com/papers/where-rounding-happens-matters-rounding-location-alignment/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32951</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;大模型强化学习通常用一套推理引擎生成回答、另一套框架训练，就算权重相同、都用 BF16，两边算出来的数也会有细微差别，本该是同策略的更新悄悄变成了异策略，训练可能突然崩掉。字节跳动 Seed 和北大的这篇论文发现，不必把两套系统整体对齐，只要在 RoPE、SwiGLU 和残差 RMSNorm 三处让训练端和推理端在同一个位置做舍入就够了：这几处的中间结果先保留 FP32，到输出时再转成 BF16。三处都对齐后，四个 Qwen 系列模型都不再崩溃，只对齐 RoPE 一处也够用。推理引擎、矩阵乘法和注意力内核以及训练目标都不用改。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.25 · 深度解读 10 分钟 · Yijing Ke, Tianle Cai, Ruosong Wang · &lt;a href=&quot;https://arxiv.org/abs/2610.32951&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Qdrant 1.20 - Full-Text Search Improvements</title>
<link>https://paper-daily.com/papers/qdrant-1-20-full-text-search-improvements/</link>
<guid isPermaLink="false">paper-daily:zh:blog_rss:qdrant_blog:https://qdrant.tech/blog/qdrant-1.20.x</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;以前在 Qdrant 里用 BM25 给关键词搜索结果排序，得先把每篇文档和每个查询都转成稀疏向量，平均文档长度还要自己维护，数据一变就不准。Qdrant 1.20 版直接在全文索引上算 BM25，所有统计量都从数据里自动算，不用再生成向量，参数可以按查询调整，也能和向量检索混合使用。新版还加了专门搜代码的分词器，getUserName 和 get_user_name 能互相匹配；另外新增 16 位的 TurboQuant 向量格式，和默认的 32 位浮点格式相比存储减半，在 12 个数据集上召回几乎不变。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.20 · 深度解读 12 分钟 · &lt;a href=&quot;https://qdrant.tech/blog/qdrant-1.20.x/&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>How NVIDIA Mission Control 2.5 Brings Autonomous Recovery to Kubernetes</title>
<link>https://paper-daily.com/2026-10-27/infra/#paper-blog_rss:nvidia_developer_blog:https:%2F%2Fdeveloper.nvidia.com%2Fblog%2Fhow-nvidia-mission-control-2-5-brings-autonomous-recovery-to-kubernetes</link>
<guid isPermaLink="false">paper-daily:zh:blog_rss:nvidia_developer_blog:https://developer.nvidia.com/blog/how-nvidia-mission-control-2-5-brings-autonomous-recovery-to-kubernetes</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;在几百个节点上连续跑几天甚至几周的大模型训练，硬件故障、软件报错和网络超时迟早会碰上，靠人工排查恢复会白白浪费大量算力。英伟达的集群管理软件 Mission Control 在 2.5 版把自动恢复引擎从 Slurm 扩展到 Kubernetes 上的训练任务。它先根据任务上下文判断故障类型，再决定是重试任务还是隔离机器：硬件出问题时，任务被重启或换到别的节点，同时坏节点被隔离并并行做诊断；临时性的软件错误只重试任务，不会误触发硬件维修。它还能提前发现性能退化的节点，在任务受影响前把它移出调度池。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.90 · &lt;a href=&quot;https://developer.nvidia.com/blog/how-nvidia-mission-control-2-5-brings-autonomous-recovery-to-kubernetes/&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>NgramRL: Accelerating RL Post-Training for Structured Generation via Rollout-Aware N-gram Speculative Decoding</title>
<link>https://paper-daily.com/papers/ngramrl-accelerating-rl-post-training-structured-generation/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32881</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;大模型强化学习后训练里，生成回答常常占到训练时间的七成以上。这篇论文注意到，同一道题在前几轮训练中生成过的回答很像这一轮要生成的内容，可以直接拿来当草稿。他们提出 NgramRL，每道题只用自己最近几次的回答建一个 n-gram 草稿表。生成时拿当前回答的最后几个词去表里查，把表中接在后面的内容当草稿，大模型一次验证多个 token，不需要额外的草稿模型，也不占 GPU 显存，生成结果的分布也不变。在推理和结构化生成任务上，缓存预热后大模型每次前向能确认 3.6 到 7.8 个 token，最多是 SuffixDecoding 的 2 倍，后者是用全局历史回答建后缀树查草稿的同类方法。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.90 · 深度解读 12 分钟 · Nilesh Prasad Pandey, Jangseon Park, Jason Kong, Onat Gungor, Tajana Rosing · &lt;a href=&quot;https://arxiv.org/abs/2610.32881&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>KnitTrans: Coordinated Trajectory Transfer for Effective and Efficient LLM Reinforcement Learning</title>
<link>https://paper-daily.com/2026-10-27/infra/#paper-arxiv:2610.32389</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32389</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;大模型强化学习把生成和训练拆到不同机器上时，生成好的轨迹往往要等凑齐一整批才能送去训练，训练用的模型版本和生成时差得更远。轨迹数据很大，搬运方式和训练取用方式对不上，又会重复搬运、白白等待。这篇论文提出 KnitTrans，先把已完成的轨迹放进早期小批次。一整批要按设定比例混合不同数据来源的轨迹，所以每放入一条前都检查剩下的名额还够不够把比例凑齐。同一道题生成的多条轨迹共用同一份图片等输入，一个小批次里这份输入只编码一次。版本差距最多降低 93%，多模态任务上搬运加训练最多快 5.8 倍。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.90 · Bangjun Xiao, Chiheng Lou, Xiaodong Ji, Xiangwei Deng, Yikai Zhao, Gang Huang, Hailin Zhang · &lt;a href=&quot;https://arxiv.org/abs/2610.32389&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Aquavit: Ascending Quantization for Communication-Efficient Vast-Scale Distributed Training</title>
<link>https://paper-daily.com/2026-10-27/infra/#paper-openalex:W7196947667</link>
<guid isPermaLink="false">paper-daily:zh:openalex:W7196947667</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;在大规模 GPU 集群上训练大模型，通信越来越成为瓶颈。ZeRO++ 这类框架用固定位数的量化压缩通信量，位数低时吞吐高，但量化噪声一直存在，训练后期难以收敛；位数高时精度好，速度却上不去。这篇论文提出一个假设：权重量化带来的噪声和随机梯度的噪声作用类似。他们从理论上证明，就像学习率要逐步衰减才能收敛，量化精度也要随训练逐步提高，才能在吞吐尽量高的同时保持训练稳定。据此做出的 Aquavit 在训练前期用低位数量化通信，后期再换成高位数。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.75 · Hong Huang, Jiaxun Ye, Jinhai Yang, Wenjiao Feng, Zonghang Li · &lt;a href=&quot;https://doi.org/10.1145/3770855.3818083&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Beyond Hotness: High-Resolution Memory Characterization of Cloud and LLM Workloads for Tiered Memory with ARM SPE</title>
<link>https://paper-daily.com/2026-10-27/infra/#paper-arxiv:2610.32711</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32711</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;数据分析和大模型应用的内存需求涨得很快，数据中心开始用多层内存，把冷数据放到便宜但较慢的内存上。但哪些数据该放哪一层，只看访问冷热往往不够准。这篇论文用 ARM 处理器的统计采样扩展（SPE）做高分辨率的内存访问分析，测了云计算基准和大模型应用里八个内存密集型负载。它把内存切成连续的区域，统计每个区域的访问延迟分布，延迟长的区域更值得放在快的一层；再看每个区域最长有多久没被访问，空闲越长，越适合挪到慢的一层，还评估了面向云负载的缓存层次是否有效。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.70 · Jie Ren, Ivy Peng · &lt;a href=&quot;https://arxiv.org/abs/2610.32711&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Accordion: Elastic-Depth Inference via Fixed-Prefix Layer Looping</title>
<link>https://paper-daily.com/2026-10-27/infra/#paper-arxiv:2610.32492</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32492</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;同一个大模型要服务不同的推理预算，为每种预算单独训练和维护一个模型成本很高。这篇论文提出 Accordion，一个混合专家模型，用同一套权重支持五档推理预算：模型中段一组连续的层是可循环的窗口，每档从窗口开头起把前若干层各连续执行两遍，预算越高，重复的层越多，最低一档就是不循环的原模型。预训练时每个小批次随机抽一档预算训练，不加额外的一致性约束。最高一档的大部分收益，中间一档只用一半的额外计算就能拿到。加深推理让 37 项任务的平均分提高 3.01 个百分点，中间一档拿到其中 89%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.65 · Yudong Zhang, Wei Ding, Kaili Zheng, Yuchen Ding, Zhenyu Zhang · &lt;a href=&quot;https://arxiv.org/abs/2610.32492&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Tile-Based Decompression in Compiled GPU Engines</title>
<link>https://paper-daily.com/2026-10-27/infra/#paper-arxiv:2610.32695</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32695</guid>
<pubDate>Tue, 27 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;GPU 做数据分析查询，只有数据装得进显存时才快，而显存被多个任务分着用，单位价格的容量这几代也没涨多少。压缩能省显存和带宽，但现有做法要么只适配一种执行方式，要么先把解压后的整列写回显存再查询。这篇论文在 GPU 查询编译引擎 Proteus 里把解压做成一个独立的算子，解压在片上共享内存里按块进行，和查询融合在同一个 GPU 内核里，解压后的数据不再写回显存。和 HeavyDB、Sirius 相比，查询时间相当，常驻显存最多降到四分之一，带宽占用最多降到六分之一。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.35 · Antonio Boffa, Ananya Gupta, Hamish Nicholson, Anastasia Ailamaki · &lt;a href=&quot;https://arxiv.org/abs/2610.32695&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>KVStream: Adaptive Parallel Storage Management for KV Caching in Large-Scale LLM Serving</title>
<link>https://paper-daily.com/papers/kvstream-adaptive-parallel-storage-management-kv-caching/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.31827</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;长上下文推理会反复用到同一段前缀，比如系统提示、整份文档、代码仓库和多轮会话历史。这些前缀的 KV cache 早已放不进 GPU 显存和主机内存，只能落到硬盘上，下次命中再读回来，读盘就卡在了每一步推理的关键路径上。现有系统只读节点本地的 NVMe，集群早已挂载的并行文件系统却几乎闲着。这篇论文做了 KVStream：每块 KV 在本地盘和共享存储各写一份，读的时候两边同时读，谁先读完谁接着领下一批。接进 LMCache 实测，离线吞吐最高是 LMCache 的 1.49 倍，突发流量下平均 TTFT 最多快 6.1 倍。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.30 · 深度解读 17 分钟 · Avinash Maurya, Jaiaid Mobin, Jie Ye, M. Mustafa Rafique, Franck Cappello, Bogdan Nicolae · &lt;a href=&quot;https://arxiv.org/abs/2610.31827&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Advancing Generative Recommendation Inference: our collaboration with NVIDIA on TensorRT LLM</title>
<link>https://paper-daily.com/papers/advancing-generative-recommendation-inference-our/</link>
<guid isPermaLink="false">paper-daily:zh:web:spotify-tensorrt-inference</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;Spotify 和 NVIDIA 把生成式播客推荐原本分散在两套推理引擎上的工作统一到 TensorRT-LLM 后，在 Qwen3-1.7B 上，束搜索的成本最多降低 54%，打分的成本最多降低 7%。Spotify 用 Semantic ID 做推荐，线上一个请求要用到三种推理：用束搜索生成候选、给一批现成候选逐个打分、把用户向量作为一个额外的 token 塞进 prompt。原来这三件事分散在 vLLM 和 SGLang 两套推理引擎里，vLLM 的束搜索又跑不满 GPU，只好退而用低档显卡。两家把缺的功能补进了 TensorRT-LLM，三件事统一到一个引擎里跑。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.20 · 深度解读 13 分钟 · &lt;a href=&quot;https://engineering.atspotify.com/2026/10/advancing-generative-recommendation-inference-our-collaboration-with-nvidia-on-tensorrt-llm&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>BiLoCo: Binary Low-Rank Corrections for Post-Training Quantization</title>
<link>https://paper-daily.com/papers/biloco-binary-low-rank-corrections-post-training/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32243</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;把大模型训练完直接量化到 FP4，在 Blackwell GPU 上能用原生的 FP4 矩阵乘提速，但精度会掉一截。常见补法 SVDQuant 是另存一个 BF16 的低秩修正项，它既占存储，又要和主计算抢同一批张量核心。这篇麻省理工的论文提出 BiLoCo，把修正项里的向量全部换成正负 1，修正只剩加减法，可以放到平时闲着的 CUDA 核心上，和矩阵乘同时跑。同样的存储能放下 16 倍的秩，困惑度持平或更好。单条请求时，整个算子只比纯 FP4 慢 6% 到 11%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.10 · 深度解读 11 分钟 · David Jin, Beshr IslamBouli, Tarushii Goel, Han Guo, Yoon Kim · &lt;a href=&quot;https://arxiv.org/abs/2610.32243&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>HyScale: Scaling Long-Context Training for Learned Sparse Attention</title>
<link>https://paper-daily.com/2026-10-26/infra/#paper-arxiv:2610.32057</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32057</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;学出来的稀疏注意力让每个查询只读最相关的 k 个历史 token，是百万 token 上下文的热门架构；但挑出这 k 个 token 的选择步骤要给之前所有 token 打分，训练时反而成了瓶颈，在 Megatron-LM 里训练长序列时它占了每步近一半的时间。HyScale 的关键观察是，选择的结果只是一组下标，不必存整张分数表，也不必在重算时再选一遍。它边打分边求出精确的前 k 个，反向重算时直接复用前向选出的下标。在 512 张 H20 GPU 上训练百万 token 序列，端到端比 Megatron-LM 快 2.07 倍。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.10 · Yangsheng Deng, Xinjing Huang, Yulong Wang, Yunzhuo Liu, Jun Hu, Shuyong Tang, Junchi Zeng, Mingji… · &lt;a href=&quot;https://arxiv.org/abs/2610.32057&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>GS-MoE: Training-Free MoE Compression via Groupwise Subspace Sharing and Pruning</title>
<link>https://paper-daily.com/papers/gs-moe-training-free-moe-compression-groupwise-subspace/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.32009</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;MoE 模型所有专家的参数都得放在显存里，部署时最先卡住的往往是显存。这篇论文提出 GS-MoE，不需要任何再训练，从两个方向同时压缩专家：一是把相似的专家分成组，组内共用一对输入和输出投影，每个专家只保留一个小的私有矩阵；二是在每个专家内部删掉那些能被其他神经元组合替代的中间神经元。在 DeepSeek-MoE-16B 上去掉 60% 的参数后，推理任务的平均准确率还保留了原模型的约 90%，对比方法 D2-MoE 只保留了 73%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.10 · 深度解读 12 分钟 · Carson Cary, Yukai Jin, Yihao Huang, Zhankai Ye, Fangyi Li, Ting Hua, Xin Liu, Shangqian Gao · &lt;a href=&quot;https://arxiv.org/abs/2610.32009&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Nested Sparsity for Scalable Pretraining and Continual Learning</title>
<link>https://paper-daily.com/2026-10-26/infra/#paper-arxiv:2610.31818</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.31818</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;MoE 只把前馈层做成稀疏的，注意力层仍是所有 token 共用一套参数、看完整的上下文。这篇论文提出 Nestor，把注意力也拆成几组参数各自独立的注意力模块，称为列：路由器给每个 token 选出其中几列，每列只在分到同一列的 token 之间算注意力，列里再各挂一组专家。预训练的扩展规律实验显示，要达到 Nestor 的验证损失，同样稀疏度的普通 MoE 需要多花 13% 到 29% 的训练算力，模型变大后这个差距没有缩小。拿去新领域继续训练时，它学到的和 MoE 差不多，忘掉的更少。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.70 · Tianzhe Chu, Druv Pai, Yi Ma · &lt;a href=&quot;https://arxiv.org/abs/2610.31818&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Efficient Omni-modal Large Language Model Inference via Per-Query Modality Selection</title>
<link>https://paper-daily.com/2026-10-26/infra/#paper-arxiv:2610.31768</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.31768</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;全模态大模型能同时读文字、听音频、看视频，但视频很贵：在 WorldSense 基准上，只给文字和音频时每题约三千个输入 token，加上视频就涨到约四万。很多问题其实不需要看视频。这篇论文不改模型，只决定每个问题要输入哪些模态，把这个选择当作准确率和成本之间的权衡来学：选择器是一个线性层，只看问题文字的 BGE-M3 向量，决定要不要加视频；训练时的目标是答错的损失加上按权重计入的推理成本。在 Qwen2.5-Omni 上，它的准确率持平或超过把全部模态都输入的做法，输入 token 只要约 41%，延迟只要约 39%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.65 · Shuqi Liu, Yuzhou Cao, Luke Ong · &lt;a href=&quot;https://arxiv.org/abs/2610.31768&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Tensormesh Launches Tensormesh Platform to Cut LLM Inference Costs by Reusing KV Cache at Enterprise Scale</title>
<link>https://paper-daily.com/2026-10-26/infra/#paper-web:tensormesh-platform-20261014</link>
<guid isPermaLink="false">paper-daily:zh:web:tensormesh-platform-20261014</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;大模型推理会反复重算同一段上下文，既浪费 GPU 时间，又拖慢首个 token 的返回。开源 KV cache 项目 LMCache 的团队 Tensormesh 为此发布了企业版平台 Tensormesh Platform，把 KV cache 当成一层需要管理的数据来运营：在显存、主机内存和存储之间自动分层缓存，既复用提示开头的前缀，也能用 CacheBlend 复用提示中间的片段，适合检索增强生成；集群里的机器还能直接互相拉取 KV cache。平台部署在企业自己的 Kubernetes 集群上，带数据安全、实时监控、高可用、缓存策略和多租户隔离等生产功能。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.45 · &lt;a href=&quot;https://tensormesh.ai/newsroom/tensormesh-platform-launch-llm-inference-kv-cache/&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Kolibri: A Sovereign European Model on the Pareto Frontier</title>
<link>https://paper-daily.com/2026-10-26/infra/#paper-arxiv:2610.31945</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.31945</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;欧洲的公共部门、工业和航天等受监管行业，需要能自己掌控、德语又好的开源大模型。Kolibri 是一个英德双语的混合专家模型，总参数 781 亿，每个 token 只激活约 35 亿，以开源许可公开权重。团队从数据、架构、训练设施到后训练和评测全流程自己掌控，还自建管线从网上整理并合成了 2 万亿以上的德语 token，让德语在训练数据里占到相当比例。在报告比较的开源模型里，它在英语和德语上都处在质量和推理成本的最优边界上，也就是同等成本下质量最好的一档。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 3.35 · Aleph Alpha, :, Moritz Althaus, Artur Baranowski, Michael Barlow, Fabien C. Y. Benureau, Felix Berk… · &lt;a href=&quot;https://arxiv.org/abs/2610.31945&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>人工智能平台 PAI：模型蒸馏（ModelDistill）</title>
<link>https://paper-daily.com/2026-10-26/infra/#paper-web:pai-modeldistill</link>
<guid isPermaLink="false">paper-daily:zh:web:pai-modeldistill</guid>
<pubDate>Mon, 26 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;想把大模型的能力迁到便宜的小模型上，又不想自己搭流程，阿里云人工智能平台 PAI 的模型蒸馏服务 ModelDistill 把这件事做成了不用写代码的托管服务。它用黑盒蒸馏：先让教师模型生成高质量的训练数据，再用这些数据对学生模型做 SFT，学生模型可选 LoRA、QLoRA 或全参微调。除了通用模板，还有指令跟随、思维链推理、智能体工具调用、文生视频和代码智能体等场景模板。文档也提醒，蒸馏一定会损失一些效果，简单的分类和文本匹配任务直接微调小模型可能更划算。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 2.90 · &lt;a href=&quot;https://www.alibabacloud.com/help/zh/pai/model-distillation-overview&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>ATTUNE: Agentic Throughput Tuning for LLM Training</title>
<link>https://paper-daily.com/papers/attune-agentic-throughput-tuning-llm-training/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.17528</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;同一个大模型换一种 GPU 或换一个框架版本，原来最快的训练配方往往不再最快，配方要定的是模型怎么拆到多张 GPU 上、用哪些底层计算程序、GPU 之间的数据传输怎么和计算同时进行。ATTUNE 让一个能写代码、跑命令的智能体来调配方，给它一份能跑通的配方和一笔 GPU 小时预算，它自己反复试、自己分析瓶颈。但这篇论文真正的看点在智能体之外，一道由固定代码执行、智能体改不了的正确性闸门：模型、数据、每步处理多少条、数值精度都锁定不变，凡是会悄悄改变训练内容的改动，比如丢掉超额的训练词，在启动前就被拒绝。三个模型的微调任务换上调好的配方后，训练速度平均提高到原来的 1.7 倍，最多 3.9 倍。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.45 · 深度解读 12 分钟 · Leo Fan, Hongyang Wang, Wenbo Chen, Jingguo Liu, Xian Li, Xuan Wang, Ruochen Wen, Yiming Yan, Hao W… · &lt;a href=&quot;https://arxiv.org/abs/2610.17528&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>uGDS: A User-Space Development Kit for High-Performance GPU Direct Storage</title>
<link>https://paper-daily.com/papers/ugds-user-space-development-kit-high-performance-gpu-direct/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.30868</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;用 NVIDIA 的 GDS 把数据从 SSD 直接读进 GPU 显存时，作者实测发现，异步读取 99.6% 的时间都卡在提交请求这一步。大模型推理服务会把算过的 KV cache 存到 SSD 上，下次遇到同样开头的请求就直接读回来，不用重算，这一步的速度直接影响首字延迟。uGDS 把指挥 SSD 干活这件事从操作系统内核搬到普通程序里来做。数据照样从 SSD 直达 GPU，变的是谁来下命令。uGDS 批量读的速度最高是 GDS 的 12 倍；接进开源缓存系统后，长提示的首字延迟中位数从 1.9 秒降到 0.7 秒。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.40 · 深度解读 11 分钟 · Jing Wei, Guanyi Chen, Qi Chen, Chuyu Zhang, Zheng Zhou, Chutian Wang, Jian Zhang · &lt;a href=&quot;https://arxiv.org/abs/2610.30868&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Cache Engineering for Agents</title>
<link>https://paper-daily.com/papers/cache-engineering-agents/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.28577</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;智能体和搜索、网页、代码执行等工具来回几百轮时，每一轮模型都要把之前所有内容的 KV cache 重新读一遍，读这些旧缓存占了总调用费用的 82.4%。常见的省钱办法是删掉或摘要旧消息，但只要改动了前面的文字，后面所有缓存都作废，得从改动处重新算一遍。作者换个层面来做：文字记录一个字不动，只在缓存里把选中的部分丢掉，留下的部分原样接着用。一个简单的策略只保留最近 12 次工具返回的缓存，和常用的到长度上限就摘要相比，在四个智能体测试上平均通过率高 1.7 个百分点，平均费用低 27.7%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.30 · 深度解读 10 分钟 · Tianyu Fu, Ruoxi Wang, Zihan Min, Zhongqi Ren, Zhihao Li, Tengxuan Liu, Shengxu Mu, Hanling Zhang,… · &lt;a href=&quot;https://arxiv.org/abs/2610.28577&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Stratified Sparse Attention: Reducing the Sparse-to-Dense Gap at Extreme Sparsity</title>
<link>https://paper-daily.com/papers/stratified-sparse-attention-reducing-sparse-to-dense-gap/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.28441</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;长上下文解码时，每生成一个 token 都要把整个 KV cache 从 HBM 读一遍，所以上下文越长，注意力越慢。稀疏注意力只读其中一小部分 token，但压到 50 倍稀疏时，现有方法和稠密注意力差得很远。SSA 的思路是分数高的 token 一定保留，剩下的长尾按代理分数抽样，抽中的 token 再按被抽中的概率放大权重。代理分数是用压缩过的键快速估出的注意力分数，经 softmax 换成概率。所有概率乘上同一个倍数，乘完达到一的 token 直接保留，倍数要让保留的个数加上其余 token 乘完的概率之和正好等于预算。剩下的额度按概率有放回地抽，重复抽中的只算一次，权重除以它至少被抽中一次的概率。同样稀疏度下，Qwen3.5-9B 做 AIME 2025，SSA 得 59.8，PQCache 只有 36.7。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.30 · 深度解读 14 分钟 · Sahil Joshi, Prithvi Dixit, Aryan Katiyar, Agniva Chowdhury, Joseph E. Gonzalez, Anshumali Shrivast… · &lt;a href=&quot;https://arxiv.org/abs/2610.28441&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>RACE: RoPE-Aligned Attention Compression Based on Query-Key Activation Energies</title>
<link>https://paper-daily.com/papers/race-rope-aligned-attention-compression-based-query-key/</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.28385</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;大模型处理长文本时存在显存里的 KV cache 越来越大，压缩它的一个方向是把每个词存的向量变短，但已有方法大多只省了存储：存的时候是短向量，真到计算时又得先还原成原来的长度，计算量反而暴涨。RACE 找到了一种不用还原的变短办法：位置编码把向量里每两个相邻的数组成一对一起旋转，只要整对保留，短向量照样能直接旋转；保留哪些对，按一小批文本上查询和键在这一对上的数值平方和挑最大的，再把这个选择直接写进模型权重。在 Llama-3.2-3B 上，向量缩短一半、输入 25.6 万个 token 时，整体吞吐提高到 1.79 倍，首字延迟降 43.2%。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.30 · 深度解读 10 分钟 · Irene Tenison, Abdulrahman Alabdulkareem, Daniel Karl I. Weidele, Nima Dehmamy, Dan Gutfreund · &lt;a href=&quot;https://arxiv.org/abs/2610.28385&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Gandalf: Flash Shall Not Die! Increasing Flash Storage Lifetime for KV Cache Offloading in LLM Serving</title>
<link>https://paper-daily.com/2026-10-25/infra/#paper-arxiv:2610.30791</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.30791</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;把注意力缓存放到 SSD 上，除了命中率，还得算写入量，因为 SSD 写多了会坏。按访问记录决定写不写会损失命中率，作者改按缓存来自哪种注意力层来定：线性注意力的状态很快就用完，留在内存里；完整注意力的缓存后面会被反复用到，才写进 SSD。回放一段 Claude Code 的使用记录，写入量从 153TB 降到 92TB，命中率几乎不变；在所有测试记录上，SSD 预计寿命平均延长到 7.3 倍。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.15 · Maharani A. P. Irawan, Kuntai Du, Jiayi Yao, Dongjoo Seo, Yuyang Huang, Haryadi S. Gunawi, Junchen… · &lt;a href=&quot;https://arxiv.org/abs/2610.30791&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Lychee: Certified Screening of Inverted Lists for High-Recall Vector Search</title>
<link>https://paper-daily.com/2026-10-25/infra/#paper-arxiv:2610.30697</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.30697</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;召回率要接近 100% 时，倒排索引要多搜很多列表、逐个读全精度向量；先用一个保证不会估大的距离下界排除大多数向量，只读剩下的少数，就能在结果完全不变的前提下快很多。每个向量事先投影到数据集方差最大的若干个方向上，再补一维记下投影丢掉部分的长度，这些短坐标上的距离一定不超过真实距离。上限取自所搜列表里每隔固定间隔存的一批锚点向量：它们本身就是候选，查询到它们的真实距离里第 k 小的，一定不小于真正第 k 近邻的距离。下界已超过上限的向量不读也能排除，剩下的按下界从小到大读原向量核对。召回率相同时，它比 IVF-Flat 快 9.7 到 117 倍。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.15 · Dongfang Zhao · &lt;a href=&quot;https://arxiv.org/abs/2610.30697&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Scaling NVIDIA TensorRT Performance Optimization Beyond a Single Build Route with the Global Performance Tuner, Part 2</title>
<link>https://paper-daily.com/2026-10-25/infra/#paper-web:nvidia-tensorrt-tuner-part-2</link>
<guid isPermaLink="false">paper-daily:zh:web:nvidia-tensorrt-tuner-part-2</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;用 TensorRT 编译模型时，算子怎么合并、哪几处做量化，最好的选法取决于模型、张量形状和 GPU，单看某一步优化有效，说明不了整个模型会更快。比如可以把几个互不依赖、并排的算子合成一个 GPU 内核，也可以把前后相连的算子合成一个。英伟达的做法是把这些选项变成可以组合的开关，逐个编出引擎实测，排除精度不达标的，留下最快的。在十个工作负载上，这样调出的引擎比默认编译快 1.14 到 1.63 倍，说明默认编译往往还有不少提速空间。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.10 · Jian Hu, Lin Chai · &lt;a href=&quot;https://developer.nvidia.com/blog/scaling-nvidia-tensorrt-performance-optimization-beyond-a-single-build-route-with-the-global-performance-tuner-part-2/&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>When PTQ Calibration Helps or Hurts: Dose-Driven Collapse and Validation-Gated Abstention in Quantized Text Embedders</title>
<link>https://paper-daily.com/2026-10-25/infra/#paper-arxiv:2610.27397</link>
<guid isPermaLink="false">paper-daily:zh:arxiv:2610.27397</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;文本向量模型压到 4 位后再做校准，结果可能变好，也可能直接毁掉模型。在 EmbeddingGemma 上，只改学习率一项，排序指标 NDCG@10 就从提高 1.47 个点变成暴跌 71.53 个点。崩不崩，主要看校准把模型从原来的状态推开了多远。作者的规则是每次校准都先在留出的查询上检验，统计上确实更好才用。在实验里这条规则从没选中过有害的结果，代价是错过了少数有益的更新。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.05 · Hyojung Han, Ryangkyung Kang, Youngeun Kim, Seung-Hun Jeon · &lt;a href=&quot;https://arxiv.org/abs/2610.27397&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
<item>
<title>Scaling NVIDIA TensorRT Performance Optimization Beyond a Single Build Route with the Global Performance Tuner, Part 1</title>
<link>https://paper-daily.com/2026-10-25/infra/#paper-web:nvidia-tensorrt-tuner-part-1</link>
<guid isPermaLink="false">paper-daily:zh:web:nvidia-tensorrt-tuner-part-1</guid>
<pubDate>Sun, 25 Oct 2026 08:00:00 +0800</pubDate>
<category>系统与索引</category>
<description>&lt;p&gt;英伟达 TensorRT 全局调优器系列的上篇，只讲思路：编译时不再走一条固定路线，而是试多种编译配置，逐个实测整个引擎，选精度达标里最快的。文中没有实测数据，加速效果见下篇。&lt;/p&gt;&lt;p&gt;系统与索引 · 评分 4.00 · Jian Hu, Lin Chai · &lt;a href=&quot;https://developer.nvidia.com/blog/scaling-nvidia-tensorrt-performance-optimization-beyond-a-single-build-route-with-the-global-performance-tuner-part-1/&quot;&gt;原文&lt;/a&gt;&lt;/p&gt;</description>
</item>
</channel>
</rss>
