Web UI 前端架构演进与体验优化设计

修订记录

日期	修订版本	修改描述	作者
2026-06-03	v1	现网 `http://127.0.0.1:2345/` 与当前 HTML 原型，补充“现网能力 vs 原型能力”的差距分析	彭志品

1. 概述

本设计文档面向 web_ui/ 当前前端实现，目标是在保持 CLI 主链路不变的前提下，梳理现状、识别问题，并给出一条低风险、可分阶段落地的前端演进路径。

当前 Web UI 基于 Gradio Blocks 构建，已经支持：

Simulator 与 Optimizer 两大入口
LLM Models、VL Models、Video Models 三类仿真工作流
参数配置、命令预览、批量任务触发、结果解析、图表分析、历史缓存与导出

从实际能力看，这个前端已经不是简单的“命令包装器”，而是一个围绕建模 CLI 的分析型工作台。问题也不再是“能不能用”，而是“如何在继续扩展参数、模型和分析能力时，仍然保持清晰、可维护和可演进”。

2. 背景与动机

随着 LLM、VL、Video 和 Optimizer 等场景持续扩展，当前前端逐步承载了越来越多的输入参数、场景切换和结果分析职责。现有方案已经形成较完整的工作闭环，但同时也出现了几个明显信号：

web_ui/app.py 页面定义、布局组织和事件绑定集中
web_ui/callbacks.py 承担了表单构造、参数校验、任务驱动、结果整形和筛选刷新等多重职责
Text Generate 表单字段规模已接近“专业配置台”级别，覆盖基础参数、量化参数、MoE 参数、高级并行覆盖和调试参数
多个回调仍依赖较长的位置参数列表在页面和回调间传递，字段扩展时存在顺序错位和漏改风险
页面已有较强结果分析能力，但配置复用、任务中心、历史实验治理和错误恢复能力仍偏弱

在当前代码与页面基础上，如果不继续对前端做结构治理，后续会出现以下趋势：

新参数和新场景接入成本持续上升
页面可理解性下降，新用户使用门槛升高
结果分析能力继续增强，但任务管理与配置复用能力跟不上
回调文件持续膨胀，测试、调试和重构成本上升
安全边界模糊，页面和后端在“谁负责真正约束执行”上缺少明确分工

因此，本设计文档的目标不是推翻现有实现，而是在保护现有能力的基础上，逐步把 Web UI 从“参数堆叠页面”演进为“面向实验分析、任务治理和专项分析的工作台”。

3. 目标与非目标

3.1 目标

形成一份能够指导后续 Web UI 演进的统一 RFC/Design 文档
梳理当前前端架构、数据流、参数组织、任务链路和结果视图能力
明确当前实现的主要问题，包括体验、结构、状态组织、并发治理、日志治理和安全边界
给出低风险、分阶段的优化路径
在尽量不改变 CLI、解析器和执行链路的前提下，提升可维护性、可扩展性与可测试性
让 Video DiT Cache、Optimizer、PD Split Analysis 等专项能力在页面上显式产品化
让页面原型中已经收敛出的交互闭环进入正式设计，而不是停留在文案层

3.2 非目标

不要求立即将 Gradio 替换为 React/Vue 等前后端分离方案
不在本设计文档中重构 CLI 核心算法、性能模型或日志协议
不要求一次性完成所有页面和回调的重写
不在本设计文档中完整展开多租户、鉴权体系和服务化部署设计

4. 当前前端架构与能力

4.1 架构全景

当前 web_ui/ 的实现已经形成较清晰的链路，只是边界还不够硬。整体可以概括为：

页面层
  app.py
  components.py
  styles.py

交互编排层
  callbacks.py

任务构造与执行层
  command_builder.py
  runner.py

解析与持久化层
  parsers.py
  result_store.py

数据与工具层
  schemas.py
  utils.py

结果可视化层
  charts.py

这套结构的优点是主链路方向清晰，前端已经不是“所有逻辑都堆在一个文件里”；不足是页面层和交互编排层仍然耦合较重，特别是 app.py 与 callbacks.py 之间的参数组织方式和职责边界仍偏脆弱。

