大模型工程师的8个硬核能力考察点：从推理到部署的工程真相-开发者社区

1. 这不是“八股文”，是大模型时代工程师的生存底线

最近帮朋友内推了三位应届生，两位卡在技术面第二轮——不是算法题没写出来，而是被问到“你用的LLM，它的KV Cache是怎么复用的？”“为什么RoPE比绝对位置编码更适合长文本？”当场愣住。第三位倒是答上来了，但追问一句“如果把FlashAttention换成标准Attention，你的推理延迟会涨多少？怎么估算？”就再没往下接。这让我意识到：现在所谓“LLM面试八股文”，根本不是考死记硬背，而是用8个问题当探针，扎进候选人对大模型底层工程逻辑的真实理解深度里。LLM、面试、模型、推理、训练、数据、评估、部署——这八个词背后，是整个AI基础设施栈的缩影。你答不上来，不是知识储备不够，而是没真正跑过一个模型、没调过一次显存、没看过一次profiler火焰图。我带过的实习生里，凡是能独立在A100上把Llama-3-8B跑通量化+LoRA微调+vLLM服务化的，哪怕代码风格乱点，面试官基本直接放行；反之，简历写满“精通Transformer”，连kv_cache是否需要在batch内共享都说不清的，再漂亮的项目经历也难救。这8个问题，本质是筛选“能动手改模型”的人，而不是“能复述论文摘要”的人。适合两类人重点看：一是准备跳槽的算法/后端/AI Infra工程师，二是刚从学校出来、手头只有HuggingFace demo notebook的同学。别把它当应试技巧，它是一张能力体检表——每答错一题，就暴露一个你没亲手踩过的坑。

2. 问题拆解与底层逻辑：为什么这8个问题成了硬门槛？

2.1 问题设计的底层意图：从“知道”到“掌控”的分水岭

这8个问题绝非随机拼凑，而是按AI系统开发流程的六个关键断层点设计：数据输入→模型结构→训练机制→推理优化→评估验证→生产部署。每个问题都卡在理论与实操的缝隙里——教科书讲清楚了Attention计算，但不会告诉你为什么FlashAttention的shared memory bank size要设为128；论文写明了LoRA原理，但不提在Qwen2-7B上做全量微调时，梯度检查点（gradient checkpointing）开不开，显存占用差1.8GB。我整理过近半年23家公司的LLM岗位JD，发现高频要求已从“熟悉Transformer”升级为“能解释vLLM中PagedAttention的内存页大小如何影响吞吐”。这8个问题，就是把这种隐性能力显性化。比如第一个问题“为什么LLM输出是逐token生成的？能不能并行解码？”，表面考生成机制，实际在测你是否理解GPU的SM（Streaming Multiprocessor）资源调度逻辑：自回归生成本质是串行依赖，强行并行会导致KV Cache写冲突，而Speculative Decoding这类方案，核心是用小模型“猜”多个token再由大模型验证——这需要你懂CUDA kernel launch的同步开销。再如“RLHF中reward model怎么训？为什么不用监督微调替代？”，考的不是强化学习公式，而是你有没有在真实场景中遇到过reward hacking：当reward model只看回复长度打分，模型就学会堆砌无意义长句。这些细节，只在你亲手调过reward loss曲线、看过KL散度爆炸的tensorboard日志时才会刻骨铭心。

2.2 领域适配性：不同岗位的考察权重差异

不同角色对这8个问题的侧重天差地别。以我参与过的三类岗位面试为例：

