这篇文章讲的是在 Kubernetes 上跑 AI 任务的团队，常看到 GPU 全被占满、批处理队列越排越长，第一反应就是加 GPU。但作者提醒，GPU 被分配、在忙、和真正产出有价值的结果是三件不同的事，队列变长也可能是时机、服务容量或模型和硬件选型的问题。解决思路是先想清楚每个任务的截止时间和产出标准，再用错峰排队把现有四块 GPU 在两小时内跑完原本需要八块的四个任务，同时用接近真实负载的压测摸清可持续吞吐，并把 OpenCost 的成本数据和实际产出对上，算出每个合格结果花多少钱。这样读者能在花钱扩容之前，先确认现有容量是否已用足、瓶颈到底在哪。Kueue、vLLM、DistServe、OpenCost 等工具文中都有提到，具体接入方式原文未详细说明。
文中可用工具
- Kueue做准入控制，按配额和策略决定任务何时被放行
- vLLM模型服务框架，其 KV-cache 占用率可反映缓存使用情况
- DistServe说明评估服务容量时应以延迟等应用层目标为准
- OpenCost按时间间隔统计工作负载成本，并可追踪每百万 token 的推理成本
展开详情收起详情：在扩容 GPU 池之前，先衡量实际产出⌄
The New Stack
原文发布：2026-10-24 20:00收录：2026-10-25
Kubernetes 里管“该开几个副本”和“每个副本该给多少 CPU/内存”的其实是好几套独立工具：HPA 按 CPU 百分比增减副本，VPA 按历史用量调整资源申请，KEDA 按 Kafka 队列积压决定副本数，Karpenter 按声明资源申请新机器。问题是它们各自跑各自的循环，看到的都是局部信息，还同时改同一批配置字段。比如 VPA 把 CPU 申请调小，HPA 的分母就跟着变小，同样的流量会被算成利用率超高，于是猛加副本，结果副本越来越多、每个越来越小，互相把对方越推越远；KEDA 加副本、HPA 又按低 CPU 减回来；GitOps 看到副本数和 Git 不一致还会把它改回去。作者认为水平和垂直扩缩本来就是一道联立方程，应该由一个统一控制面同时看 CPU、队列、延迟、节点价格和 Git 配置，一起给出副本数和资源申请。文中也提到生产集群 CPU 平均利用率只有约 8%，但这些方案的落地细节和可用性文中没有说明。
文中可用工具
- HPA根据 CPU 等运行时指标增减 Pod 副本数
- VPA根据历史用量调整容器的 CPU/内存申请
- KEDA根据 Kafka 等外部事件源的队列积压决定副本数
- Karpenter为 Pending 的 Pod 按声明资源申请节点
- Cluster Autoscaler在有 Pod 无法调度时扩缩节点池
- Argo CD按 Git 仓库内容同步集群状态并检测漂移
- FluxGitOps 工具，按版本控制强制集群基线状态
- Helm用 values 声明副本数和资源规格
展开详情收起详情：为什么 Kubernetes 自动扩缩容器会互相打架（以及为什么解决方案必须是自主的）⌄
The New Stack
原文发布：2026-10-24 21:00收录：2026-10-25
这篇文章讨论的是：当 AI 编程智能体让代码提交量暴增时，团队的交付系统会卡在哪里。作者提到 Anthropic 的代码合并量从 5 月每天约 2500 个涨到 9 月每天超过 3 万个，写代码不再是瓶颈，瓶颈变成了为人类速度设计的开发基础设施。文章用控制回路打比方：意图是目标值，智能体是控制器，验证就是传感器；控制器再快，如果传感器跟不上，它只会拿着过时信息反复重试，把本该被拦下的问题发布出去。作者提出传感器要具备三个特性：延迟（多久能出结果）、保真度（多接近真实系统）、带宽（能同时验证多少个改动），并用 StrongDM 的数字孪生宇宙举例说明保真度为什么最贵。对读者的用处是：如果你在规划智能体编程流水线，这篇文章提醒你先投资验证能力，而不是只堆智能体数量。文章是观点分析，未说明具体产品发布时间或可用状态。
文中可用工具
- Anthropic原文引用其代码合并数据作为案例，并讨论其智能体编程实践
- Digital Twin UniverseStrongDM 用来克隆第三方依赖行为、让智能体跑大量场景的验证环境
- CI持续集成，原文讨论在大量改动并发合并时它意味着什么
展开详情收起详情：构建智能体软件工厂？从传感器开始⌄
The New Stack
原文发布：2026-10-24 22:00收录：2026-10-25
AWS 周四正式开放了名为 Continuum 的 AI 安全服务。它会自动在你的代码仓库里查找漏洞、复现问题，对照 AWS 环境验证，然后提交带修复方案的 PR。AWS 自己发布的测试显示，在 920 个 C/C++ 内存安全漏洞任务中，Continuum 有 89% 能找出并修好漏洞且不破坏原有测试，远超此前公开最高分 65.9%。不过这个分数是 AWS 自己跑的，还没第三方复现；而且只有 37.8% 的修复同时命中了测试指定的那个历史漏洞——因为智能体并不知道要找哪个洞。测试也只覆盖 C/C++ 一类问题。对开发团队来说，它可能帮忙快速发现并修掉真实漏洞，但具体修的是不是你要的那个，还需人工确认。
文中可用工具
- ContinuumAWS 的 AI 安全智能体，自动查找并修复代码仓库中的漏洞，提交修复 PR
- CyberGym-E2E用于评测 AI 修复漏洞能力的公开基准测试，含 139 个开源项目和 920 个任务
展开详情收起详情：AWS 称其 AI 安全智能体修复 89% 的漏洞——但有个前提⌄
The New Stack
原文发布：2026-10-24 22:30收录：2026-10-25
Cloudflare 优化了其内部负载均衡服务中一致性哈希的 Rust 实现（pingora-ketama），把这项服务占用的内存减少了 100 TB 以上。原来的问题是：每个后端服务器要在哈希环上保存很多哈希条目，条目越多占用内存越大。这次的做法是压缩哈希环上的条目，并通过统计分析哈希分布和冲突率，把每个后端所需的哈希数量减少了约 90%。对读者来说，这说明大规模系统里看似不起眼的数据结构优化，也能省下巨量内存资源。
文中可用工具
- pingora-ketamaCloudflare 用 Rust 实现一致性哈希的组件，本次优化的对象
- Rust编写 pingora-ketama 的编程语言
展开详情收起详情：Cloudflare 优化一致性哈希，回收 100 TB 内存⌄
InfoQ Architecture & Design
原文发布：2026-10-24 16:10收录：2026-10-25
Google 把 Data Agent Kit 正式开放使用了。这是一套免费工具，包含 MCP 工具和 37 个开源技能，能让写代码的 AI 助手直接连接 Google 数据云的 15 种以上服务。它带了两道护栏，但作用不一样：一道是写在技能里的提示，让 AI 助手自己停下；另一道是 IAM 拒绝策略，在权限层面直接拦掉请求，AI 助手想绕也绕不过。对使用者来说，这意味着能连的服务变多，但需要分清两种护栏的强弱，不能把提示当成硬性限制。
文中可用工具
- Data Agent Kit连接 AI 编程助手与 Google 数据云服务的免费工具集
- MCP让 AI 助手调用外部工具和数据的标准协议
- IAM deny policy在权限层直接拒绝请求的硬性护栏
展开详情收起详情：Google Data Agent Kit 正式发布，将 Agent 护栏拆分到技能与 IAM 两层⌄
InfoQ Architecture & Design
原文发布：2026-10-24 16:34收录：2026-10-25