据 Red Hat 新兴技术团队十月六日博文，Red Hat AI Inference 3.5 的 CPU 部署指南完整公开。核心方案是：用 Podman 拉取红帽官方推理容器镜像，在纯 CPU 的 x86 服务器上启动 LLM 推理服务，然后通过标准 REST API 调用。

CPU 推理的定位很明确：开发测试、小规模部署、边缘场景。不要指望用 CPU 跑 70B 模型做高并发生产——那是 GPU 的活。但如果你是一个小团队，想在内网跑一个 7B 或 8B 模型做内部知识问答，CPU 方案能帮你省掉 GPU 采购和运维成本。

配套的 cpueval CLI 工具链可以自动化做性能基准：测吞吐量、测延迟、生成可复现的报告。红帽还开源了 vllm-cpu-perf-eval 框架，用 Ansible 和 GuideLLM 做标准化测试。在 MLPerf Inference v6.1 里，红帽跟 Intel 合作的 CPU-only 提交拿到了每核心 Llama-3.1-8B 最高吞吐量。

红帽推 CPU 推理方案的战略意图很清楚：企业已经买了大量 x86 服务器，现在 GPU 太贵、太缺，能在现有硬件上跑起来的 AI 应用就先跑起来。不需要一步到位上 GPU 集群，先在 CPU 上验证业务价值，等流量上来了再考虑硬件升级。

从实际性能数据看，CPU 跑 7B 量化模型做内部知识库问答，每路请求的延迟大约在几百毫秒到一秒之间。对于并发量不高的内部系统，这个延迟完全可以接受。关键是要做好请求排队和超时控制，别让一个慢请求把整个服务拖垮。

红帽还提供了完整的 Ansible Playbook 来自动化部署流程，适合在大规模服务器集群上批量部署。对于已经在用 Ansible 做配置管理的企业，集成起来非常顺手。

CPU 推理到底能干什么不能干什么？

CPU 推理的瓶颈是内存带宽而不是计算能力。模型参数要从内存搬到 CPU 缓存里做矩阵乘法，带宽决定了 token 生成速度。选服务器的时候，多通道内存和高频率比核心数更重要。

cpueval 基准测试怎么跑？

实际部署建议：先用 cpueval 在你的硬件上跑一遍基准，测出来单并发下的 token/s 和多并发下的吞吐衰减曲线。根据这些数据决定能接多少 QPS，不要拍脑袋定 SLA。

去论坛讨论

前往 silicon-agi.com 论坛 参与讨论