工具与应用01
这篇文章讲的是在 Kubernetes 上跑 AI 任务的团队，常看到 GPU 全被占满、批处理队列越排越长，第一反应就是加 GPU。但作者提醒，GPU 被分配、在忙、和真正产出有价值的结果是三件不同的事，队列变长也可能是时机、服务容量或模型和硬件选型的问题。解决思路是先想清楚每个任务的截止时间和产出标准，再用错峰排队把现有四块 GPU 在两小时内跑完原本需要八块的四个任务，同时用接近真实负载的压测摸清可持续吞吐，并把 OpenCost 的成本数据和实际产出对上，算出每个合格结果花多少钱。这样读者能在花钱扩容之前，先确认现有容量是否已用足、瓶颈到底在哪。Kueue、vLLM、DistServe、OpenCost 等工具文中都有提到，具体接入方式原文未详细说明。
文中可用工具
- Kueue做准入控制，按配额和策略决定任务何时被放行
- vLLM模型服务框架，其 KV-cache 占用率可反映缓存使用情况
- DistServe说明评估服务容量时应以延迟等应用层目标为准
- OpenCost按时间间隔统计工作负载成本，并可追踪每百万 token 的推理成本
研究与技术02
这篇文章讲的是 Kubernetes 控制平面的容量问题，但重点不是“集群有多大”。作者举了三个完全不同的集群：一是上万节点的训练集群，大量节点不停上报心跳，把 apiserver 和 etcd 的内存吃光；二是节点数不多但对象频繁创建、销毁的 Agent 平台，写入压力巨大；三是装了两百个 operator、对象多得每个 apiserver 都要在内存里存一份的平台集群。文章的核心观点是：这三种压力方向不同，按节点数调优往往治错病，加 apiserver 还可能因为每个都复制全量 watch 缓存而让情况更糟。作者提出从四个“接缝”入手（存储分工、节点存活上报、分片维度、缓存驻留），并说明部分能力已有现成配置，像 KEP-4743、KEP-5866 这样的改进仍在推进中，具体何时可用原文没有说明。对运维 Kubernetes 的读者来说，这是一份先分清自己属于哪种规模压力、再决定调优方向的思路清单。
文中可用工具
- Kubernetes容器编排系统，本文讨论的控制平面容量问题都发生在它上面
- etcdKubernetes 的键值存储后端，本文建议把非持久流量分流出去并用内存 lease 刷新减轻写压力
- kOps原文提到它文档里记录了增加 apiserver 的做法
- KEP-4743定义存储接口边界的提案，用来把不同资源类型路由到不同后端
- KEP-5866为 API 流量引入哈希范围过滤的提案，是分片的基础
- etcd-servers-overrides已有配置项，可把资源类型指向不同的 etcd 后端，但目前只支持内置资源
推理与部署03
Sahil170595/Chimeraforge · PyPI capacity-planning CLI for LLM deployment. pip install chimeraforge.
Chimeraforge 是一个本地优先、模型无关的 LLM 部署规划器，以 Python CLI 形式提供。用户可输入模型规模、HF 仓库或 Ollama 标签，以及 GPU 硬件与请求速率，工具会在（模型 × 量化 × 后端 × GPU 数量 × 并行策略）空间中搜索，并在 VRAM、质量、延迟、成本、能耗等门控约束下返回满足 SLO 的最便宜配置。每个数值都标注为 measured、extrapolated、derived、estimated 或 unknown 的来源，无需联网即可对本地注册表和目录进行规划。项目还提供 workload 流量画像、markdown 决策简报、MCP 服务器供 Claude/GPT/Cursor 调用，以及 suggest、measure、bench、safety 等共 25 个子命令。
行业动态04
JioHotstar（当时叫JioCinema）的工程师 Ashutosh Agrawal 和团队，为2023年印度板球超级联赛（IPL）决赛做了大量准备。直播体育的难点是：所有观众必须同步看到画面，不能让一部分人比邻居早几秒知道比分结果。他们的做法是按预期流量的大约两倍来准备容量（当年按5000万到7500万并发准备），把视频传输链路当作绝不能出错的“黄金路径”，并对登录认证等关键系统提前扩容。团队还用一份200项检查清单逐项排查故障点，比如超时配置、短信服务商全部宕机时怎么让用户仍能进入，并做单系统、多系统组合和模拟真实用户的测试。这场决赛最终创下约3200万并发观看的纪录。对读者来说，这是一套应对高不确定性大流量的可复用清单，也能用于黑五这类场景；但文中没有说明这些经验目前是否已作为公开工具或服务对外提供。