聊聊Kubernetes上部署LLM的4个关键资源分配陷阱

朋友们好，今天来聊聊AI基础设施搭建的一个硬核问题：在K8s上跑大模型，资源分配真的不能简单照搬传统方案。

最近测试了几个开源模型（LLaMA-2-70B和Mistral-7B），发现几个坑值得分享：

1. **显存与内存的“错位饥饿”**  
   - 70B模型在FP16下需140GB显存，但很多团队只关注显存，忽略了CPU内存需求。实际推理时，内存（尤其是HBM）的带宽瓶颈比显存容量更致命。  
   - 实测：使用4×A100-80GB时，若CPU内存分配不足256GB，数据预取会卡到爆，延迟从200ms飙到2秒。

2. **CPU请求必须“虚高”**  
   - LLM推理中的token生成依赖CPU做词表搜索和注意力计算，实测发现CPU利用率峰值是平均值的3倍。建议CPU请求设为“平均负载×1.5”，否则容易触发OOMKiller。

3. **GPU Memory热迁移的魔咒**  
   - K8s的GPU Memory热迁移（如NVIDIA MIG）在LLM场景中并不友好。比如MIG切分后，显存带宽下降30%-50%，这对需要高吞吐的batch推理是致命打击。

4. **网络延迟的“隐形杀手”**  
   - 多卡并行时，NVLink或InfiniBand的带宽必须≥400Gbps。实测用100GbE跑Megatron-LM，通信开销占了40%的推理时间，简直离谱。

**实用建议**：  
- 用Prometheus+Grafana监控GPU显存带宽和CPU上下文切换数。  
- 推荐工具：Kubeshark（网络抓包）+ NVIDIA DCGM（显存监控）。  

**讨论**：你们在K8s上部署LLM时，遇到过哪些奇葩资源问题？评论区聊聊。