第一次看到0.2B 參數(shù)、32Hz 實(shí)時(shí)推理、RTX 4090 上只要 0.9GB 顯存這三個(gè)數(shù)字?jǐn)[在一起的時(shí)候我的第一反應(yīng)是核對(duì)單位寫(xiě)錯(cuò)了。原因很樸素在視覺(jué)-語(yǔ)言-動(dòng)作Vision-Language-ActionVLA這條線上混過(guò)一段時(shí)間的人都知道實(shí)時(shí)性從來(lái)不是參數(shù)量單獨(dú)決定的顯存占用也從來(lái)不是一個(gè)能被簡(jiǎn)單除以參數(shù)量算出來(lái)的數(shù)。TurboVLA 這個(gè)組合之所以值得拿出來(lái)聊恰恰是因?yàn)樗瑫r(shí)踩中了三個(gè)通?；ハ啻蚣艿闹笜?biāo)——模型要小、頻率要高、顯存要省——而它給出的答卷看起來(lái)像是把三者的矛盾給繞過(guò)去了。這篇文章想做的事情不是復(fù)述一遍參數(shù)表而是把0.2B / 32Hz / 0.9GB這組數(shù)字背后的工程賬拆開(kāi)算一遍一個(gè)控制周期里時(shí)間到底花在哪顯存到底被誰(shuí)吃掉了想在自己的機(jī)器上復(fù)現(xiàn)這套鏈路需要注意哪些細(xì)節(jié)以及實(shí)測(cè)中最容易翻車的那幾個(gè)地方。內(nèi)容覆蓋實(shí)時(shí)推理的延遲拆解、顯存統(tǒng)計(jì)口徑、低顯存部署的取舍、動(dòng)作隊(duì)列與時(shí)間戳對(duì)齊、LoRA 微調(diào)的顯存預(yù)算等適合已經(jīng)在跑 VLA 或者準(zhǔn)備把某個(gè)策略模型塞進(jìn)真實(shí)控制回路的讀者也適合剛接觸這塊、想知道為什么大家都在摳毫秒和兆字節(jié)的朋友。1. 0.2B 參數(shù)跑到 32Hz這個(gè)組合真正的難點(diǎn)在哪1.1 把 32Hz 翻譯成毫秒預(yù)算討論實(shí)時(shí)推理最忌諱用幀率這個(gè)詞籠統(tǒng)地說(shuō)事因?yàn)閹手幻枋鼋Y(jié)果不描述約束。32Hz 的意思是每 31.25 毫秒必須完整走完一次取圖—編碼—推理—出動(dòng)作的閉環(huán)而且不是平均值 31.25ms是每一次都要在這個(gè)窗口內(nèi)結(jié)束。這兩者的差別在控制場(chǎng)景里是致命的平均值達(dá)標(biāo)、尾部抖動(dòng)到 100ms 的系統(tǒng)機(jī)械臂該抖還是會(huì)抖抓取該掉還是會(huì)掉。我把 31.25ms 切成幾段來(lái)看會(huì)更清楚。相機(jī)曝光與傳輸大概 2 到 5ms取決于曝光時(shí)間和傳輸接口圖像預(yù)處理在 CPU 上通常 1 到 3ms視覺(jué)編碼器前向 3 到 6ms動(dòng)作頭加上采樣步數(shù) 5 到 15ms動(dòng)作下發(fā)與通信 1 到 3ms剩下的是框架調(diào)度和 Python 層面的固定開(kāi)銷。你會(huì)發(fā)現(xiàn)真正留給神經(jīng)網(wǎng)絡(luò)計(jì)算的預(yù)算可能只有 15ms 左右剩下的全被工程細(xì)節(jié)吃掉了。所以當(dāng)我看到 TurboVLA 宣稱 32Hz 的時(shí)候我關(guān)注的不是它用了多大的模型而是它有沒(méi)有把那些看不見(jiàn)的開(kāi)銷摁住。一個(gè) 0.2B 的模型在 RTX 4090 上做單次前向理論算力根本不是瓶頸瓶頸永遠(yuǎn)在別處。1.2 參數(shù)小不等于跑得快VLA 的瓶頸在別處很多人有個(gè)直覺(jué)參數(shù)少就等于快。這個(gè)直覺(jué)在半對(duì)半錯(cuò)之間。參數(shù)量決定了權(quán)重讀取的帶寬需求和計(jì)算量下限但在小模型區(qū)間0.1B 到 1B單次前向的實(shí)際耗時(shí)往往被三件事主導(dǎo)一是 kernel 啟動(dòng)開(kāi)銷與框架調(diào)度二是序列長(zhǎng)度帶來(lái)的注意力計(jì)算三是采樣/解碼的迭代次數(shù)。第一條最容易被忽略。一次前向如果被拆成幾百個(gè)小 kernel每個(gè) kernel 啟動(dòng)哪怕只要幾微秒累加起來(lái)也是幾毫秒而這幾毫秒在 31.25ms 的預(yù)算里占掉了兩成。第二條是 VLA 特有的痛點(diǎn)視覺(jué) token 數(shù)量往往遠(yuǎn)多于語(yǔ)言 token224×224 分辨率、patch size 14 的 ViT切出來(lái)就是 256 個(gè) token如果再拼上語(yǔ)言指令和狀態(tài)向量序列很容易沖到 400 以上。注意力是 O(n2) 的序列一漲延遲就非線性上漲。第三條則取決于動(dòng)作頭設(shè)計(jì)——如果是擴(kuò)散策略或者流匹配采樣步數(shù)是直接乘在延遲上的。把這三條擺出來(lái)TurboVLA 的設(shè)計(jì)取向就基本能猜到了視覺(jué) token 要做壓縮或池化動(dòng)作頭要么步數(shù)極少要么干脆單步出框架層面要盡量用 CUDA Graph 之類的手段把調(diào)度開(kāi)銷攤平。這三點(diǎn)也是我在自己項(xiàng)目里優(yōu)化任何 VLA 時(shí)最先動(dòng)刀的地方順序基本不會(huì)錯(cuò)。1.3 一個(gè)經(jīng)常被引用的反例我見(jiàn)過(guò)不少團(tuán)隊(duì)在優(yōu)化時(shí)先去換更小的骨干網(wǎng)絡(luò)把 3B 換成 1B結(jié)果端到端只快了 15%。原因就是上面說(shuō)的瓶頸不在算力。反倒是把圖像分辨率從 448 降到 224、把序列長(zhǎng)度砍掉一半之后延遲直接掉到原來(lái)的六成。這個(gè)順序上的錯(cuò)誤很常見(jiàn)值得單獨(dú)提一句先測(cè)各段耗時(shí)占比再?zèng)Q定優(yōu)化對(duì)象別憑直覺(jué)換模型。2. VLA 推理耗時(shí)的拆解一個(gè)控制周期里時(shí)間都去哪了2.1 從相機(jī)曝光到動(dòng)作下發(fā)的完整鏈路把鏈路完整寫(xiě)出來(lái)你會(huì)對(duì)實(shí)時(shí)有更具體的感受。典型的一條鏈路是這樣的觸發(fā)相機(jī)采集 → 驅(qū)動(dòng)層把圖像拷到用戶空間 → 格式轉(zhuǎn)換與歸一化 → 縮放與裁剪 → 轉(zhuǎn)成張量 → 拷到 GPU → 視覺(jué)編碼 → 與語(yǔ)言指令、本體狀態(tài)拼接 → 動(dòng)作頭前向 → 反歸一化 → 下發(fā)到執(zhí)行器。這條鏈里跨 PCIe 的拷貝、CPU 上的格式轉(zhuǎn)換、以及沒(méi)做異步處理的同步等待是最容易累積延遲的三處。我自己的習(xí)慣是給每一段都打上時(shí)間戳跑一千個(gè)周期之后看 P50、P90、P99 三個(gè)分位數(shù)。只看平均值的優(yōu)化等于沒(méi)做優(yōu)化因?yàn)榭刂苹芈肥菍?duì)尾延遲敏感的。很多時(shí)候你會(huì)發(fā)現(xiàn) P50 很漂亮P99 卻因?yàn)榕紶栆淮蔚睦厥栈蛘邇?nèi)存分配漲到正常值的五倍。下面這段代碼是我常用的一個(gè)最小計(jì)時(shí)骨架直接嵌在推理循環(huán)里不引入額外依賴import time import torch torch.inference_mode() def control_step(obs_img, state, instruction, preprocess, model): t0 time.perf_counter() image preprocess(obs_img) # CPU 側(cè)固定 dtype 與通道順序 t1 time.perf_counter() token model.encode_vision(image) # 視覺(jué)編碼 t2 time.perf_counter() action_chunk model.predict_actions(token, state, instruction) t3 time.perf_counter() stats { preprocess_ms: (t1 - t0) * 1000, vision_ms: (t2 - t1) * 1000, action_ms: (t3 - t2) * 1000, total_ms: (t3 - t0) * 1000, } return action_chunk, stats這段代碼本身沒(méi)什么技術(shù)含量但它是所有后續(xù)優(yōu)化的前提。沒(méi)有分位數(shù)統(tǒng)計(jì)你根本不知道自己在優(yōu)化什么。2.2 視覺(jué)編碼器、動(dòng)作頭、采樣步數(shù)這三塊大頭視覺(jué)編碼器的耗時(shí)和 token 數(shù)量幾乎線性相關(guān)而 token 數(shù)量是分辨率除以 patch size 再平方。224/14 得到 16×16256448/14 得到 32×321024四倍差距。所以分辨率是第一個(gè)該動(dòng)刀的地方前提是任務(wù)本身不需要那么細(xì)的紋理信息——抓取大件物體和插拔細(xì)線纜對(duì)分辨率的要求完全不同。動(dòng)作頭這塊目前的常見(jiàn)做法有兩類。一類是把動(dòng)作離散化成 token用自回歸的方式逐個(gè)吐出來(lái)好處是能復(fù)用語(yǔ)言模型的解碼邏輯壞處是每一步都要過(guò)一次前向動(dòng)作維度一高就慢。另一類是連續(xù)動(dòng)作的生成式方法比如擴(kuò)散策略或者流匹配靠迭代去噪出動(dòng)作好處是動(dòng)作平滑、多模態(tài)表達(dá)能力強(qiáng)壞處是采樣步數(shù)直接乘在延遲上。流匹配在 1 到 4 步就能出可用動(dòng)作這是它比傳統(tǒng)擴(kuò)散更適合實(shí)時(shí)場(chǎng)景的關(guān)鍵原因。如果 TurboVLA 能在 32Hz 下工作動(dòng)作頭的采樣步數(shù)大概率被壓到了個(gè)位數(shù)甚至可能是單步。這一點(diǎn)對(duì)復(fù)現(xiàn)的人很重要如果你照著某個(gè)開(kāi)源實(shí)現(xiàn)默認(rèn)的 10 步采樣去跑延遲會(huì)直接翻兩三倍然后你會(huì)誤判成這個(gè)模型根本跑不到實(shí)時(shí)。2.3 Python 側(cè)開(kāi)銷那些看不見(jiàn)的 10 毫秒這一節(jié)是我最想強(qiáng)調(diào)的因?yàn)樗罘粗庇X(jué)。一個(gè)已經(jīng)算得很干凈的模型端到端卻跑不到 30Hz八成是 Python 和框架層面在拖后腿。常見(jiàn)的元兇有這些每步都新建張量導(dǎo)致的分配開(kāi)銷、.item()或.cpu()觸發(fā)的隱式同步、日志打印、隨機(jī)數(shù)生成、以及沒(méi)開(kāi)torch.inference_mode()導(dǎo)致自動(dòng)求導(dǎo)圖被偷偷構(gòu)建。.item()這一條尤其隱蔽。它本身只要幾微秒但它會(huì)把異步的 CUDA 隊(duì)列強(qiáng)制同步本來(lái)可以流水線重疊的計(jì)算被硬生生串行化實(shí)測(cè)中造成 5 到 10ms 的額外延遲非常常見(jiàn)。同理把張量搬到 CPU 再算損失或者做判斷也是同一個(gè)坑。我在實(shí)際項(xiàng)目里做過(guò)一次對(duì)比同一份推理代碼只做三件事——開(kāi)inference_mode、把日志從每步輸出改成每百步輸出、把所有.item()從主循環(huán)里挪走——端到端延遲從 48ms 降到 31ms。模型一行沒(méi)改。這個(gè)比例放在 32Hz 的語(yǔ)境下就是能跑和不能跑的區(qū)別。3. 0.9GB 顯存賬單怎么算出來(lái)的3.1 權(quán)重、KV 緩存、激活值、上下文開(kāi)銷逐項(xiàng)拆先做一個(gè)粗算看看 0.9GB 這個(gè)數(shù)是否合理。0.2B 參數(shù)如果用 FP16 存權(quán)重是 0.2×10?×2 字節(jié) 400MB約 0.39GB。如果部分層用 INT8 或者 FP8權(quán)重能壓到 200MB 上下。這部分是死的跑不掉。KV 緩存是變量。假設(shè)模型 16 層、隱藏維度 768那么每個(gè) token 的 KV 緩存是 2×16×768×2 字節(jié) ≈ 49KB。序列長(zhǎng)度 512 的話就是 25MB序列長(zhǎng)度 2048 就是 100MB。對(duì)一個(gè)小模型來(lái)說(shuō)KV 緩存完全不是主要矛盾這也解釋了為什么在 0.2B 這個(gè)量級(jí)上長(zhǎng)上下文不會(huì)像在大模型上那樣直接把顯存吃爆。激活值是另一塊。前向過(guò)程中中間張量的峰值占用和 batch size、序列長(zhǎng)度、隱藏維度都相關(guān)。做實(shí)時(shí)推理時(shí) batch 通常就是 1序列也不會(huì)太長(zhǎng)所以激活峰值一般在幾十 MB 量級(jí)除非視覺(jué)編碼器那邊分辨率開(kāi)得很高。真正容易被漏掉的是上下文開(kāi)銷。CUDA context、cuDNN/cuBLAS 的 workspace、PyTorch 的緩存分配器這些加在一起在消費(fèi)級(jí)卡上通常是 300 到 600MB。這個(gè)數(shù)字和模型完全無(wú)關(guān)只要你初始化了 CUDA 就會(huì)占。所以一個(gè)0.9GB的讀數(shù)里可能有三分之一到一半根本不是模型本身。3.2 顯存數(shù)字的口徑問(wèn)題nvidia-smi 與 torch 統(tǒng)計(jì)的差異這是我特別想提醒的一點(diǎn)不同工具給出的顯存數(shù)字可以差出一倍比較之前一定要先對(duì)齊口徑。統(tǒng)計(jì)方式統(tǒng)計(jì)對(duì)象典型差異來(lái)源nvidia-smi進(jìn)程占用的全部顯存包含 CUDA context、緩存分配器保留塊、碎片torch.cuda.memory_allocated()當(dāng)前活躍張量不含緩存分配器保留的空閑塊torch.cuda.memory_reserved()分配器向驅(qū)動(dòng)申請(qǐng)的總量通常大于 allocated反映緩存水位torch.cuda.max_memory_allocated()峰值活躍張量最接近模型真實(shí)需求的口徑舉個(gè)具體例子一個(gè)模型用nvidia-smi看是 1.6GB用max_memory_allocated看可能只有 0.85GB中間那 0.75GB 是上下文開(kāi)銷加上分配器為了減少碎片而保留的空閑塊。所以當(dāng)你看到0.9GB這個(gè)數(shù)的時(shí)候先問(wèn)一句這是哪個(gè)口徑的讀數(shù)否則拿它去和自己的 1.5GB 對(duì)比結(jié)論會(huì)完全跑偏。想干凈地測(cè)一次可以按這個(gè)順序來(lái)import torch torch.cuda.empty_cache() torch.cuda.reset_peak_memory_stats() model load_model(...) # 加載權(quán)重 _ warmup(model) # 預(yù)熱觸發(fā) kernel 編譯與緩存分配 start torch.cuda.memory_allocated() out model.infer(dummy_input) # 跑一次真實(shí)推理 print(權(quán)重與常駐:, (start) / 1024**3, GB) print(峰值活躍 :, torch.cuda.max_memory_allocated() / 1024**3, GB) print(分配器保留:, torch.cuda.max_memory_reserved() / 1024**3, GB)預(yù)熱這一步不能省。第一次前向會(huì)觸發(fā) kernel 自動(dòng)調(diào)優(yōu)、cuDNN 算法選擇、以及各種惰性初始化測(cè)出來(lái)的峰值會(huì)明顯偏高。3.3 想自己驗(yàn)證的話幾組值得記錄的指標(biāo)如果打算長(zhǎng)期維護(hù)這套推理鏈路我建議把下面這幾組指標(biāo)做成常駐監(jiān)控它們能幫你在問(wèn)題變嚴(yán)重之前發(fā)現(xiàn)苗頭峰值顯存max_memory_allocated跨版本升級(jí)、換精度之后必看能直接反映回歸。顯存保留量與活躍量的差值差值持續(xù)增大說(shuō)明碎片在累積長(zhǎng)時(shí)間運(yùn)行后可能 OOM。單步延遲的 P50 / P90 / P99只看平均會(huì)漏掉抖動(dòng)問(wèn)題。GPU 利用率與 SM 占用利用率長(zhǎng)期偏低說(shuō)明瓶頸在 CPU 側(cè)。每秒推理次數(shù)與丟幀數(shù)丟幀數(shù)是控制穩(wěn)定性的直接指標(biāo)。順便說(shuō)一句如果你懷疑顯存本身有硬件問(wèn)題比如跑長(zhǎng)任務(wù)時(shí)隨機(jī)報(bào)錯(cuò)、或者同樣的任務(wù)在不同機(jī)器上表現(xiàn)不一致業(yè)界確實(shí)有一些底層顯存檢測(cè)工具可以做壓力測(cè)試思路是反復(fù)寫(xiě)入讀出并校驗(yàn)。這類工具屬于硬件排障范疇和模型優(yōu)化是兩條線別混在一起用。4. 把 TurboVLA 跑起來(lái)環(huán)境準(zhǔn)備與最小推理腳本4.1 依賴與版本對(duì)齊小模型的部署最大的坑往往不在模型而在版本組合。我踩過(guò)的最典型的一次是PyTorch 版本和 CUDA 版本匹配但 flash attention 的實(shí)現(xiàn)和 PyTorch 版本不匹配結(jié)果是能跑通但速度只有應(yīng)有的三分之一而且精度還有細(xì)微偏差。這種問(wèn)題不會(huì)報(bào)錯(cuò)只會(huì)讓你懷疑模型本身。幾條實(shí)操建議一是把環(huán)境固定下來(lái)用torch.__version__、torch.version.cuda、torch.cuda.get_device_capability()三個(gè)值記錄基線換機(jī)器時(shí)先比對(duì)二是優(yōu)先用官方推薦的組合不要自己拼新版本三是如果用到量化和編譯加速組件注意它們對(duì) PyTorch 小版本通常非常敏感鎖死版本比追新重要得多。4.2 權(quán)重加載與精度選擇在 RTX 4090 這類消費(fèi)級(jí)卡上精度選擇有個(gè)實(shí)用的原則**權(quán)重可以量化注意力和歸一化層盡量保持 FP16/BF16。**原因是動(dòng)作輸出對(duì)數(shù)值精度比較敏感把注意力全部降到 INT8 有時(shí)會(huì)導(dǎo)致動(dòng)作出現(xiàn)細(xì)微漂移這種漂移在單次測(cè)試中看不出來(lái)但會(huì)隨著控制步數(shù)累積表現(xiàn)出來(lái)就是機(jī)械臂末端慢慢偏移目標(biāo)點(diǎn)。另外要注意 BF16 和 FP16 的選擇。4090 對(duì)兩者都支持BF16 動(dòng)態(tài)范圍更大、更不容易溢出FP16 在某些 kernel 上速度略快。如果訓(xùn)練用的是 BF16推理就別隨手改成 FP16數(shù)值分布的細(xì)微差異經(jīng)過(guò)動(dòng)作頭放大之后可能變成肉眼可見(jiàn)的行為差異。這一點(diǎn)在復(fù)現(xiàn)別人模型時(shí)特別重要。4.3 一段可以直接改的最小推理循環(huán)下面是我整理的一個(gè)最小可用推理循環(huán)結(jié)構(gòu)上刻意保持簡(jiǎn)單方便你往里加?xùn)|西import time import torch import collections torch.inference_mode().__enter__() torch.backends.cudnn.benchmark True model load_model(ckpt_path, dtypetorch.bfloat16, devicecuda) model.eval() # 用滑動(dòng)窗口記錄延遲避免每步都做同步 lat collections.deque(maxlen200) action_queue collections.deque() def loop(camera, robot, instruction, target_hz32): period 1.0 / target_hz next_tick time.perf_counter() while robot.is_running(): now time.perf_counter() if now next_tick: time.sleep(max(0.0, next_tick - now)) next_tick period img camera.capture() # 建議走零拷貝路徑 if len(action_queue) 2: # 隊(duì)列快空了才推理 t0 time.perf_counter() chunk model.predict_actions(img, robot.state(), instruction) lat.append((time.perf_counter() - t0) * 1000) action_queue.extend(chunk.tolist()) action action_queue.popleft() robot.send(action, timestamptime.perf_counter())循環(huán)里有三個(gè)設(shè)計(jì)點(diǎn)值得說(shuō)。第一time.sleep用于對(duì)齊節(jié)拍但不要指望它精確真實(shí)系統(tǒng)里更穩(wěn)的做法是配合一個(gè)高精度定時(shí)器或者實(shí)時(shí)線程。第二推理觸發(fā)條件是隊(duì)列快空了而不是每幀都推理這就是動(dòng)作塊action chunking的思想——一次推理出一小段動(dòng)作執(zhí)行若干步之后再推下一次。第三動(dòng)作下發(fā)帶時(shí)間戳方便下游做延遲補(bǔ)償。這三點(diǎn)在后面還會(huì)展開(kāi)。4.4 第一次跑通之后應(yīng)該先測(cè)什么很多人跑通第一個(gè) demo 之后就急著上真機(jī)結(jié)果在真機(jī)上遇到一堆沒(méi)法定位的問(wèn)題。我的建議是跑通之后按這個(gè)順序測(cè)先在固定輸入下測(cè)延遲分位數(shù)確認(rèn) P99 在預(yù)算內(nèi)再喂一段錄制的回放數(shù)據(jù)確認(rèn)動(dòng)作輸出穩(wěn)定、不抖然后空跑機(jī)械臂執(zhí)行動(dòng)作不接觸任何物體看軌跡是否平滑最后才上真實(shí)任務(wù)。這個(gè)順序能幫你把模型問(wèn)題和系統(tǒng)問(wèn)題分開(kāi)省掉大量排查時(shí)間。5. 32Hz 穩(wěn)定性靠什么守住幀率抖動(dòng)、動(dòng)作隊(duì)列與時(shí)間戳5.1 平均幀率好看不代表控制穩(wěn)控制回路里的抖動(dòng)jitter比平均延遲更值得關(guān)注。原因在于執(zhí)行器是按固定節(jié)拍消費(fèi)動(dòng)作的如果你的推理時(shí)不時(shí)慢一拍執(zhí)行器就會(huì)收到相鄰兩步之間間隔不均的動(dòng)作序列表現(xiàn)出來(lái)就是抖動(dòng)或者過(guò)沖。32Hz 意味著每 31.25ms 一個(gè)動(dòng)作點(diǎn)如果其中某一次的延遲漲到 60ms那一瞬間整個(gè)節(jié)奏就亂了。實(shí)測(cè)中造成抖動(dòng)的原因排個(gè)序大概是垃圾回收、顯存分配與釋放、操作系統(tǒng)調(diào)度、以及隨機(jī)出現(xiàn)的后臺(tái)任務(wù)。對(duì)付前兩個(gè)的辦法是預(yù)分配和對(duì)象復(fù)用——把輸入輸出張量提前開(kāi)好每步只做原地寫(xiě)入避免分配器反復(fù)申請(qǐng)釋放。對(duì)付后兩個(gè)則需要在進(jìn)程優(yōu)先級(jí)和線程模型上做隔離把推理線程和日志、監(jiān)控、網(wǎng)絡(luò)通信這些雜活分開(kāi)。5.2 動(dòng)作塊與隊(duì)列設(shè)計(jì)動(dòng)作塊是解決實(shí)時(shí)性最有效的一招道理很簡(jiǎn)單把每步都要推理變成每若干步推理一次推理的延遲預(yù)算立刻寬松好幾倍。假設(shè)一次推理出 8 個(gè)動(dòng)作以 32Hz 執(zhí)行那么推理本身只需要在 250ms 內(nèi)完成就行而不是 31.25ms。這個(gè)空間足夠讓模型跑得更從容也足夠讓實(shí)現(xiàn)上不那么極限。但動(dòng)作塊有它自己的代價(jià)。開(kāi)環(huán)執(zhí)行多步意味著模型看不到中間的狀態(tài)變化如果環(huán)境變化快或者模型預(yù)測(cè)偏保守中間幾步就可能出問(wèn)題。常見(jiàn)的折中是塊長(zhǎng)取 4 到 16隊(duì)列低于水位閾值時(shí)提前推理同時(shí)保留一個(gè)緊急重規(guī)劃的入口——檢測(cè)到狀態(tài)偏離閾值時(shí)立刻清空隊(duì)列重新推理。這個(gè)閾值怎么定得看具體任務(wù)容忍度抓取大件物體可以放寬松精細(xì)裝配就得收緊。5.3 時(shí)間戳對(duì)齊與丟棄策略只要鏈路里存在延遲動(dòng)作下發(fā)的時(shí)候就必須帶時(shí)間戳。原因有二一是執(zhí)行器可以用時(shí)間戳做插值把不均勻的動(dòng)作點(diǎn)映射到均勻的控制節(jié)拍上二是當(dāng)某個(gè)動(dòng)作已經(jīng)過(guò)期超過(guò)容忍延遲才輪到執(zhí)行時(shí)系統(tǒng)應(yīng)該知道該丟棄它而不是硬著頭皮執(zhí)行。過(guò)期動(dòng)作判定的容忍度一般取一到兩個(gè)控制周期比如 32Hz 下就是 30 到 60ms。這個(gè)邏輯寫(xiě)進(jìn)循環(huán)就是幾行代碼但它能顯著降低真機(jī)上偶發(fā)的怪動(dòng)作——那些讓人覺(jué)得模型突然抽風(fēng)了的時(shí)刻事后復(fù)盤(pán)往往發(fā)現(xiàn)是一個(gè)延遲很久的動(dòng)作被延遲執(zhí)行了。6. 低顯存部署踩坑記錄從精度漂移到顯存碎片6.1 動(dòng)作反歸一化統(tǒng)計(jì)量錯(cuò)位這是 VLA 部署里最高頻、也最難查的一類問(wèn)題。模型訓(xùn)練時(shí)動(dòng)作通常做了歸一化推理時(shí)需要拿訓(xùn)練集的統(tǒng)計(jì)量反歸一化回去。如果加載的統(tǒng)計(jì)量和訓(xùn)練時(shí)的不一致比如用錯(cuò)了數(shù)據(jù)集版本、或者分位數(shù)取的是 q01/q99 而不是 min/max模型輸出的動(dòng)作數(shù)值范圍會(huì)整體偏移表現(xiàn)出來(lái)就是機(jī)械臂動(dòng)作幅度不對(duì)或者明顯偏向一側(cè)。排查方法很直接喂一批訓(xùn)練時(shí)的樣本把模型輸出的原始動(dòng)作反歸一化之后和數(shù)據(jù)集里對(duì)應(yīng)的真實(shí)動(dòng)作做逐維對(duì)比。如果某一維的系統(tǒng)性偏差很大八成是統(tǒng)計(jì)量的問(wèn)題而不是模型沒(méi)訓(xùn)好。6.2 圖像通道與預(yù)處理的不一致這個(gè)坑我中過(guò)不止一次。常見(jiàn)的圖像讀取庫(kù)默認(rèn)給出的是 BGR 順序而絕大多數(shù)模型是按 RGB 訓(xùn)練的歸一化時(shí)用的均值方差也可能不一致縮放時(shí)用的插值方式最近鄰、雙線性、雙三次差異在紋理豐富的場(chǎng)景下會(huì)真實(shí)影響輸出。這些問(wèn)題都不會(huì)報(bào)錯(cuò)只會(huì)讓模型表現(xiàn)比預(yù)期差一點(diǎn)。我的做法是把預(yù)處理寫(xiě)成一份獨(dú)立的、可測(cè)試的模塊給它固定輸入然后逐像素比對(duì)參考實(shí)現(xiàn)。花半小時(shí)做這件事能省掉后面好幾天的為什么效果不對(duì)。6.3 量化后的精度漂移定位如果做了量化一定要做逐層誤差對(duì)比。思路是拿若干真實(shí)輸入分別跑一次全精度和量化版本記錄每一層的輸出差異。正常情況下誤差會(huì)在一個(gè)很小的范圍內(nèi)波動(dòng)如果某一層突然放大說(shuō)明那一層不適合量化把它單獨(dú)保留高精度就行。經(jīng)驗(yàn)上以下幾類層比較容易出問(wèn)題第一層和最后一層、做歸一化的層、以及任何涉及指數(shù)運(yùn)算的層。把它們排除在量化范圍外整體顯存增加不多但輸出穩(wěn)定性會(huì)好很多。6.4 顯存碎片與長(zhǎng)時(shí)間運(yùn)行短時(shí)間測(cè)試沒(méi)問(wèn)題、跑幾個(gè)小時(shí)之后 OOM這是碎片化的典型癥狀。PyTorch 的緩存分配器會(huì)盡量復(fù)用塊但如果你的序列長(zhǎng)度、圖像尺寸在不同時(shí)刻有變化分配器就會(huì)保留下不同尺寸的塊長(zhǎng)期下來(lái)保留量越來(lái)越大。處理辦法有幾個(gè)把輸入尺寸和序列長(zhǎng)度固定下來(lái)動(dòng)態(tài)形狀是碎片的主要來(lái)源周期性調(diào)用torch.cuda.empty_cache()但別在主循環(huán)里調(diào)它本身有開(kāi)銷以及監(jiān)控reserved和allocated的差值差值持續(xù)增長(zhǎng)就是要出問(wèn)題的信號(hào)。現(xiàn)象可能原因處理方向短時(shí)間正常數(shù)小時(shí)后 OOM顯存碎片累積固定輸入形狀監(jiān)控 reserved 與 allocated 差值換批次大小時(shí)延遲突增重新觸發(fā) kernel 調(diào)優(yōu)固定形狀并預(yù)熱或提前編譯輸出動(dòng)作整體偏移反歸一化統(tǒng)計(jì)量不匹配用訓(xùn)練樣本逐維比對(duì)原始輸出效果比預(yù)期差一點(diǎn)通道順序或歸一化不一致預(yù)處理模塊化并逐像素比對(duì)降精度后動(dòng)作輕微漂移敏感層被量化逐層誤差分析敏感層保留 FP167. 微調(diào)與擴(kuò)展0.2B 還能再壓榨出什么7.1 LoRA 微調(diào)的顯存預(yù)算小模型微調(diào)在消費(fèi)級(jí)卡上是完全可行的但顯存預(yù)算要算清楚。以 0.2B 為例全參數(shù)微調(diào)時(shí)權(quán)重、梯度、優(yōu)化器狀態(tài)三份加起來(lái)即使在混合精度下也要好幾個(gè) GB還不算激活值。換成 LoRA 之后可訓(xùn)練參數(shù)降到原來(lái)的百分之幾優(yōu)化器狀態(tài)和梯度都跟著大幅縮小主要顯存開(kāi)銷回到激活值和權(quán)重本身。激活值這塊靠梯度檢查點(diǎn)gradient checkpointing來(lái)壓原理是用時(shí)間換空間——前向時(shí)不保存中間激活反向時(shí)重新算一遍。這會(huì)增加大約三成的訓(xùn)練時(shí)間但能把激活顯存降下來(lái)一大截。訓(xùn)練顯存吃緊的時(shí)候先開(kāi)梯度檢查點(diǎn)再考慮降 batch size最后才動(dòng)序列長(zhǎng)度這個(gè)順序?qū)κ諗啃缘挠绊懽钚?。至于用不用現(xiàn)成的高效微調(diào)框架我的看法是如果你的目標(biāo)是快速驗(yàn)證一個(gè)想法用成熟框架省時(shí)間如果要做深入調(diào)參和定制自己寫(xiě)幾十行訓(xùn)練循環(huán)反而更透明、更好調(diào)試。這兩條路沒(méi)有對(duì)錯(cuò)取決于你要的是速度還是可控性。7.2 多任務(wù)與多本體的取舍0.2B 這個(gè)量級(jí)能不能承載多任務(wù)、多本體我的觀察是能但要克制。參數(shù)越少任務(wù)之間的干擾越明顯。如果硬塞進(jìn)十幾個(gè)差異很大的任務(wù)模型很容易在每個(gè)任務(wù)上都表現(xiàn)平庸。比較務(wù)實(shí)的做法是先跑通一到三個(gè)高度相關(guān)的任務(wù)把數(shù)據(jù)質(zhì)量和動(dòng)作空間對(duì)齊這兩件事做扎實(shí)再逐步擴(kuò)展。多本體不同機(jī)械臂、不同自由度的情況更復(fù)雜一些通常需要給模型喂本體標(biāo)識(shí)或者對(duì)動(dòng)作空間做統(tǒng)一映射。這里的取舍很實(shí)際統(tǒng)一映射能讓模型共享知識(shí)但會(huì)引入映射誤差分開(kāi)處理能保持精度但每條線上都要單獨(dú)維護(hù)數(shù)據(jù)和評(píng)估。我傾向于在小模型上先分開(kāi)等數(shù)據(jù)量足夠再考慮統(tǒng)一。7.3 什么時(shí)候該換更大的模型這也是很多人關(guān)心的問(wèn)題尤其在顯存充足的機(jī)器上既然卡夠大為什么不用大模型是很自然的想法。我的判斷標(biāo)準(zhǔn)是看瓶頸在哪。如果失敗案例集中在語(yǔ)義理解層面——比如聽(tīng)不懂復(fù)合指令、分不清相似物體、記不住多步任務(wù)的狀態(tài)——那說(shuō)明模型容量不夠換大模型有收益。但如果失敗集中在執(zhí)行層面——?jiǎng)幼鞑黄交?、抓取位置偏、反?yīng)慢——那換大模型基本沒(méi)用問(wèn)題在數(shù)據(jù)和系統(tǒng)上。現(xiàn)實(shí)里我見(jiàn)到的失敗執(zhí)行層面的比例遠(yuǎn)高于語(yǔ)義層面。所以每次有人問(wèn)要不要換大模型我的回答通常是先把延遲分位數(shù)、動(dòng)作平滑度、數(shù)據(jù)覆蓋度這三個(gè)指標(biāo)查一遍再談模型規(guī)模。8. 實(shí)測(cè)之后的一點(diǎn)個(gè)人體會(huì)折騰這類實(shí)時(shí)策略模型有一段時(shí)間了最深的體會(huì)是把一個(gè)大模型跑起來(lái)和把一個(gè)小模型跑穩(wěn)是兩種完全不同的能力。前者靠資源和耐心后者靠對(duì)每一毫秒、每一兆字節(jié)的敏感度。TurboVLA 這組數(shù)字之所以有意思不在于它把參數(shù)壓到了多小而在于它把一個(gè)完整的 VLA 鏈路壓進(jìn)了 31.25ms 和不到 1GB 的預(yù)算里——這背后必然是視覺(jué) token 壓縮、動(dòng)作頭步數(shù)控制、框架調(diào)度優(yōu)化一整套組合拳而不是單點(diǎn)突破。如果你準(zhǔn)備復(fù)現(xiàn)這套鏈路我的建議是先把測(cè)量工具搭好再去優(yōu)化。分位數(shù)計(jì)時(shí)、顯存分口徑統(tǒng)計(jì)、逐層精度對(duì)比這三樣?xùn)|西花不了多少時(shí)間但能讓你少走很多彎路。另外動(dòng)作塊、時(shí)間戳、過(guò)期丟棄這三個(gè)機(jī)制最好一開(kāi)始就設(shè)計(jì)進(jìn)去它們是實(shí)時(shí)控制系統(tǒng)里最便宜也最有效的保險(xiǎn)。至于后續(xù)能擴(kuò)展的方向我比較看好兩條一是把量化做細(xì)用逐層混合精度把顯存再壓一檔同時(shí)不傷動(dòng)作精度二是把視覺(jué) token 的壓縮做成自適應(yīng)的簡(jiǎn)單場(chǎng)景少算、復(fù)雜場(chǎng)景多算讓平均延遲再降一些。這兩條都不需要?jiǎng)幽Ｐ徒Y(jié)構(gòu)屬于工程側(cè)的純收益值得優(yōu)先試。