模型部署与推理加速 思维导图定稿版总览推理加速基础技术部署框架与推理引擎量化部署实战批处理与吞吐优化生产部署工程化一、推理加速基础技术模型量化Quantization核心原理把模型参数从高精度FP32/FP16压缩到低精度INT8/INT4类比理解一本书用32位编码每个字→改成8位甚至4位编码书变薄了但意思基本不变面试点一句话“牺牲微小精度换显存和速度的大幅提升”常见精度等级FP32全精度32位浮点数基准线显存最大FP16/BF16半精度16位显存减半精度损失极小INT88位整数显存再减半精度损失小INT44位整数显存降至约1/8精度有一定损失但大多数场景可接受对推理的影响显存INT8是FP16的一半INT4是FP16的约1/4速度低精度计算更快INT8推理速度比FP16快1.5-2倍精度INT8损失1%INT4损失1-3%大部分业务场景可接受适用场景消费级显卡部署大模型量化是必经之路高并发推理服务降低单请求显存提升并发数端侧/边缘设备部署手机、嵌入式设备面试点量化是性价比最高的推理加速手段几乎零成本实现2-4倍显存节省知识蒸馏Knowledge Distillation核心原理用大模型Teacher的输出来训练小模型Student不是让小模型学标准答案而是学大模型的“软标签”概率分布类比理解不是让学生背答案而是让学生学老师的解题思路和判断依据面试点一句话“让小模型学会大模型的思维方式不只是记住答案”和量化的本质区别量化同一个模型压精度模型结构不变蒸馏换一个小模型让它学大模型的行为优点小模型推理极快显存极小可以针对特定任务蒸馏效果接近大模型缺点需要大模型做标注蒸馏过程本身成本高小模型能力有上限复杂任务可能搞不定大模型更新后蒸馏模型也需要重新训练适用场景高频简单任务客服FAQ、文本分类需要极低延迟的端侧场景模型剪枝Pruning核心原理删除模型中不重要的参数权重接近0的神经元连接类比理解修剪一棵树的枯枝烂叶主干保留树变小但功能不减面试点一句话“模型里很多参数贡献极小剪掉不影响效果但能提速”剪枝类型非结构化剪枝逐个参数判断删掉不重要的单个权重压缩率高但需要硬件和框架支持稀疏计算才能加速结构化剪枝整行/整列/整头删除压缩率稍低但通用性好标准硬件就能加速和量化、蒸馏的关系三者为互补关系常组合使用典型组合先蒸馏到小模型→再剪枝→再量化→部署面试点剪枝在LLM领域用得不如量化和蒸馏普遍了解即可投机采样Speculative Decoding核心原理用小模型快速生成多个候选Token大模型一次性验证类比理解助手先草拟几个方案老板快速审核通过的直接用不通过的老板自己写面试点一句话“用小模型‘猜’代替大模型逐Token生成大模型只做验证速度翻倍”为什么能加速大模型逐Token生成是顺序的每生成一个都要完整前向计算一次但大模型一次性验证多个Token的计算量和一个Token差不多所以小模型猜对N个Token大模型一次验证通过省了N-1次推理加速效果理论上2-3倍推理加速实际取决于小模型猜得有多准猜得准加速多猜不准反而慢适用场景有现成小模型可用的场景生成任务对话、翻译、摘要面试点投机采样是2024-2025热门方向vLLM等框架已内置支持四种技术速查对比表面试快速说出来量化不换模型、压精度、显存降2-4倍、精度损失1-3%、性价比最高蒸馏换小模型、学大模型、显存降10倍、需要重新训练、效果上限受限剪枝不换模型、删参数、加速有限、常和量化组合使用投机采样不换模型、小模型猜大模型验、加速2-3倍、猜不准时加速有限面试话术推理加速选型策略“推理加速我最先用量化成本最低效果立竿见影INT4量化显存降4倍精度损失不到3%”“需要极致性能再考虑蒸馏训一个小模型专门服务高频任务但维护成本高”“投机采样是锦上添花配合量化一起用适用于生成类任务”“生产环境最常用的组合量化到INT4 vLLM部署 投机采样可选开启”二、部署框架与推理引擎vLLM最高频考点定位高吞吐、低延迟的生产级LLM推理引擎核心创新PagedAttention解决的问题KV缓存内存碎片化传统方式每个请求预留一块连续显存放KV缓存问题请求长度不一预留大了浪费预留小了不够碎片严重PagedAttention方案把KV缓存切成固定大小的“页”按需分配类比理解操作系统用分页管理内存PagedAttention用同样思路管理KV缓存带来的收益显存利用率大幅提升碎片消除浪费从50%降到接近0吞吐量提升相同显存能同时服务更多请求面试点一句话“PagedAttention让KV缓存管理从预分配变成按需分配显存利用率从不到50%提升到接近100%”面试点PagedAttention是vLLM的核心竞争力面试必问其他关键特性连续批处理Continuous Batching请求完成立即踢出新请求立即加入不等到整批结束支持多种量化方式GPTQ/AWQ/SqueezeLLM兼容OpenAI API格式迁移成本低适用场景高并发在线推理服务首要选择需要低延迟的实时对话场景多用户同时使用的API服务面试点vLLM是2025-2026年生产级LLM部署的首选方案TensorRT-LLM定位NVIDIA官方推出的LLM推理优化框架极致性能核心优势基于NVIDIA TensorRT生态针对N卡做了最深度的内核优化性能上限最高理论上比vLLM更快在NVIDIA显卡上支持多GPU并行推理Tensor Parallelism / Pipeline Parallelism和vLLM的关键区别vLLM开源、通用性好、部署简单、生态活跃TensorRT-LLMNVIDIA专属、性能极致但部署复杂、需要模型转换部署流程能说出步骤步骤一把模型转成TensorRT-LLM支持的格式步骤二构建TensorRT引擎编译优化图步骤三加载引擎进行推理面试点TensorRT-LLM需要额外的模型转换和引擎构建步骤比vLLM复杂适用场景对延迟要求极致的场景如高频交易、实时对话重度依赖NVIDIA生态的企业愿意投入更多部署和维护成本的团队面试点vLLM和TensorRT-LLM的选择本质是“够用就行”和“追求极致”的权衡Ollama本地开发与测试首选定位零门槛本地模型运行平台面向开发者和个人用户类比理解Ollama之于LLM部署就像Docker之于服务部署核心优势安装即用一行命令安装ollama run llama3直接跑起来模型管理简便ollama pull下载模型ollama list查看本地模型Modelfile用类似Dockerfile的方式自定义和分享模型配置自动硬件适配自动识别GPU/CPU自动选择最佳量化级别和vLLM/TensorRT-LLM的本质区别Ollama为开发和本地测试设计追求操作简单vLLM/TensorRT-LLM为生产高并发设计追求吞吐和性能面试点Ollama不是生产级推理引擎是开发效率工具适用场景本地开发和调试个人项目和小团队原型验证内网或离线环境快速搭建模型服务学习LLM应用开发时的本地模型替代方案和LangChain/LlamaIndex的集成Ollama提供兼容OpenAI格式的API在代码里配base_url指向localhost的Ollama服务即可调用面试点Ollama是面试中常被问到的工具证明你有本地开发和调试经验llama.cpp定位C实现的高性能LLM推理库Ollama的后端基础核心特点纯C实现无Python依赖极度轻量支持CPU推理也能用GPU加速对量化格式支持极广GGUF格式成为开源模型分发标准和Ollama的关系Ollama底层基于llama.cppOllama封装了llama.cpp的复杂性提供更友好的用户接口面试点llama.cpp让消费级设备跑大模型成为可能了解即可部署框架选型速查表本地开发/Demo验证 → Ollama最方便生产在线推理服务 → vLLM性价比最高最主流极致性能追求 → TensorRT-LLM但复杂度高CPU环境/端侧部署 → llama.cpp面试点选型要结合业务阶段不要一上来就追最复杂的方案面试话术部署框架选型策略“开发阶段我用Ollama一行命令起服务本地调试效率高”“上生产我用vLLMPagedAttention解决显存碎片问题连续批处理提升吞吐兼容OpenAI API迁移成本低”“如果对延迟要求到毫秒级极致考虑TensorRT-LLM但要接受部署复杂度”“小模型或端侧场景考虑llama.cpp极致轻量还能跑在CPU上”三、量化部署实战量化精度等级详解FP16/BF16基线用途微调后的模型默认精度作为量化前的参考基线显存参考7B模型约14GBINT8量化显存约为FP16的50%7B模型约7-8GB精度损失通常1%绝大部分场景几乎无感加速效果推理速度比FP16快1.5-2倍适用场景要求精度几乎无损、显存有一定余量的场景INT4量化显存约为FP16的25%7B模型约4-5GB精度损失1-3%大部分业务场景可接受复杂推理任务可能略感退化加速效果推理速度比FP16快2-3倍适用场景消费级显卡部署大模型、高并发服务节省显存NF44-bit NormalFloat是什么专门为神经网络权重分布设计的一种4bit量化格式和INT4的区别INT4假设权重均匀分布NF4假设权重正态分布信息保留更好QLoRA中用的就是NF4面试点NF4比普通INT4精度损失更小是QLoRA的核心技术之一主流量化工具对比GPTQ全称GPT-Post-Training Quantization原理一句话离线量化用小批量校准数据逐层优化量化参数优点效果好精度损失小学术界和工业界广泛验证缺点量化过程慢需要跑校准数据和逐层优化几十分钟到几小时适用场景追求最优量化效果对量化时间不敏感面试点GPTQ是效果最好的离线量化方案之一AWQ全称Activation-aware Weight Quantization原理一句话离线量化根据激活值的分布来决定哪些权重通道应该保留更高精度优点比GPTQ快不需要逐层优化效果接近GPTQ缺点对大batch校准数据有一定依赖适用场景追求量化速度和效果的平衡面试点AWQ是GPTQ的快速替代方案速度和效果的权衡更好bitsandbytes原理一句话在线量化加载模型时动态转换精度不需要离线处理优点使用最简单加载模型时加一行参数就能量化代码示例model AutoModel.from_pretrained(..., load_in_4bitTrue)缺点量化效果比GPTQ/AWQ稍差推理速度比离线量化慢适用场景快速验证、QLoRA微调、不想折腾离线量化流程面试点bitsandbytes是最方便的量化方式适合开发阶段和QLoRA量化工具速查对比表GPTQ离线量化、效果最好、速度最慢、适合追求最优效果的生产部署AWQ离线量化、效果好、速度快、适合需要快速迭代的生产部署bitsandbytes在线量化、效果略差、速度最慢、适合开发和QLoRA微调精度影响评估评估方法方法一跑标准评测集用量化前后的模型分别跑MMLU/HellaSwag等基准测试对比分数变化方法二跑业务评测集用自己业务的50-100条典型问题对比量化前后答案质量方法三人工盲评量化前后各生成一组答案人工不标明来源做对比打分精度损失的典型表现复杂推理任务退化最明显数学推理、逻辑推断长文本生成可能出现前后不一致简单问答和闲聊几乎无感面试点量化后必须跑评测验证不要想当然觉得“精度损失不大就没事”量化推理框架的部署组合推荐组合一AWQ量化 vLLM部署先用AutoAWQ把模型量到INT4保存量化模型vLLM直接加载量化模型启动推理服务推荐组合二GPTQ量化 vLLM部署同上效果稍好但量化过程更慢注意vLLM内置支持AWQ和GPTQ不需要额外转换QLoRA部署的特殊注意事项高频踩坑点QLoRA训练后的模型不是标准量化格式训练时基础模型是NF4 LoRA权重是FP16不能直接把QLoRA训练的checkpoint拿去给vLLM加载正确部署流程步骤一合并LoRA权重回基础模型merge_and_unload这一步把NF4基础模型转回FP16 融入LoRA权重步骤二对合并后的FP16模型重新量化用GPTQ或AWQ步骤三用量化后的模型配合vLLM部署面试点QLoRA训练完不能直接部署要先合并再重新量化面试点这个坑很多人不知道能说清楚说明你真的做过面试话术量化部署实践“量化我一般用AWQ效果接近GPTQ但快很多量化完配合vLLM部署”“开发阶段用bitsandbytes在线量化最方便一行代码搞定不用离线处理”“量化后我会跑业务评测集验证精度损失简单任务通常2%复杂推理任务要重点验证”“QLoRA训练完一定要记得先合并再重新量化不能直接部署NF4格式的模型”四、批处理与吞吐优化静态批处理Static Batching工作原理收集一批请求 → 等这批全部完成 → 一次性返回 → 再收集下一批类比理解公交车等人必须等这一车所有人都到齐了才发车优点实现简单逻辑清晰批量计算效率高GPU一次处理多条利用率高缺点短板效应严重一个请求生成500个Token另一个只生成10个生成10个Token的早就完成了但要等生成500个的白白占用显存新请求必须等当前批次结束才能进来延迟不可控最长的那个请求决定了整批的延迟适用场景离线批处理如批量文档摘要、数据标注不要求实时性面试点静态批处理逻辑简单但在线服务不适用短板效应浪费显存和算力连续批处理Continuous Batching高频考点工作原理不是“收集→处理→返回”的固定循环而是动态队列请求来了立即加入完成了立即踢出随时有位置新请求随时进来类比理解流水线作业做完一个拿走一个新的马上补位不停等核心优势相对静态批处理优势一消除短板等待短请求完成后立即释放显存返回给用户不等长请求优势二显存利用率最大化短请求释放的显存立即被新请求使用不留空隙优势三延迟更可控每个请求的延迟只和自己的长度有关不被其他请求拖累吞吐量提升相同显存下吞吐量比静态批处理高2-10倍实现方式vLLM内置连续批处理默认行为TGIText Generation Inference也支持面试点主流推理框架都已默认支持部署时自动开启面试点连续批处理是生产级推理服务的标配面试必问动态批处理策略最大批处理大小Max Batch Size含义同时处理的最大请求数由显存决定显存越大能同时放的KV缓存越多batch_size越大设置建议太小GPU利用率低吞吐量低太大显存溢出OOM或排队延迟增加面试点max_batch_size不是越大越好要看显存和延迟要求排队策略Scheduling先到先服务FCFS公平但可能短请求被长请求堵优先短请求短请求优先处理提升用户体验和吞吐量面试点vLLM默认FCFS但可通过参数调优优先策略Token预算控制每个请求设max_tokens上限防止单个请求霸占太久面试点max_tokens是保护系统不被单请求拖死的简单有效手段吞吐量与延迟的权衡吞吐量Throughput定义单位时间能处理多少请求或生成多少Token衡量指标Token/s每秒生成Token数、Requests/s每秒处理请求数提升手段增加batch_size、开启连续批处理、使用量化模型延迟LatencyTTFT首Token延迟用户发出请求到看到第一个字的等待时间用户体验的关键指标超过2秒用户开始不耐烦TPOT每Token生成时间每个后续Token之间的间隔影响阅读流畅度超过100ms会感觉卡顿总延迟E2E Latency从请求到完整回复的总时间权衡关系增大batch_size → 吞吐量↑ 但单请求延迟↑排队等batch凑满连续批处理缓解了这个矛盾不需要凑满batch就能开始处理面试点一句话“连续批处理让吞吐和延迟从对立变得可以兼顾”实际做法设延迟SLA如P99延迟5秒在满足SLA前提下尽可能提吞吐面试点能说出吞吐和延迟的权衡并给出“设SLA→调batch_size→监控”的调优思路实际调优策略部署前模型量化INT4能省75%显存同样显存下batch_size可以更大估算显存根据模型大小预期batch_size输入输出长度预估所需显存部署中压测找最优batch_size从小到大试找到延迟可接受范围内的最大batch_size设max_tokens限制防止单个长回复拖慢整体部署后监控TTFT和TPOT发现劣化及时调整监控排队长度排队太长说明batch_size太小或请求量超预期面试话术批处理优化回答模板“生产环境必须用连续批处理静态批处理的短板效应会让短请求被长请求堵死”“vLLM默认就是连续批处理部署时自动开启我需要做的是根据显存和延迟要求调max_batch_size”“调优思路上我以用户体验定SLA比如P99延迟5秒在满足SLA的前提下把batch_size调到最大提升吞吐”“监控上我重点关注首Token延迟和排队长度首Token延迟超过阈值说明batch_size可能太大了”五、生产部署工程化灰度发布与A/B测试为什么需要灰度发布新模型离线评估好不等于线上效果好直接全量上线出问题影响所有用户面试点灰度是把风险控制在最小范围内的标准做法灰度方案设计方案一流量百分比分流新模型5%流量旧模型95%流量观测核心指标延迟/错误率/点踩率逐步放量5%→20%→50%→100%方案二用户ID哈希分流按用户ID尾号路由到不同模型版本好处同一用户始终看到同一版本体验一致方案三请求头/参数路由通过API参数指定模型版本适合内部测试观测与决策至少观测1-3天积累足够样本核心指标优于旧版且无异常 → 扩大灰度比例指标持平 → 保留旧版或增加灰度比例再观察指标劣化或出现异常 → 立即回滚面试点灰度不是技术炫技是控制风险的工程纪律模型网关设计为什么需要模型网关多个模型服务不同版本/不同用途需要统一入口管理避免每个业务方直接连模型服务耦合太紧统一做路由、限流、降级、鉴权、计费模型网关的核心功能路由根据请求特征用户/场景/模型名称路由到不同模型服务举例VIP用户路由到高配模型普通用户路由到量化模型限流每个用户/每个API Key设QPS上限防止被打爆降级主模型挂了自动切换到备用模型或返回兜底话术鉴权统一验证API Key和权限日志与监控记录每次请求的模型版本、延迟、Token消耗实现方式轻量方案Nginx/Envoy反向代理 Lua/插件做路由逻辑定制方案自建Gateway服务FastAPI/Go集成路由和限流逻辑面试点模型网关是微服务架构下管理多个模型服务的标准组件面试点能说清模型网关API网关模型路由证明有系统架构思维高并发服务架构架构分层接入层负载均衡Nginx/ALB分发请求到多个推理实例推理层多个vLLM/TGI实例水平扩展缓存层Redis缓存热点问题结果减少推理调用存储层模型文件存储对象存储/共享文件系统水平扩展策略无状态设计每个推理实例独立不存储会话状态自动扩缩容根据GPU利用率和请求排队长度自动增减实例面试点推理服务做成无状态可水平扩展是扛住高并发的关键连接池与并发控制推理实例前端放连接池复用HTTP连接限制每个实例的最大并发请求数防止过载面试点高并发架构不是单点优化是分层解耦水平扩展的组合监控与告警体系核心监控指标服务质量指标TTFT首Token延迟P50/P95/P99TPOT每Token生成时间平均值和P95端到端延迟从请求到完整回复的总时间吞吐量QPS和Token/s系统资源指标GPU利用率太低浪费资源太高接近瓶颈显存使用率超过90%告警接近OOMCPU/内存/网络IO业务指标错误率5xx错误比例排队长度等待处理的请求数Token消耗量控制成本告警规则设计P99延迟超过SLA阈值如5秒→ 告警错误率超过5% → 告警GPU显存使用率超过95% → 紧急告警排队长度持续增长 → 预警可能需要扩容监控工具Prometheus Grafana采集和可视化指标vLLM自带Metrics接口暴露TTFT/TPOT/吞吐等指标面试点监控不只是搭工具关键是定义SLA和告警阈值面试点生产部署的底线是“出问题能第一时间知道”快速回滚机制什么时候需要回滚新模型上线后错误率飙升延迟指标明显劣化P99延迟翻倍用户投诉明显增多回滚方案方案一模型版本管理模型文件按版本号存储如v1.0/v1.1/v2.0回滚 把推理服务指向旧版本模型文件方案二流量切换灰度时保留旧版服务不下线回滚 把流量从新版切回旧版秒级完成方案三配置热更新模型路径做成配置项改配置即切换无需重启服务回滚后必做排查原因新模型哪里出了问题修复后重新灰度验证面试点回滚不是终点是止损后的排查和修复起点面试点快速回滚是生产部署的安全网灰度是回滚的前置条件面试话术生产部署实践“上线新模型我走灰度流程先切5%流量观测1-3天核心指标正常逐步放量到全量”“模型网关我用来统一管理多个模型服务做路由、限流、降级不让业务方直接连推理实例”“监控上我盯三个核心指标首Token延迟、错误率、GPU显存分别对应用户体验、服务稳定性和资源瓶颈”“回滚上我保留旧版服务不下线灰度期间出事秒级切回配置热更新不用重启”
思维导图笔记：模型部署与推理加速
模型部署与推理加速 思维导图定稿版总览推理加速基础技术部署框架与推理引擎量化部署实战批处理与吞吐优化生产部署工程化一、推理加速基础技术模型量化Quantization核心原理把模型参数从高精度FP32/FP16压缩到低精度INT8/INT4类比理解一本书用32位编码每个字→改成8位甚至4位编码书变薄了但意思基本不变面试点一句话“牺牲微小精度换显存和速度的大幅提升”常见精度等级FP32全精度32位浮点数基准线显存最大FP16/BF16半精度16位显存减半精度损失极小INT88位整数显存再减半精度损失小INT44位整数显存降至约1/8精度有一定损失但大多数场景可接受对推理的影响显存INT8是FP16的一半INT4是FP16的约1/4速度低精度计算更快INT8推理速度比FP16快1.5-2倍精度INT8损失1%INT4损失1-3%大部分业务场景可接受适用场景消费级显卡部署大模型量化是必经之路高并发推理服务降低单请求显存提升并发数端侧/边缘设备部署手机、嵌入式设备面试点量化是性价比最高的推理加速手段几乎零成本实现2-4倍显存节省知识蒸馏Knowledge Distillation核心原理用大模型Teacher的输出来训练小模型Student不是让小模型学标准答案而是学大模型的“软标签”概率分布类比理解不是让学生背答案而是让学生学老师的解题思路和判断依据面试点一句话“让小模型学会大模型的思维方式不只是记住答案”和量化的本质区别量化同一个模型压精度模型结构不变蒸馏换一个小模型让它学大模型的行为优点小模型推理极快显存极小可以针对特定任务蒸馏效果接近大模型缺点需要大模型做标注蒸馏过程本身成本高小模型能力有上限复杂任务可能搞不定大模型更新后蒸馏模型也需要重新训练适用场景高频简单任务客服FAQ、文本分类需要极低延迟的端侧场景模型剪枝Pruning核心原理删除模型中不重要的参数权重接近0的神经元连接类比理解修剪一棵树的枯枝烂叶主干保留树变小但功能不减面试点一句话“模型里很多参数贡献极小剪掉不影响效果但能提速”剪枝类型非结构化剪枝逐个参数判断删掉不重要的单个权重压缩率高但需要硬件和框架支持稀疏计算才能加速结构化剪枝整行/整列/整头删除压缩率稍低但通用性好标准硬件就能加速和量化、蒸馏的关系三者为互补关系常组合使用典型组合先蒸馏到小模型→再剪枝→再量化→部署面试点剪枝在LLM领域用得不如量化和蒸馏普遍了解即可投机采样Speculative Decoding核心原理用小模型快速生成多个候选Token大模型一次性验证类比理解助手先草拟几个方案老板快速审核通过的直接用不通过的老板自己写面试点一句话“用小模型‘猜’代替大模型逐Token生成大模型只做验证速度翻倍”为什么能加速大模型逐Token生成是顺序的每生成一个都要完整前向计算一次但大模型一次性验证多个Token的计算量和一个Token差不多所以小模型猜对N个Token大模型一次验证通过省了N-1次推理加速效果理论上2-3倍推理加速实际取决于小模型猜得有多准猜得准加速多猜不准反而慢适用场景有现成小模型可用的场景生成任务对话、翻译、摘要面试点投机采样是2024-2025热门方向vLLM等框架已内置支持四种技术速查对比表面试快速说出来量化不换模型、压精度、显存降2-4倍、精度损失1-3%、性价比最高蒸馏换小模型、学大模型、显存降10倍、需要重新训练、效果上限受限剪枝不换模型、删参数、加速有限、常和量化组合使用投机采样不换模型、小模型猜大模型验、加速2-3倍、猜不准时加速有限面试话术推理加速选型策略“推理加速我最先用量化成本最低效果立竿见影INT4量化显存降4倍精度损失不到3%”“需要极致性能再考虑蒸馏训一个小模型专门服务高频任务但维护成本高”“投机采样是锦上添花配合量化一起用适用于生成类任务”“生产环境最常用的组合量化到INT4 vLLM部署 投机采样可选开启”二、部署框架与推理引擎vLLM最高频考点定位高吞吐、低延迟的生产级LLM推理引擎核心创新PagedAttention解决的问题KV缓存内存碎片化传统方式每个请求预留一块连续显存放KV缓存问题请求长度不一预留大了浪费预留小了不够碎片严重PagedAttention方案把KV缓存切成固定大小的“页”按需分配类比理解操作系统用分页管理内存PagedAttention用同样思路管理KV缓存带来的收益显存利用率大幅提升碎片消除浪费从50%降到接近0吞吐量提升相同显存能同时服务更多请求面试点一句话“PagedAttention让KV缓存管理从预分配变成按需分配显存利用率从不到50%提升到接近100%”面试点PagedAttention是vLLM的核心竞争力面试必问其他关键特性连续批处理Continuous Batching请求完成立即踢出新请求立即加入不等到整批结束支持多种量化方式GPTQ/AWQ/SqueezeLLM兼容OpenAI API格式迁移成本低适用场景高并发在线推理服务首要选择需要低延迟的实时对话场景多用户同时使用的API服务面试点vLLM是2025-2026年生产级LLM部署的首选方案TensorRT-LLM定位NVIDIA官方推出的LLM推理优化框架极致性能核心优势基于NVIDIA TensorRT生态针对N卡做了最深度的内核优化性能上限最高理论上比vLLM更快在NVIDIA显卡上支持多GPU并行推理Tensor Parallelism / Pipeline Parallelism和vLLM的关键区别vLLM开源、通用性好、部署简单、生态活跃TensorRT-LLMNVIDIA专属、性能极致但部署复杂、需要模型转换部署流程能说出步骤步骤一把模型转成TensorRT-LLM支持的格式步骤二构建TensorRT引擎编译优化图步骤三加载引擎进行推理面试点TensorRT-LLM需要额外的模型转换和引擎构建步骤比vLLM复杂适用场景对延迟要求极致的场景如高频交易、实时对话重度依赖NVIDIA生态的企业愿意投入更多部署和维护成本的团队面试点vLLM和TensorRT-LLM的选择本质是“够用就行”和“追求极致”的权衡Ollama本地开发与测试首选定位零门槛本地模型运行平台面向开发者和个人用户类比理解Ollama之于LLM部署就像Docker之于服务部署核心优势安装即用一行命令安装ollama run llama3直接跑起来模型管理简便ollama pull下载模型ollama list查看本地模型Modelfile用类似Dockerfile的方式自定义和分享模型配置自动硬件适配自动识别GPU/CPU自动选择最佳量化级别和vLLM/TensorRT-LLM的本质区别Ollama为开发和本地测试设计追求操作简单vLLM/TensorRT-LLM为生产高并发设计追求吞吐和性能面试点Ollama不是生产级推理引擎是开发效率工具适用场景本地开发和调试个人项目和小团队原型验证内网或离线环境快速搭建模型服务学习LLM应用开发时的本地模型替代方案和LangChain/LlamaIndex的集成Ollama提供兼容OpenAI格式的API在代码里配base_url指向localhost的Ollama服务即可调用面试点Ollama是面试中常被问到的工具证明你有本地开发和调试经验llama.cpp定位C实现的高性能LLM推理库Ollama的后端基础核心特点纯C实现无Python依赖极度轻量支持CPU推理也能用GPU加速对量化格式支持极广GGUF格式成为开源模型分发标准和Ollama的关系Ollama底层基于llama.cppOllama封装了llama.cpp的复杂性提供更友好的用户接口面试点llama.cpp让消费级设备跑大模型成为可能了解即可部署框架选型速查表本地开发/Demo验证 → Ollama最方便生产在线推理服务 → vLLM性价比最高最主流极致性能追求 → TensorRT-LLM但复杂度高CPU环境/端侧部署 → llama.cpp面试点选型要结合业务阶段不要一上来就追最复杂的方案面试话术部署框架选型策略“开发阶段我用Ollama一行命令起服务本地调试效率高”“上生产我用vLLMPagedAttention解决显存碎片问题连续批处理提升吞吐兼容OpenAI API迁移成本低”“如果对延迟要求到毫秒级极致考虑TensorRT-LLM但要接受部署复杂度”“小模型或端侧场景考虑llama.cpp极致轻量还能跑在CPU上”三、量化部署实战量化精度等级详解FP16/BF16基线用途微调后的模型默认精度作为量化前的参考基线显存参考7B模型约14GBINT8量化显存约为FP16的50%7B模型约7-8GB精度损失通常1%绝大部分场景几乎无感加速效果推理速度比FP16快1.5-2倍适用场景要求精度几乎无损、显存有一定余量的场景INT4量化显存约为FP16的25%7B模型约4-5GB精度损失1-3%大部分业务场景可接受复杂推理任务可能略感退化加速效果推理速度比FP16快2-3倍适用场景消费级显卡部署大模型、高并发服务节省显存NF44-bit NormalFloat是什么专门为神经网络权重分布设计的一种4bit量化格式和INT4的区别INT4假设权重均匀分布NF4假设权重正态分布信息保留更好QLoRA中用的就是NF4面试点NF4比普通INT4精度损失更小是QLoRA的核心技术之一主流量化工具对比GPTQ全称GPT-Post-Training Quantization原理一句话离线量化用小批量校准数据逐层优化量化参数优点效果好精度损失小学术界和工业界广泛验证缺点量化过程慢需要跑校准数据和逐层优化几十分钟到几小时适用场景追求最优量化效果对量化时间不敏感面试点GPTQ是效果最好的离线量化方案之一AWQ全称Activation-aware Weight Quantization原理一句话离线量化根据激活值的分布来决定哪些权重通道应该保留更高精度优点比GPTQ快不需要逐层优化效果接近GPTQ缺点对大batch校准数据有一定依赖适用场景追求量化速度和效果的平衡面试点AWQ是GPTQ的快速替代方案速度和效果的权衡更好bitsandbytes原理一句话在线量化加载模型时动态转换精度不需要离线处理优点使用最简单加载模型时加一行参数就能量化代码示例model AutoModel.from_pretrained(..., load_in_4bitTrue)缺点量化效果比GPTQ/AWQ稍差推理速度比离线量化慢适用场景快速验证、QLoRA微调、不想折腾离线量化流程面试点bitsandbytes是最方便的量化方式适合开发阶段和QLoRA量化工具速查对比表GPTQ离线量化、效果最好、速度最慢、适合追求最优效果的生产部署AWQ离线量化、效果好、速度快、适合需要快速迭代的生产部署bitsandbytes在线量化、效果略差、速度最慢、适合开发和QLoRA微调精度影响评估评估方法方法一跑标准评测集用量化前后的模型分别跑MMLU/HellaSwag等基准测试对比分数变化方法二跑业务评测集用自己业务的50-100条典型问题对比量化前后答案质量方法三人工盲评量化前后各生成一组答案人工不标明来源做对比打分精度损失的典型表现复杂推理任务退化最明显数学推理、逻辑推断长文本生成可能出现前后不一致简单问答和闲聊几乎无感面试点量化后必须跑评测验证不要想当然觉得“精度损失不大就没事”量化推理框架的部署组合推荐组合一AWQ量化 vLLM部署先用AutoAWQ把模型量到INT4保存量化模型vLLM直接加载量化模型启动推理服务推荐组合二GPTQ量化 vLLM部署同上效果稍好但量化过程更慢注意vLLM内置支持AWQ和GPTQ不需要额外转换QLoRA部署的特殊注意事项高频踩坑点QLoRA训练后的模型不是标准量化格式训练时基础模型是NF4 LoRA权重是FP16不能直接把QLoRA训练的checkpoint拿去给vLLM加载正确部署流程步骤一合并LoRA权重回基础模型merge_and_unload这一步把NF4基础模型转回FP16 融入LoRA权重步骤二对合并后的FP16模型重新量化用GPTQ或AWQ步骤三用量化后的模型配合vLLM部署面试点QLoRA训练完不能直接部署要先合并再重新量化面试点这个坑很多人不知道能说清楚说明你真的做过面试话术量化部署实践“量化我一般用AWQ效果接近GPTQ但快很多量化完配合vLLM部署”“开发阶段用bitsandbytes在线量化最方便一行代码搞定不用离线处理”“量化后我会跑业务评测集验证精度损失简单任务通常2%复杂推理任务要重点验证”“QLoRA训练完一定要记得先合并再重新量化不能直接部署NF4格式的模型”四、批处理与吞吐优化静态批处理Static Batching工作原理收集一批请求 → 等这批全部完成 → 一次性返回 → 再收集下一批类比理解公交车等人必须等这一车所有人都到齐了才发车优点实现简单逻辑清晰批量计算效率高GPU一次处理多条利用率高缺点短板效应严重一个请求生成500个Token另一个只生成10个生成10个Token的早就完成了但要等生成500个的白白占用显存新请求必须等当前批次结束才能进来延迟不可控最长的那个请求决定了整批的延迟适用场景离线批处理如批量文档摘要、数据标注不要求实时性面试点静态批处理逻辑简单但在线服务不适用短板效应浪费显存和算力连续批处理Continuous Batching高频考点工作原理不是“收集→处理→返回”的固定循环而是动态队列请求来了立即加入完成了立即踢出随时有位置新请求随时进来类比理解流水线作业做完一个拿走一个新的马上补位不停等核心优势相对静态批处理优势一消除短板等待短请求完成后立即释放显存返回给用户不等长请求优势二显存利用率最大化短请求释放的显存立即被新请求使用不留空隙优势三延迟更可控每个请求的延迟只和自己的长度有关不被其他请求拖累吞吐量提升相同显存下吞吐量比静态批处理高2-10倍实现方式vLLM内置连续批处理默认行为TGIText Generation Inference也支持面试点主流推理框架都已默认支持部署时自动开启面试点连续批处理是生产级推理服务的标配面试必问动态批处理策略最大批处理大小Max Batch Size含义同时处理的最大请求数由显存决定显存越大能同时放的KV缓存越多batch_size越大设置建议太小GPU利用率低吞吐量低太大显存溢出OOM或排队延迟增加面试点max_batch_size不是越大越好要看显存和延迟要求排队策略Scheduling先到先服务FCFS公平但可能短请求被长请求堵优先短请求短请求优先处理提升用户体验和吞吐量面试点vLLM默认FCFS但可通过参数调优优先策略Token预算控制每个请求设max_tokens上限防止单个请求霸占太久面试点max_tokens是保护系统不被单请求拖死的简单有效手段吞吐量与延迟的权衡吞吐量Throughput定义单位时间能处理多少请求或生成多少Token衡量指标Token/s每秒生成Token数、Requests/s每秒处理请求数提升手段增加batch_size、开启连续批处理、使用量化模型延迟LatencyTTFT首Token延迟用户发出请求到看到第一个字的等待时间用户体验的关键指标超过2秒用户开始不耐烦TPOT每Token生成时间每个后续Token之间的间隔影响阅读流畅度超过100ms会感觉卡顿总延迟E2E Latency从请求到完整回复的总时间权衡关系增大batch_size → 吞吐量↑ 但单请求延迟↑排队等batch凑满连续批处理缓解了这个矛盾不需要凑满batch就能开始处理面试点一句话“连续批处理让吞吐和延迟从对立变得可以兼顾”实际做法设延迟SLA如P99延迟5秒在满足SLA前提下尽可能提吞吐面试点能说出吞吐和延迟的权衡并给出“设SLA→调batch_size→监控”的调优思路实际调优策略部署前模型量化INT4能省75%显存同样显存下batch_size可以更大估算显存根据模型大小预期batch_size输入输出长度预估所需显存部署中压测找最优batch_size从小到大试找到延迟可接受范围内的最大batch_size设max_tokens限制防止单个长回复拖慢整体部署后监控TTFT和TPOT发现劣化及时调整监控排队长度排队太长说明batch_size太小或请求量超预期面试话术批处理优化回答模板“生产环境必须用连续批处理静态批处理的短板效应会让短请求被长请求堵死”“vLLM默认就是连续批处理部署时自动开启我需要做的是根据显存和延迟要求调max_batch_size”“调优思路上我以用户体验定SLA比如P99延迟5秒在满足SLA的前提下把batch_size调到最大提升吞吐”“监控上我重点关注首Token延迟和排队长度首Token延迟超过阈值说明batch_size可能太大了”五、生产部署工程化灰度发布与A/B测试为什么需要灰度发布新模型离线评估好不等于线上效果好直接全量上线出问题影响所有用户面试点灰度是把风险控制在最小范围内的标准做法灰度方案设计方案一流量百分比分流新模型5%流量旧模型95%流量观测核心指标延迟/错误率/点踩率逐步放量5%→20%→50%→100%方案二用户ID哈希分流按用户ID尾号路由到不同模型版本好处同一用户始终看到同一版本体验一致方案三请求头/参数路由通过API参数指定模型版本适合内部测试观测与决策至少观测1-3天积累足够样本核心指标优于旧版且无异常 → 扩大灰度比例指标持平 → 保留旧版或增加灰度比例再观察指标劣化或出现异常 → 立即回滚面试点灰度不是技术炫技是控制风险的工程纪律模型网关设计为什么需要模型网关多个模型服务不同版本/不同用途需要统一入口管理避免每个业务方直接连模型服务耦合太紧统一做路由、限流、降级、鉴权、计费模型网关的核心功能路由根据请求特征用户/场景/模型名称路由到不同模型服务举例VIP用户路由到高配模型普通用户路由到量化模型限流每个用户/每个API Key设QPS上限防止被打爆降级主模型挂了自动切换到备用模型或返回兜底话术鉴权统一验证API Key和权限日志与监控记录每次请求的模型版本、延迟、Token消耗实现方式轻量方案Nginx/Envoy反向代理 Lua/插件做路由逻辑定制方案自建Gateway服务FastAPI/Go集成路由和限流逻辑面试点模型网关是微服务架构下管理多个模型服务的标准组件面试点能说清模型网关API网关模型路由证明有系统架构思维高并发服务架构架构分层接入层负载均衡Nginx/ALB分发请求到多个推理实例推理层多个vLLM/TGI实例水平扩展缓存层Redis缓存热点问题结果减少推理调用存储层模型文件存储对象存储/共享文件系统水平扩展策略无状态设计每个推理实例独立不存储会话状态自动扩缩容根据GPU利用率和请求排队长度自动增减实例面试点推理服务做成无状态可水平扩展是扛住高并发的关键连接池与并发控制推理实例前端放连接池复用HTTP连接限制每个实例的最大并发请求数防止过载面试点高并发架构不是单点优化是分层解耦水平扩展的组合监控与告警体系核心监控指标服务质量指标TTFT首Token延迟P50/P95/P99TPOT每Token生成时间平均值和P95端到端延迟从请求到完整回复的总时间吞吐量QPS和Token/s系统资源指标GPU利用率太低浪费资源太高接近瓶颈显存使用率超过90%告警接近OOMCPU/内存/网络IO业务指标错误率5xx错误比例排队长度等待处理的请求数Token消耗量控制成本告警规则设计P99延迟超过SLA阈值如5秒→ 告警错误率超过5% → 告警GPU显存使用率超过95% → 紧急告警排队长度持续增长 → 预警可能需要扩容监控工具Prometheus Grafana采集和可视化指标vLLM自带Metrics接口暴露TTFT/TPOT/吞吐等指标面试点监控不只是搭工具关键是定义SLA和告警阈值面试点生产部署的底线是“出问题能第一时间知道”快速回滚机制什么时候需要回滚新模型上线后错误率飙升延迟指标明显劣化P99延迟翻倍用户投诉明显增多回滚方案方案一模型版本管理模型文件按版本号存储如v1.0/v1.1/v2.0回滚 把推理服务指向旧版本模型文件方案二流量切换灰度时保留旧版服务不下线回滚 把流量从新版切回旧版秒级完成方案三配置热更新模型路径做成配置项改配置即切换无需重启服务回滚后必做排查原因新模型哪里出了问题修复后重新灰度验证面试点回滚不是终点是止损后的排查和修复起点面试点快速回滚是生产部署的安全网灰度是回滚的前置条件面试话术生产部署实践“上线新模型我走灰度流程先切5%流量观测1-3天核心指标正常逐步放量到全量”“模型网关我用来统一管理多个模型服务做路由、限流、降级不让业务方直接连推理实例”“监控上我盯三个核心指标首Token延迟、错误率、GPU显存分别对应用户体验、服务稳定性和资源瓶颈”“回滚上我保留旧版服务不下线灰度期间出事秒级切回配置热更新不用重启”
