在本地大语言模型部署场景中，延迟直接影响交互体验与产品可用性。Lemonade Server 作为开源本地 LLM 服务框架，通过 GPU 与 NPU 异构计算架构为消费级硬件提供了可行的推理加速路径。本文聚焦于不同硬件配置下的延迟基准测试数据，给出可落地的工程调优参数与部署选型建议。
异构计算架构的核心设计
Lemonade Server 的核心竞争力在于其混合执行路径设计。在 AMD Ryzen AI 300 系列平台上，系统将提示词处理（prefill 阶段）卸载至 NPU（神经网络处理单元），而将 token 生成（decode 阶段）交由集成显卡（iGPU）执行。这种分工源于两个阶段的计算特性差异：prefill 阶段需要大规模并行矩阵运算处理输入序列，NPU 的专用 AI 加速器在此场景下效率更高；decode 阶段则是自回归的逐 token 生成，GPU 的通用计算能力更能发挥吞吐量优势。
当硬件不具备 NPU 时，Lemonade Server 会自动回退至 CPU+GPU 组合模式。实测表明，这种回退机制在缺乏 Ryzen AI 硬件的平台上依然能够提供可用的推理性能，但延迟会显著上升。根据社区测试反馈，使用纯 CPU 路径时，7B 参数模型的提示词处理延迟可能达到 NPU 路径的 3 至 5 倍。
延迟基准测试的核心指标
评估 LLM 服务延迟需要关注三个关键指标。第一个是首 token 时间（Time to First Token，TTFT），即从发起请求到模型输出第一个 token 的耗时，这一指标直接影响用户感知的响应速度。第二个是 token 生成速率（Tokens Per Second，TPS），衡量稳定状态下的吞吐量。第三个是端到端响应延迟，涵盖从请求发起到完整响应返回的全过程。
在 Lemonade Server 的官方演示与社区测试中，针对 2048 个输入 token 的提示词处理场景，使用 Ryzen AI 300 系列处理器的 TTFT 大约在 1.5 秒至 2.5 秒之间，具体数值取决于模型大小与系统散热条件。稳定状态下的 TPS 则呈现更明显的硬件依赖性：集成 Radeon 显卡的 Ryzen AI 平台在 7B 参数模型上通常可达到 17 至 21 token/s 的生成速率，而当上下文长度缩短至 256 个 token 以下时，TPS 可提升至 30 以上。
需要特别指出的是，token/s 这一指标存在一定的误导性。输入端的提示词处理速度与输出端的 token 生成速度通常不在同一数量级，混淆两者会导致对实际响应时间的误判。端到端延迟中，生成阶段往往占据更大权重，尤其是当输出长度超过 100 个 token 时。
不同硬件配置的量化对比
基于公开测试数据与社区反馈，我们可以将 Lemonade Server 的硬件配置划分为三个性能层级。
高端配置采用 Ryzen AI 300 系列处理器（如 Ryzen AI 9 HX 370）配合统一内存架构，可加载 120B 参数的量化模型。在 32GB 统一内存条件下，系统通常能够运行 7B 至 14B 参数的全精度模型，或通过量化（Q4_K、Q5_K 等）方式运行更大参数规模的模型。此配置下的实测数据为：2048 token 提示词的 TTFT 约为 1.8 秒，稳定生成阶段的 TPS 约为 20 至 25 token/s。
主流配置基于较早一代的 Ryzen AI 处理器或搭载独立显卡的桌面系统。例如 Ryzen 7 8845HS 配合 Radeon 780M 显卡，在 16GB 系统内存下可流畅运行 7B 参数模型。此配置的典型表现为：TTFT 约 2.5 秒至 3 秒，TPS 约为 12 至 18 token/s。独立显卡（如 Radeon RX 7600 XT）可以进一步将 TPS 提升至 35 以上，但需要确保 PCIe 带宽与电源供应。
入门配置则依赖纯 CPU 推理。Lemonade Server 后端基于 llama.cpp 实现，支持 AVX2、AVX-512 等 SIMD 指令集加速。在 8 核 16 线程的现代处理器上，7B 参数模型的 TTFT 通常在 8 秒以上，TPS 约为 4 至 8 token/s。这一配置适合模型调试或对延迟不敏感的后台任务，但不建议用于交互式应用。
工程调优的关键参数
在部署层面，有若干参数可直接调整以优化延迟表现。第一个关键参数是批处理大小（batch size），默认为 1 以最小化延迟，但当需要并发处理多个请求时，可将 batch_size 提升至 4 或 8 以提高吞吐量。需注意批处理会线性增加 TTFT，因为系统需要等待一个批次的所有输入处理完毕才会开始输出。
第二个参数是上下文量化级别。Lemonade Server 支持多种量化方法，Q4_K 量化可在几乎不损失模型质量的前提下将内存占用减半，从而允许加载更大的模型或减少内存带宽瓶颈。对于延迟敏感场景，建议优先采用 Q4_K 或 Q5_K 量化级别。
第三个参数是 KV 缓存量化。通过 --kv_cache_type 参数启用 KV 量化，可以显著降低推理过程中的内存带宽需求。实测表明，启用 KV 量化后 TPS 可提升 15% 至 25%，代价是轻微的输出质量下降。
第四个参数是预加载策略。使用 --no-mmap 参数可以禁用内存映射，强制模型权重预加载至物理内存，从而减少首次推理时的加载延迟。在长时间运行的服务中，这一设置能够提供更稳定的响应时间。
监控与瓶颈诊断
实际部署中，延迟波动往往源于系统资源竞争而非算法瓶颈。Lemonade Server 提供了内置的性能监控端点，可通过访问 /api/v1/metrics 获取实时的 NPU 利用率、GPU 显存占用与队列深度信息。当观察到 NPU 利用率持续低于 50% 时，通常意味着提示词处理阶段存在数据搬运开销或 CPU 端的前处理成为了瓶颈。
对于连续运行的服务，建议设置延迟告警阈值：TTFT 超过 5 秒或 TPS 低于 10 token/s 时触发告警。在排除硬件资源不足的情况下，可以尝试更新至最新版本的 Lemonade Server，因为每个版本都会对主流 Ryzen AI 平台的驱动适配进行优化。
部署选型建议
选择硬件配置时应基于具体的延迟要求与成本预算。若应用场景要求 TTFT 低于 2 秒且 TPS 超过 20 token/s，Ryzen AI 300 系列笔记本或配备高性能集成显卡的桌面处理器是性价比最优的选择。若需要运行超过 14B 参数的大模型，则应考虑配备独立显卡的桌面系统，并通过 PCIe 通道接入更高带宽的 GPU。
对于隐私合规要求极高且延迟容忍度较高的企业内部部署场景，纯 CPU 方案仍然可作为可行性验证的起点，其优势在于硬件成本低、部署复杂度小，且随着 CPU SIMD 指令集的持续优化，实测性能正在逐步提升。
小结
Lemonade Server 通过 NPU+iGPU 异构分工架构，为本地 LLM 部署提供了明确的性能提升路径。在 Ryzen AI 平台上，实测 TTFT 约为 1.5 至 2.5 秒，稳定生成阶段的 TPS 可达 17 至 25 token/s，显著优于纯 CPU 方案。通过合理配置批处理大小、量化级别与 KV 缓存参数，可在延迟与吞吐量之间取得平衡。部署时应结合硬件能力与业务需求选择对应层级配置，并利用内置监控诊断潜在瓶颈。
参考资料
- Lemonade Server 官方文档与性能特性说明（lemonade-server.ai）
- AMD 技术文章：Unlocking a Wave of LLM Apps on Ryzen AI Through Lemonade Server（amd.com）
- Hardware Corner：AMD Targets Faster Local LLMs - Ryzen AI 300 Hybrid NPU+iGPU Approach