KERNELHIVE · DAILY TECHNICAL INTELLIGENCE
今日论文聚焦算子与服务运行时向硬件极限要性能：cuBLAS 用整数 Tensor Core 精确重建 FP64 GEMM，cuPhoton 重排 IO 密集的 GPU 相关流水线；服务侧以跨机张量并行、microVM 快照冷启动和 Spot 混布，分别回应容量、启动与成本约束，cuDLA 则把端侧算子放置开放到 Python。
科学计算最耗时的部分是稠密高精度矩阵乘（DGEMM/ZGEMM），但 GPU 的 FP64 单元吞吐远低于整数 Tensor Core。CUDA 13.4.2 的 cuBLAS 新增 Ozaki-II 与 2M 算法：把双精度数按共享指数切成大整数，用中国剩余定理使每个模数只做一次整数 GEMM，再由余数精确重建乘积；精度不足时 ADP 回退原生 FP64 MMA。实测 DGEMM 较原生 FP64 快 5.5x（VR NVL72）与 3.9x（GB200），ZGEMM 快 5x，BerkeleyGW 端到端 6.6x，小 shape 仍走原生路径。
为何值得关注：它把 FP64 GEMM 的换算代价从平方级降到线性，并在运行期自动回退，让科学计算无需改代码即可吃到整数 Tensor Core 吞吐。
753B 参数的 GLM-5.3 NVFP4 MoE 每 token 激活 40B，checkpoint 约 464 GB，超过单张 GB300 的 252 GB HBM3e，本地部署因此无法只靠一块 GPU。报告用两台 DGX Station 经 ConnectX-8 RDMA（单 rail 400 Gb/s、RoCE）做 TP=2：vLLM 以 nnodes=2 启动，每卡约 218 GiB 权重，并启用 MTP 四 token 草稿、FP8 KV cache 与前缀缓存。AIPerf 在 SPEED-Bench Coding 上测得吞吐 C1 为 107.4、C16 峰值 607.8 tok/s，C32 反降至 385.0 tok/s、平均请求延迟 453.5 s。
为何值得关注：两台工作站即可跑通 753B MoE 并给出并发拐点，为本地推理替代云端提供了可复现的容量与吞吐基线。
serverless agent 的冷启动过去随镜像变大而变慢：V1 每个 session 都要拉镜像、跑初始化。AgentCore runtime V2 改为在创建/更新时启动容器、等 /ping 报健康后清空文件缓存并冻结 microVM，把内存与磁盘存成快照；新 session 恢复快照，import 与 client 原样回来，镜像文件按块惰性读取。于是“懒加载”的直觉反转：静态初始化应放进 init，动态值必须留在 handler。AWS 给出四类模式——init 内建对象、用 build hook 预热大文件、按用户交互预开会话把首次响应压到约 200 ms；未预热的新 session 约 2 秒。
为何值得关注：它把冷启动优化从“调镜像、少 import”变成“决定哪些状态该进快照”，并给出 CloudWatch 的 Latency 与 OverheadLatency 拆分，让团队先判定延迟到底出在平台还是自身代码；结论只在 AgentCore V2 的 microVM 快照语义下成立，init 变重会放大快照体积与内存计费。
语音转写要为每个音频跑声学模型、语言模型与后处理，长期满载的 On-Demand GPU 成本过高，而 Spot 实例会在 2 分钟预警后被回收。AWS 与 AssemblyAI 的方案是：ECS capacity provider 混合 On-Demand 基线与 Spot，横向铺开 g4dn/g5/g6 三个 GPU 家族并按 price-capacity optimized 选池，用 SQS 把作业提交与执行解耦，回收时由 EventBridge 触发 Lambda 把在飞任务重新入队，另设死信队列，配合约 2 分钟可拉起的自定义 AMI。结果推理算力成本比 On-Demand 降低约 70%，在算力需求同比增长近 4 倍时仍维持 SLA 与欧洲数据驻留。
为何值得关注：它把“Spot 便宜但不可靠”变成可复用的架构：实例家族多样化降低中断率，队列级重试让中断只表现为处理时间略增；证据来自 AssemblyAI 的转写流水线（T4/A10G/L4，us-west-2 与 eu-west-2），不适用于长会话或强实时推理。
射电干涉测量要把每台望远镜的电压流两两相关成 visibility，数据量达 PB 级，长期依赖 CPU 相关器。cuPhoton.xBeam 把 FX 相关器搬上 GPU：先建 .vdix 索引按时间戳定位 VDIF 帧，再做延迟与条纹改正、FFT 信道化、站对交叉相乘累加，并输出 DiFX SWIN 格式，配合 GPUDirect Storage 与按时间分片实现多卡扩展。Vera Rubin NVL72 上 64 卡处理 10 TB 记录用 70 秒，较 x86 CPU 基线 31,992 秒快约 460x，读带宽从 4 卡 20 GB/s 升到 64 卡 170 GB/s，说明瓶颈已转向数据搬运与分片合并。
为何值得关注：它示范了 IO 密集算子库的流水线化写法：索引解耦随机读取、FFT 与交叉相乘留在 GPU、时间分片做扩展，对其它大规模数据同构计算有直接借鉴价值。
边缘设备要在有限功耗内并行跑多个网络，Jetson AGX Orin 的 DLA 是只做卷积、池化等固定算子的加速器，可把这类算子从 GPU 卸下，但此前只能用 C++ 管理。cuda-bindings 13.3.0 起提供 cuda.bindings.cudla，把 13 个函数、9 种数据类型与 8 个枚举暴露给 Python；在 CUDA_DLA 混合模式下，预处理 kernel、DLA 推理与后处理排在同一条 CUDA stream 上，缓冲区大小由张量描述符决定，注册后的 GPU 指针交给 DLA 任务。文中未给出性能数字，且 standalone 模式尚不支持。
为何值得关注：它把“算子是否放到固定功能加速器”从编译期决定变成应用层可编排，为 GPU 与 DLA 的算子放置与流水重叠提供了可编程入口。
新闻侧有两条与硬件现实相关的线索：一边是个人用户用 8 张 V100 加混合精度专家布局，让 DeepSeek V4.1 Flash 在旧卡上保住多数路由质量；另一边是研究者以权重指纹反推训练所用 GPU 家族，把算力合规争议变成可测量的软件证据。
显存成本高企时，能否用二手 Volta 卡跑超大 MoE 模型？这位律师在 8×V100（共 256GiB）上把 DeepSeek V4.1 Flash 从 2-bit 升到接近 NVFP4：该模型 40 层、每层 384 个路由专家，官方精度约需 269GiB 显存，装不下；于是所有专家保持 2-bit，只把最常用的约 38.7%（5,949 个）换成 NVFP4，热度按四类文本等权混合的流量统计。结果单请求时 80%–86% 的 decode 路由落在高精度专家上，相对 Nvidia 官方权重同一 next token 率 92.2%→95.1%，KL 散度 0.196→0.079；代价是代码输出 160–215 降到 150–180 tokens/s。边界：单机、贪心解码的保真度对比，不是通用性能基准。
为何值得关注：把“哪些专家值得留在高精度”变成显存分配问题，为老卡上跑 MoE 推理给出可复现的 混合精度专家布局 取舍范式。
受管制的加速器是否真被用于训练，过去多靠传闻判断。独立研究机构 UnemploymentLabs 用权重指纹给出相关性证据：不同 GPU 家族的 SM（流多处理器）数不同（Hopper 132、Blackwell B 系列 148、GB 系列 152），cuRAND 初始化会按固定线程划分把随机扰动摊到每 SM 2,048 线程上，从而在权重统计分布里留下硬件痕迹；用相同芯片、软件栈与线程数重放初始化，分布与 DeepSeek V4、Kimi K3.1、MiniMax-M3、Ling-3.1-Flash 高度吻合，改动 SM 或线程数则相关性消失，据此还能粗估所用卡数。边界：只适用于开放权重模型，依赖训练软件栈，无法确定芯片所在位置，也不证明管制被违反。
为何值得关注：训练产物可反推硬件家族，为算力合规审计补上软件侧证据链，同时提醒团队权重初始化布局本身会泄露硬件信息。