[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"similar-NVIDIA--runx":3,"tool-NVIDIA--runx":64},[4,17,27,35,43,56],{"id":5,"name":6,"github_repo":7,"description_zh":8,"stars":9,"difficulty_score":10,"last_commit_at":11,"category_tags":12,"status":16},3808,"stable-diffusion-webui","AUTOMATIC1111\u002Fstable-diffusion-webui","stable-diffusion-webui 是一个基于 Gradio 构建的网页版操作界面，旨在让用户能够轻松地在本地运行和使用强大的 Stable Diffusion 图像生成模型。它解决了原始模型依赖命令行、操作门槛高且功能分散的痛点，将复杂的 AI 绘图流程整合进一个直观易用的图形化平台。\n\n无论是希望快速上手的普通创作者、需要精细控制画面细节的设计师，还是想要深入探索模型潜力的开发者与研究人员，都能从中获益。其核心亮点在于极高的功能丰富度：不仅支持文生图、图生图、局部重绘（Inpainting）和外绘（Outpainting）等基础模式，还独创了注意力机制调整、提示词矩阵、负向提示词以及“高清修复”等高级功能。此外，它内置了 GFPGAN 和 CodeFormer 等人脸修复工具，支持多种神经网络放大算法，并允许用户通过插件系统无限扩展能力。即使是显存有限的设备，stable-diffusion-webui 也提供了相应的优化选项，让高质量的 AI 艺术创作变得触手可及。",162132,3,"2026-04-05T11:01:52",[13,14,15],"开发框架","图像","Agent","ready",{"id":18,"name":19,"github_repo":20,"description_zh":21,"stars":22,"difficulty_score":23,"last_commit_at":24,"category_tags":25,"status":16},1381,"everything-claude-code","affaan-m\u002Feverything-claude-code","everything-claude-code 是一套专为 AI 编程助手（如 Claude Code、Codex、Cursor 等）打造的高性能优化系统。它不仅仅是一组配置文件，而是一个经过长期实战打磨的完整框架，旨在解决 AI 代理在实际开发中面临的效率低下、记忆丢失、安全隐患及缺乏持续学习能力等核心痛点。\n\n通过引入技能模块化、直觉增强、记忆持久化机制以及内置的安全扫描功能，everything-claude-code 能显著提升 AI 在复杂任务中的表现，帮助开发者构建更稳定、更智能的生产级 AI 代理。其独特的“研究优先”开发理念和针对 Token 消耗的优化策略，使得模型响应更快、成本更低，同时有效防御潜在的攻击向量。\n\n这套工具特别适合软件开发者、AI 研究人员以及希望深度定制 AI 工作流的技术团队使用。无论您是在构建大型代码库，还是需要 AI 协助进行安全审计与自动化测试，everything-claude-code 都能提供强大的底层支持。作为一个曾荣获 Anthropic 黑客大奖的开源项目，它融合了多语言支持与丰富的实战钩子（hooks），让 AI 真正成长为懂上",138956,2,"2026-04-05T11:33:21",[13,15,26],"语言模型",{"id":28,"name":29,"github_repo":30,"description_zh":31,"stars":32,"difficulty_score":23,"last_commit_at":33,"category_tags":34,"status":16},2271,"ComfyUI","Comfy-Org\u002FComfyUI","ComfyUI 是一款功能强大且高度模块化的视觉 AI 引擎，专为设计和执行复杂的 Stable Diffusion 图像生成流程而打造。它摒弃了传统的代码编写模式，采用直观的节点式流程图界面，让用户通过连接不同的功能模块即可构建个性化的生成管线。\n\n这一设计巧妙解决了高级 AI 绘图工作流配置复杂、灵活性不足的痛点。用户无需具备编程背景，也能自由组合模型、调整参数并实时预览效果，轻松实现从基础文生图到多步骤高清修复等各类复杂任务。ComfyUI 拥有极佳的兼容性，不仅支持 Windows、macOS 和 Linux 全平台，还广泛适配 NVIDIA、AMD、Intel 及苹果 Silicon 等多种硬件架构，并率先支持 SDXL、Flux、SD3 等前沿模型。\n\n无论是希望深入探索算法潜力的研究人员和开发者，还是追求极致创作自由度的设计师与资深 AI 绘画爱好者，ComfyUI 都能提供强大的支持。其独特的模块化架构允许社区不断扩展新功能，使其成为当前最灵活、生态最丰富的开源扩散模型工具之一，帮助用户将创意高效转化为现实。",107662,"2026-04-03T11:11:01",[13,14,15],{"id":36,"name":37,"github_repo":38,"description_zh":39,"stars":40,"difficulty_score":23,"last_commit_at":41,"category_tags":42,"status":16},3704,"NextChat","ChatGPTNextWeb\u002FNextChat","NextChat 是一款轻量且极速的 AI 助手，旨在为用户提供流畅、跨平台的大模型交互体验。它完美解决了用户在多设备间切换时难以保持对话连续性，以及面对众多 AI 模型不知如何统一管理的痛点。无论是日常办公、学习辅助还是创意激发，NextChat 都能让用户随时随地通过网页、iOS、Android、Windows、MacOS 或 Linux 端无缝接入智能服务。\n\n这款工具非常适合普通用户、学生、职场人士以及需要私有化部署的企业团队使用。对于开发者而言，它也提供了便捷的自托管方案，支持一键部署到 Vercel 或 Zeabur 等平台。\n\nNextChat 的核心亮点在于其广泛的模型兼容性，原生支持 Claude、DeepSeek、GPT-4 及 Gemini Pro 等主流大模型，让用户在一个界面即可自由切换不同 AI 能力。此外，它还率先支持 MCP（Model Context Protocol）协议，增强了上下文处理能力。针对企业用户，NextChat 提供专业版解决方案，具备品牌定制、细粒度权限控制、内部知识库整合及安全审计等功能，满足公司对数据隐私和个性化管理的高标准要求。",87618,"2026-04-05T07:20:52",[13,26],{"id":44,"name":45,"github_repo":46,"description_zh":47,"stars":48,"difficulty_score":23,"last_commit_at":49,"category_tags":50,"status":16},2268,"ML-For-Beginners","microsoft\u002FML-For-Beginners","ML-For-Beginners 是由微软推出的一套系统化机器学习入门课程，旨在帮助零基础用户轻松掌握经典机器学习知识。这套课程将学习路径规划为 12 周，包含 26 节精炼课程和 52 道配套测验，内容涵盖从基础概念到实际应用的完整流程，有效解决了初学者面对庞大知识体系时无从下手、缺乏结构化指导的痛点。\n\n无论是希望转型的开发者、需要补充算法背景的研究人员，还是对人工智能充满好奇的普通爱好者，都能从中受益。课程不仅提供了清晰的理论讲解，还强调动手实践，让用户在循序渐进中建立扎实的技能基础。其独特的亮点在于强大的多语言支持，通过自动化机制提供了包括简体中文在内的 50 多种语言版本，极大地降低了全球不同背景用户的学习门槛。此外，项目采用开源协作模式，社区活跃且内容持续更新，确保学习者能获取前沿且准确的技术资讯。如果你正寻找一条清晰、友好且专业的机器学习入门之路，ML-For-Beginners 将是理想的起点。",84991,"2026-04-05T10:45:23",[14,51,52,53,15,54,26,13,55],"数据工具","视频","插件","其他","音频",{"id":57,"name":58,"github_repo":59,"description_zh":60,"stars":61,"difficulty_score":10,"last_commit_at":62,"category_tags":63,"status":16},3128,"ragflow","infiniflow\u002Fragflow","RAGFlow 是一款领先的开源检索增强生成（RAG）引擎，旨在为大语言模型构建更精准、可靠的上下文层。它巧妙地将前沿的 RAG 技术与智能体（Agent）能力相结合，不仅支持从各类文档中高效提取知识，还能让模型基于这些知识进行逻辑推理和任务执行。\n\n在大模型应用中，幻觉问题和知识滞后是常见痛点。RAGFlow 通过深度解析复杂文档结构（如表格、图表及混合排版），显著提升了信息检索的准确度，从而有效减少模型“胡编乱造”的现象，确保回答既有据可依又具备时效性。其内置的智能体机制更进一步，使系统不仅能回答问题，还能自主规划步骤解决复杂问题。\n\n这款工具特别适合开发者、企业技术团队以及 AI 研究人员使用。无论是希望快速搭建私有知识库问答系统，还是致力于探索大模型在垂直领域落地的创新者，都能从中受益。RAGFlow 提供了可视化的工作流编排界面和灵活的 API 接口，既降低了非算法背景用户的上手门槛，也满足了专业开发者对系统深度定制的需求。作为基于 Apache 2.0 协议开源的项目，它正成为连接通用大模型与行业专有知识之间的重要桥梁。",77062,"2026-04-04T04:44:48",[15,14,13,26,54],{"id":65,"github_repo":66,"name":67,"description_en":68,"description_zh":69,"ai_summary_zh":69,"readme_en":70,"readme_zh":71,"quickstart_zh":72,"use_case_zh":73,"hero_image_url":74,"owner_login":75,"owner_name":76,"owner_avatar_url":77,"owner_bio":78,"owner_company":79,"owner_location":79,"owner_email":79,"owner_twitter":79,"owner_website":80,"owner_url":81,"languages":82,"stars":87,"forks":88,"last_commit_at":89,"license":90,"difficulty_score":23,"env_os":91,"env_gpu":92,"env_ram":91,"env_deps":93,"category_tags":99,"github_topics":79,"view_count":23,"oss_zip_url":79,"oss_zip_packed_at":79,"status":16,"created_at":100,"updated_at":101,"faqs":102,"releases":133},3084,"NVIDIA\u002Frunx","runx","Deep Learning Experiment Management","runx 是一款专为深度学习研究设计的实验管理工具，旨在自动化科研过程中的重复性任务。它核心解决了研究人员在进行超参数搜索时手动编写脚本的繁琐问题，通过简单的 YAML 配置文件，即可自动计算参数组合并生成对应的执行命令。此外，runx 还能统一管理日志、TensorBoard 可视化及模型检查点，并为每次实验自动创建独立的输出目录，有效避免了文件覆盖冲突。\n\n该工具特别适合 AI 研究员和深度学习开发者使用，尤其是那些需要在本地或集群农场（Farm）上批量运行大量实验的用户。runx 的独特亮点在于其灵活的架构：既支持交互式快速验证，也能无缝对接集群调度系统，根据预设的资源配置（如 GPU、内存）自动提交批量作业。配合内置的 logx 和 sumx 模块，用户还能轻松实现实验结果的汇总与分析。\n\n需要注意的是，该项目目前已停止维护且存在已知安全漏洞，官方建议使用者在充分评估风险的前提下谨慎采用，或将其作为理解实验管理流程的参考案例。","## ⚠️ NOTICE: End of Life\n\n**This project is no longer maintained and contains security vulnerabilities. No further updates or security patches will be provided. Use at your own risk.**\n\n# runx - An experiment management tool\n\n`runx` helps to automate common tasks while doing research:\n* hyperparameter sweeps\n* logging, tensorboard, checkpoint management\n* experiment summarization\n* code checkpointing\n* unique, per-run, directory creation\n\n# Table of Contents\n- [Quick-start Installation](#quick-start-installation)\n- [Introduction: a simple example](#introduction--a-simple-example)\n- [runx Architecture](#runx-architecture)\n- [Create a project-specific configuration file](#create-a-project-specific-configuration-file)\n- [Run directory, logfiles](#run-directory--logfiles)\n- [Experiment yaml details](#experiment-yaml-details)\n  * [Booleans](#booleans)\n  * [Lists, Inheritance](#lists--inheritance)\n- [logx - logging, tensorboarding, checkpointing](#logx---logging--tensorboarding--checkpointing)\n- [sumx - summarizing your runs](#sumx---summarizing-your-runs)\n- [NGC Support](#ngc-support)\n\n## Quick-start Installation\n\nInstall with pip:\n```\n> pip install runx\n```\n\nInstall with source:\n```\n> git clone https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\n> cd runx\n> python setup.py .\n```\n\n## Introduction example\nSuppose you have an existing project that you call as follows:\n\n```bash\n> python train.py --lr 0.01 --solver sgd\n```\nTo run a hyperparameter sweep, you'd normally have to code up a one-off script to generate the sweep. But with runx, you would simply define a yaml that defines lists of hyperparams that you'd like to use.\n\nStart by creating a yaml file called `sweep.yml`:\n```yml\nCMD: 'python train.py'\n\nHPARAMS:\n  lr: [0.01, 0.02]\n  solver: ['sgd', 'adam']\n```\n\nNow you can run the sweep with runx:\n\n```bash\n > python -m runx.runx sweep.yml -i\n\npython train.py --lr 0.01 --solver sgd\npython train.py --lr 0.01 --solver adam\npython train.py --lr 0.02 --solver sgd\npython train.py --lr 0.02 --solver adam \n```\nYou can see that runx automatically computes the cross product of all hyperparameters, which in this case results in 4 runs. It then builds commandlines by concatenating the hyperparameters with the training command.\n\nA few useful runx options:\n```\n-n     don't run, just print the command\n-i     interactive mode (as opposed to submitting jobs to a farm)\n```\n### runx is especially useful to launch batch jobs to a farm. \n\nFarm support is simple. First create a .runx file that configures the farm:\n```yaml\nLOGROOT: \u002Fhome\u002Flogs\nFARM: bigfarm\n\nbigfarm:\n  SUBMIT_CMD: 'submit_job'\n  RESOURCES:\n     gpu: 2\n     cpu: 16\n     mem: 128\n```\n**LOGROOT**: this is where the output of runs should go\n**FARM**: you can define multiple farm targets. This selects which one to use\n**SUBMIT_CMD**: the script you use to launch jobs to a farm\n**RESOURCES**: the arguments to present to SUBMIT_CMD\n\nNow when you run runx, it will generate commands that will attempt to launch jobs to a farm using your SUBMIT_CMD. Notice that we left out the `-i` cmdline arg because now we want to submit jobs and not run them interactively.\n\n```bash\n> python -m runx.runx sweep.yml\n\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.01 --solver sgd\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.01 --solver adam\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.02 --solver sgd\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.02 --solver adam\"\n```\n\n### Unique run directories\nWe want the results for each training run to go into a unique output\u002Flog directory.  We don't want things like tensorboard files or logfiles to write over each other. `runx` solves this problem by automatically generating a unique output directory per run. \n\nYou have access to this unique directory name within your experiment yaml via the special variable: `LOGDIR`. Your training\nscript may use this path and write its output there.\n\n```yml\nCMD: 'python train.py'\n\nHPARAMS:\n  lr: [0.01, 0.02]\n  solver: ['sgd', 'adam']\n  logdir: LOGDIR\n```\n\nIn the above experiment yaml, we have passed LOGDIR as an argument to your training script. When we launch the jobs, runx automatically generates unique output directories and passes the paths to your training script:\n\n```bash\n> python -m runx.runx sweep.yml\n\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.01 --solver sgd  --logdir \u002Fhome\u002Flogs\u002Fathletic-wallaby_2020.02.06_14.19\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.01 --solver adam  --logdir \u002Fhome\u002Flogs\u002Findustrious-chicken_2020.02.06_14.19\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.02 --solver sgd  --logdir \u002Fhome\u002Flogs\u002Farrogant-buffalo_2020.02.06_14.19\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.02 --solver adam  --logdir \u002Fhome\u002Flogs\u002Fvengeful-jaguar_2020.02.06_14.19\"\n```\n\n## Summarization with sumx\nAfter you've run your experiment, you will likely want to summarize the results.  You might want to know:\n* Which training run was best?\n* How long was an epoch\n* What about other metrics?\n\nYou summarize your runs with on the commandline with `sumx`. All you need to do is tell `sumx` which experiment you want summarized. `sumx` knows what your LOGROOT (it'll get that from the .runx file) and so it looks within that directory for your experiment directory.\n\nIn the following example, we ask `sumx` to summarize the `sweep` experiment.\n\n```bash\n> python -m runx.sumx sweep --sortwith acc\n\n        lr    solver  acc   epoch  epoch_time\n------\t----  ------  ----  -----  ----------\nrun4    0.02  adam    99.1   10     5:11\nrun3    0.02  sgd     99.0   10     5:05\nrun1    0.01  sgd     98.2   10     5:15\nrun2    0.01  adam    98.1   10     5:12\n```\n`sumx` is part of the runx suite, and is able to summarize the different hyperparmeters used as well as the metrics\u002Fresults of your runs. Notice that we used the --sortwith feature of sumx, which sorts your results so you can easily locate your best runs.\n\nThis is the basic idea.\nThe following sections will go into more details about all the various features.\n\n## runx Architecture\nrunx consists of three main modules:\n\n* **runx**\n  * Launch sweeps of training runs using a concise yaml format that allows for multiple values for each hyperparameter\n  * In particular, when you call runx:\n    * Calculate cross product of all hyperparameters -> runs\n\t* For each run, create an output directory, copy your code there, and then launch the training command\n* **logx**\n  * Logging of metrics, messages, checkpoints, tensorboard\n* **sumx**\n  * Summarize the results of training runs, showing results and unique hyperparameters\n\nThese modules are intended to be used jointly, but if you just want to use runx, that's fine.\nHowever using sumx requires that you've used logx to record metrics.\n\n\n## Create a project-specific configuration file\nIn order to use `runx`, you need to create a configuration file in the directory where you'll call the `runx` CLI.\n\nThe .runx file defines a number of critical fields:\n* `LOGROOT` - the root directory where you want your logs placed. This is a path that any farm job can write to.\n* `FARM` - if defined, jobs should be submitted to this farm, else run interactively\n* For a given farm, these fields are required:\n  + `SUBMIT_CMD` - the farm submission command\n  + `RESOURCES` - hyperparameters passed to the `SUBMIT_CMD`. You can list any number of these items, the ones shown below are just examples.\n* `CODE_IGNORE_PATTERNS` - ignore these files patterns when copying code to output directory\n\nHere's an example of such a file:\n\n```yaml\nLOGROOT: \u002Fhome\u002Flogs\nCODE_IGNORE_PATTERNS: '.git,*.pyc,docs*,test*'\nFARM: bigfarm\n\n# Farm resource needs\nbigfarm:\n    SUBMIT_CMD: 'submit_job'\n    RESOURCES:\n        image: mydocker-image-big:1.0\n        gpu: 8\n        cpu: 64\n        mem: 450\n\nsmallfarm:\n    SUBMIT_CMD: 'submit_small'\n    RESOURCES:\n        image: mydocker-image-small:1.2\n        gpu: 4\n        cpu: 32\n        mem: 256\n```\n\n## Run directory, logfiles\n\nrunx has two level of experiment hierarchy: **experiments** and **runs**. An `experiment` corresponds to a single yaml file, which may contain many `runs`.\n\n`runx` creates both a parent experiment directory and a unique subdirectory for each run. The name of the experiment directory is `LOGROOT\u002F\u003Cexperiment name>`, so in the example of sweep.yml, the experiment name is `sweep`, derived from the yaml filename.\n\nFor example, this might be the directory structure for the sweep study:\n```bash\n\u002Fhome\u002Flogs\n  sweep\u002F\n     curious-rattlesnake_2020.02.06_14.19\u002F\n     ambitious-lobster_2020.02.06_14.19\u002F\n     ...\n```\n\nThe individual run directories are named with a combination of `coolname` and date. The use of `coolname` makes it much easier to refer to a given run than referring to a date code.\n\nIf you include the RUNX.TAG field in your experiment yaml or if you supply the --tag argument to the `runx` CLI, the names will include that tag.\n\n## Staging of code\n`runx` actually makes a copy of your code within each run's log directory. This is done for a number of reasons:\n* If you wish to continue modifying your code, while a training run is going on, you may do so without worry whether it will affect the running job(s)\n* In case your job dies and you must restart it, the code and training environment is self-contained within the logdir of a run.\n* This is also useful for documentation purposes: in case you ever want to know exactly the state of the code for a given run. \n\n\n## Experiment yaml details\n\n### Special variables\n**CMD** - Your base training command. You typically don't include any args here.\n**HPARAMS** - All hyperparmeters. This is a datastructure that may either be a simple dict of params or may be a list of dicts. Furthermore, each hyperparameter may be a scalar or list or boolean.\n**PYTHONPATH** - This is field optional. For the purpose of altering the default PYTHONPATH which is simply LOGDIR\u002Fcode. Can be a colon-separated list of paths. May include LOGDIR special variable. \n\n### HPARAMS\n\n#### A simple example of HPARAMS is:\n```yaml\nCMD: \"python train.py\"\n\nHPARAMS:\n  logdir: LOGDIR\n  adam: true\n  arch: alexnet\n  lr: [0.01, 0.02]\n  epochs: 10\n  RUNX.TAG: 'alexnet'\n```\nHere, there will be 2 runs that will be created. \n\n### Booleans\nIf you want to specify that a boolean flag should be on or off, this is done using `true` and `false` keywords:\n  ```\n  some_flag: [true, false]\n  ```\nThis would result having one run with `--some_flag` and another run without that flag\n\nIf instead you want to pass an actual string, you could instad do the following:\n```\n  some_arg: ['True', 'False']\n```\nThis would result in one run with `--some_arg True` and other run with `--some_arg False`\n\nIf you'd like an argument to not be passed into your script at all, you can set it to `None`\n```\n  some_arg: None\n```\n\n### Lists, Inheritance\nOftentimes, you might want to define separate lists of hyperparameters in your experiment.\nFor example:\n 1. arch = alexnet with lr=[0.01, 0.02]\n 2. arch = resnet50 with lr=[0.002, 0.005]\n\nYou can do this with hparams defined as follows:\n```yaml\nPYTHONPATH: LOGDIR\u002Fcode:LOGDIR\u002Fcode\u002Flib\nCMD: \"python train.py\"\n\nHPARAMS: [\n  {\n   logdir: LOGDIR,\n   adam: true,\n   arch: alexnet,\n   lr: [0.01, 0.02],\n   epochs: 10,\n   RUNX.TAG: 'alexnet',\n  },\n  {\n   arch: resnet50,\n   lr: [0.002, 0.005],\n   RUNX.TAG: 'resnet50',\n  },\n  {\n   RUNX.SKIP: true,\n   arch: resnet50,\n   lr: [0.002, 0.005],\n   RUNX.TAG: 'resnet50',\n  }\n]\n```\nYou might observe that hparams is now a list of two dicts. \nThe nice thing is that runx assumes inheritance from the first item in the list to all remaining dicts, so that you don't have to re-type all the redundant hyperparms.\n\nWhen you pass this yaml to runx, you'll get the following out:\n\n``` bash\nsubmit_job ... --name alexnet_2020.02.06_6.32  -c \"python train.py --logdir ... --lr 0.01 --adam --arch alexnet --epochs 10\nsubmit_job ... --name alexnet_2020.02.06_6.40  -c \"python train.py --logdir ... --lr 0.02 --adam --arch alexnet --epochs 10\nsubmit_job ... --name resnet50_2020.02.06_6.45 -c \"python train.py --logdir ... --lr 0.002 --adam --arch resnet50 --epochs 10\nsubmit_job ... --name resnet50_2020.02.06_6.50 -c \"python train.py --logdir ... --lr 0.005 --adam --arch resnet50 --epochs 10\n```\nBecause of inheritance, adam, arch, and epochs params are set identically in each run.\n\nThis is also showing the use of the magic variable `RUNX.TAG`, which allows you to add a tag to a subset of your experiment. This is the same as if you'd used the --tag \u003Ctagname> option to runx.py, except that here you can specify the tag within the hparams data structure. The value of `RUNX.TAG` is not passed to your training script.\n\nA very useful feature of RUNX.TAG is that you can reference other hyperparameters, for example:\n\n``` yaml\n   arch: resnet50,\n   RUNX.TAG: '{arch}-lrstudy'\n```\n\nThis results in the tag becoming `resnet50-lrstudy`. `runx` performs simple string matching and substitution when it finds curly braces.\n\n## logx - logging, tensorboarding, checkpointing\nIn order to use sumx, you need to export metrics with logx.\nlogx helps to write metrics in a canonical way, so that sumx can summarize the results.\n\nlogx can also make it easy for you to output log information to a file (and stdout)\nlogx can also manage saving of checkpoints automatically, with the benefit being that logx will keep around only the latest and best checkpoints, saving much disk space.\n\nThe basic way you use logx is to modify your training code in the following ways:\n\nAt the top of your training script (or any module that calls logx functions:\n```python\nfrom runx.logx import logx\n```\n\nBefore using logx, you must initialize it as follows:\n```python\n   logx.initialize(logdir=args.logdir, coolname=True, tensorboard=True)\n```\nMake sure that you're only calling logx from rank=0, in the event that you're using distributed data parallel.\n\n\nThen, substitute the following logx calls into your code:\n\n| From                | To                | What                      |\n| ------------------- | ----------------- | ------------------------- |\n| print()             | logx.msg()        | stdout messages           |\n| writer.add_scalar() | logx.add_scalar() | tensorboard scalar writes |\n| writer.add_image()  | logx.add_image()  | tensorboard image writes  |\n|                     | logx.save_model() | save latest\u002Fbest models   |\n\nFinally, in order for sumx to be able to read the results of your run, you have to push your metrics to logx. You should definitely push the 'val' metrics, but can push 'train' metrics if you like (sumx doesn't consume them at the moment). \n\n```python\n# define which metrics to record\nmetrics = {'loss': test_loss, 'accuracy': accuracy}\n# push the metrics to logfile\nlogx.metric(phase='val', metrics=metrics, epoch=epoch)\n```\n\nSome important points of logx.metric():\n* The `phase` argument describes whether the metric is a train or validation metric.\n* You should set idx == epoch for validation metrics. And for training, idx is typically the iteration count.\n\n\nHere's a final feature of logx: saving of the model. This feature helps save not only the latest but also the best model.\n\n```python\nsave_dict = {'epoch': epoch + 1,\n             'arch': args.arch,\n             'state_dict': model.state_dict(),\n             'best_acc1': best_acc1,\n             'optimizer' : optimizer.state_dict()}\nlogx.save_model(save_dict, metric=accuracy, epoch=epoch, higher_better=True)\n```\n\nYou do have to tell save_model whether the metric is better when it's higher or lower.\n\n## sumx - summarizing your runs\n\nsumx summarizes the results of your runs. It requires that you've logged your metrics with logx.metric().\nWe chose this behavior instead of reading Tensorboard files directly because that would be much slower.\n\n``` bash\n> python -m runx.sumx sweep\n        lr    solver  acc   epoch  epoch_time\nrun4    0.02  adam    99.1  10     5:21\nrun3    0.02  sgd     99.0  10     5:02\nrun1    0.01  sgd     98.2  10     5:40\nrun2    0.01  adam    98.1  10     5:25\n```\n\nA few features worth knowing about:\n* use `--sortwith` to sort the output by a particular field (like accuracy) that you care about most\n* sumx tells you what epoch your run is current on\n* sumx tells you the average epoch time, which is handy if you are monitoring training speed\n* use the optional `--ignore` flag to limit what fields sumx prints out\n\n## NGC Support\nNGC support is now standard. Your `.runx` file should look like the following.\n\n```yaml\n\nLOGROOT: \u002Fpath\u002Fto\u002Flogroot\n\nFARM: ngc\n\nngc:\n    NGC_LOGROOT: \u002Fpath\u002Fto\u002Fngc_logroot\n    WORKSPACE: \u003Cyour ngc workspace>\n    SUBMIT_CMD: 'ngc batch run'\n    RESOURCES:\n       image: nvidian\u002Fpytorch:19.10-py3\n       instance: dgx1v.16g.1.norm\n       ace: nv-us-west-2\n       result: \u002Fresult\n```\n\nNecessary steps:\n* Fill out a path to LOGROOT, which is a client-side staging directory for the log directory\n* Create a RW NGC workspace and fill in `WORKSPACE` with it\n* Mount this workspace on your local machine and fill in `NGC_LOGROOT` with this path. When the\n  job is launched, this is also the path used to mount the workspace on the running instance.\n* Fill out any necessary fields under `RESOURCES`. Recall that these parameters are passed on\n  to the `SUBMIT_CMD`, which must be `ngc batch run`.\n\n\nYou should be able to launch jobs to NGC using this configuration. When jobs write their results, you should also be able to see the results in the mounted workspace,\nand then you should be able to run runx.sumx in order to summarize the results of those runs.\n","## ⚠️ 通知：已停止维护\n\n**该项目已不再维护，并且存在安全漏洞。将不会提供进一步的更新或安全补丁。请自行承担使用风险。**\n\n# runx - 一个实验管理工具\n\n`runx` 帮助自动化研究中的常见任务：\n* 超参数扫描\n* 日志记录、TensorBoard、检查点管理\n* 实验总结\n* 代码检查点\n* 为每次运行创建唯一的目录\n\n# 目录\n- [快速入门安装](#快速入门安装)\n- [简介：一个简单示例](#简介--一个简单示例)\n- [runx 架构](#runx架构)\n- [创建项目特定的配置文件](#创建项目特定的配置文件)\n- [运行目录、日志文件](#运行目录--日志文件)\n- [实验 YAML 详细信息](#实验-yaml-详细信息)\n  * [布尔值](#布尔值)\n  * [列表、继承](#列表--继承)\n- [logx - 日志记录、TensorBoard、检查点](#logx---日志记录--tensorboard--检查点)\n- [sumx - 总结你的运行](#sumx---总结你的运行)\n- [NGC 支持](#ngc支持)\n\n## 快速入门安装\n\n使用 pip 安装：\n```\n> pip install runx\n```\n\n从源码安装：\n```\n> git clone https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\n> cd runx\n> python setup.py .\n```\n\n## 简介示例\n假设你有一个现有的项目，你可以通过以下方式运行：\n\n```bash\n> python train.py --lr 0.01 --solver sgd\n```\n通常情况下，要进行超参数扫描，你需要编写一个一次性脚本生成扫描任务。但使用 runx，你只需定义一个 YAML 文件，列出你想要使用的超参数列表即可。\n\n首先创建一个名为 `sweep.yml` 的 YAML 文件：\n```yml\nCMD: 'python train.py'\n\nHPARAMS:\n  lr: [0.01, 0.02]\n  solver: ['sgd', 'adam']\n```\n\n现在你可以使用 runx 运行扫描：\n\n```bash\n > python -m runx.runx sweep.yml -i\n\npython train.py --lr 0.01 --solver sgd\npython train.py --lr 0.01 --solver adam\npython train.py --lr 0.02 --solver sgd\npython train.py --lr 0.02 --solver adam \n```\n可以看到，runx 自动计算了所有超参数的笛卡尔积，在这个例子中产生了 4 次运行。然后它通过将超参数与训练命令拼接来构建命令行。\n\n一些有用的 runx 选项：\n```\n-n     不执行，只打印命令\n-i     交互模式（而不是提交作业到集群）\n```\n### runx 特别适合向集群提交批量作业。\n\n集群支持非常简单。首先创建一个 `.runx` 文件来配置集群：\n```yaml\nLOGROOT: \u002Fhome\u002Flogs\nFARM: bigfarm\n\nbigfarm:\n  SUBMIT_CMD: 'submit_job'\n  RESOURCES:\n     gpu: 2\n     cpu: 16\n     mem: 128\n```\n**LOGROOT**：这是运行输出应该存放的地方\n**FARM**：你可以定义多个集群目标。这里选择使用哪一个\n**SUBMIT_CMD**：用于向集群提交作业的脚本\n**RESOURCES**：传递给 SUBMIT_CMD 的参数\n\n现在当你运行 runx 时，它会生成尝试使用你的 SUBMIT_CMD 向集群提交作业的命令。注意我们省略了 `-i` 命令行参数，因为现在我们是要提交作业，而不是交互式地运行它们。\n\n```bash\n> python -m runx.runx sweep.yml\n\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.01 --solver sgd\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.01 --solver adam\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.02 --solver sgd\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.02 --solver adam\"\n```\n\n### 唯一的运行目录\n我们希望每次训练的结果都保存到一个唯一的输出\u002F日志目录中。我们不希望 TensorBoard 文件或日志文件相互覆盖。`runx` 通过自动为每次运行生成唯一的输出目录来解决这个问题。\n\n你可以在实验 YAML 中通过特殊变量 `LOGDIR` 访问这个唯一目录名。你的训练脚本可以使用该路径并将输出写入其中。\n\n```yml\nCMD: 'python train.py'\n\nHPARAMS:\n  lr: [0.01, 0.02]\n  solver: ['sgd', 'adam']\n  logdir: LOGDIR\n```\n\n在上面的实验 YAML 中，我们将 `LOGDIR` 作为参数传递给了你的训练脚本。当我们启动作业时，runx 会自动生成唯一的输出目录，并将路径传递给你的训练脚本：\n\n```bash\n> python -m runx.runx sweep.yml\n\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.01 --solver sgd  --logdir \u002Fhome\u002Flogs\u002Fathletic-wallaby_2020.02.06_14.19\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.01 --solver adam  --logdir \u002Fhome\u002Flogs\u002Findustrious-chicken_2020.02.06_14.19\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.02 --solver sgd  --logdir \u002Fhome\u002Flogs\u002Farrogant-buffalo_2020.02.06_14.19\"\nsubmit_job --gpu 2 --cpu 16 --mem 128 -c \"python train.py --lr 0.02 --solver adam  --logdir \u002Fhome\u002Flogs\u002Fvengeful-jaguar_2020.02.06_14.19\"\n```\n\n## 使用 sumx 进行总结\n在运行完实验后，你可能希望对结果进行总结。你可能会想知道：\n* 哪次训练效果最好？\n* 每个 epoch 花了多长时间？\n* 其他指标如何？\n\n你可以使用命令行工具 `sumx` 来总结你的运行。你只需要告诉 `sumx` 要总结哪个实验。`sumx` 知道你的 LOGROOT（它会从 `.runx` 文件中获取），因此它会在该目录下查找你的实验目录。\n\n在下面的例子中，我们要求 `sumx` 总结 `sweep` 实验。\n\n```bash\n> python -m runx.sumx sweep --sortwith acc\n\n        lr    solver  acc   epoch  epoch_time\n------\t----  ------  ----  -----  ----------\nrun4    0.02  adam    99.1   10     5:11\nrun3    0.02  sgd     99.0   10     5:05\nrun1    0.01  sgd     98.2   10     5:15\nrun2    0.01  adam    98.1   10     5:12\n```\n`sumx` 是 runx 套件的一部分，能够总结所使用的不同超参数以及你的运行指标和结果。请注意，我们使用了 sumx 的 `--sortwith` 功能，它可以对结果进行排序，以便你轻松找到最佳的运行。\n\n这就是基本思路。\n接下来的部分将更详细地介绍所有功能。\n\n## runx 架构\nrunx 由三个主要模块组成：\n\n* **runx**\n  * 使用简洁的 YAML 格式启动训练运行的扫描，允许每个超参数有多个值\n  * 特别是，当你调用 runx 时：\n    * 计算所有超参数的笛卡尔积 -> 运行次数\n    * 对于每次运行，创建一个输出目录，将你的代码复制到那里，然后启动训练命令\n* **logx**\n  * 记录指标、消息、检查点、TensorBoard\n* **sumx**\n  * 总结训练运行的结果，显示结果和独特的超参数\n\n这些模块旨在一起使用，但如果你只想使用 runx，也是可以的。\n不过，使用 sumx 需要你先使用 logx 记录指标。\n\n## 创建项目专用配置文件\n为了使用 `runx`，您需要在将要调用 `runx` CLI 的目录中创建一个配置文件。\n\n`.runx` 文件定义了若干关键字段：\n* `LOGROOT` - 您希望日志存放的根目录。这是一个任何农场作业都可以写入的路径。\n* `FARM` - 如果已定义，则作业应提交到该农场；否则以交互方式运行。\n* 对于给定的农场，以下字段是必需的：\n  + `SUBMIT_CMD` - 农场提交命令\n  + `RESOURCES` - 传递给 `SUBMIT_CMD` 的超参数。您可以列出任意数量的条目，下面显示的只是示例。\n* `CODE_IGNORE_PATTERNS` - 在将代码复制到输出目录时忽略这些文件模式。\n\n以下是此类文件的示例：\n\n```yaml\nLOGROOT: \u002Fhome\u002Flogs\nCODE_IGNORE_PATTERNS: '.git,*.pyc,docs*,test*'\nFARM: bigfarm\n\n# 农场资源需求\nbigfarm:\n    SUBMIT_CMD: 'submit_job'\n    RESOURCES:\n        image: mydocker-image-big:1.0\n        gpu: 8\n        cpu: 64\n        mem: 450\n\nsmallfarm:\n    SUBMIT_CMD: 'submit_small'\n    RESOURCES:\n        image: mydocker-image-small:1.2\n        gpu: 4\n        cpu: 32\n        mem: 256\n```\n\n## 运行目录、日志文件\n\n`runx` 具有两级实验层次结构：**实验**和**运行**。一个 `实验` 对应于一个单独的 YAML 文件，其中可能包含多个 `运行`。\n\n`runx` 会为每个实验创建一个父级实验目录，并为每次运行创建一个唯一的子目录。实验目录的名称为 `LOGROOT\u002F\u003C实验名称>`，因此在 `sweep.yml` 的示例中，实验名称为 `sweep`，源自 YAML 文件名。\n\n例如，这可能是 `sweep` 研究的目录结构：\n```bash\n\u002Fhome\u002Flogs\n  sweep\u002F\n     curious-rattlesnake_2020.02.06_14.19\u002F\n     ambitious-lobster_2020.02.06_14.19\u002F\n     ...\n```\n\n各个运行目录的命名结合了 `coolname` 和日期。使用 `coolname` 比仅用日期代码更容易引用特定的运行。\n\n如果您在实验 YAML 中包含 `RUNX.TAG` 字段，或者向 `runx` CLI 提供 `--tag` 参数，则名称中会包含该标签。\n\n## 代码暂存\n`runx` 实际上会在每个运行的日志目录中复制一份您的代码。这样做有几个原因：\n* 如果您希望在训练运行进行时继续修改代码，可以放心地进行，而不必担心会影响正在运行的作业。\n* 如果您的作业失败并需要重新启动，代码和训练环境都自包含在运行的日志目录中。\n* 这也有助于文档记录：如果您想了解某个运行时代码的确切状态，这也是一个有用的方法。\n\n\n## 实验 YAML 详细信息\n\n### 特殊变量\n**CMD** - 您的基础训练命令。通常这里不包含任何参数。\n**HPARAMS** - 所有超参数。这是一个数据结构，可以是简单的参数字典，也可以是字典列表。此外，每个超参数可以是标量、列表或布尔值。\n**PYTHONPATH** - 此字段为可选。用于修改默认的 PYTHONPATH，即 LOGDIR\u002Fcode。可以是冒号分隔的路径列表，也可以包含 LOGDIR 特殊变量。\n\n### HPARAMS\n\n#### HPARAMS 的一个简单示例如下：\n```yaml\nCMD: \"python train.py\"\n\nHPARAMS:\n  logdir: LOGDIR\n  adam: true\n  arch: alexnet\n  lr: [0.01, 0.02]\n  epochs: 10\n  RUNX.TAG: 'alexnet'\n```\n在此例中，将创建 2 个运行。\n\n### 布尔值\n如果您想指定某个布尔标志应开启或关闭，可以使用 `true` 和 `false` 关键字：\n  ```\n  some_flag: [true, false]\n  ```\n这将导致一个运行带有 `--some_flag`，而另一个运行则没有该标志。\n\n如果您想传递实际的字符串，可以这样做：\n```\n  some_arg: ['True', 'False']\n```\n这将导致一个运行带有 `--some_arg True`，另一个运行带有 `--some_arg False`。\n\n如果您希望某个参数根本不传递到脚本中，可以将其设置为 `None`：\n```\n  some_arg: None\n```\n\n### 列表、继承\n通常，您可能希望在实验中定义不同的超参数列表。例如：\n  1. 架构 = alexnet，学习率 = [0.01, 0.02]\n  2. 架构 = resnet50，学习率 = [0.002, 0.005]\n\n您可以通过如下方式定义超参数：\n```yaml\nPYTHONPATH: LOGDIR\u002Fcode:LOGDIR\u002Fcode\u002Flib\nCMD: \"python train.py\"\n\nHPARAMS: [\n  {\n   logdir: LOGDIR,\n   adam: true,\n   arch: alexnet,\n   lr: [0.01, 0.02],\n   epochs: 10,\n   RUNX.TAG: 'alexnet',\n  },\n  {\n   arch: resnet50，\n   lr: [0.002, 0.005],\n   RUNX.TAG: 'resnet50',\n  },\n  {\n   RUNX.SKIP: true，\n   arch: resnet50，\n   lr: [0.002, 0.005],\n   RUNX.TAG: 'resnet50',\n  }\n]\n```\n您可能会注意到，`HPARAMS` 现在是一个包含两个字典的列表。好处是 `runx` 会假定从列表中的第一项继承到所有剩余的字典，这样您就不必重复输入所有冗余的超参数。\n\n当您将此 YAML 文件传递给 `runx` 时，您将得到以下输出：\n\n``` bash\nsubmit_job ... --name alexnet_2020.02.06_6.32  -c \"python train.py --logdir ... --lr 0.01 --adam --arch alexnet --epochs 10\nsubmit_job ... --name alexnet_2020.02.06_6.40  -c \"python train.py --logdir ... --lr 0.02 --adam --arch alexnet --epochs 10\nsubmit_job ... --name resnet50_2020.02.06_6.45 -c \"python train.py --logdir ... --lr 0.002 --adam --arch resnet50 --epochs 10\nsubmit_job ... --name resnet50_2020.02.06_6.50 -c \"python train.py --logdir ... --lr 0.005 --adam --arch resnet50 --epochs 10\n```\n由于继承机制，`adam`、`arch` 和 `epochs` 参数在每个运行中都相同。\n\n这也展示了魔术变量 `RUNX.TAG` 的使用，它允许您为实验的一部分添加标签。这与使用 `runx.py` 的 `--tag \u003Ctagname>` 选项效果相同，不同之处在于您可以直接在 `HPARAMS` 数据结构中指定标签。`RUNX.TAG` 的值不会传递到您的训练脚本中。\n\n`RUNX.TAG` 的一个非常有用的功能是，您可以引用其他超参数，例如：\n\n``` yaml\n   arch: resnet50，\n   RUNX.TAG: '{arch}-lrstudy'\n```\n\n这将使标签变为 `resnet50-lrstudy`。`runx` 在遇到花括号时会进行简单的字符串匹配和替换。\n\n## logx - 日志记录、TensorBoard 可视化、检查点保存\n为了使用 sumx，你需要使用 logx 导出指标。\n\nlogx 帮助以标准方式记录指标，从而使 sumx 能够汇总结果。\n\nlogx 还可以方便地将日志信息输出到文件（以及标准输出）。\n\n此外，logx 还能自动管理检查点的保存，其优势在于只会保留最新的和最优的检查点，从而节省大量磁盘空间。\n\n使用 logx 的基本方法是按照以下方式修改你的训练代码：\n\n在训练脚本的顶部（或任何调用 logx 函数的模块中）：\n```python\nfrom runx.logx import logx\n```\n\n在使用 logx 之前，必须按如下方式初始化它：\n```python\n   logx.initialize(logdir=args.logdir, coolname=True, tensorboard=True)\n```\n确保在使用分布式数据并行时，仅从 rank=0 节点调用 logx。\n\n然后，将以下 logx 调用替换到你的代码中：\n\n| 从                | 到                | 作用                      |\n| ------------------- | ----------------- | ------------------------- |\n| print()             | logx.msg()        | 标准输出消息           |\n| writer.add_scalar() | logx.add_scalar() | TensorBoard 标量写       |\n| writer.add_image()  | logx.add_image()  | TensorBoard 图像写       |\n|                     | logx.save_model() | 保存最新\u002F最佳模型       |\n\n最后，为了让 sumx 能够读取你运行的结果，你必须将指标推送到 logx。务必推送验证集指标，但也可以选择推送训练集指标（目前 sumx 尚未使用这些指标）。\n\n```python\n# 定义要记录的指标\nmetrics = {'loss': test_loss, 'accuracy': accuracy}\n# 将指标推送到日志文件\nlogx.metric(phase='val', metrics=metrics, epoch=epoch)\n```\n\nlogx.metric 的一些重要注意事项：\n* `phase` 参数用于指定该指标是训练指标还是验证指标。\n* 对于验证指标，应将 idx 设置为当前 epoch；而对于训练指标，idx 通常为迭代次数。\n\nlogx 的最后一个功能是模型保存。此功能不仅能够保存最新模型，还能保存最优模型。\n\n```python\nsave_dict = {'epoch': epoch + 1,\n             'arch': args.arch,\n             'state_dict': model.state_dict(),\n             'best_acc1': best_acc1,\n             'optimizer' : optimizer.state_dict()}\nlogx.save_model(save_dict, metric=accuracy, epoch=epoch, higher_better=True)\n```\n\n在调用 save_model 时，需要明确指标是越高越好还是越低越好。\n\n## sumx - 汇总你的运行结果\nsumx 会汇总你的运行结果。它要求你已使用 logx.metric 记录了指标。\n\n我们选择这种方式而不是直接读取 TensorBoard 文件，是因为后者速度会慢很多。\n\n``` bash\n> python -m runx.sumx sweep\n        lr    solver  acc   epoch  epoch_time\nrun4    0.02  adam    99.1  10     5:21\nrun3    0.02  sgd     99.0  10     5:02\nrun1    0.01  sgd     98.2  10     5:40\nrun2    0.01  adam    98.1  10     5:25\n```\n\n几个值得注意的功能：\n* 使用 `--sortwith` 参数可以根据你最关心的字段（如准确率）对输出进行排序。\n* sumx 会显示当前运行正在进行的 epoch。\n* sumx 还会显示平均每个 epoch 的耗时，这对于监控训练速度非常有帮助。\n* 可以使用可选的 `--ignore` 标志来限制 sumx 输出的字段。\n\n## NGC 支持\nNGC 支持现已成为标配。你的 `.runx` 文件应如下所示。\n\n```yaml\n\nLOGROOT: \u002Fpath\u002Fto\u002Flogroot\n\nFARM: ngc\n\nngc:\n    NGC_LOGROOT: \u002Fpath\u002Fto\u002Fngc_logroot\n    WORKSPACE: \u003Cyour ngc workspace>\n    SUBMIT_CMD: 'ngc batch run'\n    RESOURCES:\n       image: nvidian\u002Fpytorch:19.10-py3\n       instance: dgx1v.16g.1.norm\n       ace: nv-us-west-2\n       result: \u002Fresult\n```\n\n必要的步骤：\n* 填写 LOGROOT 路径，这是客户端侧的日志目录暂存目录。\n* 创建一个 RW 权限的 NGC 工作区，并将其填写到 `WORKSPACE` 中。\n* 在本地机器上挂载该工作区，并将挂载路径填写到 `NGC_LOGROOT` 中。当作业启动时，这也是用于在运行实例上挂载工作区的路径。\n* 填写 `RESOURCES` 下的必要字段。请注意，这些参数会被传递给 `SUBMIT_CMD`，而 `SUBMIT_CMD` 必须设置为 `ngc batch run`。\n\n使用此配置你应该能够成功提交作业到 NGC。当作业写入结果时，你也应该能够在挂载的工作区内看到这些结果，随后就可以运行 runx.sumx 来汇总这些运行的结果。","# runx 快速上手指南\n\n> **⚠️ 重要提示：项目已停止维护**\n> 本项目不再维护，且存在已知安全漏洞。官方不再提供更新或安全补丁。请仅在了解风险的前提下谨慎使用，或仅用于学习其设计思路。\n\n`runx` 是一个实验管理工具，旨在自动化科研中的常见任务，包括超参数搜索、日志记录、TensorBoard 管理、检查点管理以及为每次运行创建唯一的输出目录。\n\n## 环境准备\n\n*   **系统要求**：Linux \u002F macOS (Windows 需通过 WSL 或类似环境)\n*   **前置依赖**：\n    *   Python 3.x\n    *   `pip` 包管理器\n    *   (可选) 集群作业提交脚本（如 SLURM, LSF 等），若需在农场\u002F集群上运行任务。\n\n## 安装步骤\n\n### 方式一：通过 pip 安装（推荐）\n\n```bash\npip install runx\n```\n\n### 方式二：从源码安装\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\ncd runx\npython setup.py .\n```\n\n## 基本使用\n\n### 1. 创建项目配置文件 (.runx)\n\n在项目根目录下创建名为 `.runx` 的配置文件，用于定义日志根目录和运行环境。\n\n创建文件 `.runx`：\n```yaml\nLOGROOT: .\u002Flogs\nFARM: local\n\nlocal:\n  SUBMIT_CMD: ''\n  RESOURCES: {}\n```\n*   `LOGROOT`: 实验日志和结果的存储根目录。\n*   `FARM`: 定义运行目标。此处设为 `local` 表示在本地交互式运行。\n\n### 2. 定义实验超参数 (YAML)\n\n创建一个 YAML 文件（例如 `sweep.yml`）来定义训练命令和需要搜索的超参数列表。`runx` 会自动计算所有参数的笛卡尔积。\n\n创建文件 `sweep.yml`：\n```yaml\nCMD: 'python train.py'\n\nHPARAMS:\n  lr: [0.01, 0.02]\n  solver: ['sgd', 'adam']\n  logdir: LOGDIR\n```\n*   `CMD`: 基础训练命令。\n*   `HPARAMS`: 超参数字典。列表类型的值（如 `[0.01, 0.02]`）将触发自动遍历。\n*   `LOGDIR`: 特殊变量，`runx` 会自动将其替换为本次运行唯一的输出目录路径，防止文件覆盖。\n\n### 3. 运行实验\n\n#### 本地交互式运行\n使用 `-i` 标志在本地直接运行所有组合：\n\n```bash\npython -m runx.runx sweep.yml -i\n```\n\n执行后，`runx` 将依次执行以下命令（示例）：\n```bash\npython train.py --lr 0.01 --solver sgd --logdir .\u002Flogs\u002Fsweep\u002Fathletic-wallaby_2023.10.27_10.00\npython train.py --lr 0.01 --solver adam --logdir .\u002Flogs\u002Fsweep\u002Findustrious-chicken_2023.10.27_10.01\npython train.py --lr 0.02 --solver sgd --logdir .\u002Flogs\u002Fsweep\u002Farrogant-buffalo_2023.10.27_10.02\npython train.py --lr 0.02 --solver adam --logdir .\u002Flogs\u002Fsweep\u002Fvengeful-jaguar_2023.10.27_10.03\n```\n*注意：每次运行都会生成一个包含“形容词 - 名词_时间戳”的唯一目录名。*\n\n#### 预览命令（不执行）\n如果只想查看生成的命令而不实际运行，使用 `-n` 标志：\n\n```bash\npython -m runx.runx sweep.yml -n\n```\n\n### 4. 结果汇总 (sumx)\n\n实验完成后，使用 `sumx` 工具汇总结果。它会自动读取 `LOGROOT` 下的实验数据。\n\n假设你的训练脚本在日志中记录了 `acc` (准确率) 指标：\n\n```bash\npython -m runx.sumx sweep --sortwith acc\n```\n\n输出示例：\n```text\n        lr    solver  acc   epoch  epoch_time\n------\t----  ------  ----  -----  ----------\nrun4    0.02  adam    99.1   10     5:11\nrun3    0.02  sgd     99.0   10     5:05\nrun1    0.01  sgd     98.2   10     5:15\nrun2    0.01  adam    98.1   10     5:12\n```\n\n### 进阶提示：代码快照\n`runx` 在每次运行时，会自动将当前代码复制到对应的唯一日志目录中。这确保了即使后续修改了代码，已运行的实验环境依然保持不变，便于复现和追溯。","某深度学习团队正在对图像分类模型进行大规模超参数调优，需同时测试多种学习率与优化器组合并在集群上并行运行。\n\n### 没有 runx 时\n- 研究人员必须手动编写临时脚本来生成超参数的排列组合，代码冗余且容易出错。\n- 每次实验产生的日志和 TensorBoard 文件常因目录命名冲突而相互覆盖，导致历史数据丢失。\n- 向计算集群提交任务时，需反复手动拼接资源参数（如 GPU 数量、内存），操作繁琐且难以统一标准。\n- 缺乏统一的实验记录机制，复盘时难以快速定位特定配置对应的模型权重与训练曲线。\n\n### 使用 runx 后\n- 只需定义一个简单的 YAML 文件列出超参数列表，runx 自动计算所有组合并生成对应的执行命令。\n- 工具为每次运行自动创建唯一的输出目录，确保日志、检查点和可视化文件互不干扰且井井有条。\n- 通过预配置的集群文件，runx 能自动将实验任务封装并提交到农场集群，无需人工干预资源分配细节。\n- 内置的实验总结功能让团队能快速对比不同配置的性能表现，大幅缩短从实验到结论的周期。\n\nrunx 将原本碎片化、易出错的实验流程转化为标准化的自动化流水线，让研究人员能专注于算法创新而非运维琐事。","https:\u002F\u002Foss.gittoolsai.com\u002Fimages\u002FNVIDIA_runx_022b291d.png","NVIDIA","NVIDIA Corporation","https:\u002F\u002Foss.gittoolsai.com\u002Favatars\u002FNVIDIA_7dcf6000.png","",null,"https:\u002F\u002Fnvidia.com","https:\u002F\u002Fgithub.com\u002FNVIDIA",[83],{"name":84,"color":85,"percentage":86},"Python","#3572A5",100,641,39,"2026-02-20T01:39:48","BSD-3-Clause","未说明","非工具运行必需，但配置文件中示例显示支持提交需要 GPU 的任务（如 2-8 核），具体型号和显存取决于用户定义的农场配置",{"notes":94,"python":95,"dependencies":96},"⚠️ 重要提示：该项目已停止维护（End of Life），存在安全漏洞且不再提供更新或补丁，使用风险自负。该工具主要用于自动化超参数扫描、日志管理和实验总结，本身不依赖特定深度学习框架，但被管理的训练脚本（如 train.py）可能依赖其他库。支持将任务提交到自定义计算集群（Farm）。","未说明 (需通过 pip 或 setup.py 安装)",[97,98],"pyyaml (隐含，用于解析 YAML)","tensorboard (隐含，用于 logx 模块)",[13],"2026-03-27T02:49:30.150509","2026-04-06T05:14:55.974144",[103,108,113,118,123,128],{"id":104,"question_zh":105,"answer_zh":106,"source_url":107},14201,"如何在没有集群（Farm）设置的单机上运行 runx？","默认情况下 runx 设计用于向集群提交作业（使用 'submit_job'），但现已支持单机交互模式。请确保升级到最新版本，然后在运行命令时添加 `-i` 标志以启用交互模式。例如：\n`pip install --upgrade runx`\n`python -m runx.runx config.yml -i`\n这样就不需要配置复杂的 FARM 或 SUBMIT_CMD 即可在本地直接运行实验。","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\u002Fissues\u002F2",{"id":109,"question_zh":110,"answer_zh":111,"source_url":112},14202,"运行 simple example 时报错找不到 .runx 配置文件怎么办？","runx 必须依赖配置文件才能运行。报错 \"can't find file .\u002F.runx\" 是因为当前目录或全局配置路径下缺少该文件。\n解决方案：\n1. 确保项目根目录下存在 `.runx` 文件（可以参考 examples 目录中的示例）。\n2. 或者将配置文件放置在全局路径 `~\u002F.config\u002Frunx.yml`。\n3. 配置文件中至少需要定义 `LOGROOT` 变量，例如：\n```\nLOGROOT: \u002Fpath\u002Fto\u002Fyour\u002Flogs\n```\n建议升级 runx 到最新版本以获得更好的默认处理。","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\u002Fissues\u002F7",{"id":114,"question_zh":115,"answer_zh":116,"source_url":117},14203,"使用 sumx 汇总数据时报错 \"No valid experiments found\" 是什么原因？","这通常是因为初始化 logger 时缺少必要的参数。在使用 `logx.initialize()` 时，必须传入 `hparams=vars(args)` 参数，以便 runx 能够识别超参数并正确记录实验元数据。\n修正代码示例：\n`logx.initialize(hparams=vars(args))`\n此外，请确保已升级到最新版本（0.0.11+），新版中 `.runx` 配置文件只需定义 `LOGROOT`，不再需要伪造的 FARM 配置。","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\u002Fissues\u002F15",{"id":119,"question_zh":120,"answer_zh":121,"source_url":122},14204,"在 NGC 等远程环境中运行时，每次运行都上传代码导致速度很慢，如何优化？","如果代码目录中包含不需要频繁变动的大文件，或者网络连接较慢，可以通过以下方式优化：\n1. 使用 `CODE_IGNORE_PATTERNS` 在 `.runx` 文件中排除大文件或无需上传的目录（如数据文件夹、git 目录等）：\n```\nCODE_IGNORE_PATTERNS: '*.git,data\u002Fraw*,.*,results*'\n```\n2. 将大型静态文件放置在远程工作区的中央位置，避免每次重复复制。\n注意：目前 runx 为了保障可复现性（Reproducibility），默认策略是为每次运行复制一份代码快照。虽然社区有提出共享代码目录的建议，但官方目前仍推荐通过忽略模式来减少上传量。","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\u002Fissues\u002F9",{"id":124,"question_zh":125,"answer_zh":126,"source_url":127},14205,"运行时报错 \"\u002Fbin\u002Fsh: 1: submit_job: not found\" 如何解决？","这个错误表明系统找不到 `submit_job` 命令，这是因为 `.runx` 配置中默认指定了集群提交命令，而你的环境中并没有安装该工具或不需要使用集群。\n解决方法是切换到单机交互模式：\n1. 升级 runx：`pip install --upgrade runx`\n2. 运行命令时加上 `-i` 参数：`python -m runx.runx sweep.yml -i`\n这将绕过 `submit_job` 调用，直接在本地执行脚本。","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\u002Fissues\u002F5",{"id":129,"question_zh":130,"answer_zh":131,"source_url":132},14206,"runx 是否支持标准的 Python logging 模块或自定义日志格式？","目前 runx 为了保持实现的最小化，内置了非常基础的日志功能，并未直接集成标准的 Python `logging` 包。维护者表示未来可能会考虑支持，但目前尚未实现。\n如果你需要使用特定的日志格式（如包含时间戳、线程名等），建议在代码中自行配置 `logging.basicConfig`，但这部分日志不会自动被 runx 的特殊格式捕获或管理，它们将作为标准输出的一部分存在。","https:\u002F\u002Fgithub.com\u002FNVIDIA\u002Frunx\u002Fissues\u002F3",[134],{"id":135,"version":136,"summary_zh":137,"released_at":138},80953,"v0.0.5","v0.0.5 版本发布\n\n新增了交互式运行作业的功能（-i）。\n同时新增了 RUNX.SKIP，允许跳过某次运行。","2020-08-25T19:13:06"]