企业官网建设流程全解析

1. 这不是招聘启事，而是一份AI基础设施工程师的实战能力图谱

“诚招AI Infra 工程师 · 推理引擎开发方向”——看到这行字，我第一反应不是点开JD投简历，而是立刻打开本地终端，敲了两行命令：nvidia-smi和lsof -i :8000。为什么？因为真正懂这个岗位的人，脑子里没有“岗位描述”，只有三组正在跑的进程、四类正在排队的请求、五种可能崩在GPU显存边缘的模型实例。这不是HR写的招聘广告，这是AI系统在真实生产环境里发出的求救信号。

AI Infra，不是PPT里的“AI底座”或“大模型基座”，它是凌晨两点告警群里跳出来的CUDA out of memory错误堆栈，是业务方催着上线新模型时你发现TensorRT编译耗时比模型训练还长，是线上QPS从200突然掉到20后查了一整晚才发现是gRPC连接池没设超时导致线程全卡死。推理引擎开发，也不是调用一下HuggingFace的pipeline()就能交差的事——它意味着你要亲手把PyTorch的.pt文件，变成能在4核ARM芯片上稳定跑出12ms延迟的量化算子图；意味着你要在不改一行业务代码的前提下，把一个BERT-base模型的内存占用从3.2GB压到896MB；意味着当产品经理说“这个新模型要支持动态batch size”时，你得立刻判断是改调度器还是重写KV Cache管理逻辑。

关键词“AI Infra”和“推理引擎”背后，藏着三个硬核事实：第一，它已经彻底脱离纯算法范畴，进入系统工程深水区；第二，它的技术债比模型本身更难还——一个写错的CUDA kernel可能让整个集群的GPU利用率长期卡在35%；第三，它的价值从来不在“做了什么”，而在“没出什么事”。我带过三支推理引擎团队，最常被夸的不是上线了多牛的新功能，而是连续187天零P0故障、平均延迟波动小于±0.8ms、资源成本年降23%。这些数字背后，是每天盯着Prometheus面板调参、对着Nsight Compute火焰图抠kernel launch配置、在Kubernetes Event里翻找OOMKilled记录的日常。

如果你正考虑切入这个方向，别急着刷LeetCode——先去GitHub搜tensorrt、vllm、onnxruntime的issue区，看最近30天最热的5个bug是什么；下载一份Llama-3-8B的ONNX模型，在本地用onnxruntime-gpu跑起来，故意把--providers ['CUDAExecutionProvider']改成['CPUExecutionProvider']，感受下延迟从37ms飙到2140ms的窒息感；再用ps aux | grep python看看自己笔记本上那些“后台运行”的AI demo到底占了多少内存。真正的门槛，从来不在概念，而在你愿不愿意为每一毫秒延迟、每一MB显存、每一次context switch付出显微镜级的耐心。

2. 推理引擎开发的核心战场：从模型交付到服务落地的七道生死关

2.1 第一道关：模型格式战争与IR抽象层设计

模型交付到推理引擎，绝不是拖个.pt文件进来就完事。现实中的模型来源五花八门：PyTorch训练导出的torchscript、TensorFlow SavedModel、HuggingFace Hub上的transformers模型、甚至客户自己用MXNet训的旧模型。每种格式背后是完全不同的计算图表达、内存布局约定和算子语义。比如PyTorch的aten::add和ONNX的Add在广播规则上就有细微差异，而TensorRT对aten::bmm的支持直到8.6版本才完善——这意味着你得在IR（Intermediate Representation）层做一层“语义对齐”。

我们团队踩过的典型坑：某金融客户提供的scikit-learn 1.5.x逻辑回归模型，用sklearn2onnx转成ONNX后，TreeEnsembleClassifier节点的nodes_falsenodeids字段在ONNX Runtime里解析正常，但在TensorRT中触发了INVALID_GRAPH: Unknown layer type。根因是ONNX spec 1.14对树模型的定义变更，而TensorRT 8.5只认1.12。解决方案不是升级TensorRT（客户环境锁死），而是写了个轻量IR转换器，在ONNX加载后、TRT解析前，把nodes_falsenodeids重映射为nodes_truenodeids的补集——12行Python代码，解决了客户价值千万的实时评分主引擎上线卡点。

提示：IR层不是越通用越好。vLLM选择自研PagedAttention IR而非直接用ONNX，是因为ONNX无法表达KV Cache的分页内存管理；Triton Inference Server保留ONNX但加了custom op扩展机制，本质是在IR层留了“打补丁”的活口。你的IR设计哲学，决定了后续六道关的改造成本。

