使用真实世界任务评估 Nemotron 3.5 Bolt

我评估新模型的方法是，把可信模型已经完成的实际工作任务交给它们，再比较结果。我通常会先在 Gemini 中规划任务/需求，并创建一份 Markdown 规格说明，列出需要完成的工作及验收标准，然后直接把它粘贴到一个全新的 pi.dev 会话中，让模型照着执行。这次，我给 Nemotron 3.5 Bolt 安排了两个任务，这两个任务此前已由 Qwen Flash Next（UD-IQ4_XS，llama.cpp）完成，属于我实际工作（数据工程师）中正在进行的一项 ETL 重构。两个任务都不是那种“试图包办一切”的庞大任务，但很能代表我交给大语言模型处理的工作类型。两个任务的总体要求是：1. 重构 run.sh 脚本，使其符合 run-new.sh 中定义的设计模式、标志管理、结构化日志记录和 AWS SNS 错误处理方式，同时保留现有的 Python 虚拟环境（venv）解析逻辑。2. 创建一个名为 orchestrator.py 的 Python 脚本，生成一系列时间窗口（根据运行时参数按天或按月划分），并依次为每个窗口调用 run.sh。再强调一次，这两个任务都不算特别困难或繁重，但都是我经常遇到的事情：更新脚本以符合客户采用的既有模式，以及将某项任务自动化。新模型完成工作后，我会把规格说明、所有相关文件（原始 run.sh 和 run-new.sh），以及两个模型的结果一起交给 Gemini，让它评估表现并选出优胜者。在任务 #1（run.sh 重构）中，Gemini 认为 Nemotron 做得更好。以下是 Gemini 根据规格说明中的要求，对重构脚本所做的详细比较，模型 1 是 Nemotron，模型 2 是 Qwen Flash Next：``文本 1. 目录路径处理（LOG_DIR 与 SCRIPT_DIR）- 模型 1：在顶部定义 SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"，并将 $SCRIPT_DIR/logs 用作 LOG_DIR。这保证了无论从哪里调用脚本，日志都会创建在相对于脚本目录的位置。- 模型 2：在顶部定义 LOG_DIR="$(pwd)/logs"，直到文件后面才定义 SCRIPT_DIR。如果用户从 /tmp 调用 /path/to/run.sh，模型 2 会将日志创建在 /tmp/logs`，而不是应用程序目录中。标志解析与参数转发 两个模型都使用 while/case 循环实现了相同且健壮的参数解析器，能够正确解析所有必需的标志（-o、-x、-s、-e、-i、-b、-h、-d）及其对应的长格式选项。两个模型都没有不必要地将命令行参数导出为环境变量，严格遵守了要求 2。错误处理、陷阱与进程执行 依赖检查：模型 1 在重定向输出之前，会检查必需的二进制程序（tee、aws）是否存在。模型 2 则在检查 tee 是否存在之前，就使用进程替换 >(tee -a ...) 重定向输出。- `exec` 的行为：- `run-old.sh` 使用了 `exec "$VENV/bin/python" ...`。- 模型 2 保留了 `exec`，但由于 `exec` 会用 Python 替换正在运行的 shell 进程，因此 Python 执行结束时，shell 中定义的任何 `trap ... EXIT` 都不会执行。- 模型 1 移除了 `exec`，将 Python 作为子进程调用，使 shell 陷阱能够在退出时正常完成清理。结论 模型 1（run-model1.sh）的重构更出色。它符合所有验收标准，正确地将日志目录定位在 SCRIPT_DIR 下而不是 pwd 下，合理安排了初始化任务的顺序（在使用进程替换之前检查 tee），并且妥善管理了陷阱。``` 在任务 #2（编写 orchestrator.py）中，Gemini 认为 Qwen Flash Next 做得更好。以下是 Gemini 根据规格说明中的要求，对 Python 脚本所做的详细比较，模型 1 是 Nemotron，模型 2 是 Qwen Flash Next：``文本 1. 规格符合性（subprocess.run）- 模型 1：使用 subprocess.Popen，并设置 stdout=subprocess.PIPE 和 stderr=subprocess.STDOUT，实现流式管道输出。虽然这种方式可以流式输出日志，但它需要手动管理进程读取循环，并手动检查返回码。- 模型 2：严格遵循规格要求，使用 subprocess.run(cmd, check=True)`。由于没有指定流捕获参数，子进程会直接继承父进程的 stdout/stderr，实时输出日志，同时让 Python 妥善处理进程生命周期。健壮性与文件路径处理 模型 1：假定 ./run.sh 的位置是相对于执行脚本时的当前工作目录（CWD）。模型 2：相对于脚本自身所在目录解析 run.sh 的路径（Path(__file__).resolve().parent / "run.sh"）。它会在执行任何逻辑之前检查 run.sh 是否存在，如果不存在，就抛出明确的错误。参数解析与验证 模型 1：先将参数解析为原始字符串，然后在 main() 中尝试调用 parse_timestamp()。模型 2：直接将 type=parse_timestamp 传给 parser.add_argument()，让 argparse 在解析期间自动抛出符合惯例的命令行错误（ArgumentTypeError）。日志记录与用户体验 模型 1：运行各个窗口之前，不会打印任何进度提示。模型 2：添加了清晰的日志，显示找到的窗口总数、各个窗口的执行标记（=== 窗口 X/Y ===），以及将要执行的命令预览。结论 模型 2** 的实现更出色。两个实现都满足核心规格要求，但模型 2 明显更简洁、更健壮，也更严格地遵守了提示词的要求。它精确遵循规格中的 subprocess.run(check=True)，安全地处理路径解析，使用恰当的 argparse 类型，并在多窗口批量执行过程中提供了更好的终端反馈。``` 我的结论是，Nemotron 3.5 Bolt 有能力胜任我的工作，而且它在我的服务器上运行得很快，我看到的平均速度约为 130 token/秒，一个 2 位量化模型能达到这种表现，令人印象深刻。我不会用它替代 Qwen Flash Next，尤其是在大型、复杂的仓库级任务上，但对于那些我希望快速完成、又不想让模型过度思考的轻到中等难度任务，它很可能会取代 Gemma4-31B。我很快就会买一台 M5 Mac Studio，想搭建智能体/子智能体工作流。我觉得 Bolt 可能会是一个很好的子智能体，由 Qwen Flash Next（希望到时是 Qwen4）向它传递规格说明，让它负责实现。