这篇文章讲的是 Kubernetes 控制平面在集群规模变大后，一些平时看起来正常的设计反而会把小问题放大成故障。作者举了三个真实例子：一个扩展 API 升级依赖后发布了不合法的 OpenAPI 模式，结果连只用普通 Kubernetes 资源、根本没用这个扩展的 Helm 部署也失败，因为 OpenAPI v2 把所有 API 的定义合并成一份文档，一个扩展出错就拖累所有人；大批 DaemonSet 代理同时重启，启动时的正常请求叠加成风暴，API 服务器扛不住；还有组件把依赖服务的短暂不可用误判成自己进程坏了，反复重启。文章建议用 OpenAPI v3 缩小影响范围、控制重启节奏、别让健康检查过度依赖下游。这是经验分享文章，没有发布新工具，文中提到的 OpenAPI v2/v3、informer、聚合 API 服务器、PR #131755 都是已有机制或改动。
文中可用工具
- OpenAPI v2把所有 API 的接口定义合并成一份文档供客户端读取校验
- OpenAPI v3按 API 组和版本分开提供接口定义，缩小单个扩展出错的影响范围
- informer让控制器在本地缓存集群状态，减少反复查询 API 服务器
- 聚合 API 服务器（aggregated API server）在不改核心 API 服务器的前提下给 Kubernetes 增加新 API
- Helm部署图表前会读取 OpenAPI 文档做校验，因此可能被无关扩展的错误波及
- DaemonSet在集群每个节点上运行代理，大规模重启时会集中产生请求
- Kubernetes PR #131755让 OpenAPI 模型名称由作者显式声明，而不是从 Go 包路径推导
展开详情收起详情：影响 Kubernetes 控制平面可用性的隐藏故障路径⌄
The New Stack
原文发布：2026-10-27 22:00收录：2026-10-28
Nebius 的 AI 训练团队在 Terminal-Bench 类负载上做了一次实验：把一次 256 条轨迹的批次收集时间减少了 66.9%。原来在智能体强化学习训练中，模型要先完成任务、拿到结果才能学习，但任务长短不一，慢的几条会让整批训练卡住，昂贵的 GPU 常常在等便宜的沙箱和代码执行。做法是把推理引擎当成训练优化器的一部分：按整组完成而不是启动顺序来组批，让生成和训练部分重叠、缓存对话历史避免重复预填，并把基础设施故障和模型自身失败分开计分。这只是一个实验中的批次收集测量，不含训练器本身的前向反向计算，不等于完整训练提速。对读者来说，这提供了一个思路：智能体训练慢，瓶颈往往不在 GPU 算力，而在任务执行和调度这些配套环节。
文中可用工具
- Nebius提供 AI 训练与推理服务的公司，本文实验由其实施
- Terminal-Bench用于评测终端操作类智能体任务的基准，本文实验基于它构造负载
- GRPO一种强化学习训练方法，把同一任务的多次尝试相互比较打分
展开详情收起详情：Nebius 将 rollout 收集时间缩短 66.9%——改变了什么⌄
The New Stack
原文发布：2026-10-27 23:38收录：2026-10-28
Google DeepMind 在周二发布了 Genie 4。它是一个“世界模型”，能实时生成可互动的场景，带有模拟物理、人物动作和声音，主要给 AI 智能体提供练习和测试任务的地方。原来开发者要测智能体，往往得自己搭仿真环境；现在可以用文字提示按需生成，甚至边生成边用键盘移动、改视角。问题在于，长时间运行后物体位置会漂移、物理表现不稳定，而且 Google 没有公布重复测试的一致性数据，所以失败时很难分清是智能体不行还是场景本身出错。目前只有受信任的测试者能用，之后计划开放给 Google AI Ultra 订阅者和部分合作方，价格和正式发布时间都没说。
文中可用工具
- Genie 4实时生成可互动模拟场景的世界模型，供智能体练习和测试
- Gemini Omni帮助塑造模拟环境的形态
- Gemini 3.8 Flash跟踪场景进展、规划下一步并在变化时调整
- Gemini 4 Argon在棋盘演示中规划每一步走法
- Gemini Robotics用于机器人研究的项目，可在变化环境中测试智能体
- Project Genie面向 Google AI Ultra 订阅者提供 Genie 4 的计划渠道
- Gemini API计划供部分合作方接入的接口
- Google AI Studio计划供部分合作方接入的开发平台
展开详情收起详情：Google 为 AI 智能体打造了一个可练习的世界，但物理效果还不太对⌄
The New Stack
原文发布：2026-10-28 06:33收录：2026-10-28
这是一场演讲，讲者是 Khawaja Shams，主题是如何高效地大规模运行大语言模型（LLM）服务。问题在于：模型推理很吃 GPU，而对话上下文对应的 KV Cache 会占用大量显存，容易撞上“内存悬崖”，还会拖慢响应、推高成本。演讲从分布式系统的角度给出几种做法：提高 GPU 利用率、管理 KV Cache 内存、利用分层存储、降低尾部延迟，以及把预填充和解码拆开部署。读者可以借此了解如何让整套推理集群跑得更快、更便宜、更稳。目前公开的只有标题和摘要，具体实现细节、数据和演示材料均未说明。
展开详情收起详情：演讲：大规模 LLM 服务——隐藏的 KV Cache 优势⌄
InfoQ Architecture & Design
原文发布：2026-10-27 19:00收录：2026-10-28