2.2 第二道关：算子优化与硬件亲和性调优

推理引擎的性能天花板，90%由算子实现决定。同一层Linear，在不同硬件上有截然不同的最优解：

• 在A100上：用cuBLAS的GEMM+ Tensor Core FP16，batch=32时吞吐达1.2TFLOPS；
• 在T4上：改用INT8量化+cuBLASLt，batch=16时延迟降低41%；
• 在Jetson Orin上：必须手写Triton kernel，用shared memory做tile reuse，否则DDR带宽直接吃满。

我们曾为一个OCR模型的Conv2d层做专项优化。原始PyTorch实现用nn.Conv2d，在A100上batch=1延迟18.7ms。第一步：用TVM AutoScheduler生成CUDA kernel，降到12.3ms；第二步：发现输入feature map有大量零值，改用稀疏卷积（SpConv），降到9.1ms；第三步：观察到该层输出channel数=64，而A100的warp size=32，于是手动unroll loop并调整block dim，最终压到6.8ms——比原始实现快2.75倍。

关键参数选择逻辑：blockSize不是越大越好。实测发现，当blockSize=1024时，occupancy率仅37%（SM利用率低）；blockSize=512时occupancy达62%，但寄存器压力导致spill；最终选定blockSize=768，通过Nsight Compute验证寄存器使用率89%、shared memory使用率42%、L1 cache命中率93.7%，达成最佳平衡。这些数字不会出现在任何文档里，只存在于你反复nvprof --unified-memory-activity后的日志里。

2.3 第三道关：内存管理：从显存碎片到KV Cache生命周期

GPU显存是推理引擎的命脉，而显存管理是最容易被低估的领域。典型问题不是“不够用”，而是“用不好”：

• 碎片化：连续分配1GB显存失败，但实际空闲显存总量有1.8GB；
• 生命周期错配：模型权重常驻显存，但KV Cache随请求动态创建销毁；
• 跨请求污染：batch=4时，某个bad request的KV Cache异常增长，拖垮整个batch。

vLLM的PagedAttention是教科书级解法：把KV Cache按page（通常256x128 FP16）切片，用类似虚拟内存的页表管理。但落地时发现，当page size=256时，小模型（如Phi-3）的page table本身内存开销占比达7%；page size=1024时，大模型（Llama-3-70B）的TLB miss rate飙升。最终我们采用动态page size策略：根据模型hidden_size自动选择（hidden_size≤2048用512，否则用1024），配合per-request page allocator，显存利用率从61%提升至89%。

注意：不要迷信“零拷贝”。我们在RDMA集群测试发现，当GPU间通信带宽>200GB/s时，cudaMemcpyAsync比ncclSend/Recv延迟低17%，因为NCCL的ring buffer管理开销在短消息场景反而更大。显存管理没有银弹，只有针对具体硬件拓扑的暴力调优。

2.4 第四道关：调度系统：从静态batch到动态请求流控

传统batching（如TensorRT的max_batch_size）在真实业务中处处碰壁。电商搜索的query长度方差极大（“手机”vs“iPhone 15 Pro Max 256GB 深空黑 官方标配 全国联保”），固定batch size必然导致长query饿死短query。我们的解法是三级调度：

1. 接入层：Nginx+Lua做请求预分类，按token length分桶（<32, 32-128, >128）；
2. 队列层：每个桶配独立FIFO队列，但设置动态timeout（短query桶timeout=50ms，长query桶timeout=200ms）；
3. 执行层：调度器按“最小等待时间+最大吞吐”混合策略选batch，例如当前队列有[12, 45, 8]tokens的三个请求，优先组合12+8=20（满足min batch=16），而非等45到来。

实测效果：P99延迟从312ms降至89ms，长尾请求（>95%分位）处理速度提升3.2倍。关键洞察：调度算法的价值不在于理论最优，而在于对业务流量模式的拟合度。我们甚至为金融实时评分场景定制了“信用分加权调度”——高信用分用户请求优先级+30%，因为其业务损失成本是普通用户的5.7倍（基于历史坏账率反推）。

2.5 第五道关：服务治理：从单机推理到多租户SLA保障

当推理引擎从demo走向生产，服务治理成为生死线。核心矛盾是：如何在共享GPU资源下，保障不同业务线的SLA互不干扰？我们放弃K8s原生resource limit（它只管memory/CPU，不管GPU显存和compute time），自研了三层隔离机制：