算法工程师岗：重点深挖第3题（训练稳定性）、第4题（数据质量）、第6题（评估指标）。曾有候选人流畅讲完PPO流程，但被问“你在reward model训练时，怎么处理用户标注的噪声数据？用的是Jensen-Shannon divergence还是KL？为什么？”就卡壳了——他没做过真实标注清洗，所有方案都是纸上谈兵。
AI Infra工程师岗：死磕第1题（推理机制）、第5题（量化压缩）、第7题（服务框架）。某次面试让候选人现场画vLLM的memory pool管理图，结果发现80%的人连“block table”和“sequence group”的关系都说反——这直接暴露其没读过vLLM源码的core/llm_engine.py。
AI产品经理岗：聚焦第2题（模型能力边界）、第8题（部署成本）。曾让一位候选人估算：“用Qwen2-72B在AWS g5.48xlarge（4×A10G）上部署API服务，支持100并发，单请求平均延迟目标2s，你选什么量化方案？显存够吗？瓶颈在CPU还是GPU？”——这题不考代码，考的是对硬件参数、网络IO、模型计算量的综合直觉。真正能算出来的，要么做过压测，要么用过NVIDIA Nsight Systems分析过kernel耗时。

提示：如果你是应届生，别急着背答案。先去HuggingFace下载一个Llama-3-8B-GGUF文件，在Mac M2 Max上用llama.cpp跑起来，手动改--n-gpu-layers参数观察显存变化；再用Ollama拉起一个Phi-3-mini，用curl发100个并发请求，用htop看CPU负载。这些动作比刷100道题更管用。

2.3 考察维度的三维穿透：原理、调试、权衡

每个问题都要求三维能力：原理层（Why it works）、调试层（How to verify）、权衡层（Trade-off analysis）。以第5题“LLM量化有哪些方法？各自适用场景？”为例：

原理层：需说清AWQ的activation-aware clipping如何避免outlier channel失真，而GGUF的quantization group size=32为何比group size=128更抗精度损失；
调试层：得知道用llama.cpp的--verbose-prompt参数打印量化前后weight的L2误差分布，或用transformers的torch.quantization模块导出fake quant模型对比logits；
权衡层：要能判断——在边缘设备部署时，INT4比FP16省75%显存，但attention softmax精度下降导致长文本连贯性变差，这时该牺牲多少吞吐换稳定性？我见过最扎实的答案来自一位嵌入式工程师，他掏出手机展示自己用TensorRT-LLM在Jetson Orin上跑Qwen2-1.5B的profiling截图，指着“dequantize_matmul” kernel耗时占比42%说：“这里就是瓶颈，所以我在onnx graph里把linear层fuse成int8 matmul+dequant，延迟降了3.2倍”。

这种三维穿透能力，无法靠短期突击获得。它需要你把模型当“黑盒”拆开过至少三次：第一次看架构图，第二次读源码，第三次调profiler。

3. 核心问题逐题解析：从原理到实操的完整链路

3.1 问题1：为什么LLM输出是逐token生成的？能否真正并行解码？

这个问题常被简化为“因为自回归”，但真实瓶颈远不止于此。逐token生成的本质，是GPU硬件执行模型与计算依赖关系的矛盾统一。我们拆解三层：

第一层：计算依赖
Transformer Decoder的每个token生成，必须等待前序所有token的KV Cache计算完成。数学上，第t个token的attention输出为：
Attn_t = softmax(Q_t @ K_{1:t}^T / sqrt(d_k)) @ V_{1:t}
其中K_{1:t}、V_{1:t}是前t-1个token的缓存。这意味着t时刻的Q_t必须等1~t-1时刻的K/V写入显存后才能读取——这是数据依赖，无法绕过。

第二层：硬件约束
即使忽略依赖，GPU的SM（Streaming Multiprocessor）资源也限制并行。以A100为例，单个SM有1024个CUDA core，但一个完整的LLM前向传播（含FFN、RMSNorm、RoPE）需占用大量寄存器和shared memory。实测Llama-3-8B单token推理约消耗32个SM，若强行并行10个token，需320个SM，而A100仅108个SM，必然触发warp调度阻塞，实际吞吐反而下降。我用Nsight Compute抓过trace：当batch_size=1时，SM利用率峰值达89%；batch_size=10时，因shared memory bank conflict，利用率跌至41%。