4.2 当前页面能力

结合 python -m web_ui.web_ui_start --host 127.0.0.1 --port 2345 和当前代码，可以确认当前页面已经具备以下能力：

Simulator / Optimizer 两大工作流
LLM / VL / Video 三类仿真入口
配置预览与命令预览
批量任务执行与结果刷新
图表、结果表、基线对比、导出
Optimizer 结果摘要与明细刷新

同时也可以确认当前页面仍保留以下形态特征：

页面整体仍以“长表单 + 结果区”组织为主
任务过程可视化仍弱于结果分析能力
进度组件仅展示 completed / total、状态和 latest task，未形成可信 ETA 体系
顶层缺少明确的 Stop / Cancel 控制
设备与卡数仍以单全局字段为主，未形成显式绑定区

4.3 核心数据流

以文本仿真为例，当前核心流程可抽象为：

用户填写表单
-> Preview / Run
-> callbacks.py 收集与校验参数
-> command_builder.py 生成 ExperimentTask 列表
-> result_store.py 尝试缓存命中
-> runner.py 并发执行未命中任务
-> parsers.py 解析日志并生成 ExperimentResult
-> result_store.py 持久化结果与日志
-> callbacks.py 组织 summary / charts / tables / filters
-> 页面刷新展示

这里有两个关键点值得在架构层明确，而不是零散写在模块说明里：

前端与执行链路之间的核心数据契约是 ExperimentTask 和 ExperimentResult
缓存并不是附属功能，而是主链路的一部分，因为执行前就会参与任务去重与结果复用

4.4 数据契约与缓存机制

当前实现中，schemas.py 定义了 ExperimentTask 和 ExperimentResult 两个核心结构，分别承担任务描述与结果描述职责。它们决定了前端如何把表单值组织成任务，也决定了结果如何被统一渲染、缓存和导出。

特别值得强调的是 ExperimentResult.source 字段：

source="run" 表示结果来自真实执行
source="cache" 表示结果来自缓存复用

缓存机制由 result_store.py 提供，当前已经实现了：

SQLite 数据库存储，路径为 .msmodeling_ui/results.sqlite3
原始日志文件持久化，路径为 .msmodeling_ui/logs/
基于稳定参数哈希的缓存键生成
查询历史结果、复用缓存结果、补充 Optimizer 摘要信息

从能力上看，这套缓存机制已经比较完整。当前问题更多在于页面没有把它很好地表达为“历史结果与任务复用能力”，而仍偏向“底层实现细节”。

4.5 现网页面能力分析

4.5.1 现网页面已有能力分析

现网页面已经具备：

Hero 品牌区
LLM / VL / Video / Optimizer 工作流入口
参数表单
Preview / Run
图表、结果表、导出
Optimizer 专项页面入口

但整体仍偏“长表单 + 结果区”，缺少：

顶层任务治理
显式日志治理
绑定区
专项结果产品化

4.5.2 现网页面能力拓展

当前 HTML 原型已经证明下列能力在信息架构上是成立的：

高频场景入口
device / device_nums 绑定区
任务中心
任务卡联动结果上下文
命令预览可复制
DiT Cache Analysis
PD Disaggregated 专项结果解释
并发治理摘要
日志与安全页签

这些能力不是“想法”，而是已经过页面原型验证的候选落地项。

4.5.3 原型中存在，但不应立即进入开发

当前原型里有些能力虽然存在，但不建议立即排入首批开发：

过重的 Hero 区摘要和说明
过细的开发 / 联调显示项
多批次并行会话管理
配置资产管理（保存 / 加载 / 回填）完整能力
所有任务按钮的完整后端闭环

原因不是这些能力没价值，而是它们都建立在“核心任务治理、日志治理、结果映射和安全边界”已稳定的前提之上。

5. 参数与场景复杂度分析

5.1 参数规模已经进入“专业配置台”阶段

按当前实现，Text Generate 表单规模已经接近 70 个字段，覆盖：

基础模型与设备参数
并行参数
量化参数
MoE 参数
模块级高级并行覆盖参数
性能模型与调试参数