• 显存隔离：基于NVIDIA MIG（Multi-Instance GPU），将A100物理卡切分为4个7GB实例，每个实例绑定独立业务；
• 算力隔离：用CUDA MPS（Multi-Process Service）限制每个租户的SM占用率上限（如风控模型限60%，推荐模型限30%）；
• QoS隔离：在gRPC层注入priority header，高优请求走独立线程池，且其CUDA context拥有更高scheduler priority。

最狠的一次压测：同时模拟风控（P99<50ms）、推荐（P99<200ms）、客服对话（P99<800ms）三路流量，故意让推荐服务突发流量打满GPU，结果风控P99仍稳定在48.3±2.1ms。秘诀在于MIG实例的硬件级隔离——它不像cgroups那样可被绕过，而是NVIDIA硬件强制的资源边界。

2.6 第六道关：可观测性：从日志埋点到根因定位黄金路径

推理服务的debug难度远超Web服务。一个500错误背后，可能是CUDA driver crash、NCCL timeout、ONNX runtime internal error，甚至是PCIe链路误码。我们构建了“黄金三角”可观测体系：

• 指标层：Prometheus采集GPU utilization、显存占用、CUDA context count、request queue length；
• 链路层：OpenTelemetry trace贯穿HTTP→gRPC→CUDA kernel→memory copy，关键span打标is_kernel_launch=true；
• 日志层：结构化日志强制包含model_id、input_hash、device_id、cuda_error_code。

某次线上事故：P99延迟突增300%。传统做法查日志，但日志里只有inference failed。用黄金三角定位：指标显示GPU utilization从72%骤降至12%，trace发现98%请求卡在cudaStreamSynchronize，日志grepcudaError_t=35（CUDA_ERROR_LAUNCH_TIMEOUT）。根因是客户更新驱动后，nvidia-smi dmon默认开启导致GPU watchdog误判kernel hang。解决方案：在容器启动脚本加nvidia-smi dmon -D禁用。没有这套体系，这类问题平均定位时间是6.2小时；有了它，压缩到11分钟。

2.7 第七道关：持续交付：从模型热更到灰度发布原子性

模型更新不能停服，这是铁律。但我们发现，单纯用“蓝绿部署”在推理场景会引发严重问题：新模型加载时，GPU显存瞬间暴涨，触发OOM Killer杀掉老模型进程。最终方案是“原子化热更”：

1. 新模型在独立CUDA context中加载、warmup、benchmark；
2. 用cudaEventRecord标记新旧模型切换点；
3. 调度器收到切换指令后，对新请求原子性地切换到新context，老请求继续在旧context完成；
4. 当旧context无活跃请求时，安全卸载。

关键保障：切换过程<100μs，且全程无显存realloc。我们用cudaMallocAsync替代cudaMalloc，配合per-context memory pool，使warmup阶段显存分配耗时从2.3s降至87ms。这套机制支撑了日均27次模型热更，零服务中断。

3. AI Infra工程师的八股真题：从面试题到生产现场的残酷映射

3.1 “请手写CUDA kernel实现矩阵乘法”——背后的真实考察能力

这道题绝不是考你背没背过《CUDA C Programming Guide》。面试官真正想看的是：

• 硬件意识：你是否知道A100的L2 cache line size是128B，因此tile size选16x16（FP16）刚好填满cache line？
• 内存访问模式：是否意识到global memory coalescing要求thread block内thread按row-major顺序读取，所以需要shared memory做transpose缓存？
• 边界处理：当矩阵尺寸非tile整除时，是用if (row < M && col < N)防护，还是用zero-padding？前者分支预测失败率高，后者浪费显存——我们选折中方案：padding到next multiple of 32，用__syncthreads()前加if (tid < 32*32)过滤无效thread。

我见过最惊艳的答案：候选人没写完整kernel，而是画了张图——左边是naive kernel的memory access pattern（锯齿状乱序），右边是tiling+shared memory后的pattern（规整的矩形块），并标注“L2 cache hit rate from 42% → 89%”。这比写一百行代码更能说明问题。

3.2 “如何优化Transformer推理延迟？”——业务场景拆解才是得分关键

标准答案（FlashAttention、PagedAttention、KV Cache量化）只能拿基础分。高分答案必须绑定具体场景：

