把模型跑起来的工程实践：推理优化、显存与成本、Serving 架构与基础设施选型。
MIT Technology Review 通过15个月调查，绘制了美国与墨西哥边境监控塔附近死亡事件的综合地图，并分析监控塔是否在相关人员死亡时已部署且可能覆盖现场。调查整合了近4,000起案件、监控塔位置和卫星影像，使用地形分析估算视线是否可能受阻；文章也说明了记录不完整、死亡时间和塔的实际运行状态难以确认等限制。
推荐理由：文章系统拆解了如何整合死亡记录、监控塔位置与卫星影像，并明确说明数据缺口和分析边界，为调查型数据项目提供了可复用的方法参考。
Hugging Face 发布 tokenizers v1 release candidate，保持与 v0.23 相同的 token IDs、API、词表和 merge ranks，同时重写编码路径以提升性能。
推荐理由：文章用统一基准拆解 tokenizers v1 的性能改动，并给出与 v0.23 的速度和扩展性对比，便于评估升级收益。
Google Research 介绍 MilleMiglia，这是一个用 C++ 编写的中程物流实例生成器，可创建包含固定车辆时刻表、配送中心吞吐限制和复杂同步约束的现实基准数据。它通过空间分布、需求和车辆班次等统计分布生成隐私保护的合成网络，覆盖从小型测试到洲际规模实例，并可用于训练 ML 算法。项目代码和文档已在 GitHub 开源，Google 及学术合作伙伴还在开发专用求解器和 API。
推荐理由：文章解释了中程物流为何难以套用传统 VRP，并展示 MilleMiglia 如何用隐私保护的合成数据支持统一基准与后续求解器研究。
NVIDIA Vera Rubin NVL72 首次提交 MLPerf Inference v6.1 预览结果，在 Qwen3-VL 上的吞吐量最高达到 GB300 NVL72 的 3.7x，在 DeepSeek-R1 上最高达到 2.5x。
推荐理由：文章集中比较 Vera Rubin 与 GB300 在吞吐、跨机架扩展和软件优化上的表现，呈现了影响推理成本的系统级因素。
Emerald AI、Google与NVIDIA宣布成立AI Energy Management Alliance（AEMA），推动可根据电网状况动态调整用电的AI数据中心。联盟提出技术中立、以性能为基础的要求，涵盖响应速度、持续时间、可预测性、应急行为、技术标准和运营数据共享，并计划与公用事业及电网运营商合作，探索更快的AI基础设施并网路径。
推荐理由：文章介绍了AEMA面向AI数据中心的性能化灵活用电框架，涵盖响应指标、互联成本和电网协作，为理解AI基础设施扩张中的电力约束提供了具体背景。
Hugging Face 介绍了在分离机器的 Hugging Face Jobs 上运行 AsyncGRPO 的方案：训练端仅将 LoRA adapter 通过 Storage Bucket 同步到 vLLM，并用代理完成鉴权、KV 前缀路由和多副本广播。
推荐理由：文章给出了跨 Hugging Face Jobs 部署 AsyncGRPO 与 LoRA 的完整方案，并用多轮指标定位瓶颈和优化路径。
Mistral AI 帮助一家欧洲能源运营商将40,000行Fortran 77迁移到C++，对象是没有测试套件和集中式文档的物理密集型储层模拟器。项目先建立数值一致性校验框架并整理代码文档，再由规划、编码、测试和代码质量审查智能体按模块协作，配合人工审核合并。首个冲刺覆盖300,000行代码中的40,000行，团队总结出先建校验框架、先整理文档，以及采用带人工审核门的结构化工作流三项原则。
推荐理由：文章以40,000行Fortran 77迁移为例，拆解校验、文档整理和人机协作流程，为复杂遗留代码现代化提供可复用方法。
Hugging Face 发布 @huggingface/kernels，并在 Hub 上提供 207 个 Apache-2.0 授权的 WebGPU kernels，每个 kernel 都配有接口契约、WGSL shader 模板、正确性测试和 benchmark 用例。
推荐理由：Hugging Face 将 WebGPU kernel 做成可版本化、可测试和可复用的 Hub 资源，并用 Fleet 收集真实设备证据，为浏览器推理优化提供了清晰的工程路径。
IBM Granite Team 介绍 Granite 4.2 推理模型家族的构建过程，模型分为 3B、8B 和 30B 三种规模，均基于 Granite-4.1 基座模型进行后训练。
推荐理由：文章系统梳理了 Granite 4.2 从预训练、SFT 到多阶段 RL 的构建流程，并说明不同规模模型的智能体训练差异。
Liquid AI 发布 LFM2.5-1.2B-Instruct、LFM2.5-2.6B 和 LFM2.5-8B-A1B 的 DSpark 草稿模型，通过 speculative decoding 在不改变 greedy decoding 输出的前提下提升推理速度。
推荐理由：LFM2.5-DSpark同时给出H100与M4 Max上的实测加速、函数调用延迟变化和llama.cpp及SGLang接入方式，便于评估部署收益。
Hugging Face 介绍一种约束感知 GPU 分配器，并在七个基准场景中与 FIFO 调度器对比；相同硬件和工作负载下，GPU 利用率最高提升 33 个百分点，优先级加权产出最高提升 105.1%。
推荐理由：文章用七组对照实验拆解 GPU 调度中的预留与排队成本，并给出可落地的约束建模、需求预测和滚动优化方案。
Mistral宣布Mistral Regional Endpoints正式可用，客户可选择在欧洲或美国运行推理；Mistral Priority Tier进入公开预览，并提供自定义速率限制和正常运行时间SLA。其平台将支持第三方开源模型，首个接入Z.ai的GLM-5.2，同时通过European Compute Units整合企业多年期承诺，计划到2030年建设最高1 GW的欧洲AI算力。
推荐理由：Mistral同时推进区域推理、SLA服务和第三方开源模型支持，勾勒出企业控制数据位置、模型选择与算力供给的基础设施路径。
Microsoft Research 发布 Orchard，这是一个面向可扩展智能体研究的开源框架，核心是基于 Kubernetes 的可复用环境服务 Orchard Env，可支持编码、网页导航和个人助理智能体的训练与评测。
推荐理由：文章拆解了 Orchard Env 如何复用环境、数据和评测流程，并用三个领域的结果展示开放基础设施对智能体训练效率的影响。
IBM Research 将 K-Search 扩展为支持 MLX 的后端，并通过结构化 CUDA-to-MLX 翻译层，把 CUDA 内核优化经验迁移到 Apple Silicon。
推荐理由：文章展示了如何把 CUDA 内核优化经验转化为 MLX 的架构原生策略，并用 Attention 与 Mamba SSM 实验说明跨硬件迁移的具体收益。
Hugging Face 将 Nunchaku Lite 原生接入 Diffusers，Nunchaku 检查点现在可通过 from_pretrained() 加载，无需自定义 pipeline、独立推理引擎或本地 CUDA 编译。
推荐理由：Nunchaku Lite 将 4-bit 扩散推理接入 Diffusers，并给出显存、速度和自定义量化流程，便于评估其部署价值。
Hugging Face 通过 PyTorch profiler 对比了手写 Attention、in-place 掩码和 SDPA 的 math、efficient、flash、cuDNN 后端。
推荐理由：文章通过对比多种 Attention 实现的 profiler trace，具体展示了 kernel 融合、显存访问和 CPU 开销如何影响性能判断。
Hugging Face 表示，Transformers vLLM modeling backend 在多种 LLM 架构上已达到或超过定制 vLLM 实现的吞吐。
推荐理由：文章用 Qwen3 三种规模模型的对比说明，展示了该后端在兼容架构上如何免写定制代码获得原生 vLLM 吞吐。
Google Research 在10个美国城市开展为期六个月的导航改道实验，通过引导不到2%的出行避开约100个拥堵路段，评估系统性交通改善效果。目标路段车速中位数提高约2%，燃料消耗率中位数下降0.5%至1.0%；受影响路段整体车速中位数提高约0.35%，高峰时段提高0.5%，每个城市每年可能节省数千吨 CO2e。
推荐理由：研究通过10个美国城市的长期对照实验，量化了少量改道对整体车速、燃耗和排放的系统性影响。
Microsoft 在 Foundry Model Catalog 中推出 Hugging Face 模型 Collection，提供每周更新的开源权重模型，并支持一键部署到 Foundry Managed Compute。
推荐理由：文章完整说明了 Hugging Face 模型接入 Foundry 的筛选、部署与运行机制，适合了解开源模型如何进入企业生产环境。
Berkeley AI Research 的文章认为，AI 推理成本快速下降将推动智能体成为数据系统的主要工作负载，并带来三类问题：为智能体设计数据系统、为大规模智能体群构建状态与协作基础设施，以及由智能体合成定制数据系统。文章讨论了 agentic speculation、结构化记忆、多智能体协调与故障处理，以及通过验证智能体和证明系统保障自动生成系统的可靠性。
推荐理由：文章将智能体数据系统拆成支持智能体、承载智能体和由智能体构建三类问题，为理解多智能体规模化运行的工程瓶颈提供了清晰框架。