这意味着页面的核心问题不是“字段多一点”，而是“需要明确的分层与认知路径”。否则页面会越来越像“高级命令行参数全集”。

5.2 MoE 参数

当前前端已支持一组明显具有专业门槛的 MoE 参数，包括：

moe_tp_size
moe_dp_size
enable_redundant_experts
enable_external_shared_experts
host_external_shared_experts
word_embedding_tp

这类参数和普通 TP/DP 参数不同，它们牵涉专家并行、冗余专家、共享专家等结构化决策，使用者通常需要模型结构背景知识才能正确配置。

因此，MoE 不应只是“更多参数”之一，而应被明确归类为专项专家参数。后续页面设计建议：

把 MoE 参数单独放入“MoE / Expert”区域
为非专家用户提供更强的默认值与说明
避免和基础参数混排，减少误操作

5.3 高级并行覆盖参数

当前系统还提供细粒度的模块级并行覆盖参数，包括：

num_hidden_layers_override
o_proj_tp_size
o_proj_dp_size
mlp_tp_size
mlp_dp_size
lmhead_tp_size
lmhead_dp_size

这类参数主要服务于：

部分层测试与快速调试
特定模块并行策略验证
高级用户的精细调优

它们不应和基础参数处于同一认知层级。后续应明确标记为“高级并行覆盖”，并向用户说明默认情况下不需要修改。

5.4 性能模型与 Profiling

当前前端支持性能模型选择：

analytic
profiling

同时支持：

profiling_database

这说明页面不仅在收集仿真输入，还在承载“如何估算性能”的选择逻辑。对用户来说，这会直接影响结果的理解：

analytic 更快，适合快速探索
profiling 更依赖数据，但更贴近测量

因此，后续前端设计和文档都应明确这两种模式的差异，而不是把它们埋在参数列表里。

5.5 Video 特有的 DiT Cache 能力

当前实现已经支持 DiT Cache 相关结果解释，包括：

dit_cache 开关
是否真正生效
替换块数量
替换区间
总块数
失效原因

这意味着页面已经不只是“能开缓存”，而是“能解释缓存为什么生效或为什么没生效”。这类能力是前端产品价值的一部分，后续在页面结构上应体现为专项分析能力，而不是隐藏实现。

5.6 Optimizer 专项复杂度

Optimizer 页面也不是普通参数表单。当前实现至少包括两类值得单独强调的专项能力：

第一类是部署模式标准化，支持：

PD Aggregated
PD Disaggregated
PD Ratio

并兼容多种中英文别名和大小写变体输入。

第二类是结果摘要增强。当前缓存与解析逻辑会从 top_configs 和原始日志中补充提取：

best_parallel
best_batch_size
best_concurrency
best_throughput
best_ttft_ms
best_tpot_ms
no_result_reason

这说明 Optimizer 已具备专项结果语义，而不是通用结果模板可以完全覆盖的页面。

6. 当前主要问题

6.1 页面体验问题

6.1.1 参数密度高，认知负担重

当前页面虽然通过 Accordion 等方式做了分组，但基础参数、高级参数、调试参数和专家参数仍然混在较近的交互层级里，导致：

用户不知道应该先填什么
新用户容易只看到“参数很多”，看不到“流程很清晰”
高级参数对基础流程形成噪音

6.1.2 高频场景与参数分层虽然明确，但页面主视觉仍需继续收敛

当前原型已经把“高频场景”“基础参数 / 专项参数 / 高级调试”拉出来，但 Hero 区、状态区、左侧导航和结果工作台之间仍然需要持续做减法，避免同一信息在多个区块里重复表达。

6.1.3 能力入口有，但能力解释不够清晰

当前页面已经提供 Simulator 与 Optimizer 两类入口，但对两者的场景差异说明仍偏弱，用户第一次进入页面时难以快速判断：

我是要做单次 forward 建模，还是做寻优
我当前的问题更适合 Simulator 还是 Optimizer
我应该先验证一个配置，还是直接做搜索

6.1.4 关键参数缺少“填写指导”

目前多数参数主要以字段名和默认值呈现，缺少统一的字段说明、示例值和输入建议，导致：

