使用ChromeDriver自动填写表单测试训练提交功能

在大模型研发节奏日益加快的今天，一个常见的工程挑战浮出水面：如何让模型训练任务像流水线一样稳定、高效地运行？许多团队仍依赖手动操作——打开网页、选择模型、填写参数、点击提交。这种模式不仅耗时费力，还容易因人为疏忽导致配置错误或任务遗漏。

有没有可能把这一整套流程自动化起来？比如每天凌晨三点，系统自动为最新的多模态模型启动一轮图文理解微调任务，并将结果上传至内部模型库？答案是肯定的。借助ms-swift这一统一的大模型工程框架，配合 ChromeDriver 实现前端表单的自动化填充与提交，我们完全可以构建一套“无人值守”的训练调度系统。

这背后不仅仅是脚本的拼接，而是一整套从交互层到执行层的工程闭环设计。

ms-swift：不只是微调工具，而是AI工程的操作系统

要理解这套自动化系统的可行性，首先要明白 ms-swift 到底解决了什么问题。它不像传统微调脚本那样只关注某个具体任务，而是试图打通从模型选择、数据准备、训练执行到推理部署的全链路。

它的设计理念很清晰：一次配置，全流程贯通。无论是 Qwen3、Llama4 还是 InternVL3.5，只要你在 YAML 配置文件中声明模型名称和任务类型，框架就能自动加载对应的训练逻辑、prompt 模板、并行策略甚至量化方案。这意味着你不需要为每个新模型重写训练代码，也不必担心不同架构之间的接口不兼容。

更关键的是，ms-swift 提供了两种主要使用方式：命令行接口（CLI）和 Web-UI 界面。前者适合集成进 CI/CD 流程，后者则降低了非技术人员的使用门槛。而我们的自动化提交系统，正是建立在这两者之间的桥梁之上——通过模拟用户在浏览器中的操作，触发后端基于 ms-swift 的训练任务。

自动化训练的核心链条：从表单提交到GPU集群

设想这样一个典型场景：某智能客服团队需要每天用最新对话数据对 Qwen3-VL 模型进行 LoRA 微调，以保持其对图文混合输入的理解能力。他们搭建了一个简单的 Web 页面用于提交训练任务，字段包括模型名、数据集路径、batch size、epoch 数等。

如果我们能用程序代替人工完成这个页面的填写与提交，再由后端服务将其转换为标准的 ms-swift 训练指令，整个流程就可以实现完全自动化。

这条链路由四个关键环节构成：

前端交互层：基于 HTML 表单的训练任务提交页面；
自动化驱动层：使用 Selenium + ChromeDriver 模拟浏览器行为；
后端解析层：接收 HTTP 请求，生成符合 ms-swift 规范的配置文件；
执行引擎层：调用swift sft命令启动训练任务，资源调度交由 Slurm 或 Kubernetes 管理。

其中最有趣的部分，就是如何让机器“看懂”网页并精准填表。

用 ChromeDriver 实现无感提交：不只是 click 和 send_keys

很多人以为自动化就是简单地.find_element().send_keys()，但实际上真实环境远比想象复杂。网络延迟、动态加载、验证码、权限校验都可能让脚本中途失败。

以下是一个经过生产验证的自动化脚本示例，加入了容错机制和等待策略：

from selenium import webdriver from selenium.webdriver.common.by import By from selenium.webdriver.support.ui import WebDriverWait from selenium.webdriver.support import expected_conditions as EC import time import logging logging.basicConfig(level=logging.INFO) logger = logging.getLogger(__name__) def submit_training_task(): options = webdriver.ChromeOptions() options.add_argument("--headless") # 生产环境中通常启用无头模式 options.add_argument("--no-sandbox") options.add_argument("--disable-dev-shm-usage") options.add_argument("--disable-gpu") driver = None try: driver = webdriver.Chrome(options=options) driver.get("http://localhost:8080/train") # 显式等待元素可交互 wait = WebDriverWait(driver, 10) model_input = wait.until(EC.element_to_be_clickable((By.NAME, "model"))) # 填写表单 model_input.send_keys("qwen3-vl-7b") driver.find_element(By.NAME, "dataset").send_keys("/data/daily_vl_train.jsonl") driver.find_element(By.NAME, "method").send_keys("lora") driver.find_element(By.NAME, "batch_size").send_keys("8") driver.find_element(By.NAME, "epochs").send_keys("3") # 提交前滚动到按钮位置（防止被遮挡） submit_btn = driver.find_element(By.ID, "submit-btn") driver.execute_script("arguments[0].scrollIntoView();", submit_btn) time.sleep(1) # 防止滚动未完成 submit_btn.click() # 等待响应提示出现 success_msg = wait.until(EC.presence_of_element_located((By.CLASS_NAME, "success"))) assert "任务已提交" in success_msg.text logger.info("训练任务提交成功") except Exception as e: logger.error(f"任务提交失败: {str(e)}") if driver: driver.save_screenshot("error_screenshot.png") # 便于排查 raise finally: if driver: driver.quit() if __name__ == "__main__": submit_training_task()