第三层：工程实践
真正的“并行解码”方案如Speculative Decoding，本质是用小模型预测+大模型验证的异步流水线。关键不在“并行”，而在降低大模型的token生成次数。例如用1.3B模型预测5个token，大模型只需验证这5个而非逐个生成——这节省的是大模型的compute time，而非消除依赖。实操中要注意：小模型预测准确率低于70%时，验证开销会超过收益。我在vLLM中配置speculative_model时，通过--speculative-model指定Phi-3-mini，再用--speculative-draft-tokens设为3，压测发现当TPS>50时，准确率稳定在68%，此时端到端延迟比baseline低37%。

注意：网上流传的“用beam search并行”是误导。Beam search的并行发生在同一层的不同candidate之间，但各candidate仍需串行生成下一个token。真正提升吞吐的是增大batch_size，而非单序列并行。

3.2 问题2：LLM的“幻觉”本质是什么？如何从数据和模型层面缓解？

“幻觉”不是模型“胡说”，而是概率分布采样与训练数据偏差的耦合失效。我们拒绝玄学解释，用三个可测量的指标定位：

数据层根因

事实密度（Fact Density）：指训练数据中明确陈述客观事实的比例。用OpenBookQA数据集测试，发现Llama-2-7B在高fact density数据上幻觉率12%，低density数据上飙升至47%。解决方案不是加更多数据，而是构建fact-aware filtering pipeline：用SPARQL查询Wikidata，提取实体三元组，过滤掉“XX可能是YY”这类模糊表述的句子。
领域偏移（Domain Shift）：模型在维基百科上训练，却在医疗问答中使用。我处理过一个案例：某医疗LLM在“糖尿病并发症”问题上幻觉率达31%，经分析发现训练数据中78%的糖尿病相关文本来自患者论坛（含大量错误经验），仅22%来自临床指南。解决方式是重加权loss：对指南来源样本的loss乘以权重2.5，使模型更关注权威数据。

模型层根因

logit尖锐度（Logit Sharpness）：用entropy衡量。高entropy表示模型对多个token信心接近，易选错；低entropy表示过度自信。实测发现幻觉样本的平均logit entropy比正确样本低23%。缓解方案是temperature scaling：将softmax温度从1.0调至1.3，使分布更平滑。但注意——这会降低响应“确定性”，需在accuracy和fluency间权衡。
注意力坍塌（Attention Collapse）：当模型对无关token分配过高attention weight时发生。用captum库可视化Llama-3-8B的attention map，发现幻觉样本中，52%的head在生成“治疗方案”时，将60%以上weight分配给“患者年龄”这类无关token。解决方案是attention regularization：在训练时加入loss项λ * ||A - I||_F^2，强制attention matrix接近单位阵，实测使幻觉率下降18%。

工程验证
别信“缓解幻觉”的空话。必须做三件事：

构建幻觉检测pipeline：用BERTScore计算生成文本与参考答案的token overlap，overlap<0.3且包含未在prompt中出现的新实体，即标记为幻觉；
AB测试：在真实业务流中，对同一query用原模型和优化模型各跑1000次，统计幻觉率变化；
人工审计：抽样200条幻觉case，分类为“事实错误”“逻辑断裂”“虚构引用”，针对性优化。

3.3 问题3：训练时Loss突然飙升，可能原因及排查步骤？

Loss spike不是bug，是模型在告诉你“这里有问题”。我总结过127次Loss spike的根因，92%集中在三类：

数据问题（占比58%）

异常token：训练数据中混入不可见字符（如U+200B零宽空格），tokenizer将其映射为unk token，导致embedding lookup返回全零向量。解决方案：用tokenizers库的pre_tokenizer.pre_tokenize_str()预检数据，过滤含\u200b的行。
长度突变：batch中某样本长度远超其他（如99%样本<512，1%样本=4096），导致padding过多，有效token占比骤降。实测会使loss spike 300%。对策：动态batching——按长度分桶，每桶内样本长度差<64。HuggingFace的DataCollatorForSeq2Seq支持此功能，需设pad_to_multiple_of=64。

硬件/框架问题（占比27%）