用户知道参数“能填”，但不知道“该怎么填”
新用户容易把基础参数和高级参数混用
某些专项参数虽然已存在，但缺少适用条件说明

6.1.5 缺少预置 case，首次使用成本高

当前用户通常需要从空白表单开始填写，这对熟悉 CLI 的用户问题不大，但对首次进入 Web UI 的用户来说成本偏高：

不知道从哪个场景开始最稳妥
不知道一套最小可运行配置长什么样
不知道 Video、MoE、PD Split 等专项能力应该如何起步

6.1.6 任务视角偏弱，但已经开始出现明确闭环

当前前端页面仍缺：

多批次并行治理
任务级独立 Stop / Retry 后端链路
任务详情页与日志详情页

6.1.7 时间进度条估计不准或缺少可信 ETA

当前时间进度条存在“总时间沿用上一次任务时间”的问题，容易误导用户。结合现网页面和代码也可以看到，当前进度组件仅显示：

completed / total
百分比
当前状态
最新任务

6.1.8 缺少真正的多批次并行会话能力

当前页面设计已经能表达：

一个批次内部的并发运行
一个任务组的状态治理

但还不能表达：

同时管理两个独立仿真批次
为两个批次分别展示进度、日志和停止按钮

因此“并发治理”当前更偏“单批次任务组并发”，不是“多会话并行工作台”。

6.2 任务、日志与结果问题

6.2.1 并行优化表达仍需和真实执行能力对齐

当前执行层已经不是纯串行，但距离“理想状态只需一次寻优运行时间，可以完成所有任务”仍有明显距离。问题包括：

页面缺少真正的全局并发池配置入口
用户难以区分并发上限、队列长度和真实运行数
Parallel Jobs 与实际 worker 关系不清晰

当前原型已把“并发治理”压缩为摘要卡，方向是对的，但仍需和真实执行层语义对齐。

6.2.2 日志操作仍需真实后端能力补齐

当前页面仍需补：

打开本地日志目录
打开具体日志文件
失败任务自动定位对应日志片段

6.2.3 PD 分离结果展示错误

已通过最小化真实验证确认，PD Disaggregated 不是完全不能用，而是结果展示存在明显解析错误，尤其是详情表里的 QPS / TTFT / TPOT 列映射会错位。该问题说明：

PD Disaggregated 不能继续依赖通用表格语义
前端需要为其建立专项展示和专项映射校验
页面需要更明确地区分 TTFT-oriented 与 TPOT-oriented 分析视角

6.2.4 空列展示造成噪音

当前结果表对“某些模式下整体为空的列”缺少统一裁剪逻辑，例如：

PD 混部结果中的 PD 配比列
某些 Video 特有列
某些 Optimizer 专项列

后续需要建立“全空列默认隐藏”的结果表展示约束。

6.3 架构与代码问题

6.3.1 页面定义与回调编排文件过大

app.py 和 callbacks.py 当前已经成为维护热点。问题不只是文件大，而是改动牵连面大：

新增字段需要同步修改输入定义、回调收集、校验、命令映射、预览、展示和测试
局部改动容易引起回归
新同学理解成本高

6.3.2 位置参数传递方式脆弱

多个回调依赖较长的位置参数列表来收集 UI 值，这种方式在字段规模较小时可以工作，但在当前复杂度下存在明显风险：

顺序依赖强
新字段漏改概率高
代码审查时不易快速发现错位问题

6.3.3 状态管理分散

当前大量使用 gr.State 维护表格行、完整结果、筛选状态和模型状态。这种方式可以工作，但如果继续扩展：

历史对比
收藏配置
报告生成
失败任务重试
日志定位
绑定设备切换
多批次会话

状态复杂度会持续上升，联动逻辑也更容易重复。

6.3.4 `device` 和 `device_nums` 缺少正式绑定模型

当前页面仍以全局 device 与全局 num-devices 为主。后续需要把这一交互模型正式沉淀成数据对象，而不是仅存在于页面原型中。

6.4 安全问题

6.4.1 前后端通信和命令执行存在安全边界问题

