1. 从一张显卡说起为什么模型部署绕不开GPU适配搞LLM应用开发绕来绕去最后都会撞上同一堵墙——模型跑不起来或者跑起来慢得让人想砸键盘。很多人以为把模型权重下载下来、装个推理框架就完事了结果一上手发现显存爆了、算子不支持、精度对不上甚至驱动版本差一个小数点就直接给你甩个CUDA error。这些问题归根结底都指向同一个核心GPU适配优化。我做了几年模型部署踩过的坑比跑通的模型还多。这篇文章不打算给你讲教科书式的GPU架构原理而是从一线部署的视角把GPU在LLM推理场景下的适配逻辑、选型思路、优化手段和排查经验掰开揉碎讲清楚。不管你是刚接触模型部署的新手还是已经能跑通vLLM但搞不定性能调优的老手下面这些内容应该都能帮你少走一些弯路。先明确一下讨论范围这里说的“GPU面面观”聚焦在LLM模型部署与推理这个具体场景下GPU相关的适配与优化问题。包括硬件选型怎么定、显存怎么算、算子怎么匹配、推理引擎怎么挑、多卡怎么配、性能怎么压榨。每一个点我都会给出可操作的判断依据和实操建议而不是泛泛而谈“要看具体情况”。2. GPU适配优化的整体思路拆解2.1 为什么GPU适配是LLM部署的核心矛盾LLM推理和传统深度学习推理有一个本质区别模型太大了。一个7B参数的模型FP16精度下光权重就要占大约14GB显存再加上KV Cache、中间激活值、框架自身的开销实际占用轻松突破18GB。这意味着很多消费级显卡连模型都装不下更别提跑出可用的吞吐量。这就引出了GPU适配的第一个核心矛盾显存容量与模型规模的匹配问题。你手里有什么卡决定了你能跑什么模型、用什么精度、开多大的并发。这不是一个可以绕过去的问题而是一切优化的起点。第二个矛盾是算力与延迟的平衡。LLM推理分两个阶段Prefill阶段是计算密集型的需要大量矩阵运算吃的是GPU的浮点算力Decode阶段是访存密集型的每生成一个token都要把整个模型权重读一遍吃的是显存带宽。这两个阶段对GPU的需求完全不同而实际部署中你往往需要在两者之间做取舍。第三个矛盾是生态兼容性。不同推理框架对GPU架构的支持程度不一样不同GPU厂商的软件栈成熟度也参差不齐。你选了一张卡不只是选了硬件还选了它背后的整个软件生态。2.2 适配优化的三层逻辑硬件、框架、模型我把GPU适配优化分成三个层次来理解从下往上依次是硬件层、框架层和模型层。硬件层关注的是GPU本身的物理特性显存容量、显存带宽、CUDA核心数、Tensor Core支持、互联带宽多卡场景。这一层决定了你的性能上限是硬约束。框架层关注的是推理引擎和运行时环境CUDA版本、cuDNN版本、推理框架vLLM、TensorRT-LLM、llama.cpp等对特定GPU架构的支持情况、算子实现质量。这一层决定了你能发挥出硬件多少潜力。模型层关注的是模型本身的特性参数量、精度需求、注意力机制类型MHA/GQA/MQA、是否用了MoE架构、KV Cache的大小。这一层决定了你对硬件和框架的具体需求。三层之间的关系是模型层提出需求硬件层划定边界框架层在边界内做匹配和优化。任何一层出了问题整个部署方案就会卡住。实际工作中我习惯先从模型层倒推需求再看硬件层能不能满足最后在框架层找最优解。2.3 常见GPU选型路线与适用场景目前LLM推理场景下常见的GPU选择大致可以分成几条路线每条路线都有自己的适用场景和坑。路线一消费级显卡RTX系列。代表型号是RTX 409024GB、RTX 309024GB、RTX 4060 Ti 16GB等。优势是性价比高、容易获取、社区支持好。劣势是显存有限、没有NVLink、多卡扩展性差。适合个人开发者、小团队做原型验证和小规模部署。24GB显存可以跑7B模型FP16、13B模型INT8、或者经过量化后的更大模型。路线二专业级显卡A系列、L系列。代表型号是A10040GB/80GB、A600048GB、L40S48GB等。优势是显存大、支持NVLink、软件栈成熟。劣势是价格高、获取门槛高。适合企业级部署和对延迟有严格要求的场景。A100 80GB是目前LLM推理最主流的专业卡之一单卡可以跑13B FP16或者70B INT4。路线三国产加速卡。包括昇腾系列、寒武纪等。优势是在特定场景下有供应保障和成本优势。劣势是软件生态相对不成熟很多推理框架的支持还在完善中。选择这条路线需要做好充分的技术验证确认你用的推理框架和目标模型能在上面跑通。路线四云端GPU租用。不买卡按需租用云端的GPU资源。优势是灵活、无前期投入、可以随时切换卡型。劣势是长期成本可能更高、数据需要上传到云端。适合项目初期验证和弹性扩容场景。选哪条路线核心看三个因素预算、模型规模、部署规模。预算有限且模型不超过13B消费级显卡是首选需要跑70B以上模型或者要求高并发专业卡或云端方案更合适对供应链有特殊要求的场景国产卡值得评估但要留足验证时间。3. 显存计算与精度选择部署前必须算清楚的账3.1 显存占用的四个组成部分很多人部署模型时只看权重占多少显存结果跑起来发现实际占用远超预期。LLM推理的显存占用由四部分组成缺一不可。模型权重是最直观的部分。计算公式很简单参数量 × 每个参数的字节数。FP16是2字节INT8是1字节INT4是0.5字节。一个7B模型FP16需要约14GBINT8需要约7GBINT4需要约3.5GB。KV Cache是容易被忽略的大头。KV Cache的大小取决于批次大小、序列长度、层数、注意力头数和头维度。计算公式是2 × 层数 × 批次大小 × 序列长度 × 注意力头数 × 头维度 × 精度字节数。以一个7B模型为例32层32个注意力头头维度128在批次大小为1、序列长度为4096、FP16精度下KV Cache约为2 × 32 × 1 × 4096 × 32 × 128 × 2 2GB。如果批次大小提到8KV Cache就变成16GB直接超过模型权重本身。中间激活值在Prefill阶段比较显著Decode阶段相对较小。这部分和具体实现有关通常预留1-2GB比较稳妥。框架开销包括CUDA上下文、通信缓冲区、内存池等通常预留0.5-1GB。所以一个7B模型FP16部署实际显存需求大约是14GB权重 2GBKV Cache批次1 1GB激活值 0.5GB框架 17.5GB。24GB的卡跑起来刚刚好但几乎没有余量做并发。3.2 精度选择FP16、INT8、INT4怎么选精度选择本质上是在显存占用、推理速度和输出质量之间做权衡。FP16/BF16是默认选择输出质量最好不需要额外的量化处理。缺点是显存占用大。如果显存够用优先选这个。INT8量化可以把显存占用减半推理速度通常也有提升因为访存量减少。质量损失一般很小在大多数任务上几乎感知不到。主流的INT8量化方案有GPTQ、AWQ、SmoothQuant等。我实测下来AWQ在LLM上的表现比较均衡推荐优先尝试。INT4量化把显存占用压到FP16的四分之一可以让你在消费级显卡上跑更大的模型。但质量损失开始变得明显尤其是在需要精确推理的任务上。INT4方案有GPTQ、AWQ、GGUF等。GGUF格式配合llama.cpp在CPUGPU混合推理场景下很实用。选择精度的实操建议先看显存能不能装下FP16能装就装装不下就上INT8INT8还装不下再考虑INT4。不要一上来就INT4质量损失是实打实的。3.3 实操显存需求快速估算方法我平时用一个简化公式快速估算显存需求 ≈ 参数量(B) × 精度字节数 × 1.2 KV Cache 1.5GB其中1.2是权重之外的额外开销系数包括embedding层、LayerNorm等1.5GB是激活值和框架开销的预留。KV Cache按实际批次和序列长度单独算。举个例子13B模型INT8部署批次大小4序列长度2048。权重13 × 1 × 1.2 15.6GBKV Cache2 × 40层 × 4 × 2048 × 40头 × 128维 × 1字节 ≈ 3.3GB预留1.5GB总计约20.4GB24GB的卡可以跑但余量不大。如果要提高并发就需要考虑INT4或者换更大的卡。注意这个公式是快速估算用的实际占用会因框架实现、模型结构不同而有偏差。正式部署前一定要用实际模型跑一遍观察nvidia-smi的实际占用。4. 推理引擎选型不同GPU架构下的最优解4.1 主流推理引擎对比与适用场景选推理引擎和选GPU一样重要甚至更重要。同一个模型在同一张卡上用不同的推理引擎吞吐量可能差好几倍。vLLM是目前最流行的LLM推理引擎之一核心优势是PagedAttention和连续批处理Continuous Batching。PagedAttention把KV Cache分页管理大幅减少了显存碎片使得高并发场景下的显存利用率显著提升。连续批处理让不同请求可以在不同时间点加入和退出批次提高了GPU利用率。vLLM对NVIDIA GPU支持最好AMD和国产卡的支持在逐步完善中。TensorRT-LLM是NVIDIA官方的推理加速方案基于TensorRT做深度优化。优势是性能极致尤其是在A100/H100等专业卡上通过算子融合、量化、内核自动调优等手段可以把延迟压到很低。劣势是编译流程复杂、对模型的支持不如vLLM灵活、调试难度大。llama.cpp是轻量级推理方案支持CPU、GPU以及混合推理。优势是部署简单、对硬件要求低、GGUF格式的量化模型生态丰富。劣势是GPU利用率不如vLLM和TensorRT-LLM高并发场景下性能差距明显。适合个人开发者在消费级硬件上跑模型。Text Generation InferenceTGI是HuggingFace推出的推理服务框架和HuggingFace生态集成好支持张量并行、量化、流式输出等特性。性能介于vLLM和TensorRT-LLM之间部署体验比较友好。SGLang是较新的推理引擎核心特色是RadixAttention对多轮对话场景下的KV Cache复用做了优化。在对话类应用中性能表现突出。选型建议NVIDIA专业卡追求极致性能选TensorRT-LLM通用场景和快速迭代选vLLM消费级显卡和个人开发选llama.cppHuggingFace重度用户选TGI多轮对话场景可以试试SGLang。4.2 框架与GPU架构的兼容性排查选好推理引擎后第一件事是确认它和你的GPU架构兼容。这里有几个关键检查点。CUDA Compute Capability是最核心的指标。每个GPU架构对应一个Compute Capability版本比如RTX 4090是8.9A100是8.0H100是9.0。推理框架在编译时会针对特定的Compute Capability生成代码如果你的GPU架构不在支持列表里要么跑不了要么跑的是兼容模式性能大打折扣。CUDA版本要和GPU驱动版本匹配。每个CUDA版本有最低驱动版本要求比如CUDA 12.1需要驱动版本530。驱动版本不够CUDA就初始化不了。用nvidia-smi可以查看当前驱动版本和最高支持的CUDA版本。框架预编译包的架构支持也要确认。有些推理框架的pip包只编译了特定架构的kernel比如只支持SM 7.0以上。如果你的卡是更老的架构就需要从源码编译。排查流程我一般是这样先nvidia-smi看驱动和CUDA版本再查推理框架的文档确认支持的Compute Capability范围然后跑一个最小推理示例验证。如果报错优先看是不是架构不支持。4.3 实操从零搭建vLLM推理环境以vLLM为例走一遍完整的搭建流程。第一步确认GPU环境。运行nvidia-smi记录驱动版本、CUDA版本、GPU型号和显存大小。第二步创建Python虚拟环境。推荐用conda或venv隔离环境避免依赖冲突。conda create -n vllm python3.10 -y conda activate vllm第三步安装vLLM。vLLM的安装包会自动处理CUDA依赖但要注意PyTorch版本和CUDA版本的匹配。pip install vllm如果网络环境导致下载慢可以指定国内镜像源。安装完成后用python -c import vllm; print(vllm.__version__)验证。第四步启动推理服务。以Qwen2.5-7B-Instruct为例python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --dtype auto \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000关键参数说明--dtype auto让vLLM自动选择精度--max-model-len控制最大序列长度直接影响KV Cache大小--gpu-memory-utilization 0.9表示使用90%的显存留10%给系统。第五步验证服务。用curl发一个请求curl http://localhost:8000/v1/completions \ -H Content-Type: application/json \ -d {model: Qwen/Qwen2.5-7B-Instruct, prompt: 你好, max_tokens: 50}如果返回正常说明环境搭建成功。接下来可以压测看吞吐量和延迟根据结果调整参数。实操心得--gpu-memory-utilization不要设成1.0留一点余量给CUDA上下文和临时分配。设成0.85-0.9比较稳妥。如果启动时报OOM优先降低这个值或者减小--max-model-len。5. 多卡部署与性能调优实战5.1 张量并行与流水线并行的选择单卡装不下模型时就需要多卡。多卡部署有两种主流并行策略张量并行Tensor ParallelismTP和流水线并行Pipeline ParallelismPP。张量并行把每一层的矩阵运算切分到多张卡上每张卡计算一部分然后通过通信汇总结果。优势是单层内的计算被并行化延迟低。劣势是通信频繁对卡间带宽要求高。适合NVLink互联的场景比如A100/H100集群。vLLM的--tensor-parallel-size参数就是控制TP的。流水线并行把模型的不同层分配到不同卡上数据像流水线一样依次经过各张卡。优势是通信量小对带宽要求低。劣势是有流水线气泡GPU利用率可能不均衡。适合卡间带宽有限的场景。实际选择如果卡间有NVLink或高速互联优先TP如果只有PCIe互联TP的通信开销可能成为瓶颈这时候可以考虑TPPP混合。对于大多数中小规模部署TP2或TP4是比较常见的选择。5.2 关键性能指标吞吐量、延迟、显存利用率性能调优要有明确的指标否则就是瞎调。LLM推理场景下关注三个核心指标。吞吐量Throughput通常用tokens/s衡量表示单位时间内系统能生成多少token。高吞吐量适合批量处理场景比如离线数据生成。延迟Latency分首token延迟TTFT和每token延迟TPOT。TTFT影响用户的第一印象TPOT影响生成速度的体感。交互式应用对延迟敏感需要优先优化。显存利用率反映GPU显存的利用效率。太低说明浪费太高说明没有余量应对峰值。一般控制在85%-92%比较合理。这三个指标往往互相制约。提高批次大小可以提升吞吐量但会增加延迟和显存占用。调优的本质是在三者之间找到适合你场景的平衡点。5.3 实操用vLLM压测并调优参数vLLM自带benchmark工具可以直接用来压测。python -m vllm.benchmarks.benchmark_throughput \ --model Qwen/Qwen2.5-7B-Instruct \ --num-prompts 100 \ --input-len 128 \ --output-len 256这个命令会跑100个请求每个请求输入128token、输出256token然后报告吞吐量。调优时重点调整这几个参数--max-num-seqs控制同时处理的最大请求数。调大可以提高吞吐量但增加显存占用和延迟。--max-model-len最大序列长度。调小可以节省KV Cache显存但限制了长文本处理能力。--gpu-memory-utilization显存使用比例。调高可以容纳更多KV Cache但风险也更大。--enable-chunked-prefill开启分块Prefill可以降低长请求对短请求的阻塞改善延迟表现。我的调优流程是先固定其他参数单独调--max-num-seqs观察吞吐量和延迟的变化曲线找到拐点然后调--max-model-len在满足业务需求的前提下尽量减小最后微调--gpu-memory-utilization留出合理余量。注意压测时要用真实场景的输入输出长度分布不要只用固定长度。实际业务中请求长度是变化的固定长度压测的结果可能过于乐观。6. 常见问题与排查技巧实录6.1 显存溢出OOM的排查路径OOM是LLM部署中最常见的问题排查思路要清晰。第一步确认是加载时OOM还是推理时OOM。加载时OOM说明模型权重加框架开销就超了需要降精度或换卡。推理时OOM说明KV Cache或激活值超了需要减小批次、序列长度或降低--gpu-memory-utilization。第二步用nvidia-smi观察显存占用的变化。如果显存是逐渐涨上去然后OOM大概率是KV Cache管理问题如果是一下子就OOM可能是某个操作分配了大块内存。第三步检查是否有显存泄漏。长时间运行后显存持续增长不释放可能是框架的bug或者配置问题。可以尝试更新框架版本或者调整内存池配置。常见解决方案降低--gpu-memory-utilization、减小--max-model-len、降低--max-num-seqs、换用更低精度的量化模型、开启CPU offload把部分层放到CPU内存。6.2 推理速度慢的典型原因与优化推理速度慢的原因很多我按出现频率排个序。批次大小太小是最常见的原因。批次为1时GPU利用率很低增大批次可以显著提升吞吐量。但要注意延迟也会增加。KV Cache没有复用。多轮对话场景下如果每轮都重新计算整个上下文的KV Cache浪费很大。vLLM的Prefix Caching和SGLang的RadixAttention就是解决这个问题的。精度太高。FP16比INT8慢INT8比INT4慢在访存瓶颈场景下。如果延迟要求高且能接受质量损失可以降精度。算子没有优化。某些推理框架对特定模型的算子实现不够优化导致计算效率低。可以尝试换推理框架或者等框架更新。PCIe带宽瓶颈。多卡TP场景下如果卡间通信走PCIe带宽可能成为瓶颈。用NVLink可以显著改善。6.3 常见问题速查表问题现象可能原因排查方法解决方案启动时OOM模型权重框架开销超显存计算权重显存需求降精度、换卡、CPU offload推理时OOMKV Cache或激活值超限观察显存增长曲线减小批次/序列长度、降gpu-memory-utilization推理速度慢批次小、精度高、算子未优化压测对比不同配置增大批次、降精度、换框架CUDA error驱动/CUDA版本不匹配nvidia-smi查版本升级驱动或降CUDA版本算子不支持GPU架构不在支持列表查框架文档的架构支持换框架、从源码编译多卡通信慢PCIe带宽瓶颈对比单卡和多卡性能用NVLink、调整TP/PP策略显存泄漏框架bug或配置问题长时间运行观察显存更新框架、调整内存池输出质量差量化损失过大对比FP16和量化输出换量化方案、提高精度6.4 独家避坑经验分享说几个文档里不会写但实际会遇到的坑。坑一驱动版本自动更新导致环境崩溃。Linux系统自动更新驱动后CUDA版本可能变化导致之前编译好的推理框架无法运行。建议锁定驱动版本关闭自动更新。坑二显存碎片导致“假OOM”。有时候nvidia-smi显示还有空闲显存但程序就是分配不了。这是显存碎片问题。vLLM的PagedAttention就是为解决这个问题设计的。如果用的框架没有类似机制可以尝试重启服务释放碎片。坑三多卡负载不均衡。TP场景下如果各卡的计算量不一致会出现有的卡忙死、有的卡闲死的情况。用nvidia-smi -l 1持续观察各卡利用率如果差异大检查模型切分策略。坑四量化模型的实际显存占用比理论值高。INT4量化理论上权重占0.5字节/参数但实际因为反量化开销、scale/zero_point存储等实际占用会高10%-20%。估算时要留足余量。坑五长序列场景下KV Cache爆炸。序列长度从2048提到8192KV Cache直接翻4倍。长文本场景一定要单独算KV Cache不能按短序列的经验估。7. 不同硬件平台上的部署策略差异7.1 消费级显卡的部署要点消费级显卡RTX系列部署LLM核心约束是显存。24GB是主流上限意味着7B FP16是舒适区13B需要INT8再大就要INT4或者多卡。消费级卡没有NVLink多卡只能走PCIe。TP的通信开销会比较明显建议TP不超过2。如果模型实在大考虑用llama.cpp做CPUGPU混合推理把部分层放到CPU内存。消费级卡的另一个问题是散热和功耗。长时间高负载推理会导致降频影响性能稳定性。建议做好机箱散热必要时限制功耗上限。7.2 专业级显卡的部署要点专业级显卡A100、L40S等显存大、带宽高、支持NVLink部署策略更灵活。A100 80GB单卡可以跑13B FP16或者70B INT4双卡NVLink可以跑70B INT8。专业卡上优先用TensorRT-LLM做极致优化或者用vLLM做通用部署。多卡场景下TP可以开到4甚至8NVLink的高带宽能撑住通信开销。专业卡通常部署在服务器上要注意机箱风道和电源冗余。A100的功耗是300W-400W多卡场景下电源和散热都要提前规划。7.3 国产加速卡的适配现状与建议国产加速卡昇腾等在LLM推理上的生态还在完善中。主流推理框架对国产卡的支持程度不一vLLM有昇腾的后端适配但版本更新可能滞后。选择国产卡的建议第一确认你要用的推理框架和目标模型有官方或社区的适配案例第二留足验证时间不要等到项目上线才发现跑不通第三关注框架的版本更新节奏国产卡的适配往往滞后于NVIDIA卡。适配过程中最常见的问题是算子不支持。某些模型用了特殊的注意力机制或激活函数国产卡上可能没有对应的优化算子。这时候要么等适配要么用通用算子性能会差一些要么换模型。8. 模型适配优化的进阶方向8.1 量化方案的深度对比GPTQ、AWQ、GGUF量化是显存优化的核心手段不同方案各有特点。GPTQ是基于二阶信息的后训练量化方法把权重逐层量化用校准数据最小化量化误差。优势是压缩率高、质量损失小。劣势是量化过程需要校准数据不同数据集的量化效果可能有差异。AWQ是激活感知的权重量化核心思想是保护对激活值影响大的权重通道。实测下来AWQ在LLM上的表现通常优于GPTQ尤其是在指令跟随任务上。推荐优先尝试。GGUF是llama.cpp使用的量化格式支持多种量化级别Q2_K到Q8_0。优势是格式灵活、CPUGPU混合推理支持好。劣势是GPU上的性能不如专用格式。选择建议NVIDIA GPU vLLM场景优先AWQ需要CPU推理或混合推理用GGUF对压缩率要求极高可以试GPTQ。8.2 投机采样与Medusa用更少算力换更高速度投机采样Speculative Decoding是一种用小型草稿模型加速大型目标模型推理的技术。核心思路是先用小模型快速生成多个候选token再用大模型一次性验证接受正确的token拒绝错误的。这样大模型每次前向传播可以生成多个token而不是一个。Medusa是投机采样的一种变体不用单独的草稿模型而是在目标模型上添加多个解码头并行预测多个后续token。优势是不需要额外的小模型部署更简单。这两种方法在延迟敏感的场景下效果显著可以把TPOT降低2-3倍。但要注意投机采样会增加显存占用草稿模型或额外解码头且加速效果取决于草稿模型和目标模型的一致性。8.3 持续批处理与PagedAttention的实际效果持续批处理Continuous Batching和PagedAttention是vLLM的两大核心特性实际效果值得单独说。持续批处理让不同请求可以在不同时间点加入和退出批次而不是等整个批次都完成才处理下一批。这样GPU不会因为等待最慢的请求而空闲利用率显著提升。实测下来在高并发场景下持续批处理可以把吞吐量提升2-5倍。PagedAttention把KV Cache分成固定大小的页按需分配不需要连续内存。这样显存碎片大幅减少可以容纳更多的并发请求。同时页的共享机制让相同前缀的请求可以复用KV Cache在多轮对话场景下节省大量显存。这两个特性配合使用是vLLM在高并发场景下性能领先的关键。部署时确保这两个特性开启vLLM默认开启并根据实际负载调整--max-num-seqs和--block-size参数。9. 从部署到上线稳定性保障要点9.1 监控指标与告警设置模型上线后监控是保障稳定性的基础。核心监控指标包括GPU利用率、显存占用、推理延迟TTFT和TPOT、吞吐量、错误率。GPU利用率和显存占用可以用nvidia-smi或者Prometheus DCGM exporter采集。推理延迟和吞吐量需要在应用层埋点。错误率包括CUDA error、OOM、超时等。告警阈值设置建议显存占用持续超过90%告警、TTFT超过业务容忍阈值告警、错误率超过1%告警。告警要分级P0告警立即处理P1告警当天处理。9.2 灰度发布与回滚策略模型更新或配置调整时不要一次性全量发布。先灰度一小部分流量观察监控指标确认稳定后再逐步扩大。灰度期间重点观察新版本的延迟和吞吐量是否达标、输出质量是否有下降、显存占用是否异常。如果发现问题立即回滚到旧版本。回滚策略要提前准备好保留旧版本的模型文件和配置、确保回滚操作可以在5分钟内完成、回滚后验证服务恢复正常。9.3 长期运行中的显存管理长时间运行后显存碎片和泄漏可能导致性能下降甚至OOM。建议定期重启推理服务比如每天凌晨低峰期释放累积的碎片。如果框架支持开启显存池化Memory Pooling可以减少碎片。vLLM的PagedAttention本身就是一种显存管理机制但框架层面的内存池也有帮助。另外监控显存的长期趋势。如果发现显存占用持续缓慢增长大概率是泄漏需要排查框架或代码问题。常见泄漏点包括未释放的KV Cache、未清理的临时张量、日志或缓存累积。实操心得我习惯在服务启动脚本里加一个定时重启的逻辑每天凌晨3点重启一次。虽然理论上不需要但实际跑下来定期重启能避免很多莫名其妙的显存问题。重启前做好流量切换确保不影响在线请求。10. 一些个人体会GPU适配优化这件事说到底是一个不断做取舍的过程。显存、延迟、吞吐量、成本、质量这几个维度很难同时最优。我的经验是先明确业务的核心需求——是延迟敏感还是吞吐量敏感是质量优先还是成本优先——然后围绕核心需求做优化其他维度只要不拖后腿就行。另外不要过度优化。我见过不少团队花大量时间调参把吞吐量从1000 tokens/s压到1200 tokens/s但业务实际只需要500 tokens/s。优化的收益要放在业务场景里衡量脱离场景的优化没有意义。最后保持对新技术和新硬件的关注。这个领域变化太快今天的最优解可能半年后就过时了。多动手实测少看营销材料自己的benchmark结果才是最可靠的依据。