eval-dev-quality 在 Kubernetes 上运行指南代码生成评测的容器化部署与并行执行【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder本指南完整讲解如何将eval-dev-qualityDevQualityEval 代码生成评测框架迁移到 Kubernetes 集群中运行从集群前置检查、RWX 存储卷与 Secret 的准备到通过--runtime kubernetes一键提交批量评测任务再到评测结果如何从集群卷回传到宿主机。读完本文你将掌握该评测框架在 Kubernetes 上的完整部署与排错能力并能结合源码理解其 Job 调度、并行控制与结果回传的底层实现。eval-dev-quality是评测 LLM 代码生成质量的开源框架本仓库中位于 qwencoder-eval/instruct/eval-dev-quality属于 Instruct 评测工具链的一部分其官方文档明确提供了三种运行时本地local、Dockerdocker与 Kuberneteskubernetes。当评测规模较大、需要同时验证多个模型、多个代码仓库时Kubernetes 运行时能把每个模型-仓库评测封装为集群内的 Job按需并发、统一管理资源是规模化评测的首选方式。一、前置检查清单Prerequisite Checklist在向集群提交任何评测任务之前请逐项确认以下三个前提缺一不可kubectl已安装并配置好集群认证eval-dev-quality的 Kubernetes 运行时本身不直接调用集群 API而是通过本机的kubectl命令行工具完成 Job 的创建、等待、删除与结果回传见下文源码分析因此宿主机的kubectl必须能通过kubectl get nodes之类的命令正常访问目标集群。专用命名空间Namespace评测 Job 与存储访问 Deployment 都会以命名空间为单位创建资源。源码中该参数有默认值eval-dev-quality见 evaluate.go 的--namespace定义建议为评测单独创建命名空间避免与其他工作负载互相干扰。RWXReadWriteMany存储卷集群中必须存在一个支持多节点同时读写的共享卷用于保存所有评测 Job 的输出结果。因为多个 Job 会同时运行在不同的节点上且最后还要由一个独立的存储访问 Pod 汇总拷贝全部结果普通 ReadWriteOnce 卷无法满足要求。官方在 volume.yml 中给出了一个参考实现详见下一节。二、准备 RWX 存储卷volume.yml 参考实现volume.yml 提供了一个基于 PersistentVolumeClaim 的存储卷示例内容如下apiVersion: v1 kind: PersistentVolumeClaim metadata: name: eval-dev-quality namespace: eval-dev-quality spec: storageClassName: ceph-cephfs-sc accessModes: - ReadWriteMany # Ensure that the access mode is ReadWriteMany. resources: requests: storage: 50Gi要点解读accessModes: ReadWriteMany这是整个配置的核心注释也特别强调“确保访问模式是 ReadWriteMany”。只有该模式才允许集群中多个节点上的多个 Pod 同时挂载同一卷支撑并行 Job 各自写入结果。storageClassName: ceph-cephfs-sc示例使用的是 CephFS 提供的存储类。你可以根据自己集群的实际情况替换为任何支持 RWX 的存储类如 NFS、Longhorn、GlusterFS 等。name: eval-dev-qualityPVC 的名称必须与 job.yml 和 storage-access.yml 中claimName: eval-dev-quality保持一致否则评测 Job 将无法挂载卷。storage: 50Gi按评测规模调整容量。每个模型在每个仓库上的评测结果都会写入该卷模型数量多、--runs次数大时建议调大容量。准备好存储类之后可通过如下命令创建 PVC请将命名空间替换为你实际使用的命名空间kubectl --namespace eval-dev-quality apply -f volume.yml三、定义评测密钥evaluation-secret评测 Job 在集群内需要访问模型推理服务如 OpenRouter、Ollama、自定义 OpenAI 兼容端点等而 API 令牌必须通过 Kubernetes Secret 注入容器避免明文出现在镜像或命令行参数中。3.1 Secret 的命名与引用方式Job 模板会自动引用名为evaluation-secret的 Secret并将其中的键值对以环境变量的形式注入评测容器。这一点可以直接在 job.yml 中看到envFrom: - secretRef: name: evaluation-secret3.2 必填键PROVIDER_TOKENevaluation-secret中至少需要创建一个键PROVIDER_TOKEN其值包含各个 provider 的 API 令牌。格式为逗号分隔的provider:token键值对例如openrouter:abcdefgh1234,custom-provider:abcdefgh1234这与eval-dev-quality命令行的PROVIDER_TOKEN环境变量格式完全一致——在容器化运行时中本地环境变量不会自动透传进容器必须经由 Secret 注入。3.3 创建命令官方给出的创建命令如下注意末尾的PROVIDER_TOKEN为空值实际使用时请填入真实令牌kubectl --namespace eval-dev-quality create secret generic evaluation-secret --from-literalPROVIDER_TOKEN按需补全令牌后执行kubectl --namespace eval-dev-quality create secret generic evaluation-secret \ --from-literalPROVIDER_TOKENopenrouter:abcdefgh1234,custom-provider:abcdefgh1234注意事项请确保该 Secret 与评测 Job 位于同一个命名空间若命名空间不同secretRef将无法解析到该 SecretJob 容器启动时会因缺少PROVIDER_TOKEN而无法通过 provider 校验。四、提交评测--runtime kubernetes的使用方法前置资源命名空间、RWX 卷、Secret就绪后即可在宿主机上执行评测命令。Kubernetes 运行时要求显式指定三个参数参数作用--model定义需要放入容器化工作负载中运行的模型可重复指定多个--runtime kubernetes指示评测任务应在 Kubernetes 集群内运行--parallel控制同时运行的评测 Job 数量即同时运行的容器数官方示例命令eval-dev-quality evaluate --runtime kubernetes --runs 5 --model symflower/symbolic-execution --model symflower/symbolic-execution --model symflower/symbolic-execution --repository golang/plain --parallel 2这条命令的含义是在 Kubernetes 集群的容器化工作负载中对symflower/symbolic-execution模型执行3 次评测模型被指定了 3 遍每个评测执行5 轮--runs 5评测仓库限定为golang/plain并将并行执行的容器数限制为 2。也就是说集群中最多同时有 2 个评测 Job 在运行其余排队等待。4.1 容器内实际执行的命令结合源码分析上述命令被宿主机上的eval-dev-quality进程拆解后会为每个模型在集群内提交一个 Job容器内部实际执行的核心命令形如见 evaluate.goeval-dev-quality evaluate --model symflower/symbolic-execution --result-path /var/evaluations/symflower-symbolic-execution ...其他透传参数其中--result-path被强制重写为共享卷挂载点下的路径/var/evaluations/模型名保证结果统一落在 RWX 卷中--model、--parallel、--result-path、--runtime-image、--runtime这五个参数会被过滤掉见 evaluate.go 的ignoredFlags其余参数如--runs、--repository、--execution-timeout等原样透传给容器内的评测进程。4.2 常用参数速查以下参数与 Kubernetes 运行时强相关定义均出自 evaluate.go参数默认值说明--runtimelocal运行方式可选local/docker/kubernetesL84--runtime-imageghcr.io/symflower/eval-dev-quality:main评测容器镜像不指定时使用 main 分支镜像L195-L197--parallel1并行执行的容器化评测数量L88--namespaceeval-dev-qualityKubernetes 资源所属命名空间L90--runs1每个模型-仓库组合的评测轮数L77--execution-timeout5分钟编译与测试的执行超时L75--attempts3模型请求出错时的重试次数L63限制说明--parallel只对容器化运行时docker/kubernetes生效在本地运行时使用会直接报错L187-L189--namespace在使用 kubernetes 运行时不能为空L199-L201--configuration配置文件方式在容器化运行时中不受支持会触发 panicL121-L124。五、源码级原理Kubernetes 运行时的完整工作流要真正用好这个运行时理解其底层流程十分必要。整个逻辑实现在 evaluate.go 的evaluateKubernetes函数中可概括为三个阶段。5.1 阶段一为每个模型生成并提交 Job渲染 Job 模板程序加载 conf/kube/job.yml 作为 Go 模板L718其中{{.name}}、{{.namespace}}、{{.image}}、{{.command}}四个占位符分别由 Job 名、命名空间、镜像地址和容器命令填充。生成唯一 Job 名Job 名由模型 ID 经正则[^a-zA-Z0-9-]清洗后拼接索引号生成L716、L766例如symflower-symbolic-execution-0。同一模型被多次指定时通过索引号区分结果路径L752-L756。通过 STDIN 提交渲染完成的 YAML 通过管道交给kubectl apply -f -L743-L748、L778-L781因此宿主机上必须安装并配置kubectl。Job 模板的关键配置job.ymlapiVersion: batch/v1 kind: Job metadata: name: {{.name}} namespace: {{.namespace}} spec: template: spec: containers: - name: eval-dev-quality image: {{.image}} command: {{.command}} volumeMounts: - mountPath: /var/evaluations name: evaluations envFrom: - secretRef: name: evaluation-secret securityContext: fsGroup: 1000 restartPolicy: Never volumes: - name: evaluations persistentVolumeClaim: claimName: eval-dev-quality backoffLimit: 1envFrom.secretRef注入evaluation-secret中的所有键值对为环境变量即第三节的PROVIDER_TOKEN。volumeMounts/volumes将 PVCeval-dev-quality挂载到容器/var/evaluations评测结果写入该目录即落入共享卷。restartPolicy: NeverbackoffLimit: 1评测任务失败不自动重启容器Job 整体最多重试 1 次避免评测被重复执行造成结果污染或 API 费用浪费。securityContext.fsGroup: 1000统一卷内文件的组所有权确保多个 Job 与后续存储访问 Pod 对共享卷内的结果文件都有读写权限。5.2 阶段二等待 Job 完成并清理每个 Job 提交后程序随即调用kubectl wait阻塞等待其完成L789-L799kubectl wait --timeout 24h --forconditioncomplete --namespace 命名空间 jobs/jobName等待超时上限为24 小时等待条件为 Job 的complete条件该等待发生在util.NewParallel(command.Parallel)控制的并行执行器中因此--parallel的值决定了同时有多少个“提交-Job→等待完成→删除 Job”的循环在运行Job 完成后立即执行kubectl delete job从集群中清理L807-L816。5.3 阶段三结果回传与卷清理所有模型评测完成后程序执行结果回传流程L826-L901拉起存储访问 Deployment渲染并提交 conf/kube/storage-access.yml一个常驻的busyboxDeployment挂载同一个 PVCwhile true; do sleep 30; done保持存活用于后续的kubectl cp文件拷贝apiVersion: apps/v1 kind: Deployment metadata: name: {{.name}} namespace: {{.namespace}} spec: selector: matchLabels: app: eval-storage-access template: metadata: labels: app: eval-storage-access spec: containers: - name: storage-access image: busybox command: [ /bin/sh, -c, -- ] args: [ while true; do sleep 30; done; ] volumeMounts: - mountPath: /var/evaluations name: evaluations securityContext: fsGroup: 1000 volumes: - name: evaluations persistentVolumeClaim: claimName: eval-dev-quality定位 Pod通过kubectl get pods -l appeval-storage-access -o custom-columns:metadata.name查询存储访问 Pod 的名称L856-L866。拷贝结果执行kubectl cp 命名空间/podName:/var/evaluations/. 本地结果目录把共享卷内的全部评测结果拉回宿主机L873-L880。宿主机上的结果目录由--result-path决定默认evaluation-%datetime%%datetime%会被替换为时间戳并自动去重见 L208-L218。清理卷内数据最后通过kubectl exec在存储访问 Pod 内执行rm -rf /var/evaluations/*清空共享卷L886-L900为下一轮评测腾出空间。注意这一步会删除卷内所有数据不要在卷中存放其他重要内容。六、评测容器镜像运行时镜像里有什么Kubernetes 运行时默认使用镜像ghcr.io/symflower/eval-dev-quality:main--runtime-image为空时的默认值见 evaluate.go也可通过--runtime-image指定自定义构建的镜像。参考仓库中的 Dockerfile该镜像在 Ubuntu 基础上内置了评测所需的完整工具链Go 1.21.5、JavaAmazon Corretto 11、Maven 3.9.1、Gradle 8.0.2、Ruby 3.3.4等语言编译与构建环境eval-dev-quality二进制本体位于/app/.eval-dev-quality/bintestdata目录评测用代码仓库集与 Makefile以非 root 用户ubuntu运行工作目录为/app。因此容器内执行的评测进程无需额外安装工具直接可对 Go/Java/Ruby 等语言的测试生成、代码修复、代码转译任务进行编译、测试与覆盖率统计。七、常见问题与最佳实践并行度如何选择--parallel决定同时运行的评测容器数需结合集群节点资源与模型 API 的限流情况设定。模型数量多但--parallel过小会导致排队时间过长反之过大会压垮推理服务。建议从 24 起步逐步调优。结果目录丢失--result-path默认带时间戳且kubectl cp会一次性清空共享卷建议每次评测结束后及时归档宿主机上的结果目录其中包含README.md报告、evaluation.csv、各模型日志与 SVG 图表等。Secret 更新evaluation-secret内容变更后需重新执行kubectl create secret或kubectl delete secret后再创建新 Job 启动时才会读取到最新令牌。权限与安全官方在 eval-dev-quality README 中明确提醒项目默认不在沙箱中执行 LLM 生成的代码务必只在隔离环境中运行评测——Kubernetes 命名空间隔离与容器化运行时正是缓解该风险的手段之一。至此从集群前置检查、RWX 卷与 Secret 准备到--runtime kubernetes批量提交评测、再到结果回传与卷清理你已经掌握了在 Kubernetes 上规模化运行eval-dev-quality代码生成评测的完整闭环。【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 eval-dev-quality 在 Kubernetes 上运行指南：代码生成评测的容器化部署与并行执行
eval-dev-quality 在 Kubernetes 上运行指南代码生成评测的容器化部署与并行执行【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder本指南完整讲解如何将eval-dev-qualityDevQualityEval 代码生成评测框架迁移到 Kubernetes 集群中运行从集群前置检查、RWX 存储卷与 Secret 的准备到通过--runtime kubernetes一键提交批量评测任务再到评测结果如何从集群卷回传到宿主机。读完本文你将掌握该评测框架在 Kubernetes 上的完整部署与排错能力并能结合源码理解其 Job 调度、并行控制与结果回传的底层实现。eval-dev-quality是评测 LLM 代码生成质量的开源框架本仓库中位于 qwencoder-eval/instruct/eval-dev-quality属于 Instruct 评测工具链的一部分其官方文档明确提供了三种运行时本地local、Dockerdocker与 Kuberneteskubernetes。当评测规模较大、需要同时验证多个模型、多个代码仓库时Kubernetes 运行时能把每个模型-仓库评测封装为集群内的 Job按需并发、统一管理资源是规模化评测的首选方式。一、前置检查清单Prerequisite Checklist在向集群提交任何评测任务之前请逐项确认以下三个前提缺一不可kubectl已安装并配置好集群认证eval-dev-quality的 Kubernetes 运行时本身不直接调用集群 API而是通过本机的kubectl命令行工具完成 Job 的创建、等待、删除与结果回传见下文源码分析因此宿主机的kubectl必须能通过kubectl get nodes之类的命令正常访问目标集群。专用命名空间Namespace评测 Job 与存储访问 Deployment 都会以命名空间为单位创建资源。源码中该参数有默认值eval-dev-quality见 evaluate.go 的--namespace定义建议为评测单独创建命名空间避免与其他工作负载互相干扰。RWXReadWriteMany存储卷集群中必须存在一个支持多节点同时读写的共享卷用于保存所有评测 Job 的输出结果。因为多个 Job 会同时运行在不同的节点上且最后还要由一个独立的存储访问 Pod 汇总拷贝全部结果普通 ReadWriteOnce 卷无法满足要求。官方在 volume.yml 中给出了一个参考实现详见下一节。二、准备 RWX 存储卷volume.yml 参考实现volume.yml 提供了一个基于 PersistentVolumeClaim 的存储卷示例内容如下apiVersion: v1 kind: PersistentVolumeClaim metadata: name: eval-dev-quality namespace: eval-dev-quality spec: storageClassName: ceph-cephfs-sc accessModes: - ReadWriteMany # Ensure that the access mode is ReadWriteMany. resources: requests: storage: 50Gi要点解读accessModes: ReadWriteMany这是整个配置的核心注释也特别强调“确保访问模式是 ReadWriteMany”。只有该模式才允许集群中多个节点上的多个 Pod 同时挂载同一卷支撑并行 Job 各自写入结果。storageClassName: ceph-cephfs-sc示例使用的是 CephFS 提供的存储类。你可以根据自己集群的实际情况替换为任何支持 RWX 的存储类如 NFS、Longhorn、GlusterFS 等。name: eval-dev-qualityPVC 的名称必须与 job.yml 和 storage-access.yml 中claimName: eval-dev-quality保持一致否则评测 Job 将无法挂载卷。storage: 50Gi按评测规模调整容量。每个模型在每个仓库上的评测结果都会写入该卷模型数量多、--runs次数大时建议调大容量。准备好存储类之后可通过如下命令创建 PVC请将命名空间替换为你实际使用的命名空间kubectl --namespace eval-dev-quality apply -f volume.yml三、定义评测密钥evaluation-secret评测 Job 在集群内需要访问模型推理服务如 OpenRouter、Ollama、自定义 OpenAI 兼容端点等而 API 令牌必须通过 Kubernetes Secret 注入容器避免明文出现在镜像或命令行参数中。3.1 Secret 的命名与引用方式Job 模板会自动引用名为evaluation-secret的 Secret并将其中的键值对以环境变量的形式注入评测容器。这一点可以直接在 job.yml 中看到envFrom: - secretRef: name: evaluation-secret3.2 必填键PROVIDER_TOKENevaluation-secret中至少需要创建一个键PROVIDER_TOKEN其值包含各个 provider 的 API 令牌。格式为逗号分隔的provider:token键值对例如openrouter:abcdefgh1234,custom-provider:abcdefgh1234这与eval-dev-quality命令行的PROVIDER_TOKEN环境变量格式完全一致——在容器化运行时中本地环境变量不会自动透传进容器必须经由 Secret 注入。3.3 创建命令官方给出的创建命令如下注意末尾的PROVIDER_TOKEN为空值实际使用时请填入真实令牌kubectl --namespace eval-dev-quality create secret generic evaluation-secret --from-literalPROVIDER_TOKEN按需补全令牌后执行kubectl --namespace eval-dev-quality create secret generic evaluation-secret \ --from-literalPROVIDER_TOKENopenrouter:abcdefgh1234,custom-provider:abcdefgh1234注意事项请确保该 Secret 与评测 Job 位于同一个命名空间若命名空间不同secretRef将无法解析到该 SecretJob 容器启动时会因缺少PROVIDER_TOKEN而无法通过 provider 校验。四、提交评测--runtime kubernetes的使用方法前置资源命名空间、RWX 卷、Secret就绪后即可在宿主机上执行评测命令。Kubernetes 运行时要求显式指定三个参数参数作用--model定义需要放入容器化工作负载中运行的模型可重复指定多个--runtime kubernetes指示评测任务应在 Kubernetes 集群内运行--parallel控制同时运行的评测 Job 数量即同时运行的容器数官方示例命令eval-dev-quality evaluate --runtime kubernetes --runs 5 --model symflower/symbolic-execution --model symflower/symbolic-execution --model symflower/symbolic-execution --repository golang/plain --parallel 2这条命令的含义是在 Kubernetes 集群的容器化工作负载中对symflower/symbolic-execution模型执行3 次评测模型被指定了 3 遍每个评测执行5 轮--runs 5评测仓库限定为golang/plain并将并行执行的容器数限制为 2。也就是说集群中最多同时有 2 个评测 Job 在运行其余排队等待。4.1 容器内实际执行的命令结合源码分析上述命令被宿主机上的eval-dev-quality进程拆解后会为每个模型在集群内提交一个 Job容器内部实际执行的核心命令形如见 evaluate.goeval-dev-quality evaluate --model symflower/symbolic-execution --result-path /var/evaluations/symflower-symbolic-execution ...其他透传参数其中--result-path被强制重写为共享卷挂载点下的路径/var/evaluations/模型名保证结果统一落在 RWX 卷中--model、--parallel、--result-path、--runtime-image、--runtime这五个参数会被过滤掉见 evaluate.go 的ignoredFlags其余参数如--runs、--repository、--execution-timeout等原样透传给容器内的评测进程。4.2 常用参数速查以下参数与 Kubernetes 运行时强相关定义均出自 evaluate.go参数默认值说明--runtimelocal运行方式可选local/docker/kubernetesL84--runtime-imageghcr.io/symflower/eval-dev-quality:main评测容器镜像不指定时使用 main 分支镜像L195-L197--parallel1并行执行的容器化评测数量L88--namespaceeval-dev-qualityKubernetes 资源所属命名空间L90--runs1每个模型-仓库组合的评测轮数L77--execution-timeout5分钟编译与测试的执行超时L75--attempts3模型请求出错时的重试次数L63限制说明--parallel只对容器化运行时docker/kubernetes生效在本地运行时使用会直接报错L187-L189--namespace在使用 kubernetes 运行时不能为空L199-L201--configuration配置文件方式在容器化运行时中不受支持会触发 panicL121-L124。五、源码级原理Kubernetes 运行时的完整工作流要真正用好这个运行时理解其底层流程十分必要。整个逻辑实现在 evaluate.go 的evaluateKubernetes函数中可概括为三个阶段。5.1 阶段一为每个模型生成并提交 Job渲染 Job 模板程序加载 conf/kube/job.yml 作为 Go 模板L718其中{{.name}}、{{.namespace}}、{{.image}}、{{.command}}四个占位符分别由 Job 名、命名空间、镜像地址和容器命令填充。生成唯一 Job 名Job 名由模型 ID 经正则[^a-zA-Z0-9-]清洗后拼接索引号生成L716、L766例如symflower-symbolic-execution-0。同一模型被多次指定时通过索引号区分结果路径L752-L756。通过 STDIN 提交渲染完成的 YAML 通过管道交给kubectl apply -f -L743-L748、L778-L781因此宿主机上必须安装并配置kubectl。Job 模板的关键配置job.ymlapiVersion: batch/v1 kind: Job metadata: name: {{.name}} namespace: {{.namespace}} spec: template: spec: containers: - name: eval-dev-quality image: {{.image}} command: {{.command}} volumeMounts: - mountPath: /var/evaluations name: evaluations envFrom: - secretRef: name: evaluation-secret securityContext: fsGroup: 1000 restartPolicy: Never volumes: - name: evaluations persistentVolumeClaim: claimName: eval-dev-quality backoffLimit: 1envFrom.secretRef注入evaluation-secret中的所有键值对为环境变量即第三节的PROVIDER_TOKEN。volumeMounts/volumes将 PVCeval-dev-quality挂载到容器/var/evaluations评测结果写入该目录即落入共享卷。restartPolicy: NeverbackoffLimit: 1评测任务失败不自动重启容器Job 整体最多重试 1 次避免评测被重复执行造成结果污染或 API 费用浪费。securityContext.fsGroup: 1000统一卷内文件的组所有权确保多个 Job 与后续存储访问 Pod 对共享卷内的结果文件都有读写权限。5.2 阶段二等待 Job 完成并清理每个 Job 提交后程序随即调用kubectl wait阻塞等待其完成L789-L799kubectl wait --timeout 24h --forconditioncomplete --namespace 命名空间 jobs/jobName等待超时上限为24 小时等待条件为 Job 的complete条件该等待发生在util.NewParallel(command.Parallel)控制的并行执行器中因此--parallel的值决定了同时有多少个“提交-Job→等待完成→删除 Job”的循环在运行Job 完成后立即执行kubectl delete job从集群中清理L807-L816。5.3 阶段三结果回传与卷清理所有模型评测完成后程序执行结果回传流程L826-L901拉起存储访问 Deployment渲染并提交 conf/kube/storage-access.yml一个常驻的busyboxDeployment挂载同一个 PVCwhile true; do sleep 30; done保持存活用于后续的kubectl cp文件拷贝apiVersion: apps/v1 kind: Deployment metadata: name: {{.name}} namespace: {{.namespace}} spec: selector: matchLabels: app: eval-storage-access template: metadata: labels: app: eval-storage-access spec: containers: - name: storage-access image: busybox command: [ /bin/sh, -c, -- ] args: [ while true; do sleep 30; done; ] volumeMounts: - mountPath: /var/evaluations name: evaluations securityContext: fsGroup: 1000 volumes: - name: evaluations persistentVolumeClaim: claimName: eval-dev-quality定位 Pod通过kubectl get pods -l appeval-storage-access -o custom-columns:metadata.name查询存储访问 Pod 的名称L856-L866。拷贝结果执行kubectl cp 命名空间/podName:/var/evaluations/. 本地结果目录把共享卷内的全部评测结果拉回宿主机L873-L880。宿主机上的结果目录由--result-path决定默认evaluation-%datetime%%datetime%会被替换为时间戳并自动去重见 L208-L218。清理卷内数据最后通过kubectl exec在存储访问 Pod 内执行rm -rf /var/evaluations/*清空共享卷L886-L900为下一轮评测腾出空间。注意这一步会删除卷内所有数据不要在卷中存放其他重要内容。六、评测容器镜像运行时镜像里有什么Kubernetes 运行时默认使用镜像ghcr.io/symflower/eval-dev-quality:main--runtime-image为空时的默认值见 evaluate.go也可通过--runtime-image指定自定义构建的镜像。参考仓库中的 Dockerfile该镜像在 Ubuntu 基础上内置了评测所需的完整工具链Go 1.21.5、JavaAmazon Corretto 11、Maven 3.9.1、Gradle 8.0.2、Ruby 3.3.4等语言编译与构建环境eval-dev-quality二进制本体位于/app/.eval-dev-quality/bintestdata目录评测用代码仓库集与 Makefile以非 root 用户ubuntu运行工作目录为/app。因此容器内执行的评测进程无需额外安装工具直接可对 Go/Java/Ruby 等语言的测试生成、代码修复、代码转译任务进行编译、测试与覆盖率统计。七、常见问题与最佳实践并行度如何选择--parallel决定同时运行的评测容器数需结合集群节点资源与模型 API 的限流情况设定。模型数量多但--parallel过小会导致排队时间过长反之过大会压垮推理服务。建议从 24 起步逐步调优。结果目录丢失--result-path默认带时间戳且kubectl cp会一次性清空共享卷建议每次评测结束后及时归档宿主机上的结果目录其中包含README.md报告、evaluation.csv、各模型日志与 SVG 图表等。Secret 更新evaluation-secret内容变更后需重新执行kubectl create secret或kubectl delete secret后再创建新 Job 启动时才会读取到最新令牌。权限与安全官方在 eval-dev-quality README 中明确提醒项目默认不在沙箱中执行 LLM 生成的代码务必只在隔离环境中运行评测——Kubernetes 命名空间隔离与容器化运行时正是缓解该风险的手段之一。至此从集群前置检查、RWX 卷与 Secret 准备到--runtime kubernetes批量提交评测、再到结果回传与卷清理你已经掌握了在 Kubernetes 上规模化运行eval-dev-quality代码生成评测的完整闭环。【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考