Web UI 本质上会驱动后端执行 cli/inference 下的命令入口，因此必须明确以下风险：

如果服务监听非本地地址，外部请求可能访问执行接口
如果后端不做入口白名单和参数白名单，可能形成任意命令执行风险
前端按钮禁用或前端文案提示并不能构成真实安全边界

这部分要求必须覆盖 cli/inference 下的三个入口，并明确：

仅本地通信是后端约束，不是前端自我声明
命令白名单和参数白名单必须由后端强制执行
前端只负责守卫状态可视化和误操作收敛

7. 设计目标

本次前端演进希望实现以下目标：

保持当前“围绕 CLI 的轻量工作台”定位
让页面从“参数堆叠”演进为“高频场景引导 + 结果分析 + 任务治理”
让专业参数通过分层和预设被更好消化
降低 app.py 与 callbacks.py 的维护压力
为任务中心、历史对比、报告生成和推荐能力预留结构空间
让 DiT Cache、PD Disaggregated、PD Ratio 等专项分析能力被页面显式承接
让日志、安全、并发治理成为页面一级可见能力
把已经在原型中验证有效的交互闭环正式纳入设计基线
给出“现网先补什么、原型后吸收什么、哪些先不做”的优先级顺序

8. 总体方案

8.1 产品结构方向

基于现网页面现状，建议将前端稳定为五层结构：

全局层
  顶部导航 / 当前批次状态 / 历史入口 / Run / Preview / Stop

工作流入口层
  Simulator / Optimizer
  LLM / VL / Video

高频场景层
  单卡 Decode
  长上下文 Prefill
  Video 缓存诊断

配置层
  基础参数
  专项参数（MoE / Video / Advanced Parallel）
  高级调试与执行预检
  device / device_nums 绑定区
  命令预览

分析层
  结果工作台
  Optimizer 专项结果
  DiT Cache Analysis
  日志 / 安全 / 任务治理

8.2 页面信息架构设计

8.2.1 Hero 区与全局层

Hero 区不再承担“导航聚合器”职责，而是回到两件事：

承接现网页面的品牌语气与能力概述
用少量摘要卡补充当前批次信息与主设备信息

8.2.2 工作流入口层

入口层保留：

Simulator
Optimizer

Simulator 下保留：

LLM
VL
Video

设计要求：

切换入口时，配置区标题、说明、默认参数和结果工作台都必须联动
Video 切换时要能联动 DiT Cache Analysis

8.2.3 Simulator与Optimizer场景说明

1. 首屏先回答“我该运行什么能力”

Simulator 与 Optimizer 不应只作为 tab 或按钮存在，而应具备清晰说明卡：

Simulator：适用于“我已经有一个候选配置，想做单次或批量建模验证”
Optimizer：适用于“我还没有确定配置，想在约束条件下搜索更优方案”

在入口层固定展示一段简短说明：

想验证一个已有配置，用 Simulator
想自动搜索更优配置，用 Optimizer

2. Simulator 场景说明

对于 Simulator，页面需强调：

这是“单次 forward 建模 / 指定配置评估”入口
用户已知模型、设备和大致配置
页面重点是帮助用户完成一次明确、可解释的建模运行

给出一句明显说明文案：

Simulator 用于评估“这组配置跑出来会怎样”。

3.Optimizer 场景说明

对于 Optimizer，页面需强调：

这是“寻优 / 搜索最优配置”入口
用户已知优化目标和约束条件，但未必知道最终配置
页面重点是帮助用户表达搜索范围、目标指标和部署模式

给出一句明显说明文案：

Optimizer 用于搜索“在目标约束下什么配置更优”。

4.子场景说明

在 Simulator 或 Optimizer 下切换 LLM / VL / Video 时，配置区顶部需要同步切换一句场景说明：

LLM：面向文本生成与大语言模型建模
VL：面向视觉语言场景建模
Video：面向视频模型建模，并显式联动 DiT Cache Analysis

5.首次使用推荐路径

页面应显式给出首用引导：

先选择 Simulator
再选择 LLM / VL / Video
套用一个预置 case
只修改少量关键参数
运行并查看结果摘要

