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