# BenchFlow：面向OpenShift的可复现LLM推理基准测试框架

> 本文介绍BenchFlow项目，一个专为OpenShift环境设计的LLM推理基准测试控制平面。文章深入解析其架构设计、单集群与多集群部署模式、Tekton流水线集成以及与GuideLLM的协作机制，为需要在Kubernetes环境中进行模型性能评估的团队提供参考。

- 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm)
- 发布时间: 2026-03-31T10:40:28.000Z
- 最近活动: 2026-03-31T10:51:28.177Z
- 热度: 141.8
- 关键词: LLM基准测试, OpenShift, Kubernetes, Tekton, Kueue, GuideLLM, MLOps, GPU调度
- 页面链接: https://www.zingnex.cn/forum/thread/benchflow-openshiftllm
- Canonical: https://www.zingnex.cn/forum/thread/benchflow-openshiftllm
- Markdown 来源: ingested_event

---

# BenchFlow：面向OpenShift的可复现LLM推理基准测试框架\n\n## 背景：LLM基准测试的挑战\n\n随着大语言模型在生产环境中的部署越来越普遍，如何准确、可复现地评估模型推理性能成为关键问题。传统的基准测试往往依赖于手动执行的脚本，难以保证环境一致性，也无法有效管理多实验的并发执行。\n\n特别是在企业级Kubernetes平台（如OpenShift）上运行LLM推理时，团队面临额外的复杂性：\n\n- **环境一致性**：如何确保每次测试都在相同的软硬件环境中执行？\n- **资源调度**：多个基准测试竞争GPU资源时如何协调？\n- **结果追踪**：如何系统性地记录、比较和可视化不同配置下的性能数据？\n- **多集群场景**：当推理负载分布在多个集群时，如何统一管理测试？\n\nBenchFlow正是为解决这些问题而设计的控制平面框架。\n\n## 项目概述：不只是脚本集合\n\nBenchFlow的自我定位非常明确——它是一个"打包的控制平面"（packaged control plane），而不是零散的脚本集合。这意味着它提供了完整的生命周期管理：从实验定义到执行计划生成，从资源调度到结果收集，再到MLflow集成。\n\n项目由Alberto Perdomo开发，基于Apache 2.0许可证开源。其核心依赖包括：\n\n- **Tekton**：Kubernetes原生的CI/CD流水线引擎，负责实际执行基准测试\n- **Kueue**：Kubernetes作业队列管理器，处理GPU资源的准入控制\n- **GuideLLM**：vLLM项目的基准测试工具，提供负载生成和指标收集\n- **MLflow**：实验追踪和模型注册平台，用于存储基准测试结果\n\n这种架构选择体现了云原生设计的最佳实践——每个组件专注于自己的核心职责，通过标准接口协作。\n\n## 核心概念：RunPlan与执行流程\n\nBenchFlow的核心抽象是**RunPlan**（运行计划）。当用户提交一个实验配置时，BenchFlow会将其解析为一个不可变的运行计划，这个计划描述了：\n\n- 要测试的模型和配置\n- 负载模式（并发请求数、请求速率等）\n- 目标集群和环境参数\n- 指标收集和存储方式\n\nRunPlan的不可变性是一个重要设计——一旦创建，计划就不会被修改，这保证了实验的可追溯性和可复现性。如果需要变更，用户必须创建新的RunPlan。\n\n执行阶段，BenchFlow将RunPlan转化为Tekton的PipelineRun资源。Tekton负责在Kubernetes上编排实际的执行步骤，包括环境准备、模型部署、负载测试和结果收集。这种声明式的执行方式充分利用了Kubernetes的调度和容错能力。\n\n## 单集群部署模式\n\n对于简单的使用场景，BenchFlow支持单集群部署。在这种模式下：\n\n```bash\nbflow bootstrap --single-cluster\nbflow experiment run experiments/smoke/qwen3-06b-llm-d-smoke.yaml\n```\n\n`bootstrap`命令会安装所有必需的组件：\n- Tekton Pipelines和Triggers\n- Kueue及其队列配置\n- BenchFlow远程容量控制器\n- Grafana（用于监控可视化）\n- RBAC配置和GPU先决条件\n- 所需的持久卷声明（PVC）\n\nKueue在单集群模式中扮演关键角色——它根据发现的GPU容量来准入（admit）运行请求。如果当前没有足够的GPU资源，新的RunPlan会在队列中等待，直到资源可用。\n\n## 多集群部署：管理集群+目标集群\n\n更复杂的场景涉及多个目标集群。BenchFlow支持管理集群（management cluster）与目标集群（target cluster）分离的架构：\n\n**管理集群**运行控制平面组件：\n```bash\nbflow bootstrap\n```\n\n**目标集群**只需要基础的Kubernetes和GPU支持：\n```bash\nbflow bootstrap --target-kubeconfig ~/.kube/target-cluster --cluster-name target-cluster\n```\n\n执行测试时，从管理集群发起：\n```bash\nbflow experiment run experiments/smoke/qwen3-06b-llm-d-smoke.yaml --cluster-name target-cluster\n```\n\n在这种模式下，Kueue不仅管理本地资源，还通过BenchFlow远程容量控制器跟踪多个目标集群的GPU可用性。只有当目标集群有足够资源时，RunPlan才会被准入。\n\n目标集群本身不需要安装Tekton——BenchFlow使用存储在Secret中的kubeconfig，通过标准的Kubernetes Job在目标集群上启动运行时工作负载。这种设计减少了目标集群的运维负担，特别适合边缘或受管环境。\n\n## 矩阵实验：参数空间的系统探索\n\nBenchFlow的一个强大功能是支持**矩阵实验**（matrix experiments）。用户可以将实验配置中的一个或多个字段定义为列表，BenchFlow会自动生成这些参数的所有组合（笛卡尔积），并为每个组合创建子执行。\n\n例如，可以同时测试不同模型大小、不同批处理大小、不同并发度的所有组合：\n\n```yaml\nmodel:\n  - qwen3-0.6b\n  - qwen3-1.7b\n  - qwen3-4b\nbatch_size: [1, 4, 8, 16]\nconcurrency: [10, 50, 100]\n```\n\n这将生成3×4×3=36个子执行。BenchFlow通过Kueue管理这些子执行的并行度——对于`rhoai`运行时，子执行可以在目标集群GPU容量允许的情况下并行运行；而对于`llm-d`运行时，由于上游GAIE部署会创建可能冲突的命名空间资源，子执行目前需要串行执行。\n\n矩阵实验的取消操作是"尽力而为"的——一旦子执行被提交到队列，父执行的取消不会自动终止已经排队或运行的子执行，这些可能需要单独取消。\n\n## 与GuideLLM的集成\n\nBenchFlow本身不直接生成负载或收集指标，而是委托给GuideLLM——vLLM项目的官方基准测试工具。这种分工让BenchFlow专注于编排和资源管理，而GuideLLM专注于性能测试的专业领域。\n\n在PipelineRun执行过程中，BenchFlow会自动设置`GUIDELLM_OUTPUT_DIR`环境变量，确保基准测试结果存储在正确的位置。需要注意的是，`GUIDELLM_OUTPUT_PATH`环境变量在BenchFlow中不受支持，因为BenchFlow需要管理输出路径以保证结果的一致性。\n\n## 实验追踪与可视化\n\n基准测试完成后，结果被推送到MLflow。这允许团队：\n\n- 比较不同模型、不同配置下的性能指标\n- 追踪实验历史，理解性能变化趋势\n- 与模型版本关联，建立性能基线\n- 通过Grafana仪表盘实时监测试验执行\n\n这种集成使得BenchFlow不仅是一个测试工具，更是一个完整的MLOps工作流组件。\n\n## 已知限制与未来方向\n\nBenchFlow目前处于实验阶段，文档中坦诚地列出了一些已知限制：\n\n**集群级锁的缺失**：BenchFlow尚未实现对共享平台设置的集群级锁。这意味着并发的、会修改集群状态的运行可能会产生竞争条件。建议让每个基准测试作业完整执行后再启动另一个，或者使用矩阵实验让BenchFlow通过Kueue管理并行度。\n\n**llm-d矩阵执行的串行性**：如前所述，`llm-d`子执行目前需要串行运行，这限制了大规模参数扫描的效率。\n\n**父执行取消的限制**：矩阵父执行提交子执行后，取消操作只能尽力而为，已经排队的子执行可能需要单独处理。\n\n这些限制反映了项目在功能完整性和工程复杂度之间的权衡，也为社区贡献提供了明确的方向。\n\n## 技术启示\n\nBenchFlow的设计体现了几个值得关注的云原生最佳实践：\n\n**声明式配置**：实验通过YAML文件定义，符合GitOps工作流，便于版本控制和代码审查。\n\n**分层架构**：控制平面（BenchFlow）与执行平面（Tekton）分离，每个层面都可以独立演进和扩展。\n\n**资源感知调度**：通过与Kueue集成，BenchFlow实现了GPU资源的智能调度，避免了资源争抢和浪费。\n\n**可观测性优先**：内置Grafana集成和MLflow追踪，确保基准测试过程透明可审计。\n\n## 结语\n\nBenchFlow为在OpenShift等Kubernetes平台上进行LLM推理基准测试提供了一个结构化的解决方案。它的价值不仅在于自动化测试流程，更在于建立了可复现、可追踪、可比较的基准测试实践。\n\n对于正在评估或部署LLM推理服务的企业团队，BenchFlow提供了一个值得参考的框架。随着项目的成熟，它有望成为LLM Ops工具链中的重要一环。