• 场景1：金融实时评分
  特征维度固定（128维），但batch size波动大（1-200）。对策：用static batch + dynamic padding，把所有请求pad到max_len=128，避免attention mask计算开销；权重用INT4量化（误差<0.3%），显存省67%。

• 场景2：客服对话机器人
  输入长度极不均匀（3-512 tokens），且需streaming输出。对策：启用chunked prefill，把长输入切分成64-token chunks异步prefill；decode阶段用speculative decoding，用小模型（Phi-3）预测下一个token，大模型（Llama-3）仅验证——实测端到端延迟降38%。

• 场景3：边缘设备OCR
  硬件：Jetson Orin（32GB LPDDR5，无NVLink）。对策：放弃multi-head attention，改用grouped-query attention（GQA）减少KV Cache size；用Triton手写conv+attention fusion kernel，避免中间feature map落DDR。

实操心得：永远先问“你的P99延迟瓶颈在哪？”——是kernel compute bound（看nsight compute的sm__inst_executed）？还是memory bound（看l1tex__t_bytes）？或是IO bound（看pcie__tx_bytes）？没profile就优化，等于蒙眼开车。

3.3 “解释vLLM的PagedAttention原理”——考的是你能否识别架构取舍

vLLM的PagedAttention不是技术炫技，而是对LLM推理本质的深刻洞察：KV Cache的内存访问具有强局部性（当前token只读最近k个KV），但传统连续分配导致显存碎片化。其核心创新是：

• Page Table抽象：每个sequence的KV Cache被切分为固定size pages（如256x128），page table记录logical page id → physical page id映射；
• Copy-on-Write优化：fork新sequence时，只复制page table，物理pages共享，直到某page被修改才copy；
• Contiguous Memory Allocation：物理pages在显存中连续分配，消除碎片。

但面试官会追问：“为什么page size选256？不是128或512？”——答案涉及硬件细节：A100的memory bandwidth是2TB/s，但random access latency是120ns。page size=256时，一次page fault的TLB miss penalty≈120ns，而page size=128时TLB miss rate翻倍，总延迟反而上升。这些数字，只来自实测，不来自论文。

3.4 “如何设计一个支持多模型的推理服务？”——暴露你的系统工程思维

高分回答必须覆盖四个维度：

• 模型加载：用torch.compile预编译（AOT），避免runtime jit overhead；模型权重用mmap映射，启动时零拷贝；
• 资源隔离：MIG切分物理GPU，每个模型独占MIG instance，杜绝显存争抢；
• API抽象：统一REST/gRPC接口，但内部路由到不同executor（TensorRT for CNN, vLLM for LLM, ONNX Runtime for sklearn）；
• 生命周期管理：模型idle>30min自动unload，但warmup cache保留（下次load快3x）。

我们线上系统用此架构支撑17个模型，资源利用率从41%提升至79%，模型切换平均耗时<200ms。关键技巧：warmup cache不存权重，而存“first 10 token的KV Cache template”，这样load时只需memcpy template，无需重新计算。

3.5 “遇到CUDA OOM怎么办？”——考应急响应能力

标准流程（查显存、kill进程、重启）是及格线。真实高手会：

1. 立即取证：nvidia-smi -q -d MEMORY抓当前显存分布；nvidia-smi --gpu-report看ECC error；
2. 定位元凶：pynvml脚本遍历所有进程，统计cudaMemoryUsage，发现某Python进程显存异常（>95%）；
3. 根因分析：cuda-memcheck --leak-check full python script.py，发现torch.tensor(..., device='cuda')未detach，导致graph retain；
4. 临时修复：export CUDA_VISIBLE_DEVICES=0隔离问题GPU，不影响其他实例；
5. 永久修复：在PyTorch DataLoader加pin_memory=False，避免pin memory泄漏。

注意：nvidia-smi显示的显存≠CUDA实际占用。torch.cuda.memory_allocated()返回的是pytorch allocator管理的显存，而nvidia-smi显示的是driver层面的显存。两者差值往往是CUDA context、driver metadata等开销，这部分无法被pytorch释放。

3.6 “如何保证推理服务的稳定性？”——SLA不是口号，是数学公式

稳定性=可用性×一致性×可恢复性。我们用三个公式定义：

• 可用性：uptime / (uptime + downtime) ≥ 99.95%→ 要求年宕机≤4.38小时；
• 一致性：|output_A - output_B| < ε（ε由业务定义，如金融评分ε=0.001）；
• 可恢复性：MTTR ≤ 5min（Mean Time To Recovery）。

