推理部署

AI 任务排队等候，GPU 却闲置：Kubernetes 有了新方案

这篇文章是 KubeCon 前瞻专栏，讲 Kubernetes 社区怎么让 GPU 更好地服务 AI。问题在于：负责把任务分配到现有机器的调度器和负责加机器的自动扩缩器各干各的，结果任务卡在排队，昂贵的 GPU 却闲着。目前有几个方向：HPE 用开源工具自动收集 Pod 重启信息并推送到 Slack，减少人工排查；AWS 提出让扩缩器更懂调度器，并用动态资源分配、工作负载感知调度和 provisioning requests 衔接两边；SIG-Autoscaling 已有公开提案，让两个环节直接对话。另外 CNCF 沙箱项目 llm-d 发布 v1.0，IBM 测试中智能体任务推理成本降低 11.5 倍、缓存复用约 98%。这些多数是提案或演示，尚未说明何时默认可用。

Chimeraforge：LLM 部署容量规划命令行工具

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 个子命令。

快、脆、倦怠：AI 速度的代价

Harness 在 2026 年 2 月调查了 700 名工程人员，发现团队部署越快，发布失败越多，倦怠也越严重。部署失败率低于 11% 的团队里只有 4% 的管理者说团队长期倦怠，而失败率超过 30% 时这一比例升到 55%。有意思的是，84% 的受访者说 AI 反而减轻了倦怠，但因为 AI 让交付门槛提高，底层流水线没跟上，更多发布就带来更多故障和熬夜。文章建议减少每次发布的手工步骤、让回滚变得轻松，并用 AI 智能体自动处理安全问题；这些只是相关性数据，不是受控实验，原文没有给出完整报告的更多细节。

微软承诺将 Maia 扩展至多吉瓦级推理部署，其效率指标引发质疑

微软宣布从 2027 年起，把自研的 Maia 加速器系列扩大到多吉瓦级别（吉瓦是很大的用电规模单位），并用它作为自家产品的主要推理系统。新一代 Maia 300 把芯片之间的两种网络连接合并到一张以太网里，还能在预填充和解码两类工作节点之间传递 KV 状态，不用把数据搬出网络。不过有从业者质疑，这次公告重点宣传的“每瓦 token 数”效率指标是否站得住脚。对读者来说，这反映了大厂自研 AI 芯片的推进方向，也提醒大家看厂商效率数字时要多留个心眼；目前只是宣布计划，2027 年才落地，具体细节原文没有说明。