Shopee AIGC 一面
1. 自我介绍
2. 说说你简历上这俩项目
3. 多头注意力真正发挥作用的关键,不是“头变多了”而是什么
多头注意力的核心不是把一个注意力拆成几份,而是把表示空间分成多个子空间,让不同 head 在不同投影下学习不同相关性模式。有的 head 偏局部词法关系,有的偏远距离依赖,有的偏结构性边界,有的偏位置模式。如果只是单头,模型只能在一个统一度量空间里做相关性匹配,表达会更受限。
真正让多头有效的,不是“并行”两个字,而是不同头通过不同参数矩阵形成了多视角关系建模。头数继续增大并不一定更好,因为维度被切得过细后,每个头的表达能力又会下降,所以它本质上是容量分配问题,不是机械堆头数的问题。
4. 为什么推理阶段缓存 K 和 V,却不缓存 Q
因为自回归生成时,历史 token 的 K 和 V 在后续所有时间步都会反复参与计算,它们一旦算完就能复用;而 Q 只对应“当前时刻要发起查询的这个 token”,下一步生成新 token 时,查询向量已经变成新的 Q,旧 Q 不再被用到,所以缓存价值很低。缓存 Q 既不能减少未来核心计算,还会平白增加显存占用。
从计算图角度看,当前步 attention 是拿 Q_t 去和所有历史 K_1...K_t 做匹配,再用权重汇总 V_1...V_t。下一步要用的是 Q_{t+1},不是 Q_t,所以只缓存 K/V 才符合复用收益最大化。
5. KV Cache 的真实瓶颈为什么常常不是“存不下”,而是“搬不动”
很多人第一次看 KV Cache 问题,只想到显存容量,实际上线上推理更常见的瓶颈是内存带宽和访存模式。随着 batch 变大、上下文变长,注意力计算需要频繁读取大量历史 K/V,如果内存布局不友好、请求长度差异又大,就会导致访存不连续、cache miss 增多、带宽利用率变差。此时即使显存还够,吞吐也会掉得很明显。
所以推理优化的关键并不只是压缩 KV 大小,还要考虑块式管理、连续性、页映射、调度策略和 kernel 访存模式。很多系统延迟恶化,并不是 OOM,而是内存子系统先扛不住了。
6. vLLM 处理 batch 内长度不一致的请求,为什么比传统静态 batch 更有优势
传统静态 batch 通常要求请求在一个较固定的步调上推进,短请求容易被长请求拖住,导致 padding 浪费和吞吐下降。vLLM 的优势在于它把请求调度和 KV Cache 管理解耦了,采用更细粒度的 token 级调度和分页式缓存,让不同长度请求可以动态进出 batch,而不需要整批等待最慢样本。
这种设计的本质是把“按样本整批推进”改成“按 token 和可用块资源推进”。这样能显著提高 GPU 利用率,尤其是在在线服务里,长短请求混杂是常态,不做动态调度就很容易浪费算力。
7. 如果 block 不连续导致访存变慢,工程上怎么缓解
解决思路通常不是强行要求所有块连续,而是尽量减少随机访存损失。比较典型的手段包括页表式映射、相邻块优先分配、热点块重排、请求分层调度、连续块池预留以及 kernel 侧做 gather 优化。对于高频长会话,还会做前缀共享和热点 cache 复用,减少无意义的重复装载。
真正麻烦的地方在于吞吐和碎片率之间存在张力。你越激进地追求连续性,分配器越容易退化成难以维护的复杂状态机;你越放任碎片,带宽损失又会逐渐吞掉吞吐。所以这是一个典型的系统平衡题。
8. AWQ 和 GPTQ 在量化思路上的差别到底在哪
GPTQ 更偏“按误差最小化去拟合原权重效果”,它常通过二阶近似或块级误差补偿来寻找量化后尽量接近原模型输出的权重。AWQ 的关注点则更偏激活感知,它会利用一小批校准数据观察哪些权重通道对激活更敏感,尽量保护这些关键通道不被量化误差严重破坏。一个更偏权重重构,一个更偏激活敏感度保护。
工程上两者都会影响精度和推理速度,但取舍不同。GPTQ 常被认为在离线权重重构上更直接,AWQ 则在很多实际大模型部署中表现出不错的精度保留和工程友好性,尤其适合权重量化部署场景。
9. AWQ 的 group size 为什么不是越小越好,也不是越大越好
group size 小,量化尺度更细,理论上更能贴合局部分布,精度通常更容易保住,但额外的 scale/meta 信息更多,推理 kernel 也可能更复杂,吞吐未必最佳。group size 大,元信息更少、算子更规整,部署速度可能更好,但不同权重分布被硬塞到同一量化尺度里,误差会增大。
所以 group size 本质是“量化精度”和“工程效率”的折中。真正合理的设置不是凭经验拍一个数字,而是结合模型层类型、目标硬件、校准集分布和线上延迟预算来做测试。只讲理论不做实测,基本不够。
10. 量化校准为什么不能只拿几条样例随便跑一下
校准集决定了你观察到的激活分布,而激活分布又直接影响量化尺度和敏感通道识别。如果校准样本太少、分布太窄、长度太单一,量化参数就会偏向局部场景,一旦线上数据出现长上下文、代码、表格或高熵生成,精度会掉得很明显。尤其是 instruction-following 模型,不同任务形态下激活差异非常大。
所以校准数据至少要覆盖目标业务的长度、风格和任务类型,最好包含一些高风险样本,比如长输入、复杂格式和数值密集文本。量化不是“离线压一下就结束”,它其实是在用少量数据近似未来线上分布。
11. LoRA 一般挂在哪些层更有收益,为什么不是全挂最好
在 Transformer 里,LoRA 最常挂在 attention 相关投影层,比如 q_proj、k_proj、v_proj、o_proj,以及部分 MLP 投影层。原因是这些位置对任务适配最敏感,尤其是 query/value 路径更直接影响信息检索与信息写回。如果全挂,参数量和训练成本会增加,而且很多层对特定任务的边际收益很低,不一定划算。
真正的选择要结合任务性质。偏风格和指令跟随的任务,attention 投影层往往就够;如果任务涉及更强的领域知识迁移或输出分布变化,MLP 层增量也可能有效。LoRA 不是挂得越多越高级,而是要看干预位置是否值钱。
from peft import LoraConfig
config = LoraConfig(
r=16,
lora_alpha=32,
target_modules=["q_proj", "v_proj", "o_proj"],
lora_dropout=0.05,
bias="none",
task_type="CAUSAL_LM"
)
print(config)
12. LoRA 的 r、alpha、dropout 怎么理解,调参时该先看什么
r 决定低秩分解的容量上限,越大适配能力越强,但参数和显存也会增加;alpha 更像增量更新的缩放强度,它决定低秩分支对原模型输出的影响幅度;dropout 是为了防止小数据下 LoRA 分支过拟合。实际调参时,先看任务数据量和领域偏移程度,偏移大且数据多时可以适当增大 r,数据少时更该小心过拟合。
很多人只会机械背参数名,但真正有用的是知道哪种现象对应哪种调整。比如训练 loss 很快贴地但验证集没起色,往往要先怀疑数据和过拟合,而不是一味把 r 拉高。
13. Python 里的浅拷贝和深拷贝,为什么在线上代码里经常埋坑
浅拷贝只复制最外层容器,内部嵌套对象仍然共享引用;深拷贝会递归复制所有子对象。坑点在于很多工程代码
剩余60%内容,订阅专栏后可继续查看/也可单篇购买
本专栏聚焦 AI-Agent 面试高频考点,内容来自真实面试与项目实践。系统覆盖大模型基础、Prompt工程、RAG、Agent架构、工具调用、多Agent协作、记忆机制、评测、安全与部署优化等核心模块。以“原理+场景+实战”为主线,提供高频题解析、标准答题思路与工程落地方法,帮助你高效查漏补缺.


查看5道真题和解析