实现手段：

• 可用性：K8s Pod anti-affinity确保同模型实例不调度到同一物理机；GPU health check每30s执行nvidia-smi -q -d PIDS；
• 一致性：所有模型启用torch.backends.cudnn.benchmark = False，禁用cudnn auto-tuner，保证kernel选择确定性；
• 可恢复性：Chaos Engineering定期注入kill -9、nvidia-smi -r，验证auto-healing能力。

某次故障：GPU driver crash导致所有Pod pending。因提前配置了nodeSelector: nvidia.com/gpu.present: "true"+tolerations，K8s在37秒内将Pod调度到备用节点，MTTR=42秒。

3.7 “如何评估推理引擎性能？”——拒绝单一指标陷阱

业界常用指标（throughput、latency）极具误导性。我们坚持四维评估：

特别强调“弹性”指标：很多引擎在QPS=100时延迟80ms，但QPS=500时飙升至420ms。这说明调度器或内存管理存在瓶颈。我们曾因此否决了一个TPC-H benchmark跑分第一的引擎，因为它在burst traffic下P99延迟抖动达±300ms。

3.8 “AI Infra未来三年技术趋势？”——考你对产业落地的理解

不是泛泛而谈“MoE”、“RAG”，而是聚焦工程落地：

• 2024-2025：硬件协同设计爆发
  NVIDIA Blackwell架构的Transformer Engine已支持FP4，但现有推理引擎几乎无人适配。谁能率先在vLLM中集成FP4 GEMM，谁就拿下下一代LLM推理成本优势。

• 2025-2026：边缘推理标准化
  Jetson Orin、Intel Movidius、华为昇腾的算子兼容性仍是噩梦。ONNX 1.16新增的ai.onnx.preview.trainingdomain将被用于边缘模型优化，统一IR成为关键。

• 2026-2027：AI Infra即服务（AI IaaS）
  类似AWS EC2，但提供gpu_type=llm-optimized、latency_sla=50ms的抽象资源。这要求推理引擎具备跨云厂商的硬件抽象层（HAL），目前只有NVIDIA Triton接近此目标。

我的判断：未来三年，AI Infra工程师的核心竞争力，将从“调优单个引擎”转向“设计跨硬件抽象层”。现在就开始研究CUDA Graph、Triton IR、MLIR，比刷算法题重要十倍。

4. 从零搭建生产级推理引擎：一个可复现的端到端实操指南

4.1 环境准备：避开CUDA版本地狱的终极方案

别信“pip install torch==2.3.0+cu121”这种官方命令——它大概率让你陷入dependency hell。我们的生产环境初始化脚本：

# 1. 锁定CUDA driver version（关键！） nvidia-smi # 记录Driver Version，如535.104.05 # 2. 下载匹配的CUDA toolkit（不是最新版！） wget https://developer.download.nvidia.com/compute/cuda/12.1.1/local_installers/cuda_12.1.1_530.30.02_linux.run sudo sh cuda_12.1.1_530.30.02_linux.run --silent --override --toolkit --toolkitpath=/usr/local/cuda-12.1 # 3. 创建符号链接（避免PATH污染） sudo ln -sf /usr/local/cuda-12.1 /usr/local/cuda echo 'export PATH=/usr/local/cuda/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc # 4. 验证CUDA安装 nvcc --version # 必须输出12.1.105 nvidia-smi # Driver Version必须≥530.30.02

实操心得：CUDA driver version必须≥toolkit version。例如CUDA 12.1 toolkit要求driver≥530.30.02。如果nvidia-smi显示driver=525.60.11，则必须升级driver，否则torch.cuda.is_available()返回False。这个坑，我踩过7次。

4.2 模型加载与优化：以Llama-2-7B为例的全流程

步骤1：获取模型并转换为ONNX

# 使用transformers + optimum from transformers import AutoTokenizer, AutoModelForCausalLM from optimum.onnxruntime import ORTModelForCausalLM model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-2-7b-chat-hf") tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-2-7b-chat-hf") # 导出ONNX（注意：必须指定opset=17，否则vLLM不兼容） ort_model = ORTModelForCausalLM.from_pretrained( "meta-llama/Llama-2-7b-chat-hf", export=True, opset=17, use_cache=True )

步骤2：TensorRT优化（关键参数详解）

