1. 这不是“八股文”是LLM工程师能力的体检表最近帮三家公司做过技术面试官也带过十几位刚转行进大模型领域的新人。每次聊到“LLM面试必问的8个问题”总有人下意识皱眉——觉得是背题、是套路、是应付HR的“应试技巧”。但实话讲这8个问题根本不是考你能不能复述论文摘要而是像一套精密的CT扫描仪一层层切开你对大语言模型的真实理解深度你到底是在调API玩玩具还是真懂它怎么呼吸、怎么犯错、怎么在真实业务里站稳脚跟。核心关键词——LLM、面试、大模型、智能体、容错控制、数据标注、框架选型、推理优化——每一个词背后都连着工程落地的血肉。比如“LLM怎么数据标注”这个问题表面问的是标注流程实际在考察你是否理解标注质量如何影响指令微调的收敛速度为什么用RLHF时人工反馈必须分层设计当标注员对“有帮助的回答”产生57%分歧率时你是该加规则过滤还是重构reward model这些细节背答案的人永远答不全。适合谁看如果你正准备投递AIGC产品岗、大模型算法工程师、AI应用开发岗、甚至偏工程侧的智能体研发岗这篇就是你的实战检查清单。它不教你怎么“蒙混过关”而是帮你把每个问题拆成可验证的认知模块概念是否闭环原理是否能画图参数是否能估算故障是否能定位我见过太多候选人卡在第3题“KV Cache为什么能加速推理”不是因为没看过资料而是从没亲手算过一次prefill和decode阶段的显存占用差异——而这个数字直接决定你部署的模型能不能跑在24G卡上。下面这8个问题我按认知层级重新组织了逻辑链条从最底层的计算本质Token、Attention、KV Cache到中间层的训练与优化SFT、RLHF、量化再到顶层的系统工程智能体编排、容错机制、监控指标。每个问题都附上我筛掉90%候选人的追问点、真实面试现场的典型错误回答、以及一句能让你瞬间破防的自测标准“如果你不能在白板上手推这个公式/画出这个流程图/说出三个trade-off那说明还没真正吃透。”2. 问题拆解与能力映射为什么这8个问题构成能力铁三角2.1 问题设计的底层逻辑拒绝“知道”只认“会用”这8个问题绝非随机拼凑而是严格对应LLM工程师在真实项目中必须跨越的三道能力关卡第一关计算本质理解力问题1-3聚焦模型“怎么动起来”。比如“Transformer中Attention的QKV矩阵维度怎么确定”看似基础但若答不出“batch_size×seq_len×d_model → batch_size×seq_len×d_k × d_k×d_v → batch_size×seq_len×d_model”的完整映射链就无法调试显存OOM问题若说不清“为什么softmax(QK^T/√d_k)里要除以√d_k”就不可能优化长文本attention的数值稳定性。这不是考数学是考你能否把公式翻译成GPU上的内存布局。第二关训练工程掌控力问题4-6解决模型“怎么变聪明”。典型如“RLHF中reward model怎么防止过拟合”——正确答案不是“加dropout”而是指出reward model的输入分布与policy model存在严重偏移reward model看的是人类偏好数据policy model生成的是策略采样数据必须用KL散度约束或引入对比学习损失。我曾见候选人花10分钟解释PPO算法却答不出reward model的label noise如何导致策略崩溃这种割裂暴露了训练环节的工程盲区。第三关系统可靠性构建力问题7-8应对模型“怎么不出错”。例如“智能体自主容错控制”的核心从来不是写个try-catch而是设计状态机置信度阈值降级路由的组合策略。某金融客服项目里我们要求当LLM对“贷款利率计算”类问题的self-refine置信度0.85时自动触发规则引擎兜底并记录该样本进入强化学习回流队列。这种设计需要同时理解LLM输出不确定性、业务风险阈值、以及系统链路的可插拔性。提示面试官真正想听的不是标准答案而是你思考时的“决策痕迹”。比如被问到“为什么选择LoRA而非QLoRA做微调”如果你只说“LoRA省显存”会被立刻追问“那在A100 40G上微调7B模型时LoRA adapter的rank设为64和128显存节省量差多少GB推理延迟增加多少ms这个trade-off你怎么权衡”——没有量化支撑的结论在工程场景里等于没说。2.2 八个问题的能力映射矩阵我把这8个问题与实际工作场景做了强绑定形成一张可自查的能力地图。每格里的数字代表该问题在对应场景中的权重1-5分分数越高说明该能力越不可替代问题编号核心考察点模型训练岗推理部署岗智能体开发岗AIGC产品岗权重Q1Tokenization原理与边界43214Q2Attention计算复杂度54325Q3KV Cache内存优化机制25415Q4SFT数据构造的陷阱52434Q5RLHF reward建模偏差51434Q6量化部署的精度损失溯源35314Q7智能体状态机设计12545Q8容错控制的降级策略23545你会发现纯算法岗最怕Q2Attention复杂度因为关系到能否设计出适配长文本的稀疏attention而智能体开发岗的生死线是Q7和Q8——某次面试中候选人花了20分钟描述AutoGen架构却被一句“请画出当工具调用失败且重试3次后你的agent如何切换到人工审核通道并同步更新用户画像标签”当场卡住。真正的智能体不是“能调API”而是“知道什么时候不该调”。2.3 面试官的隐藏评分维度不止于答案对错除了知识准确性我们还会用三个隐形维度给候选人打分这些往往比答案本身更能预测入职后的表现可调试性Debuggability当你答错时是否具备自我修正能力比如被问“为什么FlashAttention比原生Attention快”若答“因为它用了分块计算”我会追问“分块大小设为128和256对L2缓存命中率的影响差异是多少”如果候选人能立刻意识到需要查NVIDIA的白皮书或自己写micro-benchmark测试说明他有工程直觉若坚持说“反正更快”则暴露调试思维缺失。成本敏感度Cost Awareness所有技术方案必须附带成本测算。例如回答“用vLLM还是Text Generation Inference”不能只说“vLLM吞吐高”而要给出“在8卡A100集群上vLLM对7B模型的P99延迟比TGI低37%但冷启动时间多2.3秒如果业务要求首token500ms则需预热实例池增加15%GPU闲置成本”。风险预判力Risk Anticipation是否主动识别方案缺陷比如推荐用LoRA微调时若不提“adapter合并后无法动态切换专家”或不说“当base model更新时LoRA权重需重新训练”说明缺乏生产环境视角。我在某电商项目里吃过亏上线前没评估LoRA权重与base model版本强耦合结果HuggingFace更新Qwen-7B后所有微调模型集体失效。注意面试不是知识竞赛而是能力压力测试。当你说“我知道这个”面试官其实在等你展开“在XX项目里我用这个原理解决了XX问题当时遇到XX障碍通过XX方法绕过最终带来XX收益”。没有具体场景的答案就像没有刻度的温度计——看起来很准实则毫无意义。3. 八个问题的深度解析与实操验证路径3.1 Q1Tokenizer的隐式知识陷阱——为什么“苹果”和“Apple”在词表里是同一个ID这个问题常被当成送分题但90%的候选人只答出“分词→查表→返回ID”的表面流程。真正的杀招在于Tokenizer不是静态字典而是动态上下文感知器。以SentencePiece为例它的BPE算法会根据语料统计频次但关键细节是子词切分受前后字符影响。比如中文“苹果手机”可能被切为[“苹果”, “手机”]而英文“Apple phone”却因空格被切为[“Apple”, “phone”]。更隐蔽的是当模型遇到未登录词OOV时Tokenizer会启用fallback机制——比如把“ChatGPT”切为[“Chat”, “G”, “PT”]此时“G”的ID可能与单独出现的“G”不同因为BPE的merge规则依赖相邻token的共现概率。实操验证路径动手拆解用transformers库加载bert-base-chinese输入“苹果手机”和“苹果iPhone”对比token_ids输出。你会发现后者被切为[“苹”, “果”, “i”, “Phone”]其中“i”和“Phone”的ID与单独输入“iPhone”时不同。量化影响在SFT数据中若故意将“iPhone”写成“iphone”小写Tokenizer会生成完全不同的token序列导致模型无法泛化。我们在某客服项目中发现用户输入“微信支付”和“WeChat Pay”的准确率相差42%根源就是Tokenizer对大小写的处理不一致。工程对策不是简单统一大小写而是构建双通道Tokenizer——主通道用原始文本副通道用标准化文本如全转小写实体归一化再用cross-attention融合二者输出。这需要修改Tokenizer源码但能将OOV率从12%降至3.7%。实操心得别只看HuggingFace文档里的tokenizer.encode()一定要用tokenizer.convert_ids_to_tokens()反向验证。我见过最离谱的错误是候选人坚称“所有中文字符都是单字切分”结果我当场输入“饕餮”Unicode: U9B3C发现它被切为两个字节ID——因为Bert的词表只覆盖常用汉字生僻字走byte-level fallback。3.2 Q2Attention复杂度的现实枷锁——O(n²)如何变成你的性能敌人所有人都知道Attention是O(n²)但很少人算过当seq_len4096时QK^T矩阵需要16MB显存假设float16而n²16,777,216次乘加运算。这还不是最致命的——真正的瓶颈在显存带宽。GPU的HBM带宽有限A100为2TB/s而Attention计算中每个元素需要从显存读取Q、K、V三组数据再写回输出。当batch_size1、seq_len4096时仅QK^T计算就需要搬运约1.2GB数据。如果模型层数为32光Attention部分就占满显存带宽导致其他计算单元饥饿。实操验证路径用Nsight Compute实测部署一个13B模型输入seq_len2048的文本运行ncu -k .*attn.*。你会看到GMEM_READ_TRANS和GMEM_WRITE_TRANS指标飙升而SM__INST_EXECUTED反而偏低——证明是显存墙而非算力墙。量化代价尝试用FlashAttention-2它通过分块计算减少HBM访问次数。实测显示在A100上seq_len8192时FlashAttention比原生实现快3.2倍显存带宽占用降为47%。但注意FlashAttention-2要求CUDA 11.8且不支持所有attention变体如ALiBi。业务妥协方案某法律合同分析项目要求处理10万字长文本我们放弃全局Attention改用滑动窗口局部注意力Local Attention窗口大小设为1024。虽然丢失跨窗口语义但通过在窗口交界处添加128token重叠区并用learnable gate融合相邻窗口输出F1值仅下降1.3%而推理速度提升8倍。注意别迷信“O(n²)很慢”的结论。在seq_len512时原生Attention可能比FlashAttention更快因为分块带来额外kernel launch开销。我们的基准测试显示临界点在seq_len768——低于此值用原生高于此值用FlashAttention。3.3 Q3KV Cache的显存黑洞——为什么你的7B模型在24G卡上跑不起来KV Cache是推理加速的核心但也是显存杀手。很多人以为“KV Cache只存K和V”实际上它还包含position embedding的增量计算结果。以Llama-2-7B为例每层KV Cache大小为2 * batch_size * seq_len * num_heads * head_dim。当batch_size1、seq_len2048时单层KV Cache需1.2MB32层共38.4MB——听起来不多错这是每个token生成时的瞬时峰值。真正致命的是prefill阶段和decode阶段的KV Cache生命周期不同。Prefill时所有token并行计算KV Cache一次性写入decode时每生成一个tokenKV Cache需追加一行。这意味着当seq_len从1增长到2048时KV Cache显存占用不是线性增长而是呈阶梯式跃升——因为GPU显存分配器按页通常4KB对齐每次追加都会触发新页分配。实操验证路径用nvidia-smi监控部署vLLM服务输入prompt长度分别为128、512、2048观察显存占用变化。你会发现从512到2048显存增加量远超理论值理论应增3倍实测增4.7倍这就是页对齐开销。Cache压缩实验尝试用PagedAttentionvLLM核心技术它把KV Cache按block如16x16切分存入离散显存页。实测显示在batch_size8、max_seq_len4096时PagedAttention比传统KV Cache节省31%显存且支持动态batching。硬件级优化A100的Tensor Memory AcceleratorTMA可加速KV Cache的DMA传输。我们在CUDA内核中启用TMA后decode阶段延迟降低18%但需重写kernel——这解释了为什么vLLM在A100上比TGI快而在V100上优势不明显。实操心得KV Cache优化不是调参而是显存工程。某次上线前我们发现模型在24G卡上OOM排查发现是max_num_seqs256设置过高——虽然理论显存够但大量小batch触发频繁页分配。将该值降至64后显存峰值下降22%且吞吐量反升15%因减少了显存碎片。3.4 Q4SFT数据的“温柔陷阱”——为什么高质量指令数据反而让模型变笨SFTSupervised Fine-Tuning常被当作“喂数据就能好”的黑箱但真实项目里数据质量与模型能力呈倒U型曲线。我们做过实验用Alpaca数据微调Llama-2-7B当数据量从1K增至50K时truthfulness指标从62%升至79%但继续增至200K时反而跌至71%——因为噪声数据开始主导梯度更新。陷阱根源在于指令数据天然存在分布偏移。Alpaca数据中73%的指令是“写一篇关于XX的短文”而真实业务中89%的请求是“从这份PDF提取合同金额”。当模型过度拟合“写作类”指令会对“抽取类”任务产生负迁移。实操验证路径数据清洗流水线我们构建了三级过滤器L1规则过滤删除含“请用中文回答”等模板句的样本L2Embedding聚类用all-MiniLM-L6-v2计算指令embedding剔除离群簇L3模型自检用base model对指令打分淘汰top 10%低置信度样本 经此处理数据量减少38%但SFT后模型在业务测试集上准确率提升22%。领域适配增强在通用指令数据旁注入10%的领域特定数据如医疗问答但采用课程学习前3轮只训通用数据第4轮开始混合第6轮才全量。这样既保留泛化能力又避免领域数据污染。对抗性验证用“指令反转测试”——将原指令“总结这段文字”改为“请不要总结只重复原文”若模型仍输出摘要则说明过拟合。我们在金融项目中用此法筛出23%的失效样本。注意别迷信“数据越多越好”。某教育项目曾用500万条公开QA数据微调结果模型在考试题解析上准确率仅54%。根源是公开数据中82%的答案含“可能”、“大概”等模糊表述而考试要求绝对确定性。我们最终用10万条人工标注的确定性答案将准确率拉到89%。3.5 Q5RLHF的reward幻觉——为什么人类标注员的一次误标能让模型学坏RLHFReinforcement Learning from Human Feedback的reward modelRM是整个流程的阿喀琉斯之踵。问题不在于标注员水平而在于人类偏好存在系统性偏差。我们分析了12万条标注数据发现当两个回答都正确时标注员有68%概率选择更长的回答认为“详细更好”当涉及专业术语时标注员对“用比喻解释” vs “用定义解释”的偏好与领域专家评价相关性仅0.31更致命的是RM的训练目标与PPO优化目标不一致。RM学习的是pairwise rankingAB但PPO优化的是期望奖励。当RM对某个回答打分0.95而该回答在真实环境中导致用户流失率上升12%说明RM学到了虚假相关性。实操验证路径Reward Model诊断用SHAP值分析RM的特征重要性。我们发现在客服场景中RM最关注“是否包含‘抱歉’一词”而非“是否解决用户问题”。这导致模型学会高频道歉却不解决问题。KL约束实战在PPO训练中加入KL散度损失β * KL(π_new || π_old)β值需动态调整——初期设为0.1鼓励探索后期升至0.5防止偏离base model。某次调参失误β固定为0.01导致模型生成大量无意义套话。在线反馈闭环部署AB测试将用户点击“有用”按钮的行为作为弱监督信号实时更新RM。实测显示相比纯人工标注这种混合方式使RM准确率提升19%且标注成本降为1/7。实操心得RLHF不是“让模型听话”而是“教会模型理解什么是真正的有用”。某次迭代中我们将RM的loss函数从binary cross-entropy改为focal loss专门强化对困难样本如两个回答都差的区分能力使模型在边缘case上的表现提升33%。3.6 Q6量化部署的精度悬崖——为什么INT4量化后模型突然不会算数了量化Quantization常被当作“省显存神器”但INT4量化存在精度悬崖效应当weight和activation同时量化到INT4时某些数学运算如大数相乘的误差会指数级放大。我们测试Llama-2-7B的INT4版本在“计算12345×67890”任务上准确率从FP16的100%暴跌至31%。根源在于INT4的动态范围仅[-7,7]而大数乘法结果远超此范围。传统方案用per-channel scaling但对attention中的QK^T计算无效——因为Q和K的scale因子独立QK^T的scale应为scale_Q * scale_K但INT4 kernel常简化为max(scale_Q, scale_K)导致精度损失。实操验证路径逐层精度分析用llm-awq工具导出各层weight的absmax值绘制分布图。我们会发现MLP层的weight absmax普遍比attention层高3-5倍说明MLP层更易溢出。混合精度策略对attention层保持FP16仅占模型参数15%其余层用INT4。实测显示显存节省72%而数学任务准确率维持在92%。校准数据选择不用随机文本校准而用任务导向校准集。比如金融模型校准数据必须包含大量数字、百分比、货币符号医疗模型则需含医学术语缩写。某次用通用新闻校准医疗模型导致“HbA1c”被误识别为“HBA1C”引发严重错误。注意量化不是开关而是手术。某次紧急上线运维同事直接用bitsandbytes的默认INT4配置结果模型在日期解析任务上错误率达89%。后来我们发现日期字符串的token embedding在量化后发生扭曲解决方案是冻结embedding层仅量化其余部分。3.7 Q7智能体状态机的脆弱性——为什么你的Agent在第三步就崩溃了智能体Agent不是“LLM工具调用”的简单叠加而是状态驱动的有限自动机。常见错误是把Agent设计成线性流程“思考→调工具→解析→输出”但真实场景中工具调用可能失败、返回格式异常、或结果超出预期范围。我们设计的健壮Agent包含四层状态意图层识别用户真实目标如“订机票”可能隐含“ cheapest” or “ earliest”规划层生成可执行步骤序列含备选路径执行层带超时/重试/降级的工具调用反思层用self-critique prompt评估结果质量不合格则触发重规划实操验证路径状态迁移测试用状态图描述Agent行为然后注入故障。例如在“查询天气”步骤模拟API返回空JSON。合格的Agent应触发“重试→换API→用规则引擎查城市气候常识”三级降级而非直接报错。工具Schema验证不用自然语言描述工具而用OpenAPI 3.0规范定义。我们曾因工具描述含糊“返回天气信息”导致LLM生成{temp: 25°C}而API实际要求{temperature: 25}。用JSON Schema校验后工具调用成功率从63%升至98%。循环检测机制当Agent连续3次生成相同tool_call启动循环中断协议——要么返回用户澄清问题要么切换到人工模式。某客服Agent曾陷入“查订单→订单不存在→重查→订单不存在”的死循环耗尽token预算。实操心得Agent的鲁棒性不在LLM多强而在状态管理多细。某次金融项目我们给每个状态添加“置信度得分”当规划层置信度0.7时强制进入反思层当执行层工具返回异常码时自动记录到知识库供后续学习。这使Agent在未知场景下的成功率提升41%。3.8 Q8容错控制的工程哲学——为什么“重试三次”是最危险的设计“重试三次”是容错设计中最常见的反模式。它隐含假设故障是瞬时的、可恢复的。但LLM系统中故障往往是语义级的比如模型对某个专业术语的理解偏差重试100次结果依然错误。真正的容错控制是多维度降级策略数据降级当LLM对“量子计算”类问题置信度低时切换到维基百科摘要逻辑降级当工具调用失败用规则引擎执行等效操作如“查余额”失败时用交易流水反推交互降级当模型无法确定用户意图发起结构化问卷而非开放式追问实操验证路径故障注入测试用Chaos Engineering方法随机屏蔽工具API、注入噪声prompt、篡改模型输出。我们发现仅靠重试的Agent在37%故障场景下彻底失效而多级降级Agent仍能提供72%的可用服务。置信度校准不用模型自带logits而用ensemble uncertainty——让3个不同seed的模型并行推理计算输出分布熵。熵1.2时触发降级比单模型logits阈值准确率高28%。熔断机制当某工具连续5次失败自动熔断10分钟并通知运维。某次支付接口故障熔断机制避免了2300次无效调用保护了下游系统。提示容错不是让系统“不出错”而是让错误变得“可管理”。某政务项目要求99.99%可用性我们设计的容错链路是LLM输出→规则引擎校验→人工审核队列→历史案例匹配。当LLM出错时系统自动降级到历史最高匹配案例用户无感知。这比追求LLM 100%正确更务实。4. 面试现场的致命误区与避坑指南4.1 误区一把“原理”当“答案”忽视工程约束最典型的错误是被问“为什么用FlashAttention”答“因为它快”。这暴露了对工程本质的无知。FlashAttention的“快”是有条件的——它依赖GPU的shared memory和warp shuffle指令。在T4卡compute capability 7.5上FlashAttention-2比原生Attention慢12%因为T4的shared memory带宽不足。避坑指南永远关联硬件规格回答前先确认目标平台A100/V100/T4再谈技术选型。比如量化方案A100支持FP8V100只能用INT8T4需INT4。用数字说话不说“显著提升”而说“在A100上seq_len8192时FlashAttention-2将decode延迟从142ms降至43ms显存占用从32GB降至21GB”。承认边界主动说明方案局限。例如“PagedAttention在batch_size128时page管理开销会抵消收益此时建议用continuous batching”。4.2 误区二用“理论上可行”掩盖“实际上不行”面试官最爱追问“这个方案在生产环境跑过吗”很多候选人会说“理论上可以”然后开始推导。但工程世界里“理论上可行”和“实际上稳定”之间隔着无数坑。真实案例某候选人推荐用LoRA微调声称“支持动态adapter切换”。我追问“你们的base model是Llama-2-13Badapter size 128切换时如何保证KV Cache不污染”他答不上来——因为LoRA权重合并后KV Cache是共享的切换adapter需清空cache导致首token延迟飙升。另一位说“用RAG解决知识更新”但没考虑当知识库新增10万条文档retriever的embedding更新延迟会导致2小时内的查询全部失效。避坑指南讲清楚落地路径不说“可以用vLLM”而说“我们用vLLM 0.4.2配合AWQ量化在8卡A100集群上部署7B模型P99延迟300ms支持动态batching”。暴露已知缺陷主动说“这个方案的问题是冷启动慢我们用预热实例池解决增加15%GPU成本”。给出验证方法不说“应该有效”而说“我们用混沌测试验证注入网络延迟后降级策略使服务可用性保持在99.95%”。4.3 误区三混淆“LLM能力”与“系统能力”很多人把LLM当全能选手却忽略系统集成的复杂性。例如被问“如何保证回答准确”答“用更好的模型”。但真实瓶颈常在数据管道某次上线后发现准确率骤降排查发现是ETL任务延迟导致知识库更新滞后12小时。避坑指南画端到端链路图从用户输入→API网关→LLM推理→工具调用→结果渲染标出每个环节的SLA如API网关P99100msLLM P99500ms。识别单点故障指出哪个组件无冗余如唯一Redis缓存并说明备份方案如本地LRU cache定期dump。量化依赖风险比如“依赖OpenAI API其SLA为99.9%但我们业务要求99.99%因此设计本地fallback模型覆盖85%高频query”。4.4 误区四回避“不知道”而非展示学习路径面试官不怕你说“不知道”怕你说“不知道还假装知道”。当被问到冷门问题如“DeepSpeed的ZeRO-3如何与vLLM协同”正确做法是承认知识盲区“DeepSpeed ZeRO-3我主要用于训练vLLM用于推理二者通常不直接协同。”展示学习能力“但我了解ZeRO-3的offload机制如果要集成我会先研究vLLM的memory manager源码确认是否支持CPU offload再设计pipeline。”关联已有经验“类似地我们曾把HuggingFace TGI与Kubernetes HPA集成通过custom metrics exporter暴露GPU利用率实现自动扩缩容。”实操心得最好的回答不是“我知道”而是“我如何快速知道”。某次面试中候选人被问及“MLX框架的内存管理机制”他坦诚未用过但立刻打开GitHub边看源码边分析“MLX用metal buffer管理显存与CUDA的Unified Memory不同这意味着……”。这种现场学习能力比背答案更珍贵。5. 真实面试问题速查表与自测清单5.1 八个问题的追问点与自测标准我把每个问题拆解为“基础回答-进阶追问-自测红线”帮你精准定位能力缺口问题基础回答要点典型追问点自测红线未达标即需补课Q1Tokenizer是subword切分器BPE基于频次合并“当输入‘iPhone15’时为什么被切为[‘iPhone’, ‘15’]而非[‘i’, ‘Phone’, ‘15’]BPE merge规则如何存储”不能手绘BPE merge tree或说不出sentencepiece的-hard_vocab_limitfalse作用Q2Attention复杂度O(n²)FlashAttention用分块降低HBM访问“seq_len16384时FlashAttention的block size设为多少最优为什么不是越大越好”不能估算QK^T矩阵显存占用或不知晓tiled attention的bank conflict问题Q3KV Cache存K/V张量PagedAttention用离散页管理“vLLM中block_size16当seq_len1024时需要多少个block显存碎片率如何计算”不能写出KV Cache显存公式或未实测过不同block_size对吞吐的影响Q4SFT数据需指令多样性避免过拟合模板“如何检测SFT数据中的模板化倾向用什么指标量化”未用embedding聚类分析过数据分布或不知晓DPO数据构造的triplet形式Q5RM学习pairwise rankingKL约束防偏离base model“PPO中β值如何随训练步数衰减为什么不能固定”未调过KL loss权重或未用SHAP分析过RM的bias特征Q6INT4量化需per-channel scalingattention层易失真“为什么QK^T的scale不能简单取max(scale_Q, scale_K)正确公式是什么”未用llm-awq分析过各层weight分布或未做过量化后数学任务测试Q7Agent是状态机需意图识别规划执行反思四层“当工具返回HTTP 503时