这段代码有几个值得注意的设计点：

使用WebDriverWait而非time.sleep()，避免因网络波动导致超时或等待不足；
添加截图功能，在失败时保留现场证据；
启用无头模式的同时保留调试信息输出，兼顾效率与可观测性；
通过 JavaScript 主动滚动确保按钮可见，规避前端布局问题。

这样的脚本可以轻松接入 cron 定时任务或 Airflow 工作流，实现每日定时训练。

后端如何对接 ms-swift？配置即代码

当表单数据被提交后，后端服务需要做一件事：将表单字段映射为 ms-swift 可识别的 YAML 配置文件。

例如，前端传来的 JSON 数据可能是这样：

{ "model": "qwen3-vl-7b", "dataset": "/data/daily_vl_train.jsonl", "method": "lora", "batch_size": 8, "epochs": 3 }

后端将其转换为标准配置文件：

model: qwen3-vl-7b train_type: lora dataset: - /data/daily_vl_train.jsonl per_device_train_batch_size: 8 num_train_epochs: 3 lora_rank: 64 lora_alpha: 16 output_dir: /models/qwen3-vl-7b-lora-daily logging_steps: 10 save_steps: 100 template: qwen

然后执行：

swift sft --config config.yaml

这里的关键在于，所有参数都有明确的默认值和映射规则。比如method=lora对应启用 LoRA 微调，系统会自动注入LoRAConfig；如果是full，则切换为全量微调。这种“配置即代码”的思想，使得整个流程高度可复现、易版本控制。

轻量微调为何如此重要？9GB 显存跑通 7B 模型

为什么我们要执着于自动化 LoRA 训练？因为它真正实现了“平民化微调”。

以 QLoRA 为例，通过 4-bit 量化 + LoRA 的组合，7B 参数级别的模型仅需约 9GB GPU 显存即可完成微调。这意味着 RTX 3090、4090 这类消费级显卡也能胜任企业级模型优化任务。

from swift import LoRAConfig, get_peft_model lora_config = LoRAConfig( r=64, lora_alpha=16, target_modules=["q_proj", "v_proj"], lora_dropout=0.05, bias="none" ) model = get_peft_model(base_model, lora_config)

在这个配置下，实际可训练参数仅占原始模型的不到 1%，却能在多个下游任务上达到接近全量微调的效果。更重要的是，推理时这些增量权重可以直接合并回原模型，不带来任何额外开销。

这也解释了为何自动化系统倾向于优先支持 LoRA 类任务——成本低、速度快、风险小，非常适合高频迭代。

分布式训练的支持：不只是单卡玩具

当然，不是所有任务都能在单卡完成。对于 70B 级别的大模型，或者需要处理超长上下文（如 32K tokens）的场景，就必须引入分布式训练。

ms-swift 对 Megatron 并行体系的支持非常完善。你可以通过 YAML 文件定义复杂的并行策略：

parallel: tensor_model_parallel_size: 4 pipeline_model_parallel_size: 2 sequence_parallel: true optimizer: type: AdamW lr: 1e-5 quantization: type: fp8 module_kwargs: enable_fp8_wgrad: true

上述配置表示使用 TP=4、PP=2 的混合并行，并开启序列并行以降低显存峰值。结合 FP8 量化，可在保证精度的前提下进一步提升吞吐。

这类高级配置也可以通过 Web 表单暴露给高级用户，只需增加“是否启用张量并行”、“并行度设置”等选项，后端根据勾选情况动态生成配置片段即可。

多模态与 Agent 训练：未来的自动化方向

随着 AI 应用向智能体（Agent）演进，训练任务本身也在变得复杂。现在的模型不仅要回答问题，还要能调用工具、制定计划、执行动作。

ms-swift 已经支持 Agent 数据格式的训练。例如以下结构化的 JSONL 样本：

{ "messages": [ {"role": "system", "content": "你是一个能使用工具的助手"}, {"role": "user", "content": "查询北京天气"}, {"role": "assistant", "tool_calls": [{"name": "get_weather", "arguments": {"city": "Beijing"}}]} ], "tools": [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": {"city": {"type": "string"}} } } } ] }

框架会自动解析tool_calls字段，构造监督信号来训练模型生成正确的函数调用行为。这种能力一旦纳入自动化训练流程，就意味着我们可以定期更新企业的“数字员工”，使其始终掌握最新的业务工具。