今日场景今天 8 篇里有 6 篇讲大模型推理服务。llm-d 1.0 用前缀缓存感知路由和预填充与解码分离来应对 agent 流量。FastLLM 和 Superfluid 是能把权重放到 CPU 内存甚至磁盘上的本地推理服务器。戴尔比较了张量并行和流水线并行的延迟取舍，亚马逊的 TorchNeuron 让 PyTorch 代码改一行配置就能跑在 Trainium 上。另外两篇是向量检索基础设施，SweepANN 把五亿个分子向量常驻 GPU 显存直接扫描，Tair 则在 Redis 里内置了向量引擎。 — 评分 8 篇，入选 8 篇，分数 3.00 – 4.15
本期目录 · 8 篇
- 01llm-d 1.0, an open source stack for distributed inference
- 02SweepANN: A GPU-Accelerated Large-K Approximate Vector Search for Drug Discovery
- 03llm-d 1.0 hardens open-source AI inference for production
- 04Amazon targets Trainium gains with new TorchNeuron developer tool
- 05FastLLM: a C++ LLM inference engine
- 06向量检索数据库选型：Tair（Redis 企业版）内置向量引擎方案
- 07Scaling LLM Inference via Parallelism: Throughput-Latency Trade-off
- 08Introducing Superfluid: the local-AI native LLM server for multi-agent inference
LEAD STORY · 今日必读 ·
Google现在越来越多的推理请求来自多步智能体和强化学习的 rollout，它们会共享很长的前缀、成批突发到达。把这类流量放在普通的轮询负载均衡后面，各个副本会重复计算同样的提示，显存里堆满重复的 KV cache。llm-d 1.0 是一个跑在 Kubernetes 上的开源分布式推理栈，它把一组模型服务器组织成一个统一的服务池。路由器知道每段缓存前缀在哪些副本上，会把同一会话的请求送回去；显存不够时，KV cache 会被挪到主机内存和存储。在 Ironwood TPU 的编码智能体负载上，首 token 延迟中位数下降 85% 以上，总吞吐是普通 Kubernetes Service 的 2.4 倍。这些收益大多不靠更快的算子，靠的是不再重复计算已经算过的前缀。
今日其余入选
7 篇 · 按综合排名
02 3.80
药物筛选要为每个蛋白口袋从几亿个分子里取回几十万个最匹配的候选，这种搜索用整库扫描加一条分数线比建近似索引更合适。SweepANN 把压缩后的分子向量分到几块 GPU 上，一次矩阵乘法就给一整批口袋打完一个数据块的分。分数线这样定：每块 GPU 先扫几个样本块，为每个口袋留下和要返回数量一样多的最高分分子，各 GPU 合并后再留同样多个，其中最低分就是分数线，只发回各 GPU 一次。之后只有高于分数线的分子写进固定容量的缓冲区，哪批口袋溢出，就整批重新精确扫描。用四块 Blackwell GPU 为两万多个口袋各取 50 万个候选，库装进显存后约 61 秒完成，平均召回率是精确搜索的 99.6%。
03 3.35
IBM自己部署开源大模型给 agent 用，成本能不能比买托管服务低，关键看能不能复用缓存，因为 agent 的请求大量共用同一段上下文。llm-d 是 Google、IBM 和 Red Hat 合作的开源推理栈，刚发布正式版。它把带着同一段上下文的请求送到已经存着这段上下文的服务器，并让缓存在 GPU、CPU 和存储之间流动。IBM 和 Red Hat 同时跑 3,000 个写代码的 agent，成本比托管服务低 5 到 10 倍。另一个测试里，可复用的缓存有 97% 真的复用上了。
04 3.35
Amazon换到新的 AI 芯片，最大的成本往往不在硬件，而在改写和重新验证代码。Amazon 的新工具 TorchNeuron 让现有的 PyTorch 代码只改一行配置，就能跑在自家的 Trainium 芯片上。Amazon 用同一个训练脚本分别在常规硬件和 Trainium 上跑，两边的学习过程表现一致，说明换芯片没有改变训练结果。语音公司 Cartesia 说，他们的推理流程几乎没改代码就跑起来了，只给几个决定延迟的关键层手写了算子。Amazon 还在把相关改动提交回 PyTorch 官方代码库。
05 3.20
HHysen Labs
显存不够也想跑大 MoE 模型时，FastLLM 这个 C++ 推理引擎允许把权重按层分到 GPU 显存、CPU 内存甚至磁盘上，但它宣传的速度目前没有基准数据可以核对。仓库介绍说，它能在任何显存 10 GB 以上的 GPU 上跑不做裁剪的 DeepSeek 模型，没写是哪一版；在双路服务器上，全精度、一次只处理一个请求时每秒生成 20 个 token。它不依赖 PyTorch，直接读取 Hugging Face 上的权重，提供和 OpenAI、Anthropic 兼容的接口。评测文章指出，仓库里没有发布版本，也没有可以核对这些数字的基准文件。它适合的场景很窄，主要是内存或固态硬盘比显存大得多、又要跑 MoE 模型的机器。
06 3.20
Alibaba阿里云的一篇选型文章主张，RAG 应用如果已经用 Redis 做缓存，就不必再单独部署 Milvus 或 Qdrant，直接用 Tair（Redis 企业版）内置的 TairVector 向量引擎。它支持两种索引，HNSW 图索引查得快但结果是近似的，FLAT 则逐条比对全部向量、结果精确，一次查询可以同时做向量检索、BM25 全文检索和标签过滤，数据全放在内存里，索引实时更新。文中称单节点能到 51 万 QPS，指的是性能增强型实例。文中一个电商搜索团队的案例称，换成 Tair 后向量检索延迟从 15 ms 降到 3 ms。文章也承认，十亿级以上的纯向量检索还是专用向量数据库更合适。已经在用 Redis 的团队可以少维护一套向量库，数据特别大时仍要看专用方案。
07 3.00
大模型推理该用流水线并行还是张量并行？这篇的结论是，要看首 token 的时限有多紧，不能只看吞吐。作者在 H200 上测了各种并行配置，用吞吐乘以按时出首 token 的请求比例，算出真正有用的吞吐。时限很紧（5 到 10 秒）时，把各层按顺序分给不同 GPU 的流水线并行最好；时限放宽后，优势转向把每一层拆到多块 GPU 上一起算的张量并行。输入越长，流水线为主的配置越占优。
08 3.05
BBaseCompute
本地一台机器上同时跑多个 agent 时，人在聊天框里等的那个请求常被排在批处理后面；Superfluid 让交互请求在下一个调度周期就插队，发布博客的演示里回答快了约 30 倍。演示是在一台 Mac 上，八个 agent 正在处理长文档，这时用户问了一个问题，Superfluid 0.36 秒给出回答，同一个模型用 llama-server 要等 10 秒以上。llama-server 这类服务器为吞吐设计，新来的聊天请求要排在正在跑的批处理后面，Superfluid 则让 agent 的任务稍后继续。共用同一段系统提示的请求，它也只做一次预填充。这些数字来自发布博客里的演示，不是独立的基准测试。本地多个 agent 共用一台机器时，调度要优先照顾人在等的那个请求。
其他赛道今日
点击切换