import tensorrt as trt # 创建builder config = builder.create_builder_config() config.set_flag(trt.BuilderFlag.FP16) # 必开，否则A100性能归零 config.set_flag(trt.BuilderFlag.STRICT_TYPES) # 避免int8/float16混用bug # 设置memory limit（必须！否则build失败） config.max_workspace_size = 10 * (1024**3) # 10GB # 优化profile（针对典型输入shape） profile = builder.create_optimization_profile() profile.set_shape("input_ids", (1, 1), (1, 512), (1, 512)) # min/opt/max profile.set_shape("attention_mask", (1, 1), (1, 512), (1, 512)) config.add_optimization_profile(profile) # 构建engine engine = builder.build_engine(network, config)

参数选择逻辑：

• max_workspace_size：不是越大越好。实测发现，设为8GB时build耗时12min，设为16GB时耗时47min，但最终engine性能无提升。原因是workspace用于kernel autotuning，超过阈值后收益递减。
• opset=17：ONNX Runtime 1.15+要求，旧opset会导致Unsupported op: RotaryEmbedding错误。

4.3 服务封装：gRPC + Prometheus监控的最小可行实现

proto定义（inference.proto）：

syntax = "proto3"; package inference; service InferenceService { rpc Predict(PredictRequest) returns (PredictResponse); } message PredictRequest { string model_name = 1; repeated int32 input_ids = 2; repeated int32 attention_mask = 3; } message PredictResponse { repeated float logits = 1; float latency_ms = 2; }

服务端核心逻辑（metrics集成）：

from prometheus_client import Counter, Histogram, Gauge # 定义metrics REQUEST_COUNT = Counter('inference_requests_total', 'Total requests', ['model', 'status']) LATENCY_HISTOGRAM = Histogram('inference_latency_seconds', 'Inference latency', ['model']) GPU_MEMORY_USAGE = Gauge('gpu_memory_used_bytes', 'GPU memory used', ['device']) class InferenceServicer(inference_pb2_grpc.InferenceServiceServicer): def Predict(self, request, context): start_time = time.time() try: # 执行推理... output = self.model.predict(request.input_ids) # 记录metrics REQUEST_COUNT.labels(model=request.model_name, status='success').inc() LATENCY_HISTOGRAM.labels(model=request.model_name).observe(time.time() - start_time) GPU_MEMORY_USAGE.labels(device='0').set(torch.cuda.memory_allocated()) return inference_pb2.PredictResponse( logits=output.tolist(), latency_ms=(time.time() - start_time) * 1000 ) except Exception as e: REQUEST_COUNT.labels(model=request.model_name, status='error').inc() context.set_details(str(e)) context.set_code(grpc.StatusCode.INTERNAL) raise

部署yaml（K8s）：

apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference spec: replicas: 3 template: spec: containers: - name: inference image: my-registry/llm-inference:v1.2 resources: limits: nvidia.com/gpu: 1 requests: nvidia.com/gpu: 1 env: - name: NVIDIA_VISIBLE_DEVICES value: "0" # 关键：启用GPU健康检查 livenessProbe: exec: command: ["nvidia-smi", "-q", "-d", "PIDS"] initialDelaySeconds: 30 periodSeconds: 10 --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: name: inference-monitor spec: endpoints: - port: metrics interval: 15s selector: matchLabels: app: llm-inference

4.4 压测与调优：Locust脚本与黄金参数集

locustfile.py：

from locust import HttpUser, task, between import json class InferenceUser(HttpUser): wait_time = between(0.1, 0.5) # 模拟真实请求间隔 @task def predict(self): # 动态生成不同长度输入（模拟真实流量） length = random.choice([32, 128, 512]) input_ids = [1] * length payload = { "model_name": "llama-2-7b", "input_ids": input_ids, "attention_mask": [1] * length } with self.client.post("/predict", json=payload, catch_response=True) as response: if response.status_code != 200: response.failure(f"HTTP {response.status_code}") elif response.json().get("latency_ms", 0) > 100: response.failure("Latency > 100ms")

压测黄金参数集（A100 40GB）：

调优口诀：先调max-batch-size看吞吐拐点，再调gpu-memory-utilization看OOM临界点，最后用--profile跑Nsight确认SM occupancy>65%。

4.5 故障排查：一份可直接抄作业的速查表

最后一个技巧：当所有命令都失效时，执行echo 1 > /proc/sys/vm/drop_caches清空page cache。这能解决30%的“玄学”问题，因为某些CUDA driver bug会导致page cache污染。

5. 我的血泪经验：那些没人告诉你的AI Infra生存