01
模型—硬件协同设计
NVIDIA Technical Blog
·
2026-07-31
NVIDIA 用 GEMM shape 解析和 FP8 Attention/KV cache 实测拆解 dense attention：prefill 具有大 GEMM-M，主要受计算与 softmax 约束；逐 token decode 的 GEMM-M 很小，通常受 HBM 读取 KV cache 限制，而 speculative decoding 又可能把 decode 推回计算受限。文章显示在其 DeepSeek-R1 测量中，Attention 占 prefill 时间的比例随上下文从 4K 增至 128K，由 18% 升至 85%，并据此讨论 GQA group size、head dimension、sequence length 以及跨 GPU 并行应如何共同取舍。
为什么值得读： 当 Attention 主导长上下文成本后，serving 团队不能只在模型冻结后换 kernel；Q/KV head 比例与 head dimension 会同时改变 KV 容量、matmul shape、并行效率和 interactivity。数字来自 NVIDIA 的 FP8 kernel 与特定模型分析，结论应在目标 GPU、batch、精度和 TP/CP 配置上复测。
02
开源发布
FlashInfer
·
2026-07-31
FlashInfer 0.6.16 为 MoEEpLayer 加入 deep_gemm_mega、nvfp4_cutedsl 与 mxfp8_cutedsl 三类 MegaMoE backend，在 Blackwell SM100+、NVSHMEM 路径中用单个 symmetric-memory kernel 融合 expert-parallel 通信和本地 MoE。项目方在 GB200、EP=4、DeepSeek-V3-like geometry 的微基准中自报，调优后的 CuTe-DSL NVFP4 backend 在每 rank 8192 tokens 时吞吐最高为 deep_gemm_mega 的 1.89 倍；版本还扩展 Blackwell RTX/DGX Spark 的 MiniMax sparse attention、XQA speculative decode，并加入 CuTe-DSL 落盘 JIT cache。
为什么值得读： MoE 性能越来越取决于通信注入、local expert GEMM、combine 与量化能否共享同一执行计划，而不是单独把某个 GEMM 做快。1.89 倍属于特定 GB200 微基准；采用前要核对 SM 架构、NVSHMEM、NVFP4/MXFP8 格式、上层框架 pin，以及 NIXL-EP 或 NCCL-EP 路径。
03
推理控制面
Together AI
·
2026-07-31
Together 的 Dedicated Inference Autoscaler 可按 in-flight requests、TTFT、GPU utilization 或 token throughput 设置目标，并以 ceil(N × observed/target) 计算期望副本数，再通过 scale-up/scale-down timing windows 抑制抖动并限制副本上下界。文章指出 GPU 利用率衡量的是算术忙碌程度，不一定能反映队列压力；模型副本还要经历节点放置、权重下载、VRAM 加载与 warmup，因此扩容必须在突发流量真正到达前响应领先信号。
为什么值得读： 传统 Web HPA 的 CPU/GPU 百分比很容易错过 continuous batching 的非线性饱和点；推理平台更需要把队列、TTFT、throughput 和 cold-start lead time 放进同一闭环。文章与实验来自 Together 自有平台，策略仍需结合模型大小、缓存命中、流量突发形态和副本启动分布调参。
04
部署指南
AWS Machine Learning Blog
·
2026-07-30
AWS 给出 Kimi K3 在 SageMaker HyperPod 与 Amazon EKS 上的部署路径。文章核验的模型边界为 2.8T 总参数、896 个专家、每 token 激活 16 个专家约 104B 参数、1M context，开放权重采用 MXFP4；由于主线 vLLM 尚在合并支持，文中使用 vllm/vllm-openai:kimi-k3 的 day-0 镜像，并围绕大模型权重、MoE 并行和集群编排配置服务。
为什么值得读： 超大稀疏模型的可部署性取决于权重格式、镜像 pin、专家/张量并行、网络拓扑与控制面的组合，而不是“有足够显存”这一项。文章中的模型规模与效率描述来自模型方/AWS，且 day-0 镜像尚未进入常规 vLLM 发布，生产采用前应检查 commit、镜像供应链、故障恢复与多节点网络。
05
预发布版本
TensorRT-LLM
·
2026-07-31
TensorRT-LLM 1.3.0rc23 新增 runtime KV cache compression、per-conversation KV block reuse、MiniMax-M3 sparse attention 与 disaggregated serving、fine-grained context chunk 管理，以及更多 MTP/DSpark 路径；同时修复 host tier sizing、KV 约束估算、DSpark rolling-window slot collision、NIXL decode receiver 与 MPI teardown 等问题。Release 明确列出 DeepSeek-V4-Pro 在 GB300 分离式部署可能挂起、部分 NVFP4/MTP 组合崩溃或 OOM 等已知问题。
为什么值得读： 该 RC 把 KV 状态管理从单机缓存扩展到压缩、会话复用、host tier 与跨节点传输，也说明这些路径仍处于快速变化期。它不是稳定版；生产团队应按模型、GPU、attention backend、MTP、PP/TP/EP 和 disaggregation 组合逐项核对 known issues。
06
协议与 Agent 基础设施
AWS / Amazon Bedrock AgentCore
·
2026-07-28
MCP 2026-07-28 移除 initialize/initialized handshake 与 Mcp-Session-Id；每次请求携带协议版本、客户端信息和 capabilities，可被路由到任意服务实例，不再要求负载均衡 sticky session 或共享 session store。新版本还用 Mcp-Method/Mcp-Name 暴露请求意图，加入缓存 freshness metadata 与 W3C Trace Context，并建立 extensions 治理和更贴近 OAuth 2.0/OpenID Connect 的授权规范；AgentCore Gateway 可同时公布多个协议版本，按请求选择。
为什么值得读： 工具协议从有状态长连接转为自包含请求后，Agent gateway 可以直接复用标准 HTTP 的水平扩展、限流、缓存、监控和 OpenTelemetry 设施。但这是包含不兼容变更的大版本，依赖旧 session、logging/setLevel、特定错误码或 server-initiated interactions 的客户端需要先审计，再做双版本渐进迁移。