GPU显存泄漏：PyTorch 2.1+的torch.compile在某些CUDA版本下存在内存泄漏，连续训练2小时后显存占用增长40%，触发OOM killer。解决方案：禁用compile，或升级到PyTorch 2.3。
梯度溢出（Gradient Overflow）：混合精度训练中，loss scaler未能及时调整scale值。当scale过大时，梯度更新后参数变为inf。排查命令：torch.isfinite(model.parameters()).all()，若返回False，则用torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)强制裁剪。

模型架构问题（占比15%）

LayerNorm数值不稳定：当输入方差过大时，LN的1/sqrt(var+eps)产生nan。根源常是初始化不当。解决方案：用torch.nn.init.xavier_normal_初始化linear层，而非默认的kaiming。
RoPE位置外推失败：在训练时最大长度为2048，推理时用4096，RoPE的cos/sin值超出预计算范围，导致attention score异常。对策：训练时用rope_theta=10000.0，推理时用rope_scaling={"type": "linear", "factor": 2.0}。

标准化排查流程（我团队内部SOP）：

立即保存当前checkpoint和loss curve；
检查nvidia-smi显存占用是否持续上升；
用torch.autograd.set_detect_anomaly(True)重跑最后10步，定位nan梯度源头；
抽样spike时刻的batch，用tokenizer.decode(batch['input_ids'][0])查看原始文本；
若无异常，重启训练并启用torch.compile(mode="reduce-overhead")。

3.4 问题4：如何评估LLM生成内容的质量？BLEU/ROUGE是否还适用？

BLEU/ROUGE已死，但很多人还在用。它们的问题在于：把语言当成字符串匹配游戏，无视语义、事实、逻辑。我做过对比实验：用Llama-3-8B生成100条“量子计算原理”解释，人工标注30条为高质量，70条含事实错误。BLEU得分与人工评分相关性仅0.12，ROUGE-L更是-0.08（负相关！）。真正有效的评估必须分层：

基础层：事实准确性（Factuality）

工具链：用Google Search API + LLM-as-a-judge。对生成文本中的每个声明（如“Shor算法能在多项式时间内分解大整数”），自动搜索验证。我开发的fact_checker.py脚本：先用spaCy提取主谓宾三元组，再对每个三元组调用search，用BERTScore比对搜索摘要与原文。准确率92.3%。
指标：FactScore（https://github.com/allenai/factscore），它要求模型对每个claim打分0-1，并给出证据片段。比单纯二分类更细粒度。

逻辑层：连贯性与一致性（Coherence & Consistency）

方法：用GPT-4作为裁判，prompt为：“请评估以下两段文本的逻辑一致性：[text1] vs [text2]。打分1-5，1=完全矛盾，5=完美一致”。实测GPT-4与人类专家评分相关性达0.89。
自动化：用Sentence-BERT计算相邻句子的cosine similarity，低于0.4则标为逻辑断裂。对长文本，用滑动窗口（window=3）计算平均相似度。

应用层：任务完成度（Task Completion）

场景化评测：不做通用评测，而是针对业务场景设计。例如客服LLM，评测指标是“首次响应解决率”——用模拟用户对话，统计生成回复后用户是否发送“谢谢，已解决”。
对抗测试：注入陷阱问题，如“请用Python写一个冒泡排序，但要求时间复杂度O(1)”。健康模型应拒绝，而非硬编。我团队用adversarial_bench.py生成1000个此类问题，淘汰掉所有“硬编型”模型。

避坑提醒：

别用单一指标！我见过团队因BLEU提升0.5而上线模型，结果用户投诉“回答越来越像机器人”。
人工评测必须双盲：标注者不知晓模型ID，且每条样本由3人独立评分，取中位数。
每月更新评测集：用线上bad case自动扩充，确保评测集反映真实问题分布。

3.5 问题5：LLM量化有哪些方法？INT4/INT8在什么场景下会失效？

量化不是“越小越好”，而是在精度、速度、显存间的精密平衡。主流方案有四类，适用场景截然不同：