这条路径优先服务新用户，不影响高级用户继续使用完整配置能力。

8.2.4 高频场景层

原型中已将“场景预设”收敛为“高频场景”，建议保留这一命名。

推荐高频场景：

单卡 Decode
长上下文 Prefill
Video 缓存诊断场景

约束说明：

高频场景是快捷入口，不替代完整配置
必须明确告诉用户该场景默认按单卡还是多卡初始化
PD Disaggregated 不作为独立高频场景，因为它是 Optimizer 内部部署模式，不应只偏向 Prefill 或 Decode 一侧

8.2.5 配置层

配置层建议按三层组织：

基础参数
专项参数
高级调试与执行预检

其中：

基础参数承载模型、设备、规模、性能模型等高频配置
专项参数承载 MoE / Video / 高级并行覆盖
高级调试与执行预检再拆成“普通用户运行前检查”和“开发 / 联调”

8.2.6 `device / device_nums` 绑定区

绑定区当前原型已经验证以下交互模型是合理的：

展示 当前执行规模
展示 主设备
展示 主绑定 device_nums
支持多行绑定保留
支持将某一行“设为当前执行”
支持“新增 / 编辑 / 删除”通过页面内弹窗完成

交互约束：

device_nums = 1 视为单卡
device_nums > 1 视为多卡
设为当前执行后，该行应自动排到第一行
新增、编辑、删除不再使用原生 prompt / confirm
弹窗内允许同时修改 Device / device_nums / 用途 / 是否设为当前执行

8.2.7 结果工作台

结果区建议继续强化，而不是弱化。目标是让它成为统一工作台：

顶部展示任务组摘要、缓存命中数、成功数、失败数
中部保留现有图表能力，并统一筛选联动
下部增加失败任务、原始日志、运行环境、导出记录等视图

结果工作台建议按页签拆为：

总览摘要
寻优分析
Video / DiT Cache
日志与安全

8.3 任务中心、并发治理与日志治理

8.3.1 任务中心

当前原型已经确认任务中心至少应支持：

任务卡点击联动结果上下文
查看结果
打开日志
复制配置重跑
停止

说明：

这些按钮在原型中已具备最小页面联动
真实系统中仍需补齐后端动作链路
首批开发不要求所有按钮都具备完整后端能力，但至少要形成“查看结果 / 查看日志”的稳定闭环

8.3.2 并发治理

并发治理收敛为一张摘要卡，建议正式采用这一更简洁的形态。

最低展示项：

并发上限
运行中数量
排队数量
已完成数量
缓存直出数量
失败数量
利用率

8.3.3 日志治理

需要实现：

task_id -> log_path 表格
日志页签跳转
实时日志片段
命令区“打开日志目录”反馈

正式实现要求：

打开日志目录
打开具体日志文件
按失败任务自动定位日志片段

8.4 现网到工作台的优先级演进原则

明确采用以下原则：

先补现网痛点，再吸收原型增强能力。
先做单批次闭环，再考虑多批次并行会话。
先解决结果与任务可信度，再做配置资产和更复杂的辅助能力。
先让核心按钮真可用，再增加更多入口和动作。

8.5 专项参数与专项结果设计

8.5.1 MoE / Expert

MoE 参数单独归入“专项参数”，至少包括：

moe_tp_size
moe_dp_size
shared experts
redundant experts

8.5.2 Video / DiT Cache

Video 专项参数和结果必须成对出现：

参数侧：是否开启 dit_cache、替换块数、替换区间、总块数
结果侧：DiT Cache Analysis

也就是说，DiT Cache 不能只表现为“输入开关”，还必须表现为“结果解释能力”。

8.5.3 高级并行覆盖

高级并行覆盖参数需要从基础参数中抽离，单独标识为：

TP / PP / DP / EP Override
模块级覆盖项

默认情况下不建议普通用户修改。

8.6 Optimizer 专项设计

Optimizer 页面需要被视为独立产品域，而不是普通表单页的附属模式。

部署模式：

PD Aggregated
PD Disaggregated
PD Ratio

