MAX 基准测试配置完全指南Pydantic 配置类、YAML 继承与 Sweep 参数化【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo本指南以max.benchmark.benchmark_shared.config中的基准测试配置体系为核心系统讲解 MAX 项目中 Serving 类基准测试的配置方式如何通过 Pydantic 配置类定义参数、如何用--config-file从 YAML 加载、depends_on继承机制如何工作、max_concurrency与request_rate如何展开为 Sweep 矩阵以及如何新增自定义 YAML 配置。读完本文你将能够独立编写、继承并运行一套可复现、可参数化扫描的 MAX Serving 基准测试配置并理解其底层实现原理。配置体系概览Pydantic 模型 YAML 文件 CLI 标志MAX 的基准测试配置是构建在 Pydantic 之上的数据模型。所有配置类继承自ConfigFileModel定义于 max/python/max/config/config_file_model.py因此具备两种使用方式直接在 Python 中构造实例化BaseBenchmarkConfig或ServingBenchmarkConfig并传入字段值从 YAML 文件加载通过--config-fileCLI 标志指定 YAML 路径运行时自动解析。配置值的最终生效顺序优先级从高到低在 max/python/max/config/README.md 中有明确说明CLI 参数命令行直接传入的值环境变量MODULAR_*前缀的环境变量例如MODULAR_BATCH_SIZE配置文件YAML通过--config-file指定的文件默认值配置类中定义的字段默认值。需要注意一个由 cyclopts 处理顺序决定的特殊行为环境变量在 Pydantic 校验之前生效因此配置文件无法覆盖环境变量但 CLI 参数可以覆盖一切。在基准测试的入口处benchmark_serving.py的parse_args通过 cycloptsApp解析参数并装配ServingBenchmarkConfig见 benchmark_serving.py。cyclopts 的config[Env(prefixMODULAR_)]让MODULAR_*环境变量成为配置源--config-file则负责 YAML 的加载与合并。配置类层次从通用参数到 Serving 专属参数配置类遵循清晰的继承层次相关源码位于 max/python/max/benchmark/benchmark_shared/config.py类职责关键参数BaseBenchmarkConfig所有基准测试共用的基础参数模型/分词器、数据集、工作量规模、控制标志BaseServingBenchmarkConfigServing 类基准测试共享的中间层流量突发度、LoRA 流量、GPU 统计、跳过测试提示词ServingBenchmarkConfigServing 基准测试benchmark_serving.py的完整配置后端/API、并发与 Sweep、流量控制、输出控制、结果保存BaseBenchmarkConfig通用参数BaseBenchmarkConfig覆盖所有基准类型共用的参数其section_name默认为benchmark_configexcludeTrue这使得加载 YAML 时会自动提取顶层benchmark_config:区块无需手动指定区块名。主要字段如下模型与分词器model必填运行基准时必须有、tokenizer默认分词器之外的自定义选择、tokenizer_local_files_only仅从本地 HF 缓存加载、tokenizer_revision固定加载的 commit revision适用于私有仓库或无法在 Hub 查询 revision 的场景、model_max_length覆盖分词器最大长度用于服务端最大长度低于分词器的场景、trust_remote_code数据集dataset_name默认sharegpt、dataset_path、dataset_modehuggingface或local工作量规模num_prompts处理的提示词数量随机种子seed默认值为DEFAULT_BENCHMARK_SEED 0x5EED十进制 24301拼写为 SEED。固定种子让重复运行与定时运行可复现运行间差异反映被测改动本身而非采样方差。可通过--seed none或 YAML 中seed: null改为每次抽取全新随机种子抽到的种子会被记录在结果中事后仍可复现控制标志disable_tqdm、print_inputs_and_outputs、verboseDEBUG 日志。seed字段有一个modebefore的校验器_parse_seed_cli_string负责把 CLI/YAML 传入的字符串none映射为None。ServingBenchmarkConfigServing 专属参数ServingBenchmarkConfig在基础参数之上扩展了大量 Serving 场景参数model_config ConfigDict(strictFalse, validate_assignmentTrue)——后者允许在运行时回填字段时重新触发校验。按功能分组核心字段包括后端与 APIbackend默认modular可选atom、mach、mcloud、modular、sglang、trtllm、vllm及其-chat变体、base_url远程端点、host默认localhost、port默认8000、endpoint默认/v1/chat/completions另支持/v1/completions、/v1/responses、/v1/images/generations、/v2/models/ensemble/generate_stream等、benchmark_tasktext-generation、text-to-image、image-to-image、text-to-video、image-to-video请求配置max_concurrency每个 Sweep 步骤的最大并发请求数none表示无界、lora、max_concurrent_conversationsKV-cache 压力测试、kv_block_size默认 128应与服务端--kv-cache-page-size对齐工作量配置max_benchmark_duration_s、num_chat_sessions、delay_between_chat_turns支持常数或分布串如N(mean,std)、U(lower,upper)、DU(lower,upper)、G(shape,scale)、LN(mean,std)、force_unique_runs为每次运行加 UUID 前缀以隔离 KV-cache输出控制output_lengths、max_output_len、temperature、thinking_temperaturethink块内温度MAX 专属扩展、top_p、top_k、response_format结构化输出可传 JSON 字符串或path/to/schema.json、extra_body图像/视频生成image_width、image_height、image_steps、image_guidance_scale、image_negative_prompt、image_seed、num_framestext-to-video 必需流量控制request_rate每秒请求数inf表示不限速、burstiness默认 1.0即泊松过程、skip_first_n_requests/skip_last_n_requests省略时自动设为max_concurrency、warmup_to_steady_state、warmup_oversample_factor默认 8、warmup_delay_biased及对应的warmup_delay_estimated_ttft_ms/warmup_delay_estimated_tpot_ms通过model_validator校验设置运行时间估算必须同时开启--warmup-delay-biased结果保存result_filename、record_output_lengths、record_request_text、always_save_result、metadata、latency_percentiles默认50,90,95,99、log_dirSweep 配置num_iters每个配置的迭代次数默认 1、flush_prefix_cache迭代间冲刷前缀缓存默认开启、num_prompts_multipliernum_prompts multiplier * max_concurrency替代默认 300 秒时长上限LoRA 配置lora_paths、lora_uniform_traffic_ratio、per_lora_traffic_ratio、max_concurrent_lora_ops。此外ServingBenchmarkConfig提供sampling属性将扁平的temperature/thinking_temperature/top_p/top_k组装为SamplingConfig对象OpenAI 风格采样参数集合。导入示例from max.benchmark.benchmark_shared.config import ( BaseBenchmarkConfig, ServingBenchmarkConfig, )Sweep 参数一个值或多个值的矩阵展开ServingBenchmarkConfig中有两个字段同时接受单个值或逗号分隔的多个值由sweep_benchmark_serving.py展开为运行矩阵max_concurrency每个条目按int | None解析request_rate每个条目按float解析。展开逻辑发生在 benchmark_serving.py 的main_with_parsed_args中concurrency_range parse_comma_separated(args.max_concurrency, int_or_none) request_rate_range parse_comma_separated(args.request_rate, float)parse_comma_separated与int_or_none定义于 max/python/max/benchmark/benchmark_shared/utils.pydef int_or_none(x: str) - int | None: Parse *x* as an int, returning None for the literal none. if x.lower() none: return None return int(x) def parse_comma_separated( value: str | None, convert: Callable[[str], _T], *, default: _T | None None, ) - list[_T]: if value is None: return [default] return [convert(x.strip()) for x in value.split(,)]特殊值的解析语义None大小写不敏感解析为 PythonNone对max_concurrency表示无界并发inf大小写不敏感可被float接受用于request_rate表示不限请求速率空条目文档声明逗号之间的空条目解析为None。但从当前实现看每个 token 经strip()后直接交给转换函数int_or_none()会抛出ValueError因此实践中应避免在列表中留下空条目例如1,,8会导致解析失败。模型层的类型转换字段在配置模型上的最终类型是Sequence[int | None]max_concurrency与Sequence[float]request_rate默认值分别为[None]与[float(inf)]。CLI 传入的字符串通过两个modebefore的校验器展开为序列_parse_max_concurrency_cli_strings与_parse_request_rate_cli_strings两者都处理单个值字符串单元素字符串列表cyclopts 的[sweep]形态三种输入。实际的 Sweep 执行循环矩阵展开后_run_benchmark_sweep见 benchmark_serving.py执行双层循环外层遍历args.max_concurrency每个并发级别基于种子派生独立采样mc_seed _seed_for_concurrency(args.seed, mc)保证各并发级别单独可复现内层遍历args.request_rate对每个(mc, rr)组合运行num_iters次迭代每次迭代前若flush_prefix_cache开启则调用flush_prefix_cache冲刷前缀缓存多次迭代时按吞吐量中位数挑选代表结果argmedian单次迭代直接采用该次结果校验失败时默认不保存除非always_save_result开启进程仍以退出码 1 结束。扩展新的 Sweep 维度要新增一个 Sweep 维度需要三处配合在配置类上新增一个str字段description 中说明其逗号分隔形式在benchmark_serving.py中加入对应的parse_comma_separated调用在_run_benchmark_sweep的循环中嵌套新维度。depends_onYAML 配置继承机制加载 YAML 时配置可以通过顶层depends_on字段继承另一个 YAML 文件的默认值。该机制实现在 max/python/max/config/init.py 中MAX_CONFIG_METADATA_FIELDS将name、description、version、depends_on列为元数据字段resolve_max_config_inheritance见 config/init.py读取depends_on若为相对路径则相对继承者文件所在目录解析加载父配置后递归解析其自身的继承链deep_merge_max_configs见 config/init.py执行深度合并嵌套字典递归合并其余键值由子配置覆盖子配置优先。# base_config.yaml name: Base Configuration description: Shared defaults version: 0.0.1 benchmark_config: model: modularai/Llama-3.1-8B-Instruct-GGUF num_prompts: 100 # my_config.yaml —— 继承 base_config.yaml 的默认值 name: My Custom Benchmark Configuration description: Inherits from base version: 0.0.1 depends_on: base_config.yaml # 相对路径相对于本文件所在目录 benchmark_config: model: my-other-model # 覆盖父配置当前仓库中configs 目录 下的基准测试配置尚未使用depends_on但该机制对需要分层组织配置的用户完全可用。新增一个 YAML 基准测试配置在max/python/max/benchmark/configs/下新增配置的步骤创建文件例如my_benchmark_config.yaml字段放在benchmark_config:区块下这与BaseBenchmarkConfig的section_name默认值一致加载时会自动提取该区块可选设置depends_on: parent_config.yaml继承同目录下另一个 YAML 的默认值无需修改 BUILD 文件max/python/max/benchmark/BUILD.bazel中已通过srcs glob([configs/*.yaml])自动收集该目录下所有 YAML。完整示例综合原文档与源码字段# my_benchmark_config.yaml name: My Custom Benchmark Configuration description: Configuration for my custom benchmark version: 0.0.1 benchmark_config: model: modularai/Llama-3.1-8B-Instruct-GGUF backend: modular endpoint: /v1/chat/completions dataset_name: sharegpt num_prompts: 100 # Sweepable fields accept either a single value or a comma-separated list. max_concurrency: 1,2,4,8 request_rate: 1.0,2.0,4.0,inf仓库中已有的真实配置可作参考llama3_1-405b-bf16-code_debug.yaml配max serve --model meta-llama/Llama-3.1-405B-Instructdataset_name: code_debug与 gemma-3-27b-sonnet-decode-heavy-prefix200.yamlsonnet 数据集指定sonnet_input_len: 550、output_lengths: 256、sonnet_prefix_len: 200。运行方式max benchmark --config-file my_benchmark_config.yaml用 extra_body 传递任意请求字段extra_body用于向每个文本生成请求体注入任意顶层字段覆盖那些没有专用标志的参数——例如stop、chat_template_kwargs、厂商扩展等。在 YAML 配置文件中在benchmark_config区块下以原生映射书写benchmark_config: model: modularai/Llama-3.1-8B-Instruct-GGUF extra_body: stop: [}] chat_template_kwargs: reasoning_effort: low在 CLI 上--extra-body接受三种形式由_mapping_from_argument统一解析见 config.py内联 JSON 对象以{开头--extra-body {stop: [}], chat_template_kwargs: {reasoning_effort: low}}YAML/JSON 文件路径--extra-body /path/to/extra_body.yaml直接作为--config-fileYAML 中的字段如上节所示。extra_body的校验器_parse_extra_body会在值缺失或为空串时返回{}。由于 cyclopts 默认要求标量键值对无法把单个嵌套 JSON 对象或文件路径作为一个 token 传入字段声明使用了Parameter(accepts_keysFalse)让原始 token 直接通过、交给校验器解析。合并语义last-writer-wins字段描述明确说明extra_body在专用标志之后应用包括--temperature、--max-output-len、--response-format等因此发生键冲突时extra_body覆盖专用标志且冲突会被记录日志。嵌套对象与数组原样保留。目前extra_body仅应用于文本生成请求chat/completions、completions 与 TensorRT-LLM generate_stream 端点图像/视频生成任务会忽略该字段。从配置到基准运行完整调用链将配置投入实际运行的完整链路如下parse_args解析 CLI 参数、环境变量与--config-fileYAML装配ServingBenchmarkConfigmain_with_parsed_args校验model必填缺失即抛ValueError依次执行 workload YAML 加载、运行长度默认值应用、种子解析与动态num_prompts计算_build_session构建会话含 tokenizer 加载与数据集采样dry_run模式只打印工作负载统计与预热采样预览不接触服务端wait_for_server_ready轮询服务端健康端点mcloud后端视为外部托管直接返回就绪若服务端报告的max_model_len小于 tokenizer 上限还会自动收紧上下文长度_run_benchmark_sweep按max_concurrency × request_rate矩阵执行逐迭代冲刷前缀缓存、运行异步 benchmark、按中位数挑选代表结果并保存。结语MAX 的基准测试配置体系将 Pydantic 的类型安全、YAML 的声明式管理与 cyclopts 的 CLI 解析结合BaseBenchmarkConfig与ServingBenchmarkConfig覆盖从模型、数据集到并发、流量控制、结果保存的完整参数面depends_on提供配置继承与深度合并max_concurrency与request_rate的逗号分隔语法让单次命令即可驱动多维 Sweep 矩阵。进一步阅读 benchmark_config.md 可获得更简明的速览深入配置解析可查看 max/python/max/config/README.md 与 config/init.pySweep 编排的完整实现则位于 benchmark_serving.py 与 sweep_benchmark_serving.py。【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 MAX 基准测试配置完全指南：Pydantic 配置类、YAML 继承与 Sweep 参数化
MAX 基准测试配置完全指南Pydantic 配置类、YAML 继承与 Sweep 参数化【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo本指南以max.benchmark.benchmark_shared.config中的基准测试配置体系为核心系统讲解 MAX 项目中 Serving 类基准测试的配置方式如何通过 Pydantic 配置类定义参数、如何用--config-file从 YAML 加载、depends_on继承机制如何工作、max_concurrency与request_rate如何展开为 Sweep 矩阵以及如何新增自定义 YAML 配置。读完本文你将能够独立编写、继承并运行一套可复现、可参数化扫描的 MAX Serving 基准测试配置并理解其底层实现原理。配置体系概览Pydantic 模型 YAML 文件 CLI 标志MAX 的基准测试配置是构建在 Pydantic 之上的数据模型。所有配置类继承自ConfigFileModel定义于 max/python/max/config/config_file_model.py因此具备两种使用方式直接在 Python 中构造实例化BaseBenchmarkConfig或ServingBenchmarkConfig并传入字段值从 YAML 文件加载通过--config-fileCLI 标志指定 YAML 路径运行时自动解析。配置值的最终生效顺序优先级从高到低在 max/python/max/config/README.md 中有明确说明CLI 参数命令行直接传入的值环境变量MODULAR_*前缀的环境变量例如MODULAR_BATCH_SIZE配置文件YAML通过--config-file指定的文件默认值配置类中定义的字段默认值。需要注意一个由 cyclopts 处理顺序决定的特殊行为环境变量在 Pydantic 校验之前生效因此配置文件无法覆盖环境变量但 CLI 参数可以覆盖一切。在基准测试的入口处benchmark_serving.py的parse_args通过 cycloptsApp解析参数并装配ServingBenchmarkConfig见 benchmark_serving.py。cyclopts 的config[Env(prefixMODULAR_)]让MODULAR_*环境变量成为配置源--config-file则负责 YAML 的加载与合并。配置类层次从通用参数到 Serving 专属参数配置类遵循清晰的继承层次相关源码位于 max/python/max/benchmark/benchmark_shared/config.py类职责关键参数BaseBenchmarkConfig所有基准测试共用的基础参数模型/分词器、数据集、工作量规模、控制标志BaseServingBenchmarkConfigServing 类基准测试共享的中间层流量突发度、LoRA 流量、GPU 统计、跳过测试提示词ServingBenchmarkConfigServing 基准测试benchmark_serving.py的完整配置后端/API、并发与 Sweep、流量控制、输出控制、结果保存BaseBenchmarkConfig通用参数BaseBenchmarkConfig覆盖所有基准类型共用的参数其section_name默认为benchmark_configexcludeTrue这使得加载 YAML 时会自动提取顶层benchmark_config:区块无需手动指定区块名。主要字段如下模型与分词器model必填运行基准时必须有、tokenizer默认分词器之外的自定义选择、tokenizer_local_files_only仅从本地 HF 缓存加载、tokenizer_revision固定加载的 commit revision适用于私有仓库或无法在 Hub 查询 revision 的场景、model_max_length覆盖分词器最大长度用于服务端最大长度低于分词器的场景、trust_remote_code数据集dataset_name默认sharegpt、dataset_path、dataset_modehuggingface或local工作量规模num_prompts处理的提示词数量随机种子seed默认值为DEFAULT_BENCHMARK_SEED 0x5EED十进制 24301拼写为 SEED。固定种子让重复运行与定时运行可复现运行间差异反映被测改动本身而非采样方差。可通过--seed none或 YAML 中seed: null改为每次抽取全新随机种子抽到的种子会被记录在结果中事后仍可复现控制标志disable_tqdm、print_inputs_and_outputs、verboseDEBUG 日志。seed字段有一个modebefore的校验器_parse_seed_cli_string负责把 CLI/YAML 传入的字符串none映射为None。ServingBenchmarkConfigServing 专属参数ServingBenchmarkConfig在基础参数之上扩展了大量 Serving 场景参数model_config ConfigDict(strictFalse, validate_assignmentTrue)——后者允许在运行时回填字段时重新触发校验。按功能分组核心字段包括后端与 APIbackend默认modular可选atom、mach、mcloud、modular、sglang、trtllm、vllm及其-chat变体、base_url远程端点、host默认localhost、port默认8000、endpoint默认/v1/chat/completions另支持/v1/completions、/v1/responses、/v1/images/generations、/v2/models/ensemble/generate_stream等、benchmark_tasktext-generation、text-to-image、image-to-image、text-to-video、image-to-video请求配置max_concurrency每个 Sweep 步骤的最大并发请求数none表示无界、lora、max_concurrent_conversationsKV-cache 压力测试、kv_block_size默认 128应与服务端--kv-cache-page-size对齐工作量配置max_benchmark_duration_s、num_chat_sessions、delay_between_chat_turns支持常数或分布串如N(mean,std)、U(lower,upper)、DU(lower,upper)、G(shape,scale)、LN(mean,std)、force_unique_runs为每次运行加 UUID 前缀以隔离 KV-cache输出控制output_lengths、max_output_len、temperature、thinking_temperaturethink块内温度MAX 专属扩展、top_p、top_k、response_format结构化输出可传 JSON 字符串或path/to/schema.json、extra_body图像/视频生成image_width、image_height、image_steps、image_guidance_scale、image_negative_prompt、image_seed、num_framestext-to-video 必需流量控制request_rate每秒请求数inf表示不限速、burstiness默认 1.0即泊松过程、skip_first_n_requests/skip_last_n_requests省略时自动设为max_concurrency、warmup_to_steady_state、warmup_oversample_factor默认 8、warmup_delay_biased及对应的warmup_delay_estimated_ttft_ms/warmup_delay_estimated_tpot_ms通过model_validator校验设置运行时间估算必须同时开启--warmup-delay-biased结果保存result_filename、record_output_lengths、record_request_text、always_save_result、metadata、latency_percentiles默认50,90,95,99、log_dirSweep 配置num_iters每个配置的迭代次数默认 1、flush_prefix_cache迭代间冲刷前缀缓存默认开启、num_prompts_multipliernum_prompts multiplier * max_concurrency替代默认 300 秒时长上限LoRA 配置lora_paths、lora_uniform_traffic_ratio、per_lora_traffic_ratio、max_concurrent_lora_ops。此外ServingBenchmarkConfig提供sampling属性将扁平的temperature/thinking_temperature/top_p/top_k组装为SamplingConfig对象OpenAI 风格采样参数集合。导入示例from max.benchmark.benchmark_shared.config import ( BaseBenchmarkConfig, ServingBenchmarkConfig, )Sweep 参数一个值或多个值的矩阵展开ServingBenchmarkConfig中有两个字段同时接受单个值或逗号分隔的多个值由sweep_benchmark_serving.py展开为运行矩阵max_concurrency每个条目按int | None解析request_rate每个条目按float解析。展开逻辑发生在 benchmark_serving.py 的main_with_parsed_args中concurrency_range parse_comma_separated(args.max_concurrency, int_or_none) request_rate_range parse_comma_separated(args.request_rate, float)parse_comma_separated与int_or_none定义于 max/python/max/benchmark/benchmark_shared/utils.pydef int_or_none(x: str) - int | None: Parse *x* as an int, returning None for the literal none. if x.lower() none: return None return int(x) def parse_comma_separated( value: str | None, convert: Callable[[str], _T], *, default: _T | None None, ) - list[_T]: if value is None: return [default] return [convert(x.strip()) for x in value.split(,)]特殊值的解析语义None大小写不敏感解析为 PythonNone对max_concurrency表示无界并发inf大小写不敏感可被float接受用于request_rate表示不限请求速率空条目文档声明逗号之间的空条目解析为None。但从当前实现看每个 token 经strip()后直接交给转换函数int_or_none()会抛出ValueError因此实践中应避免在列表中留下空条目例如1,,8会导致解析失败。模型层的类型转换字段在配置模型上的最终类型是Sequence[int | None]max_concurrency与Sequence[float]request_rate默认值分别为[None]与[float(inf)]。CLI 传入的字符串通过两个modebefore的校验器展开为序列_parse_max_concurrency_cli_strings与_parse_request_rate_cli_strings两者都处理单个值字符串单元素字符串列表cyclopts 的[sweep]形态三种输入。实际的 Sweep 执行循环矩阵展开后_run_benchmark_sweep见 benchmark_serving.py执行双层循环外层遍历args.max_concurrency每个并发级别基于种子派生独立采样mc_seed _seed_for_concurrency(args.seed, mc)保证各并发级别单独可复现内层遍历args.request_rate对每个(mc, rr)组合运行num_iters次迭代每次迭代前若flush_prefix_cache开启则调用flush_prefix_cache冲刷前缀缓存多次迭代时按吞吐量中位数挑选代表结果argmedian单次迭代直接采用该次结果校验失败时默认不保存除非always_save_result开启进程仍以退出码 1 结束。扩展新的 Sweep 维度要新增一个 Sweep 维度需要三处配合在配置类上新增一个str字段description 中说明其逗号分隔形式在benchmark_serving.py中加入对应的parse_comma_separated调用在_run_benchmark_sweep的循环中嵌套新维度。depends_onYAML 配置继承机制加载 YAML 时配置可以通过顶层depends_on字段继承另一个 YAML 文件的默认值。该机制实现在 max/python/max/config/init.py 中MAX_CONFIG_METADATA_FIELDS将name、description、version、depends_on列为元数据字段resolve_max_config_inheritance见 config/init.py读取depends_on若为相对路径则相对继承者文件所在目录解析加载父配置后递归解析其自身的继承链deep_merge_max_configs见 config/init.py执行深度合并嵌套字典递归合并其余键值由子配置覆盖子配置优先。# base_config.yaml name: Base Configuration description: Shared defaults version: 0.0.1 benchmark_config: model: modularai/Llama-3.1-8B-Instruct-GGUF num_prompts: 100 # my_config.yaml —— 继承 base_config.yaml 的默认值 name: My Custom Benchmark Configuration description: Inherits from base version: 0.0.1 depends_on: base_config.yaml # 相对路径相对于本文件所在目录 benchmark_config: model: my-other-model # 覆盖父配置当前仓库中configs 目录 下的基准测试配置尚未使用depends_on但该机制对需要分层组织配置的用户完全可用。新增一个 YAML 基准测试配置在max/python/max/benchmark/configs/下新增配置的步骤创建文件例如my_benchmark_config.yaml字段放在benchmark_config:区块下这与BaseBenchmarkConfig的section_name默认值一致加载时会自动提取该区块可选设置depends_on: parent_config.yaml继承同目录下另一个 YAML 的默认值无需修改 BUILD 文件max/python/max/benchmark/BUILD.bazel中已通过srcs glob([configs/*.yaml])自动收集该目录下所有 YAML。完整示例综合原文档与源码字段# my_benchmark_config.yaml name: My Custom Benchmark Configuration description: Configuration for my custom benchmark version: 0.0.1 benchmark_config: model: modularai/Llama-3.1-8B-Instruct-GGUF backend: modular endpoint: /v1/chat/completions dataset_name: sharegpt num_prompts: 100 # Sweepable fields accept either a single value or a comma-separated list. max_concurrency: 1,2,4,8 request_rate: 1.0,2.0,4.0,inf仓库中已有的真实配置可作参考llama3_1-405b-bf16-code_debug.yaml配max serve --model meta-llama/Llama-3.1-405B-Instructdataset_name: code_debug与 gemma-3-27b-sonnet-decode-heavy-prefix200.yamlsonnet 数据集指定sonnet_input_len: 550、output_lengths: 256、sonnet_prefix_len: 200。运行方式max benchmark --config-file my_benchmark_config.yaml用 extra_body 传递任意请求字段extra_body用于向每个文本生成请求体注入任意顶层字段覆盖那些没有专用标志的参数——例如stop、chat_template_kwargs、厂商扩展等。在 YAML 配置文件中在benchmark_config区块下以原生映射书写benchmark_config: model: modularai/Llama-3.1-8B-Instruct-GGUF extra_body: stop: [}] chat_template_kwargs: reasoning_effort: low在 CLI 上--extra-body接受三种形式由_mapping_from_argument统一解析见 config.py内联 JSON 对象以{开头--extra-body {stop: [}], chat_template_kwargs: {reasoning_effort: low}}YAML/JSON 文件路径--extra-body /path/to/extra_body.yaml直接作为--config-fileYAML 中的字段如上节所示。extra_body的校验器_parse_extra_body会在值缺失或为空串时返回{}。由于 cyclopts 默认要求标量键值对无法把单个嵌套 JSON 对象或文件路径作为一个 token 传入字段声明使用了Parameter(accepts_keysFalse)让原始 token 直接通过、交给校验器解析。合并语义last-writer-wins字段描述明确说明extra_body在专用标志之后应用包括--temperature、--max-output-len、--response-format等因此发生键冲突时extra_body覆盖专用标志且冲突会被记录日志。嵌套对象与数组原样保留。目前extra_body仅应用于文本生成请求chat/completions、completions 与 TensorRT-LLM generate_stream 端点图像/视频生成任务会忽略该字段。从配置到基准运行完整调用链将配置投入实际运行的完整链路如下parse_args解析 CLI 参数、环境变量与--config-fileYAML装配ServingBenchmarkConfigmain_with_parsed_args校验model必填缺失即抛ValueError依次执行 workload YAML 加载、运行长度默认值应用、种子解析与动态num_prompts计算_build_session构建会话含 tokenizer 加载与数据集采样dry_run模式只打印工作负载统计与预热采样预览不接触服务端wait_for_server_ready轮询服务端健康端点mcloud后端视为外部托管直接返回就绪若服务端报告的max_model_len小于 tokenizer 上限还会自动收紧上下文长度_run_benchmark_sweep按max_concurrency × request_rate矩阵执行逐迭代冲刷前缀缓存、运行异步 benchmark、按中位数挑选代表结果并保存。结语MAX 的基准测试配置体系将 Pydantic 的类型安全、YAML 的声明式管理与 cyclopts 的 CLI 解析结合BaseBenchmarkConfig与ServingBenchmarkConfig覆盖从模型、数据集到并发、流量控制、结果保存的完整参数面depends_on提供配置继承与深度合并max_concurrency与request_rate的逗号分隔语法让单次命令即可驱动多维 Sweep 矩阵。进一步阅读 benchmark_config.md 可获得更简明的速览深入配置解析可查看 max/python/max/config/README.md 与 config/init.pySweep 编排的完整实现则位于 benchmark_serving.py 与 sweep_benchmark_serving.py。【免费下载链接】mojoThe Modular Platform (includes MAX Mojo)项目地址: https://gitcode.com/GitHub_Trending/mo/mojo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考