當(dāng) Autoresearch 任務(wù)跑完第 1293 次實(shí)驗(yàn)時(shí)日志里的 Token 統(tǒng)計(jì)停在 779M。這不是一個(gè)想象中的數(shù)字而是一段時(shí)間內(nèi)真實(shí)跑出來的自動(dòng)研究工作量級(jí)。如果一篇文章大約折合 2000 個(gè) Token779M 的 Token 量差不多相當(dāng)于幾十萬篇文章足夠把一個(gè)小型技術(shù)文檔庫反復(fù)讀完。支撐這 779M Token 完成閉環(huán)推理的是整整調(diào)整了三輪才算穩(wěn)定的 GPU 運(yùn)行模式。很多同學(xué)接觸自動(dòng)研究時(shí)第一反應(yīng)是讓模型自己拆任務(wù)、寫代碼、跑實(shí)驗(yàn)、看結(jié)果、再改方案這不就是多輪 Prompt 嗎真上手之后才發(fā)現(xiàn)技術(shù)難點(diǎn)根本不在 Prompt而在 Token 消耗控制和 GPU 資源調(diào)度上。這篇文章就從一份自動(dòng)研究任務(wù)的真實(shí)數(shù)據(jù)切入拆解為什么它會(huì)消耗這么多 Token以及 GPU 模式連續(xù)調(diào)整三輪到底在解決什么問題。無論你是做 Agent 應(yīng)用、寫 AI 自動(dòng)化腳本還是負(fù)責(zé)大模型推理服務(wù)的部署運(yùn)維這篇文章都能給你提供一個(gè)相對(duì)完整的工程視角。1. 什么是 Autoresearch自動(dòng)研究到底在研究什么1.1 Autoresearch 的本質(zhì)Autoresearch直譯是“自動(dòng)研究”它不是某一個(gè)具體軟件而是一類基于大模型的自動(dòng)化執(zhí)行范式。它的核心思想是給模型一個(gè)研究目標(biāo)讓模型自主拆解問題、設(shè)計(jì)實(shí)驗(yàn)方案、生成代碼、執(zhí)行命令、讀取結(jié)果、分析差異最后輸出一份結(jié)論或報(bào)告。和傳統(tǒng)的腳本自動(dòng)化不同Autoresearch 的每一步不是預(yù)先寫死的而是模型根據(jù)當(dāng)前狀態(tài)動(dòng)態(tài)決定下一步動(dòng)作。比如目標(biāo)是“分析某數(shù)據(jù)集在低資源環(huán)境下的推理性能”模型可能會(huì)這樣走先理解數(shù)據(jù)集格式和字段含義。編寫一個(gè)加載數(shù)據(jù)的腳本并運(yùn)行。根據(jù)報(bào)錯(cuò)修改依賴或路徑。用不同 batch size 跑多組實(shí)驗(yàn)。橫向?qū)Ρ戎笜?biāo)。把結(jié)論整理成 markdown 報(bào)告。傳統(tǒng)腳本只能完成“如果 A 就執(zhí)行 B”而 Autoresearch 可以處理“如果結(jié)果不符合預(yù)期就換一個(gè)思路重試”。這就是它和普通自動(dòng)化程序最本質(zhì)的區(qū)別。1.2 一次自動(dòng)研究任務(wù)的完整閉環(huán)把一次 Autoresearch 任務(wù)展開通常是下面這個(gè)循環(huán)任務(wù)定義用戶輸入一個(gè)研究問題并給出約束條件比如模型、數(shù)據(jù)集、GPU 數(shù)量、時(shí)間預(yù)算。方案拆解Agent 將問題拆成若干子任務(wù)每個(gè)子任務(wù)明確輸入輸出。代碼生成為子任務(wù)生成可運(yùn)行代碼或腳本。執(zhí)行調(diào)用本地或遠(yuǎn)程環(huán)境運(yùn)行代碼真實(shí)消耗 GPU 和 CPU 資源。觀察與修正讀取執(zhí)行日志、輸出文件、運(yùn)行指標(biāo)判斷是否達(dá)到預(yù)期必要時(shí)修改代碼重新運(yùn)行。循環(huán)上述步驟反復(fù)進(jìn)行直到任務(wù)完成。報(bào)告輸出將實(shí)驗(yàn)結(jié)果寫成結(jié)構(gòu)化文檔。這個(gè)循環(huán)在真實(shí)項(xiàng)目中會(huì)反復(fù)執(zhí)行幾十次、上百次甚至上千次。每一次循環(huán)模型都需要讀取大量上下文信息這就是 Token 消耗居高不下的根本原因。1.3 Autoresearch 適合做什么Autoresearch 適合的任務(wù)通常有幾個(gè)特點(diǎn)目標(biāo)明確但路徑不明確。需要大量試錯(cuò)且試錯(cuò)成本可控。實(shí)驗(yàn)結(jié)果可以被量化評(píng)估。過程需要記錄和復(fù)現(xiàn)。比如參數(shù)調(diào)優(yōu)、模型評(píng)估、數(shù)據(jù)對(duì)比實(shí)驗(yàn)、代碼遷移適配、性能基線測(cè)試等。相反如果任務(wù)本身需要強(qiáng)人工判斷、敏感權(quán)限操作或難以量化反饋就不適合全自動(dòng)研究更適合人機(jī)協(xié)同。2. Token 與 GPU自動(dòng)研究的兩類核心成本2.1 Token 消耗為什么居高不下Token 是大模型輸入和輸出內(nèi)容的最小計(jì)量單元。中文語境下1 個(gè) Token 通常不足一個(gè)漢字英文里大約等于四分之三個(gè)單詞。在 Autoresearch 中Token 消耗不是“一次提問多少錢”那么簡(jiǎn)單而是每一輪循環(huán)都要重復(fù)消耗。我們拆一下 1293 次實(shí)驗(yàn)對(duì)應(yīng)的成本結(jié)構(gòu)。假設(shè)一次實(shí)驗(yàn)平均消耗約 60 萬個(gè) Token那么這些 Token 主要花在四個(gè)地方系統(tǒng)提示詞System Prompt每次請(qǐng)求都需要帶上任務(wù)背景、工具說明、輸出格式這部分是固定開銷。歷史消息累積Agent 是多輪交互系統(tǒng)需要把之前的關(guān)鍵上下文重新發(fā)送給模型越長(zhǎng)的任務(wù)歷史累積越大。工具調(diào)用返回執(zhí)行代碼后模型要讀取終端輸出、文件內(nèi)容、日志片段這些內(nèi)容會(huì)直接進(jìn)入上下文。模型生成內(nèi)容模型生成的思考過程、行動(dòng)計(jì)劃、代碼和中間結(jié)論也是 Token 開銷的一部分。779M 這個(gè)量級(jí)意味著任務(wù)的平均上下文長(zhǎng)度和重試次數(shù)都很高。它不是一個(gè)異常值而是大型自動(dòng)研究任務(wù)的常見特征。2.2 GPU 在自動(dòng)研究鏈路中的位置Autoresearch 對(duì) GPU 的依賴體現(xiàn)在兩個(gè)層面一是模型推理。無論是 API 調(diào)用還是本地私有化部署模型的每一次生成都需要 GPU 計(jì)算。1293 次實(shí)驗(yàn)對(duì)應(yīng)大量模型推理請(qǐng)求GPU 的吞吐量直接決定任務(wù)完成速度。二是實(shí)驗(yàn)運(yùn)行。當(dāng) Agent 生成的代碼是深度學(xué)習(xí)訓(xùn)練或推理腳本時(shí)每次實(shí)驗(yàn)本身都要占用 GPU 顯存和算力。這里消耗的不是“模型的 Token”而是“實(shí)驗(yàn)的計(jì)算量”。所以在實(shí)際項(xiàng)目中GPU 不只是底座資源更是自動(dòng)研究任務(wù)能否高效運(yùn)行的關(guān)鍵瓶頸。很多團(tuán)隊(duì)在 Autoresearch 跑不起來時(shí)第一反應(yīng)是換更強(qiáng)的模型但真正的問題往往是 GPU 模式?jīng)]有配好導(dǎo)致推理和實(shí)驗(yàn)互相搶顯存。2.3 1293 次實(shí)驗(yàn)和 779M Token 的工程含義1293 次實(shí)驗(yàn)意味著什么如果每次實(shí)驗(yàn)從生成代碼到運(yùn)行完需要 3 分鐘1293 次實(shí)驗(yàn)就是 64 個(gè)小時(shí)以上的純執(zhí)行時(shí)間這還不包括模型分析和思考的時(shí)間。779M Token 意味著什么假設(shè)一次實(shí)驗(yàn)平均 60 萬 Token說明每次實(shí)驗(yàn)過程中模型至少進(jìn)行了 3 到 5 輪的完整上下文交互。每一輪都要把前面幾輪的摘要、日志、結(jié)果重新發(fā)送給模型。上下文越長(zhǎng)單次請(qǐng)求的 Token 量就越大。所以當(dāng)你看到“1293 Experiments, 779M Tokens, GPUMode 3rd”這樣的數(shù)據(jù)時(shí)應(yīng)該把它理解成一個(gè)成本模型實(shí)驗(yàn)次數(shù)決定了循環(huán)數(shù)量Token 消耗決定了模型調(diào)用成本GPU 模式?jīng)Q定了計(jì)算資源的使用效率。三者互相影響任何一項(xiàng)失控都會(huì)導(dǎo)致整個(gè)任務(wù)不可持續(xù)。3. 環(huán)境準(zhǔn)備與版本選型本文不綁定具體的某套框架因?yàn)?Autoresearch 的工程實(shí)現(xiàn)差異很大。但有幾個(gè)共性的環(huán)境和工具需要準(zhǔn)備好我會(huì)給出常見選型和判斷依據(jù)。3.1 硬件環(huán)境運(yùn)行 Autoresearch 任務(wù)至少需要一臺(tái)具備 NVIDIA GPU 的機(jī)器。顯存大小決定你能否加載本地大模型以及實(shí)驗(yàn)?zāi)_本能使用多大的 batch size。常見的配置包括顯存 8GB可以運(yùn)行 7B 級(jí)別量化模型適合輕量推理任務(wù)。顯存 16GB可以運(yùn)行 13B 級(jí)別量化模型或支撐小規(guī)模微調(diào)實(shí)驗(yàn)。顯存 24GB 以上可以運(yùn)行 30B 以上模型適合復(fù)雜研究和模型微調(diào)。如果你的場(chǎng)景是調(diào)用云端 API本機(jī) GPU 主要用于執(zhí)行實(shí)驗(yàn)?zāi)_本如果是私有化推理GPU 同時(shí)承擔(dān)模型推理和實(shí)驗(yàn)計(jì)算顯存分配會(huì)更緊張。3.2 軟件棧典型軟件棧包括操作系統(tǒng)Ubuntu 22.04 或 Windows 11 WSL2。GPU 驅(qū)動(dòng)NVIDIA 驅(qū)動(dòng)配合 CUDA Toolkit。推理框架Ollama、vLLM、llama.cpp 或 TGI取決于你是本地推理還是自建服務(wù)。Python 環(huán)境Python 3.10 以上配合 PyTorch 或 Transformers。Agent 框架LangGraph、AutoGen 或自定義流程腳本。版本這里不寫死因?yàn)轫?xiàng)目差異太大。建議在你的目標(biāo)環(huán)境中先用nvidia-smi確認(rèn)驅(qū)動(dòng)和 CUDA 版本再選擇兼容的 PyTorch 和推理框架版本。3.3 基礎(chǔ)命令檢查拿到一臺(tái)新機(jī)器后先做三件事# 檢查 GPU 是否被系統(tǒng)識(shí)別 nvidia-smi # 檢查當(dāng)前 CUDA 版本 nvcc --version # 檢查 Python 環(huán)境和 torch 是否能訪問 GPU python -c import torch; print(torch.cuda.is_available())如果nvidia-smi能正常顯示 GPU 型號(hào)和顯存說明驅(qū)動(dòng)層面沒有問題。如果 Python 里torch.cuda.is_available()返回 False說明 PyTorch 版本與 CUDA 驅(qū)動(dòng)不匹配需要重新安裝對(duì)應(yīng)版本。4. GPU 模式到底在調(diào)什么從 GPUMode 1st 到 3rd很多自動(dòng)研究項(xiàng)目里會(huì)有一個(gè)類似GPU_MODE的配置項(xiàng)用來控制系統(tǒng)如何分配和使用 GPU。這不是某個(gè)固定開源框架的標(biāo)準(zhǔn)概念而是一種工程化的資源管理方式。GPUMode 3rd 意味著這個(gè)配置經(jīng)歷了三輪調(diào)整。下面還原每一輪調(diào)整要解決的典型問題。4.1 第一輪默認(rèn)模式多任務(wù)搶占第一版配置最簡(jiǎn)單所有 Agent 子任務(wù)統(tǒng)一使用默認(rèn) GPU 調(diào)度大家共用 0 號(hào)卡。結(jié)果很快發(fā)現(xiàn)問題多個(gè)實(shí)驗(yàn)任務(wù)同時(shí)申請(qǐng)顯存顯存耗盡。一個(gè)任務(wù) OOM 之后其他任務(wù)也被影響。推理服務(wù)和實(shí)驗(yàn)?zāi)_本搶同一塊 GPU互相拖慢。這一階段典型報(bào)錯(cuò)是CUDA out of memory. Tried to allocate 512.00 MiB原因很簡(jiǎn)單Autoresearch 會(huì)并發(fā)執(zhí)行多個(gè)實(shí)驗(yàn)每個(gè)實(shí)驗(yàn)都認(rèn)為自己是唯一的 GPU 用戶。我的建議是如果環(huán)境允許最好給推理服務(wù)和實(shí)驗(yàn)任務(wù)分配不同 GPU。沒有多卡條件時(shí)至少要設(shè)定顯存上限或串行化執(zhí)行實(shí)驗(yàn)任務(wù)。4.2 第二輪設(shè)備隔離但引入 WSL 和 NVML 問題第二輪思路是給每個(gè)任務(wù)分配不同的 GPU 編號(hào)通過環(huán)境變量隔離設(shè)備# 給任務(wù) A 指定 GPU 0 CUDA_VISIBLE_DEVICES0 python run_experiment.py # 給任務(wù) B 指定 GPU 1 CUDA_VISIBLE_DEVICES1 python run_experiment.py這個(gè)方法在物理機(jī)上有效但在 WSL2 環(huán)境下很多同學(xué)會(huì)碰到一個(gè)經(jīng)典報(bào)錯(cuò)failed to initialize nvml: gpu access blocked by the operating system這個(gè)報(bào)錯(cuò)的含義是程序想通過 NVML 接口讀取 GPU 狀態(tài)但被操作系統(tǒng)攔截了。原因通常是 WSL2 的 GPU 透?jìng)鳈C(jī)制不完整或驅(qū)動(dòng)版本與 WSL 內(nèi)核不匹配。解決辦法不是改代碼而是升級(jí) Windows 側(cè) NVIDIA 驅(qū)動(dòng)并確認(rèn) WSL 里能看到 GPU# 在 WSL 中執(zhí)行 nvidia-smi如果 WSL 中無法顯示 GPU 信息先解決驅(qū)動(dòng)的版本匹配問題再回來看 Autoresearch 的調(diào)度配置。4.3 第三輪組合方案顯存預(yù)留 串行控制GPUMode 3rd 這輪問題在于把推理、執(zhí)行、報(bào)告三種任務(wù)放在一套 GPU 調(diào)度策略下管理。最終采用的方案可以概括為推理服務(wù)固定使用 GPU 0提前預(yù)留顯存。實(shí)驗(yàn)?zāi)_本通過CUDA_VISIBLE_DEVICES指定 GPU 1 或 GPU 2。同型號(hào)實(shí)驗(yàn)任務(wù)串行執(zhí)行避免并發(fā)搶顯存。每個(gè)實(shí)驗(yàn)開始前檢查當(dāng)前顯存剩余量不足則排隊(duì)等待。對(duì)應(yīng)的調(diào)度腳本片段import subprocess import pynvml pynvml.nvmlInit() def get_free_memory(device_id): handle pynvml.nvmlDeviceGetHandleByIndex(device_id) info pynvml.nvmlDeviceGetMemoryInfo(handle) return info.free / 1024**3 # 單位 GB def can_run(device_id, required_gb): free_mb get_free_memory(device_id) return free_mb required_gb # 示例申請(qǐng) GPU 1要求剩余顯存 6GB if can_run(1, 6): subprocess.run( [python, run_experiment.py], env{CUDA_VISIBLE_DEVICES: 1} ) else: print(GPU 1 顯存不足等待下次調(diào)度)這段代碼不是某個(gè)框架的標(biāo)準(zhǔn)寫法只是給你一種思路在 Autoresearch 執(zhí)行層可以用 NVML 做顯存感知調(diào)度。注意使用 pynvml 前需要安裝pip install nvidia-ml-py第三輪配置跑通之后1293 次實(shí)驗(yàn)才開始穩(wěn)定持續(xù)推進(jìn)。如果沒有這一輪調(diào)整任務(wù)大概率會(huì)在前兩三百次實(shí)驗(yàn)時(shí)因?yàn)轱@存沖突和推理中斷而夭折。5. Token 消耗的統(tǒng)計(jì)與分析5.1 如何統(tǒng)計(jì)一次實(shí)驗(yàn)的 Token 用量很多 Agent 框架會(huì)返回每次推理請(qǐng)求的usage信息包含prompt_tokens、completion_tokens和total_tokens。如果你用 API 或 OpenAI 兼容服務(wù)可以通過包裝請(qǐng)求層來統(tǒng)計(jì)。下面是一個(gè)簡(jiǎn)單的統(tǒng)計(jì)示例import json from collections import defaultdict token_stats defaultdict(int) def collect_usage(response, task_id): # 假設(shè) response 是 OpenAI 兼容格式 usage response.get(usage, {}) token_stats[task_id] usage.get(total_tokens, 0) return response # 每次請(qǐng)求后調(diào)用 collect_usage # 最終匯總 total sum(token_stats.values()) print(f總 Token 消耗: {total:,}) print(f實(shí)驗(yàn)次數(shù): {len(token_stats)}) print(f平均每次 Token: {total / max(1, len(token_stats)):,.0f})更完整的方式是把每次請(qǐng)求的 usage 寫入 JSONL 日志方便后續(xù)復(fù)盤{task_id: 1, step: 3, prompt_tokens: 12000, completion_tokens: 400, total_tokens: 12400}5.2 Token 消耗異常怎么定位當(dāng)總 Token 量遠(yuǎn)高于預(yù)期時(shí)先不要急著懷疑模型“話太多”可以按下面幾步排查第一步看是否歷史消息被反復(fù)拼進(jìn)新請(qǐng)求。很多 Agent 框架會(huì)把全部歷史發(fā)給模型任務(wù)越長(zhǎng)單次請(qǐng)求的輸入 Token 線性增長(zhǎng)。第二步看工具返回內(nèi)容是否過大。比如模型讀取了一個(gè) 10MB 的 CSV 文件這部分內(nèi)容會(huì)全部進(jìn)入上下文。第三步看是否有無效重試。某些情況下同一個(gè)錯(cuò)誤會(huì)讓模型反復(fù)嘗試每次都重新請(qǐng)求造成 Token 重復(fù)消耗。第四步看 System Prompt 是否穩(wěn)定。如果每次請(qǐng)求都重新帶同一段很長(zhǎng)的提示詞固定開銷會(huì)被放大。一個(gè)實(shí)用經(jīng)驗(yàn)是當(dāng)自動(dòng)研究任務(wù)的上下文超過模型窗口的 70% 時(shí)要及時(shí)做摘要壓縮而不是繼續(xù)追加?？梢宰屇Ｐ桶阎暗闹虚g結(jié)果壓縮成結(jié)構(gòu)化要點(diǎn)再帶入下一輪。5.3 降低 Token 消耗的常用手段在實(shí)際項(xiàng)目中可以從幾個(gè)方向控制 Token控制歷史范圍只保留最近三輪對(duì)話更早的內(nèi)容做摘要。限制日志讀取用tail只讀取最后 50 行日志而不是整份文件。結(jié)構(gòu)化輸出強(qiáng)制模型用 JSON 返回關(guān)鍵字段避免冗長(zhǎng)敘述。批量處理把多個(gè)小實(shí)驗(yàn)合并到一個(gè)腳本里執(zhí)行減少交互輪次。緩存系統(tǒng)提示詞如果能用 Prompt Caching可減少重復(fù)部分的開銷。這里要特別提醒Token 控制不能極端。過度壓縮上下文會(huì)讓模型丟失關(guān)鍵信息導(dǎo)致實(shí)驗(yàn)失敗次數(shù)增加反而消耗更多 Token。要在“上下文完整度”和“Token 成本”之間找平衡。6. 常見問題與排查清單把 Autoresearch 從實(shí)驗(yàn)階段推到穩(wěn)定運(yùn)行階段大概率會(huì)遇到下面這些問題。我整理成一張排查表方便你對(duì)照處理問題現(xiàn)象常見原因解決思路CUDA out of memory多個(gè)任務(wù)并發(fā)搶顯存設(shè)置 CUDA_VISIBLE_DEVICES 隔離設(shè)備或串行執(zhí)行nvidia-smi 看不到 GPU驅(qū)動(dòng)未裝好或 WSL 版本不匹配升級(jí) NVIDIA 驅(qū)動(dòng)重啟 WSL 后再檢查failed to initialize nvmlWSL 下 GPU 訪問被系統(tǒng)攔截更新 Windows 側(cè)驅(qū)動(dòng)確認(rèn) WSL 內(nèi)可訪問 GPUOllama 沒識(shí)別 GPU未裝 GPU 版依賴或環(huán)境變量不對(duì)檢查 OLLAMA_NUM_GPU 或換成帶 CUDA 的版本Token 消耗異常高歷史消息累積 / 日志讀取太大做上下文壓縮限制工具返回內(nèi)容實(shí)驗(yàn)反復(fù)失敗同一錯(cuò)誤模型沒有獲得足夠錯(cuò)誤信息在 prompt 中要求讀取完整 error tracebackGPU 利用率低跑得慢推理和實(shí)驗(yàn)共用一張卡業(yè)務(wù)量大時(shí)增加 GPU或調(diào)整調(diào)度策略6.1 WSL 環(huán)境下的 GPU 訪問問題Windows 上開發(fā)的同學(xué)經(jīng)常會(huì)碰到 WSL 和 GPU 相關(guān)的坑。最典型的是failed to initialize nvml: gpu access blocked by the operating system出現(xiàn)這個(gè)報(bào)錯(cuò)時(shí)優(yōu)先確認(rèn)# WSL 內(nèi)檢查 GPU nvidia-smi # Windows 側(cè)檢查驅(qū)動(dòng)版本 nvidia-smi如果 Windows 側(cè)正常WSL 側(cè)報(bào)錯(cuò)或看不到 GPU通常是驅(qū)動(dòng)版本與 WSL 不兼容。解決方法是在 Windows 安裝最新版 NVIDIA 驅(qū)動(dòng)然后在 PowerShell 里重啟 WSLwsl --shutdown重新進(jìn)入 WSL 后再次運(yùn)行nvidia-smi。這個(gè)問題通常是環(huán)境級(jí)問題不是代碼問題不要在 Python 程序里找根因。6.2 顯存不足的處理思路顯存不足是自動(dòng)研究任務(wù)里最常見的挫敗點(diǎn)。碰到 OOM可以先看nvidia-smi判斷是整體顯存不足還是碎片化導(dǎo)致分配失敗整體顯存不足減小 batch size、降低序列長(zhǎng)度、換更小的模型。顯存碎片化重啟進(jìn)程或使用 PyTorch 的顯存緩存清理。多個(gè)進(jìn)程共用考慮把 GPU 設(shè)備編號(hào)固定到進(jìn)程避免互相搶占。也可以用一個(gè)小腳本監(jiān)控顯存變化# 每 2 秒刷新一次顯存狀態(tài) watch -n 2 nvidia-smi如果自動(dòng)研究任務(wù)跑了幾百次實(shí)驗(yàn)建議把free -m和顯存占用寫入日志方便事后分析是哪一步造成顯存峰值。7. 自動(dòng)研究任務(wù)的最佳實(shí)踐與工程建議7.1 任務(wù)拆解與實(shí)驗(yàn)編號(hào)Autoresearch 跑久之后最大的問題不是“跑不通”而是“跑過了卻不知道哪條路徑有效”。建議從任務(wù)開始就建立實(shí)驗(yàn)編號(hào)規(guī)則比如EXP-20250101-001這種格式。每個(gè)實(shí)驗(yàn)編號(hào)對(duì)應(yīng)一組參數(shù)、代碼版本、結(jié)果摘要和 Token 消耗形成可回溯的記錄。一種簡(jiǎn)單的實(shí)驗(yàn)記錄方式import csv experiment_records [] def record_experiment(exp_id, task_name, params, token_used, status): experiment_records.append({ exp_id: exp_id, task_name: task_name, params: json.dumps(params), token_used: token_used, status: status }) # 運(yùn)行結(jié)束后寫入 CSV with open(experiments.csv, w, newline) as f: writer csv.DictWriter(f, fieldnamesexperiment_records[0].keys()) writer.writeheader() writer.writerows(experiment_records)不要把實(shí)驗(yàn)記錄散落在各個(gè)腳本里。統(tǒng)一入口、統(tǒng)一字段后面復(fù)盤才有據(jù)可查。7.2 日志與 Checkpoint自動(dòng)研究任務(wù)可能運(yùn)行幾天甚至幾周任何中斷都可能導(dǎo)致 Token 白白浪費(fèi)。建議每個(gè)實(shí)驗(yàn)步驟都寫日志日志要包含時(shí)間戳、執(zhí)行命令、退出碼、關(guān)鍵輸出。中間結(jié)果定期存成文件比如checkpoint.json。進(jìn)程崩潰后可以從最近一個(gè) checkpoint 繼續(xù)而不是從頭開始跑。對(duì)每個(gè)實(shí)驗(yàn)保存一個(gè)config.yaml記錄當(dāng)前使用的模型、GPU 編號(hào)、Token 上下文長(zhǎng)度等。這樣即使任務(wù)跑到第 800 次實(shí)驗(yàn)時(shí)被中斷也能從第 700 次的位置恢復(fù)而不是重新消耗前面 700 次的 Token。7.3 GPU 資源治理原則在團(tuán)隊(duì)或多任務(wù)項(xiàng)目中GPU 是寶貴資源建議遵守幾條原則最小權(quán)限每個(gè)任務(wù)只申請(qǐng)自己需要的顯存量不要默認(rèn)占滿整張卡。顯存預(yù)留重要推理服務(wù)固定占一塊卡或部分顯存避免被實(shí)驗(yàn)任務(wù)擠掉。設(shè)備隔離通過CUDA_VISIBLE_DEVICES明確指定任務(wù)可見的 GPU減少不確定性。資源回收任務(wù)結(jié)束后及時(shí)清理進(jìn)程防止僵尸進(jìn)程占用顯存。成本記賬把每次實(shí)驗(yàn)的 GPU 使用時(shí)長(zhǎng)和 Token 消耗記錄到同一份日志方便量化成本。7.4 自動(dòng)化與人工審核的邊界Autoresearch 再“自動(dòng)”也要有邊界意識(shí)。關(guān)鍵節(jié)點(diǎn)建議設(shè)置人工確認(rèn)例如涉及刪除文件、重寫配置文件、修改生產(chǎn)環(huán)境時(shí)必須暫停確認(rèn)。當(dāng)模型連續(xù)多次嘗試同一失敗方案時(shí)應(yīng)觸發(fā)熔斷機(jī)制而不是無限重試。最終報(bào)告的指標(biāo)和結(jié)論需要人工復(fù)核后才能作為事實(shí)引用。如果任務(wù)可能產(chǎn)生高額 Token 費(fèi)用設(shè)置預(yù)算上限超過上限自動(dòng)停跑。這些邊界不是規(guī)則而是為了防范 AI 在自動(dòng)研究中“一本正經(jīng)地犯錯(cuò)”。8. 從一次實(shí)驗(yàn)復(fù)盤到可復(fù)用的研究系統(tǒng)回到開頭那組數(shù)據(jù)1293 次實(shí)驗(yàn)、779M Token、GPUMode 3rd。它們其實(shí)回答了三個(gè)問題實(shí)驗(yàn)次數(shù)足夠多說明模型不是一次成功的而是通過大量試錯(cuò)逼近結(jié)果。Token 消耗足夠大說明任務(wù)復(fù)雜度高上下文交互頻繁。GPU 模式調(diào)整到第三輪說明基礎(chǔ)設(shè)施的穩(wěn)定性和任務(wù)規(guī)模強(qiáng)相關(guān)。如果把 Autoresearch 當(dāng)成一個(gè)長(zhǎng)期使用的系統(tǒng)建議你從這組數(shù)據(jù)中提煉出自己的指標(biāo)基線。比如平均每次實(shí)驗(yàn)消耗多少 Token實(shí)驗(yàn)失敗率是多少平均每個(gè)任務(wù)需要多少輪 GPU 調(diào)度單 GPU 能支撐多少個(gè)并發(fā)實(shí)驗(yàn)有了這些基線之后的項(xiàng)目就能提前預(yù)估成本、判斷瓶頸、優(yōu)化調(diào)度策略而不是跑完才發(fā)現(xiàn)資源不夠或費(fèi)用超支。下一步可以學(xué)習(xí)的方向包括深入 PyTorch CUDA 內(nèi)存管理、掌握 vLLM 或 Ollama 的推理服務(wù)調(diào)優(yōu)、學(xué)習(xí) LangGraph 或自研 Agent 框架的狀態(tài)管理機(jī)制以及研究 Prompt 壓縮和上下文蒸餾技術(shù)。對(duì)大部分團(tuán)隊(duì)來說Autoresearch 的技術(shù)突破口往往不在“模型理解能力”上而是在 Token 成本和 GPU 資源調(diào)度上。先把這兩件事做扎實(shí)自動(dòng)研究才能從“能跑”變成“可持續(xù)跑”。