llama.cpp 与 vLLM 优化算力

很多人谈“优化算力”，第一反应是换更强的 GPU。但在本地部署 AI 智能体时，真正卡住体验的往往不是峰值算力，而是显存、内存与请求调度之间的不匹配。此时，llama.cpp 和 vLLM 代表了两种不同的优化思路：前者强调在有限硬件上把模型跑起来，后者更关注如何让 GPU 持续处理更多请求。

先看场景，再选引擎

如果设备存在 CPU 算力较强、GPU 显存不足，或者 CPU 与 GPU 能力不对称的情况，llama.cpp 通常更容易找到平衡点。它是底层 C/C++ 推理引擎，原生支持 GGUF 量化格式，适合本地部署和 CPU-GPU 混合运行。以 27B 级模型为例，采用 Q4_K_M 量化后，显存需求大约可控制在 15GB—18GB，至少比直接使用 FP16 更适合 16GB—24GB 显存的设备。

vLLM 的优势则不在“单个请求一定更快”，而在于服务多个请求时能减少 GPU 空转。它通过 Continuous Batching，在生成过程中及时填充新的请求；同时利用 PagedAttention 管理 KV Cache，降低缓存分配带来的浪费。对于企业服务或并发请求较多的场景，这种调度能力往往比单次推理速度更重要。

优化重点不只是量化

量化是第一步，但不是全部。INT4、FP8 等低精度方案能够降低参数占用，代价是需要根据模型和任务观察输出质量。过度追求低显存，可能换来更明显的回答退化，因此更稳妥的方式是先从 Q4_K_M 或 INT4 开始测试，再决定是否继续压缩。

第二个容易被忽略的地方是 KV Cache。上下文越长、并发越高，缓存越可能成为显存压力来源。共享前缀缓存可以复用系统提示词等重复内容，减少重复计算；当显存仍然紧张时，再考虑模型分片或多线程 CPU 分担，而不是一开始就盲目扩大模型规模。

所以，llama.cpp 与 vLLM 并不是简单的“谁更快”竞争。前者更像是有限预算下的灵活底座，后者更像是面向服务吞吐的调度系统。你更在意单机低门槛运行，还是多请求下的整体效率？这个答案，才决定优化应该从量化、缓存还是并发调度开始。