方法	原理	典型精度损失	适用场景	失效条件
Dynamic Quantization(PyTorch)	运行时动态计算scale/zero_point	FP16→INT8: ~1.2% acc drop	CPU推理，batch_size=1	长序列推理（KV Cache量化误差累积）
AWQ	基于activation敏感度的channel-wise clipping	FP16→INT4: ~2.8% acc drop	GPU推理，显存受限	小模型（<3B）或低bit（INT2）
GGUF	分组量化+metadata嵌入	FP16→Q4_K_M: ~3.5% acc drop	本地运行（llama.cpp）	高频切换context（metadata解析开销）
FP8(NVIDIA)	IEEE 754 FP8格式，支持tensor core	FP16→FP8: ~0.7% acc drop	A100/H100集群	非NVIDIA硬件（AMD GPU不支持）

INT4失效的三大典型场景：

长上下文任务：当context length>8K时，KV Cache的量化误差随长度线性累积。实测Qwen2-7B在16K context下，Q4_K_M量化使困惑度（PPL）从8.2升至15.7，生成连贯性断崖下跌。对策：对KV Cache用FP16存储，仅weight量化。
数学推理任务：INT4的动态范围（-8~7）无法覆盖大数运算中间结果。例如计算123456 * 789，中间值超INT4范围，导致overflow。解决方案：对MLP层的output用INT8，其余用INT4。
多模态融合：当LLM与视觉encoder联合推理时，视觉特征（ViT输出）的std通常>0.5，INT4的scale精度不足。我处理过一个图文问答模型，将ViT输出通道量化为INT4后，CLIP相似度下降42%。对策：视觉分支保持FP16，仅LLM backbone量化。

实操建议：

本地部署（Mac/M2）：首选GGUF Q5_K_M，平衡精度与速度；
云服务（AWS g5）：用AWQ INT4，配合vLLM的PagedAttention；
边缘设备（Jetson）：FP8 + TensorRT-LLM，需NVIDIA驱动≥535。

3.6 问题6：LoRA微调时，rank参数如何选择？过大过小各有什么代价？

LoRA的rank不是超参，而是模型能力与硬件资源的契约。它定义了低秩矩阵的列数（A∈R^{d×r}, B∈R^{r×d}），直接影响：

Rank过小的代价（r<8）：

表达能力坍塌：当r=1时，LoRA只能学习一个方向的更新，无法捕捉多头attention的差异化需求。实测在Qwen2-1.5B上，r=1使指令遵循能力下降37%（AlpacaEval得分）。
灾难性遗忘：小rank迫使模型在有限自由度内同时适应新任务和保留旧知识，导致base model能力退化。我们监控过embedding layer的L2 norm变化，r=2时norm衰减率达21%，r=64时仅3.2%。

Rank过大的代价（r>128）：

显存反超全量微调：LoRA参数本身虽小，但训练时需保存A/B矩阵的梯度。当r=256时，Qwen2-7B的LoRA梯度显存占用达1.8GB，而全量微调（仅保存optimizer state）仅1.2GB。
收敛变慢：大rank引入过多自由度，优化路径更崎岖。在相同step下，r=128的loss下降速度比r=64慢40%。

科学选择法（我团队的r-selection protocol）：

任务复杂度初筛：
- 简单任务（风格迁移）：r=8
- 中等任务（领域适配）：r=32
- 复杂任务（多步骤推理）：r=64
硬件约束精调：用torch.cuda.memory_allocated()监控，确保LoRA参数+梯度≤GPU显存的15%。
AB验证：对同一任务，用r=32,64,128各训3次，选validation loss方差最小的r。

实操心得：别迷信“r=64是黄金值”。我们在医疗NER任务中发现，r=16时F1最高——因为医学实体模式简单，大rank反而引入噪声。永远用数据说话。

3.7 问题7：vLLM和Text Generation Inference（TGI）的核心区别是什么？何时该选哪个？

这不是“哪个更好”，而是“哪个更合适”。二者架构哲学根本不同：

vLLM核心：PagedAttention内存管理

将KV Cache视为虚拟内存，按block（默认16 token）分页存储；
优势：显存利用率提升3.2倍（相比HuggingFace generate），支持超大batch；
劣势：首次prefill延迟略高（page allocation开销），不支持streaming output。

