在 CoreWeave ($CRWV) 2026 年 Q2 财报电话会议中，管理层特别提到有客户签署了延伸至 2029 年的 A100 租赁合同。 由于Michael Burry等空头认为很多大厂强行延长了GPU的折旧时间，属于财务粉饰；也因此很多人认为这狠狠地打了Michael Burry的脸。 打不打脸另说，但这至少说明英伟达的GPU硬件的使用寿命会比大家想象的要长很多。传统印象中硬件很快就会过时，但英伟达 $NVDA在软件生态方面的改进，对旧硬件的续命与价值挖掘是有突出贡献的。 英伟达并非仅靠更新硬件（如 Hopper/Blackwell）来提升性能，其全栈软件生态的持续演进大幅延长了 A100（Ampere 架构）的技术生命周期与投资回报率（ROI）： 1. 推理优化框架（TensorRT-LLM / vLLM 兼容）大模型推理算力释放：英伟达推出的 TensorRT-LLM 以及对开源社区（如 vLLM）的深层适配，引入了如 PagedAttention、Chunked Prefill（分块预填充）、投机采样（Speculative Decoding） 等高级优化技术。吞吐量倍增：通过纯软件层的内存管理与 Kernel 融合优化，A100 在运行主流开源大语言模型（如 Llama 3 系列、DeepSeek 系列）时的推理吞吐量和延迟表现，比硬件发布初期提升了数倍，使其非常适合承担性价比极高的中量级推理任务。 2. FlashAttention 与算子级（Kernel）优化突破 HBM2e 带宽瓶颈：A100 拥有 80GB HBM2e 显存和 2 TB/s 带宽。随着 FlashAttention-2 及后期针对 Ampere 架构算子的持续重构，GPU 在注意力机制计算时的显存读写开销大幅降低，使得计算单元（Tensor Cores）利用率接近极限。 TF32 与 INT8/FP16 持续调优：英伟达在 CUDA 代码库中持续完善 Ampere 专有的 Tensor Float 32 (TF32) 及混合精度计算吞吐，免去了企业大幅修改底层代码的麻烦。 3. 多实例 GPU（MIG）与细粒度切分资源弹性复用：A100 硬件上支持将单卡切分为最多 7 个独立的 MIG（Multi-Instance GPU）实例。 云原生调度优化：结合英伟达 Triton Inference Server 和云厂商（如 CoreWeave）的编排软件，企业可以将 80GB 的 A100 精细化切分给轻量级 AI 服务（如 Embedding 模型、小参数微调、RAG 向量检索等），实现极高的资源利用率和单位成本效益。 4. CUDA 向后兼容性与生态长寿命支持（LTS）版本不脱节：英伟达最新的 CUDA 版本（如 CUDA 12.x+）和底层驱动保持着对 Ampere 架构的完整原生支持与功能适配。 NGC 优化容器：英伟达在 NGC（NVIDIA GPU Cloud）上持续更新针对 A100 优化的深度学习框架容器（PyTorch、TensorFlow、NeMo 等），确保用户无需更改底层架构即可直接享受到软件栈带来的性能增益。 总结与行业视角英伟达的“软硬一体”策略使硬件随着时间推移因软件更新而变快（Software-Driven Performance Upgrades）：集群成熟度（已部署、即开即用、供电稳定） + 软件持续优化（降低推理 Token 成本） = 旧卡仍具备高经济价值。对于很多企业而言，训练超级大模型可能需要 Hopper 或 Blackwell，但在长尾推理、中小型模型微调、RAG 和数据预处理等场景下，经过软件高度优化后的 A100 提供了极佳的成本效益比，因此租赁合同顺理成章地延长到了 2029 年。

一台 GB300 NVL72： → 72 颗 GB300 (Blackwell Ultra) GPU + 36 颗 Grace CPU。 → 单卡显存：GB300 288 GB HBM3e → 整机柜总显存：72 × 288 GB ≈ 20.7 TB → NVLink 总带宽约 130 TB/s → 全机柜通过 NVLink 5 连成统一内存池，可以视为一张拥有 20TB 显存的“超大 GPU”。 DeepSeek-V4-Flash-0731 核心规格： →304B 参数（0731 仓库包含 DSpark speculative decoding 模块） → 基础模型 284B → 13B activated → 1M context → 官方权重为 FP8 + FP4 Mixed 加油 OpenCode !

推荐这篇文章，Together AI 的 ThunderAgent（ICML 2026 Spotlight）。 把 agent 工作流当成一个"程序"来调度，而非一系列无关的请求——单节点吞吐翻倍，8 节点近线性扩展。 Together AI 在 7 月 29 日发布了 ThunderAgent——一个面向 agentic 推理的高吞吐调度系统。ICML 2026 Spotlight 论文。核心贡献：把 agent workflow 抽象为"程序"而非"一系列不相关的请求"。 问题：KV Cache Thrashing Agent 工作流在两个阶段之间交替：GPU 密集的推理阶段和 GPU 空闲的等待工具返回阶段。当数百个 agent 并发运行时，各自的 KV cache 在每轮不断增长，竞争有限的 GPU 内存。 传统推理引擎（vLLM、SGLang、TensorRT-LLM）按请求级别调度——agent A 暂停等待工具调用时，它的 KV cache 被 LRU 淘汰腾出空间给 agent B 的 prefill。当 A 的工具返回，引擎必须从头重算 A 的整段对话历史，这又淘汰了 C 的 cache。高并发下，这种淘汰和重算的级联反应导致严重的吞吐量和延迟退化——论文称之为 KV cache thrashing。 能通过加 GPU 节点解决吗？不完全。现有多节点路由器（如 SGLang Gateway）把每个 agent 钉在固定节点上以保留 cache 局部性——但 agent 的上下文长度不可预测增长，某些节点被赋予长上下文 agent 导致内存耗尽，其他节点闲置。 能通过 KV cache offloading 解决吗？也解决不了。LMCache 和 HiCache 把 KV cache 卸载到 CPU 内存或磁盘，扩大了总容量但只是延迟 thrasthing。当并发 agent 的工作集超过所有存储层级时，淘汰恢复，同一个恶性循环重现。 ThunderAgent 的解法 ThunderAgent 在 agentic 客户端和推理后端之间插入一个轻量调度层。它将每个 agent 工作流抽象为一个可调度程序（program），追踪其执行阶段、KV cache 占用和节点位置。 Program-level admission control：监控每个节点的内存压力，选择性暂停低优先级工作流，减少竞争 cache 的程序数量。当被暂停的工作流准备恢复时，通过全局等待队列路由到容量最充足的节点。 多节点部署：用全局等待队列替代了基于 session 的静态节点绑定。暂停的工作流恢复时被路由到可用容量最多的节点，在 KV cache 局部性和多节点负载均衡之间取得平衡。 评测 集成在 Together AI 自己的合成数据生成管道里——就是产生 CoderForge 等数据集的那套基础设施。对比 SGLang 默认调度器： 单节点 8×H100（HiCache offloading），batch size 192： • SGLang：吞吐 390 token/s，平均延迟 65s • ThunderAgent：吞吐 803 token/s，平均延迟 10.6s 多节点（2→8 节点）： • 近线性扩展，16 GPU 到 64 GPU 吞吐从 671 增长到 2248 steps/min • 加速比随集群规模增大：2 节点 1.79× → 8 节点 2.39× 使用 一个 program_id 字段，OpenAI 兼容 API，直接适配现成的 offloading 和 speculative decoding。已被 SkyRL 和 NVIDIA Dynamo 集成。 GitHub： 论文： #AgentInference# #KVcache# #ThunderAgent#