1. 显存墙与计算墙：LLM 推理性能调优到底卡在哪
大模型服务上线前，最容易被低估的就是推理性能调优。模型在实验室里跑通 demo 是一回事，放到线上扛并发、控延迟、压成本是另一回事。我见过太多团队把 7B 模型部署上去，单条请求响应还行，一旦并发上来，显存直接 OOM，或者吞吐量低到每张卡每秒只出几十个 token，GPU 利用率长期趴在 20% 以下。
先说清楚 LLM 推理性能调优是什么、能解决什么、适合谁。它是一套围绕显存占用、吞吐量、首 token 延迟（TTFT）三个核心指标做工程化优化的方法，适合正在把大模型服务推向生产环境的后端工程师、算法工程师和运维同学。核心矛盾来自两个物理约束：显存墙和计算墙。
显存墙很好理解。模型权重必须完整加载进 GPU 显存才能推理，FP16 精度下 7B 模型约需 14GB，70B 模型约需 140GB，单张 80GB 的卡根本放不下 70B。更麻烦的是，除了权重，推理过程中还要为每个请求维护 KV Cache，序列越长、并发越高，KV Cache 膨胀越厉害，显存被迅速吃满，批大小被迫压到很小，吞吐自然上不去。
计算墙则来自自回归生成的特性。生成每个 token 都要读取全部模型权重，计算密度极低，GPU 的计算单元大量时间在等显存带宽，算力利用率上不去。推理分两个阶段：预填充（Prefill）处理输入 prompt 的所有 token，计算 KV Cache，属于计算密集型；解码（Decode）逐个生成输出 token，每步读取 KV Cache 和权重，属于显存带宽密集型。两个阶段瓶颈不同，优化手段也不同。
实际生产中，优化目标不是单纯追求吞吐，而是在满足延迟 SLA 的前提下最大化吞吐量。这就需要在模型层、引擎层、系统层三个层面协同调优。下面我会从显存瓶颈定位开始，一步步给出可复制的压测配置、参数对照表，最后把服务 endpoint 切到统一 API 通道做连通性验证，让整套流程能稳定提升单位显存吞吐。
2. 显存瓶颈定位与 KV Cache 膨胀排查实战
定位显存瓶颈，第一步是搞清楚显存到底被谁吃了。很多人一上来就调 batch size，其实应该先量化拆解。显存占用大致分三块：模型权重、KV Cache、激活值与临时缓冲。权重是固定的，激活值相对小，真正随并发和序列长度动态膨胀的是 KV Cache。
KV Cache 的大小可以估算：每层每个 token 的 KV 占用约为 2 × num_layers × hidden_size × dtype_bytes。以 7B 模型（32 层、hidden 4096、FP16）为例，单个 token 的 KV Cache 约 2 × 32 × 4096 × 2 = 512KB。如果并发 32 条、每条序列 2048 token，KV Cache 就是 32 × 2048 × 512KB ≈ 32GB，比模型权重还大。这就是为什么长上下文场景下显存瞬间爆炸。
传统 KV Cache 预分配方式是按最大序列长度一次性预留连续显存，导致严重浪费和碎片。PagedAttention 的思路借鉴操作系统虚拟内存，把 KV Cache 切成固定大小的 Block（比如每块 16 个 token），按需分配、支持共享。下面这段代码展示了 Block 管理和分配的核心逻辑，你可以直接拿来理解显存碎片是怎么被消除的。
from dataclasses import dataclass, field import math @dataclass class KVBlock: block_id: int block_size: int = 16 ref_count: int = 0 is_free: bool = True class PagedAttentionManager: def __init__(self, num_blocks: int, block_size: int = 16): self.block_size = block_size self.blocks = {i: KVBlock(block_id=i, block_size=block_size) for i in range(num_blocks)} self.free_blocks = list(range(num_blocks)) self.block_tables = {} def allocate(self, sequence_id: int, num_tokens: int): num_blocks_needed = math.ceil(num_tokens / self.block_size) if len(self.free_blocks) < num_blocks_needed: self._evict_sequences(num_blocks_needed - len(self.free_blocks)) allocated = [] for _ in range(num_blocks_needed): if not self.free_blocks: raise RuntimeError("KV Cache 显存不足，无法分配新 Block") block_id = self.free_blocks.pop() self.blocks[block_id].is_free = False self.blocks[block_id].ref_count += 1 allocated.append(block_id) self.block_tables[sequence_id] = allocated return allocated def free(self, sequence_id: int): for block_id in self.block_tables.pop(sequence_id, []): block = self.blocks[block_id] block.ref_count -= 1 if block.ref_count <= 0: block.is_free = True self.free_blocks.append(block_id) def _evict_sequences(self, num_blocks_needed: int): freed = 0 for seq_id in list(self.block_tables.keys()): if freed >= num_blocks_needed: break freed += len(self.block_tables[seq_id]) self.free(seq_id)排查显存瓶颈时，我习惯用nvidia-smi配合推理引擎的显存统计接口，观察三个数：权重占用、KV Cache 占用、峰值占用。如果 KV Cache 占比超过 50%，说明瓶颈在缓存管理，优先上 PagedAttention 或前缀缓存；如果权重就快占满，说明该考虑量化或张量并行了。
还有一个常被忽略的点：批大小受限往往不是显存不够，而是碎片导致无法分配连续空间。PagedAttention 把碎片问题解决后，同样的显存能塞下更大的批，吞吐直接翻倍。实测下来，长上下文场景开启分页管理后，单位显存吞吐提升 2 到 4 倍是常见结果。
3. 吞吐优化配置：连续批处理、量化与并行策略
定位完显存瓶颈，接下来是吞吐优化。核心手段有四类：连续批处理、量化、并行策略、投机解码。先讲连续批处理，这是提升 GPU 利用率最直接的一招。
静态批处理要等一批里所有序列都生成完才释放资源，短请求被长请求拖死，GPU 大量时间空转。连续批处理在序列完成后立即插入新请求，批次槽位始终填满。下面这个调度器实现展示了核心逻辑，你可以对照自己的推理引擎配置理解参数含义。
import time from dataclasses import dataclass, field @dataclass class InferenceRequest: request_id: str prompt_tokens: list max_output_tokens: int generated_tokens: list = field(default_factory=list) is_completed: bool = False arrival_time: float = field(default_factory=time.time) class ContinuousBatchScheduler: def __init__(self, max_batch_size: int = 32): self.max_batch_size = max_batch_size self.waiting_queue = [] self.running_batch = [] def add_request(self, request: InferenceRequest): self.waiting_queue.append(request) def schedule(self): self.running_batch = [r for r in self.running_batch if not r.is_completed] available_slots = self.max_batch_size - len(self.running_batch) while available_slots > 0 and self.waiting_queue: self.running_batch.append(self.waiting_queue.pop(0)) available_slots -= 1 return self.running_batch def get_stats(self): return { "waiting": len(self.waiting_queue), "running": len(self.running_batch), }量化是降低显存占用和带宽需求的关键。INT8 权重量化精度损失小，适合 7B 以下模型；INT4-AWQ 能大幅压缩显存，适合 30B 以上模型。选择量化方案时，要结合模型大小和延迟 SLA。下面这张对照表是我在实际项目中总结的参数参考，注意具体数值需以你的目标数据集评测为准，不要照搬。
| 量化方案 | 显存降幅 | 精度损失 | 适用模型规模 | 延迟影响 |
|---|---|---|---|---|
| FP16 基线 | 0% | 无 | 任意 | 基准 |
| INT8 权重 | 约 50% | 小 | ≤7B | 略降 |
| INT8 全量 | 约 50% | 中 | ≤13B | 降 |
| INT4-GPTQ | 约 75% | 中偏大 | ≥30B | 明显降 |
| INT4-AWQ | 约 75% | 中 | ≥30B | 明显降 |
并行策略方面，张量并行把模型切分到多 GPU，每层计算后需要 AllReduce 同步，通信开销随卡数增加。超过 8 卡时通信容易成为瓶颈，需要高带宽互联。流水线并行按层切分，适合跨节点部署，但会有气泡等待。实际部署中，单机多卡优先张量并行，跨机再叠加流水线并行。
投机解码用小模型快速生成候选 token，大模型并行验证，接受正确的、拒绝错误的。加速比取决于草稿模型与目标模型的一致性，如果候选经常被拒，反而增加延迟。适合草稿模型和目标模型分布接近的场景。
把服务 endpoint 切到统一 API 通道时，配置要写全三件套：Base URL、Key、Model ID。以常见的 OpenAI 兼容配置为例，settings 片段如下：
{ "base_url": "https://taotoken.net/api", "api_key": "sk-你的统一Key", "model": "你的模型ID", "max_tokens": 2048, "temperature": 0.7 }如果你用的是 Cline 或 Claude Code 这类工具，配置路径和字段名要对齐。Cline 的 MCP 配置里，Base URL 填https://taotoken.net/api，Key 填统一 Key，Model ID 填你实际调用的模型标识。Codex 的 auth.json 里同样要保证这三项一致，否则会出现认证失败或模型找不到的报错。
4. 压测验证：从请求连通到吞吐数据落地
配置写完，必须做连通性验证和压测，否则你不知道优化到底有没有生效。第一步是单请求连通性测试，确认 endpoint、Key、Model ID 三件套正确。用 curl 发一个最小请求：
curl -X POST https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer sk-你的统一Key" \ -H "Content-Type: application/json" \ -d '{ "model": "你的模型ID", "messages": [{"role": "user", "content": "你好"}], "max_tokens": 32 }'返回里能看到choices字段和 token 用量，说明通道打通。如果返回 401，检查 Key 是否带对了前缀；如果返回模型不存在，检查 Model ID 拼写。
连通后进入压测。压测要同时采集吞吐量（tokens/s）、TTFT、GPU 显存峰值、GPU 利用率。我一般用并发梯度压测：从并发 1 开始，逐步加到 8、16、32、64，每个梯度跑 60 秒，记录稳定后的数据。下面是一个简单的压测脚本框架：
import asyncio import aiohttp import time async def single_request(session, payload): start = time.time() async with session.post( "https://taotoken.net/api/v1/chat/completions", json=payload, headers={"Authorization": "Bearer sk-你的统一Key"}, ) as resp: data = await resp.json() ttft = time.time() - start tokens = data.get("usage", {}).get("completion_tokens", 0) return ttft, tokens async def benchmark(concurrency: int, duration: int = 60): payload = { "model": "你的模型ID", "messages": [{"role": "user", "content": "写一段关于推理优化的说明"}], "max_tokens": 256, } async with aiohttp.ClientSession() as session: end_time = time.time() + duration total_tokens = 0 ttfts = [] while time.time() < end_time: tasks = [single_request(session, payload) for _ in range(concurrency)] results = await asyncio.gather(*tasks) for ttft, tokens in results: ttfts.append(ttft) total_tokens += tokens avg_ttft = sum(ttfts) / len(ttfts) print(f"并发 {concurrency}: 吞吐 {total_tokens/duration:.1f} tokens/s, 平均 TTFT {avg_ttft*1000:.0f} ms") asyncio.run(benchmark(16))跑完梯度压测，你会得到一张吞吐随并发变化的曲线。理想情况下，吞吐随并发上升，直到 GPU 打满后趋于平缓；TTFT 随并发上升而增加，超过 SLA 的那个点就是你的最大安全并发。如果吞吐很早就平了，说明显存或计算已经打满，需要回到上一节做量化或并行优化。
验证成功的结果长这样：并发从 8 提到 32，吞吐从 400 tokens/s 提升到 1200 tokens/s，TTFT 从 180ms 涨到 420ms，GPU 利用率从 35% 提到 85%，显存峰值稳定在 90% 以内没有 OOM。如果显存峰值贴着 100%，说明批大小还能再压一点，或者该上 INT4 了。
5. 常见报错排查：401、local proxy failed 与 reading choices
调优过程中踩的坑，大多集中在接入和配置环节。我把高频报错和排查路径整理出来，对照着查能省不少时间。
401 Unauthorized 是最常见的。原因通常是 Key 没带对、Key 过期、或者 Base URL 写错导致请求打到了错误的服务。排查顺序：先确认Authorization头格式是Bearer sk-xxx，再确认 Base URL 是https://taotoken.net/api而不是别的路径，最后确认 Model ID 在目标通道里存在。三件套任何一项不一致都会 401 或 404。
local proxy failed 这类报错，通常出现在本地工具（比如 Cline、Claude Code）配置了错误的网络路径，或者本地端口被占用。排查时先确认工具里的 Base URL 填的是统一 API 地址，不要填 localhost 或自定义端口；再检查本地是否有其他进程占用了工具默认端口。如果工具支持自定义 endpoint，确保路径拼接正确，比如/v1/chat/completions不要重复。
reading choices 报错，一般是返回体结构不符合预期。可能原因：请求的模型返回格式和客户端解析逻辑不匹配，或者 max_tokens 设置过小导致返回被截断。排查时先用 curl 看原始返回，确认choices字段存在且结构完整；再检查客户端是否按 OpenAI 兼容格式解析。如果用的是非标准模型，可能需要调整解析逻辑。
OAuth 相关报错，多出现在 Claude Code 这类需要认证的工具上。如果工具走 OAuth 流程但配置了 API Key 模式，会冲突。排查时确认工具的认证模式：走 Key 模式就填统一 Key，走 OAuth 就按工具文档配置，不要混用。CC Switch 切换配置时，也要确保 Base URL、Key、Model ID 三项同步更新，否则切换后仍然报旧配置的错。
还有一个隐蔽的坑：并发压测时出现间歇性超时，但单请求正常。这通常是服务端限流或连接池耗尽。排查时降低并发梯度，观察是否在某个并发值后开始超时；如果是，检查客户端连接池大小和服务端限流配置。压测脚本里给 aiohttp 设置合理的连接池上限，避免客户端自己把自己拖死。
6. 统一接入与长期编码：把调优流程固化下来
推理性能调优不是一次性动作，而是持续迭代的工程流程。每次模型更新、量化方案调整、并发策略变化，都要重新跑一遍压测验证。把 endpoint 统一到一套 API 通道后，切换模型和对比不同配置的成本大幅降低，你可以在同一套压测脚本下快速验证不同量化方案和并行策略的效果。
对于需要长期做编码和 Agent 任务的团队，建议把统一接入配置固化到项目里，用环境变量管理 Base URL 和 Key，避免硬编码。模型对话类的快速验证，可以直接在模型对话页面测试连通性和输出质量；接入和排障相关的细节，参考接入文档能少走弯路；如果是要长期跑编码任务或 Agent 工作流，Coding Plan 更适合做稳定的通道管理。
把显存压测、吞吐梯度测试、报错排查这几步串成脚本，每次上线前跑一遍，你就能在单位显存吞吐这个指标上持续拿到可复现的提升，而不是靠拍脑袋调参。