TGI核心：FlashAttention+Continuous batching

用FlashAttention加速计算，continuous batching动态合并请求；
优势：首token延迟最低（尤其小batch），原生支持SSE streaming；
劣势：显存碎片化严重，batch_size>32时OOM风险陡增。

选型决策树：

如果你的SLA要求首token延迟<500ms，且并发<50：选TGI。我们用TGI部署客服bot，P95延迟320ms，而vLLM为410ms。
如果你需要支撑1000+并发，且接受首token稍慢：选vLLM。某电商推荐场景，vLLM在A100上达1200 RPS，TGI仅780 RPS。
如果要混合部署多尺寸模型（如同时跑Qwen2-0.5B和72B）：vLLM的multi-model serving更成熟，TGI需为每个模型启独立容器。

避坑指南：

vLLM的--max-num-seqs参数不是最大并发数，而是同时处理的sequence group数。一个group可含多个request（如batched requests），实际并发=group数×avg request per group。
TGI的--max-input-length必须≤模型context length，否则启动失败。而vLLM允许--max-model-len大于--max-num-batched-tokens，更灵活。
两者都不支持原生LoRA hotswap。vLLM需重启server加载新adapter，TGI需重建Docker镜像。

3.8 问题8：部署LLM服务时，如何估算GPU资源需求？有哪些隐藏成本？

资源估算不是算显存，而是算整个数据平面的吞吐瓶颈。我设计过一套五维估算法：

维度1：显存（Memory）
公式：Total VRAM = Model Weight + KV Cache + Activations + System Overhead

Weight：Qwen2-7B FP16需14GB，INT4需3.8GB；
KV Cache：batch_size×seq_len×2×hidden_size×2（K/V各占一半）。A100上，batch_size=32, seq_len=2048, hidden_size=4096 → 2.1GB；
Activations：用torch.cuda.memory_reserved()实测，Qwen2-7B约1.2GB；
Overhead：vLLM额外开销约0.8GB。
→ 总计：INT4版需3.8+2.1+1.2+0.8=7.9GB，单A10G（23GB）可跑3实例。

维度2：计算（Compute）
用nvidia-smi -q -d UTILIZATION监控GPU compute utilization。当util>90%时，compute成为瓶颈。此时需：

升级GPU（A100→H100）；
或降低batch_size（从32→16，util从95%→65%）。

维度3：内存（RAM）
vLLM的PagedAttention需CPU内存存储block table。公式：RAM = batch_size × max_seq_len × 8 bytes。batch_size=100, max_seq_len=4096 → 3.2MB，可忽略。但TGI的continuous batching需更大RAM，batch_size=1000时需128MB。

维度4：网络（Network）
当GPU间通信频繁时（如多卡推理），NVLink带宽成瓶颈。A100 NVLink带宽600GB/s，但实测vLLM多卡时，跨卡KV Cache传输占带宽70%。对策：用--tensor-parallel-size控制分卡数，A100双卡时设为2，四卡时设为4。

维度5：隐藏成本

冷启动延迟：vLLM加载Qwen2-7B需8.2秒，期间请求排队。解决方案：预热机制，启动后自动发100个dummy request。
显存碎片：长期运行后，vLLM的block table碎片化，显存利用率下降。对策：定期重启server（我们设为每24小时）。
监控开销：Prometheus exporter每秒采集指标，A100上占用0.3% GPU compute，不可忽视。

最终估算模板（Excel可直接套用）：

项目	计算公式	示例（Qwen2-7B, INT4）
显存需求	Weight + KV Cache + Activations + Overhead	3.8 + 2.1 + 1.2 + 0.8 = 7.9GB
最大并发	floor(GPU VRAM / 显存需求) × GPU数量	floor(23/7.9)×4 = 12
首token延迟	Prefill time + Decode time	120ms + 30ms = 150ms
吞吐瓶颈	min(GPU util%, RAM bandwidth%, Network bandwidth%)	GPU util% = 85% → compute瓶颈

4. 实操避坑指南：那些没人告诉你的血泪教训

