面经 | AI Infra | 🔥🔥🔥 | Amazon
2026(8-9月) Software Development Engineer - AI Infrastructure @ AWS | Virtual Interview | 😐 Neutral | Medium-Hard | Pending
投的是 AWS 下面偏 AI infra 的组，做 inference。这一轮没有 LC。面试官看我简历里写过 vLLM，前面就顺着项目问了几分钟，后面大部分时间都在聊一个 system design。
他基本不会停留在我说的第一版方案上。每讲完一版，他就接着问下一个：如果机器更多呢，如果版本错了呢，如果 rollout 到一半呢，如果需要快速扩容呢。
这一轮：PagedAttention、权重分发和 rollout
PagedAttention
第一个问题很直接：介绍一下 vLLM 中 PagedAttention 的原理。
这个我之前准备过。KV cache 不再要求每个 request 占一整块连续显存，而是拆成 block，需要用的时候再分配，不用一开始就按最大长度预留。
他问了一句：为什么这个对 serving 很重要。
我主要从 memory waste 和不同 sequence length 往下讲。如果每个 request 都按最大长度预留，大部分预留其实用不到，一个很短的 request 和一个很长的 request 成本差不多。按 block 分配就只用付实际用掉的那部分，同样一张卡上能放更多 sequence，最后也就是 throughput 的差别。
后面问 block size 怎么选。
这个我答得没有前面顺。我说 block 太大会在 sequence 尾部浪费，太小又会增加管理开销、每次查找也更麻烦。具体默认值和实际调的区间我记不清了，就没继续往下硬讲。
Model weights distribution
system design 的题目其实就几个词：model weights distribution。
我先确认了一下 scope。大概就是一个很大的 model，现在要部署到很多 inference machine，怎么把 weights 分发过去。
第一版我想得比较简单：model weights 放 object storage，新机器启动以后根据 model version 下载，然后 load。
他接着问：如果现在不是十台机器，是同时起几千台呢。
这里我才开始往 cache 和分层分发上想。如果所有机器同时从同一个地方拉几百 GB 的 weights，启动时间和 network 都会有问题。所以后面我讲成 origin 保留完整 artifact，region / cluster 里面再有一层 cache，新 machine 尽量从离自己近的地方拿。
他接着问：怎么保证每台机器拿到的是同一个 version。
我说不能只靠文件名。应该有 immutable version，然后配 manifest / checksum。机器下载完先 verify，再真正 load。
这一段聊得还挺久。
后面有个问题我一开始没想到：假设新版本已经 rollout 到一部分机器，突然发现模型有问题，怎么办。
我第一反应就是 rollback。
他马上问：怎么 rollback。
这里我前面其实漏掉了一个东西，就是不能把旧 weights 直接覆盖掉。是他追着问以后我才补上：新旧 version 应该都保留，当前 serving 哪个版本单独记录。这样 rollback 更像是切回 previous stable version，不用重新去下载或者重新 build。
EKS deployment 和 autoscale
他问 EKS deployment strategy 怎么做。
没有让我画特别复杂的 Kubernetes 架构，主要就是问 model server 更新的时候怎么避免一下全部换掉。我讲了 rolling / canary，先上一小部分 instance，看 health 和 metric，没问题再继续。
他又问：那什么 metric 算没问题。
我说至少会看 error rate、latency、启动失败，还有 model-specific 的 validation。这一块我感觉自己讲得有点散，因为 infrastructure metric 和 model quality metric 我混在一起讲了。
最后又问：How to set up auto scale。
我先说 GPU utilization。
然后他问，如果 utilization 已经很高才开始 scale，会不会太晚。这个问题挺合理的，因为新的 inference node 不是起来就能接流量，它还要拉 weights、load model。
后面我补了 queue depth / request latency 这些更前置的 signal，而且如果某些 model traffic 本来就比较稳定，可能需要留一些 warm capacity，而不是等 metric 动了再扩。他又绕回最开始的问题：新 node 越多，weights distribution 本身是不是又会变成 bottleneck。
Behavioral
最后几分钟没再做题，问了一个项目相关的问题：之前做过最难的 technical decision 是什么。
我讲了一个当时为了赶时间选了比较简单方案，后面 traffic 上来以后又返工的例子。
面试官没有让我完整走 STAR，主要一直问：当时为什么会做这个决定，你当时不知道这些风险吗，如果重新来一次，哪个 assumption 会先验证。
这几个 follow-up 我觉得比问题本身难一点。
PagedAttention 前面答得还行，model weights distribution 中间有几个点是被问到以后才想到的。尤其 rollback 那里，第一反应只说"切回旧版本"还是太浅了。