分析视图：

Best by Device
Fixed Config Compare
PD Split Analysis

设计要求：

模式切换必须联动约束说明、搜索空间、命令预览、结果卡片和结果表
PD Disaggregated 必须明确同时支持 TTFT-oriented 和 TPOT-oriented
页面必须为 PD Disaggregated 详情表建立专项字段映射，避免继续沿用错误列位解析

8.7 命令预览与执行边界

命令预览区不能只是“静态展示”。

以下最小交互合理：

复制命令 可用
打开日志目录 给出明确反馈并联动到日志页签
失败时至少退化为“选中文本供手动复制”

这意味着正式实现里，命令预览区应被视为“可操作区域”，而不只是“文案说明”。

8.8 安全边界设计

安全能力必须明确以后端为边界。

后端约束要求：

Web UI 后端仅允许本地通信
cli/inference 下三个执行入口都必须纳入命令白名单
只允许预定义参数集合通过，不允许未知参数直接透传
禁止把前端输入拼接为不受控 shell 字符串

前端职责：

展示当前后端守卫状态
在运行前给出本地通信、入口允许状态和未知参数策略的可视化提示
减少误操作，但不承担真实安全拦截职责

结论：

顶部 badge 文案也要遵循这一边界，避免让用户误解为“前端自身在实现安全”

9. 关键参数说明设计

9.1 参数说明原则

主要参数应至少具备以下信息：

参数名称
参数含义
建议填写方式
典型示例或默认建议

页面实现上建议采用：

字段标题
一行简短说明
placeholder 示例
tooltip 补充解释
校验失败时的修复建议

9.2 `Simulator` 关键参数

Simulator 首屏优先展示以下关键参数，并给出简要说明：

model_name：选择待建模模型
device：选择目标设备类型
device_nums：选择单卡或多卡数量
input_len：输入 token 长度
output_len：输出 token 长度
batch_size：批大小

说明要求：

device_nums=1 要明确表示单卡
input_len / output_len 应给出常见示例值
batch_size 应说明“吞吐场景通常更关注该参数”

9.3 `Optimizer` 关键参数

Optimizer 首屏优先展示以下关键参数，并给出简要说明：

优化目标：例如 TTFT / TPOT / QPS
约束条件：例如延迟、吞吐或设备数量上限
搜索范围：例如卡数范围、并行方式范围、批大小范围
部署模式：例如 PD Aggregated / PD Disaggregated / PD Ratio

说明要求：

Optimizer 不应一上来展示过多低层实现参数
用户应先完成“目标 + 约束 + 搜索范围”三件事
PD Disaggregated 要明确提示“适合进阶分析场景”

9.4 专项参数说明

以下参数必须从基础参数中抽离，作为专项参数区管理：

MoE / Expert 参数
Video / DiT Cache 参数
高级并行覆盖参数
PD Split 专项结果关联参数

专项参数区必须额外提供：

适用场景
不建议修改时机
与结果页的联动关系

例如：

开启 DiT Cache 后，结果区同步出现 DiT Cache Analysis
MoE 参数默认折叠，不建议普通用户首次运行时修改

10. 预置 Case 设计

10.1 设计原则

预置 case 的目标不是替代完整配置，而是帮助用户快速起步。

每个预置 case 应至少包含：

适用场景说明
自动填充的关键参数
用户仍需确认的少量参数

10.2 `Simulator` 推荐预置 case

建议首批提供以下预置 case：

单卡文本生成基线 说明：适合首次体验 LLM 单次建模自动填充：单卡、基础输入输出长度、推荐 batch 用户需确认：模型名、设备型号
长上下文 Prefill 基线 说明：适合长输入场景验证自动填充：较大 input_len、较小 output_len 用户需确认：模型名、设备数
多卡吞吐评估 说明：适合验证扩卡后吞吐变化自动填充：多卡、推荐并行参数用户需确认：模型名、目标卡数
Video 缓存诊断 说明：适合 Video 场景专项分析自动填充：Video 相关关键参数与 DiT Cache 推荐项用户需确认：模型名

10.3 `Optimizer` 推荐预置 case