4.1 数据清洗：90%的模型问题源于脏数据

我接手过一个金融问答模型，训练loss正常，但上线后总在“美联储利率”问题上幻觉。排查三天，发现根源是训练数据中混入了PDF OCR错误：“FED”被识别为“FED.”（带句点），tokenizer将其切分为['FED', '.']，而模型从未见过带标点的机构名。数据清洗不是预处理，而是模型的第一道防线。我的标准流程：

字符级清洗：
- 删除所有控制字符（\x00-\x08,\x0b-\x0c,\x0e-\x1f）；
- 替换全角标点为半角（，→,）；
- 统一空白符：\s+→ （单空格）。
语义级清洗：
- 用spaCy识别命名实体，过滤掉实体类型为PERSON但上下文为“公司CEO”的样本（避免混淆）；
- 对数学公式，用LaTeX parser验证语法正确性，无效公式直接剔除。
分布级清洗：
- 计算每个样本的token length分布，剔除离群点（>3σ）；
- 用UMAP降维可视化数据簇，人工检查簇间语义重叠（如“医疗”和“法律”样本混在一起）。

血泪教训：某次为赶工期跳过清洗，用原始维基百科dump训练，结果模型对“苹果”一词，73%概率指向水果，27%指向公司——因为数据中“Apple Inc.”出现频率远低于“apple pie”。清洗后，公司义占比升至91%。

4.2 微调调试：如何读懂loss曲线背后的秘密

Loss曲线不是看高低，而是看形状、波动、平台期。我整理了12种典型曲线及对应根因：

曲线特征	可能根因	解决方案
持续缓慢下降	学习率过小	将lr从1e-5调至3e-5
剧烈震荡（±20%）	batch_size过小	从8增至32，或启用gradient accumulation
前100步骤升后降	初始化不当	改用`torch.nn.init.xavier_uniform_`
长时间平台期（>500步）	数据噪声大	用cleanlab库识别并剔除低置信度样本
突然垂直飙升	数据含nan/inf	用`torch.isnan(input).any()`前置检查
周期性波动（每100步）	Dataloader shuffle导致batch分布突变	关闭shuffle，或增大buffer_size

关键技巧：

在TensorBoard中，同时画loss、grad_norm、learning_rate三条曲线。当grad_norm骤降而loss不变，说明梯度消失；当grad_norm暴涨而loss飙升，说明梯度爆炸。
用torch.utils.checkpoint时，loss曲线会出现“阶梯状”下降——这是正常现象，因checkpoint跳过部分backward计算。

4.3 推理优化：别只盯着quantization，cache才是王道

90%的优化精力花在量化上，但80%的性能提升来自cache。我的cache优化三板斧：

第一斧：Prefill阶段KV Cache复用
当多个request共享相同prompt（如客服bot的system prompt），vLLM默认为每个request单独计算prefill。解决方案：

# 在vLLM中启用prompt adapter engine_args = EngineArgs( model="Qwen/Qwen2-7B", enable_prompt_adapter=True, # 关键开关 ... )

实测使prefill耗时降低63%。

第二斧：Decode阶段KV Cache压缩
标准KV Cache存储float16，但实际只需保留top-k重要token。我实现的SparseKVCache：

对每个layer的K/V，用attention score排序，只保留score top-50%的token；
用bitmask标记保留位置，解码时只计算这些位置。
在Qwen2-7B上，显存减少28%，延迟仅增7%。

第三斧：跨请求Cache共享
当两个request的prefix高度相似（如“请解释”开头），可共享prefix的KV Cache。需修改vLLM的SequenceGroup逻辑，添加相似度阈值（cosine > 0.95）。我们在线上环境启用后，P95延迟下降22%。

注意：cache优化有风险。SparseKVCache在长文本生成中可能导致连贯性下降，必须做AB测试验证。

4.4 服务部署：监控不是看GPU，而是看“请求生命周期”

传统监控只看GPU util、VRAM，但LLM服务的真正瓶颈

大模型工程师的8个硬核能力考察点：从推理到部署的工程真相