當你在機器人項目里部署視覺-語言-動作模型Vision-Language-Action簡稱 VLA時最常見的困境往往不是模型不夠聰明而是“模型太大帶不動”。7B 級別的 VLA 在論文評測里表現好看但一旦放到機械臂控制器或移動機器人上立刻會遇到推理延遲高、顯存不足、訓練成本昂貴這幾個現實問題。楊立昆團隊近期公開的輕量 VLA 方案恰好切中這個痛點。從項目發布信息看有四個數字非常吸引人只用總參數中約 0.7% 的可訓練參數就能讓模型在評測任務上的表現相對提升約 40%整個訓練過程只要 6.5 小時一次動作推理只需要 11 毫秒并且在多個基準任務上可以超越 7B 級別的公開 VLA 模型。這不是一篇單純吹捧“小模型戰勝大模型”的文章。我要做的是把這套方案里的工程思路拆開為什么只更新 0.7% 的參數效果反而能提升滑動窗口注意力在其中到底起了什么作用訓練 6.5 小時、推理 11 毫秒這種數據對真正做機器人落地的工程師意味著什么這篇文章會從 VLA 的基礎概念講起逐步拆解參數效率、訓練成本、推理延遲和工程選型。即使你不從事具身智能方向只看它如何用極小訓練成本和極低推理成本撬動模型能力也值得認真了解一下。1. 為什么關注這項研究VLA 不是越大越好在 2024 年到 2025 年之間具身智能賽道經歷了明顯的“擴規模”趨勢。OpenVLA、PaliGemma、LLaMA-Rider 這類模型普遍采用 7B 甚至更大的語言模型作為主干再接入視覺編碼器和動作預測頭。原因是 7B 模型擁有更強的世界常識、指令理解能力和多任務泛化能力在標準機器人操作評測集上確實能拿到比較高的分數。但這里有一個容易被忽略的問題機器人不是跑在大規模數據中心里的服務而是跑在機械臂控制器、移動底盤、邊緣工控機上的物理系統。它需要實時閉環通常控制頻率要求 10Hz 甚至更高它受限于成本和功耗不可能隨時掛一張 A100它的動作數據收集成本極高不可能像互聯網文本那樣輕易獲得海量樣本。所以VLA 領域的核心矛盾不是“模型還能不能更大”而是“在算力有限、數據有限、實時性要求高的條件下模型還能不能足夠好用”。這也是為什么楊立昆團隊的這項研究會引起關注——它選擇了一條完全不同的優化目標用最小可訓練參數、最短訓練時間、最低推理延遲去逼近甚至超過大模型的可用性能。如果你正在做以下事情這篇文章對你有實際參考價值機器人操作策略選型希望判斷輕量級 VLA 是否夠用。具身智能入門想弄明白 VLA 的常用架構和關鍵設計。邊緣部署工程師關注模型推理延遲、內存占用和訓練成本。研究參數高效微調方向希望對比不同微調策略的效果。換句話說這篇文章的讀者不一定是算法研究員更多是那些需要在真實項目中把模型跑起來的人。2. VLA 基礎概念視覺-語言-動作模型到底在做什么VLA 是一個典型的“多模態進、動作出”模型。它的輸入通常是視覺信息機械臂第一視角或第三人稱相機采集的圖像。語言指令例如“把紅色方塊放到左邊盒子里”。可選的機器人狀態關節角度、夾爪開合狀態、位姿信息等。輸出則是機器人的動作。動作可以是連續參數比如末端執行器的位置增量、關節角速度也可以是離散 token比如“抬高手臂”“抓取物體”“向右移動 2 厘米”。從架構上看VLA 一般由三部分組成視覺編碼器把圖像轉換為視覺特征向量常見的是 ViT 或 SigLIP 這類預訓練視覺模型。語言模型主干把文本指令和視覺特征一起處理承擔推理和決策工作。動作解碼頭把語言模型的輸出映射為具體動作可以是一個 MLP 回歸層也可以是離散動作 token 的分類層。理解這一點后你就能發現 VLA 和多模態大模型的核心區別多模態大模型最終生成的是自然語言回復而 VLA 最終生成的是可執行的動作指令。語言模型在這里被當成“動作推理器”使用既要理解場景又要根據指令輸出行動。這也是 VLA 為什么依賴大語言模型的原因。真實世界中的操作任務往往需要常識推理比如“拿起杯子之前應該先確認杯子是空的”“螺絲刀要握住手柄而不是金屬桿”。這些知識來自大規模文本預訓練很難完全靠機器人操作數據習得。因此直接砍掉大模型主干、只留一個小網絡并不現實。但問題也隨之而來大模型主干帶來了性能和推理能力也帶來了推理延遲和訓練成本。如何把這兩者解耦就是這項研究最值得關注的地方。3. 從 7B 到輕量方案0.7% 參數和 40% 性能提升是怎么來的先把這個標題里最抓眼球的兩個數字拆開看。第一0.7% 參數。這里說的不是把模型總參數壓縮到原來的 0.7%而是指在訓練過程中只有約 0.7% 的參數參與梯度更新。根據項目公開信息這套方案在預訓練語言模型主干的 embedding 層和 LayerNorm 層上做自適應調整其他參數全部凍結。為什么選擇 embedding 層和 LayerNorm 層從工程角度理解embedding 層是文本、圖像、動作三種信息進入模型后的第一個交匯點。調整這個層相當于為當前機器人任務定制一個“語義映射器”讓模型能更好對齊視覺指令、語言指令和動作空間。LayerNorm 層控制特征分布。每一層 LayerNorm 的縮放和偏移參數都能對整體特征流產生全局影響。微調這些參數相當于在全模型范圍內做了一次輕量級的“分布適配”。這種做法的好處很明顯主干模型的參數完全凍結訓練時不需要為主干保存梯度顯存占用大幅下降同時主干模型原本具備的世界常識和語言表達能力被完整保留不會因為微調數據量少而“災難性遺忘”。第二40% 性能提升。需要說明的是這里的 40% 是相對提升不是絕對成功率提升。假設某個任務原來的基礎成功率約 50%相對提升 40% 后大約到 70%如果基礎成功率本身就低于 10%相對提升 40% 后的絕對數字依然不高。從公開消息看該方案在 MMBT、LIBERO 這類機器人操作基準上相比同參數規模的其他輕量模型取得了更明顯優勢并且在部分任務上超過了 7B 級 VLA。這里真正值得關注的不是“超越 7B”這個結論而是它證明了“參數效率”和“能力上限”并不沖突。微調少量參數不一定就代表能力弱關鍵看微調的是哪些參數、數據組織是否合理、注意力機制是否高效。很多人會拿它和 LoRA 做對比。LoRA 的思路也是凍結主干、訓練低秩矩陣同樣屬于參數高效微調而這套方案更進一步不引入額外低秩矩陣直接調整原生網絡中本來就存在的 embedding 和 LayerNorm 參數。從模型部署角度看少了一組額外矩陣推理時不需要額外合并權重維護成本更低。4. 架構設計拆解滑動窗口注意力與輕量自適應從公開資料看這套方案的核心設計有兩個輕量自適應層和滑動窗口注意力。先說滑動窗口注意力。傳統自回歸語言模型在生成動作 token 時一般會處理整段上下文包括所有歷史輸入。這在長對話任務中沒問題但在機器人任務中會造成嚴重浪費一個機械臂連續執行 10 分鐘任務如果每預測一步動作都要重新處理過去幾分鐘的圖像和歷史動作 token計算量會隨任務時間線性增長延遲也會不可控地拉高。滑動窗口注意力的思路是當前動作的預測只依賴最近一段窗口內的視覺信息、文本指令和過去若干步動作。窗口之外的舊信息在注意力計算中不再參與。這樣每一步前向計算的長度被限定在固定大小以內不會因任務執行時間變長而退化。這種做法還帶來了一個額外收益限制上下文長度實際上也限制了模型對歷史錯誤的依賴。如果模型在第 20 步動作執行失誤傳統注意力機制在后續預測中仍然要“盯著”這個錯誤歷史而滑動窗口機制會在窗口滾動后逐漸丟掉舊信息相當于給了模型一定的“自我糾錯”空間。再說輕量自適應。它體現在兩個層面參數層面前面說過只有 embedding 層和 LayerNorm 層可訓練數量占比約 0.7%。激活層面根據項目描述并不是所有主干參數都需要為當前動作預測參與計算。它通過設計讓部分與當前動作無關的 token 不進入完整的注意力計算流程實際參與計算和存儲的參數約為總量的 70%。這個“參數使用率”概念非常值得留意。傳統 7B 模型跑一次推理無論輸入多短基本都要加載全部 7B 參數到顯存計算所有層的完整矩陣乘。而這套方案通過動態裁剪輸入 token 和注意力計算范圍讓實際計算量遠低于“全參數全上下文”的理論值。這也是 11 毫秒推理能實現的重要前提。當然這種設計不是沒有代價。滑動窗口注意力要求開發者對“窗口長度”有合理設置。窗口太短模型看不到足夠的歷史上下文容易動作不連貫窗口太長計算量增加延遲上升。落地時通常需要針對具體任務做一次窗口長度調優。5. 訓練過程與數據6.5 小時背后的關鍵設計訓練時間是很多團隊最敏感的工程指標。項目描述里“6.5 小時完成訓練”這個數字放在 VLA 領域確實相當激進。常規做法是拿 7B 模型做全量微調至少需要在 8 卡 A100 上訓練數天即使用 LoRA也需要幾十個小時。這套方案能把訓練壓到 6.5 小時核心原因是訓練過程中要更新梯度的參數太少。模型的 embedding 層和 LayerNorm 層參數量占比很小訓練時不需要對主干全量參數計算梯度反向傳播的計算量和顯存占用都大幅下降。與此同時由于參與梯度更新的參數少優化器狀態占用的顯存也少訓練時可以使用更大的 batch size 和更長的訓練步數在同樣時間內看到更多樣本。在數據層面VLA 訓練通常包含兩類監督信號一類是視覺語言任務監督讓模型理解圖像和指令的含義另一類是動作監督讓模型學會把語義理解轉化為具體動作。公開材料里提到這套方案在機器人操作數據集上做了多任務訓練同時對動作 token 做了類似“動作-屬性映射”的時間步聚合處理讓離散的動作 token 能更好對齊到當前任務進度上。這里我更想強調的是工程層面的啟發訓練成本不只是算力成本更是迭代成本。6.5 小時和 6.5 天差別不只是電費和 GPU 占用而是團隊每天的迭代次數。一個實驗跑 6.5 小時意味著當天就能看到結果、調整數據、繼續下一輪實驗一個實驗跑 6.5 天意味著每周只能做少量實驗試錯空間大大縮小。對研究團隊和創業團隊來說這種成本差異可以直接決定項目推進速度。下面用一個最小示例演示“凍結主干、只訓練少量層”的訓練代碼結構。這里以 Hugging Face Transformers 框架為例演示如何篩選出可訓練參數這也是理解該方案訓練成本的關鍵。# 文件路徑train_fast_style_vla.py # 演示一個典型的“只更新 embedding 層與 LayerNorm 層”訓練參數設置 import torch from transformers import AutoModelForCausalLM # 這里替換為你實際使用的 VLM 基座模型路徑 model AutoModelForCausalLM.from_pretrained( your_base_vlm_path, torch_dtypetorch.bfloat16, ) # 凍結所有參數然后只放開 embedding 和 LayerNorm for name, param in model.named_parameters(): is_embedding embed_tokens in name or embedding in name is_layer_norm layer_norm in name or layernorm in name or ln_ in name if is_embedding or is_layer_norm: param.requires_grad True else: param.requires_grad False # 查看可訓練參數比例 total_params sum(p.numel() for p in model.parameters()) trainable_params sum(p.numel() for p in model.parameters() if p.requires_grad) print(ftotal params: {total_params / 1e6:.2f}M) print(ftrainable params: {trainable_params / 1e6:.2f}M) print(ftrainable ratio: {trainable_params / total_params * 100:.3f}%)這段代碼的關鍵邏輯是遍歷模型所有參數根據參數名判斷它是否屬于 embedding 或 LayerNorm然后設置requires_grad。訓練時優化器只接收requires_gradTrue的參數因此反向傳播不會為主干參數計算梯度。實際項目中這個篩選邏輯要結合具體模型的參數命名規則來調整。不同模型的 embedding 層命名可能不同比如model.embed_tokens、model.vision_embed_tokens、model.language_model.embed_tokens等。建議在寫訓練腳本前先打印一遍model.named_parameters()確認命名規則再寫過濾條件。訓練完成后保存模型時也應只保存可訓練參數避免保存數十 GB 的全量主干預訓練權重。推理平臺加載凍結主干的預訓練權重后再疊加你訓練出來的少量參數即可。6. 推理性能分析11 毫秒意味著什么在機器人控制場景中模型單次推理延遲直接決定了控制閉環能否跑起來。11 毫秒這個數字換算成頻率大約是 90Hz。對機械臂力控、移動機器人避障這類典型任務來說這個控制頻率已經進入了“可用”區間甚至超出部分傳統視覺伺服方案的水平。作為對比主流 7B VLA 在單張云端加速卡上做單次動作預測延遲通常在數百毫秒到一秒級別。這個延遲如果直接放在真機閉環里機器人實際反應速度會明顯滯后只能用于“感知 - 規劃 - 執行”的慢速任務很難支撐精細操作。為什么 11 毫秒有可能實現結合前面幾章的拆解主要有三個原因序列縮短滑動窗口注意力限制了每一步輸入的序列長度前向計算不再是全上下文掃描。計算裁剪與當前動作無關的 token 不參與完整注意力計算實際參與計算的參數被控制在約 70%。動作解碼輕量化語言模型主干生成的 token 數量很少不需要像通用對話模型那樣生成長篇回復。另外要提醒的是11 毫秒是一個在特定測試環境下得到的數字通常對應單張云端加速卡、batch size 為 1 的推理條件。真實機器人上還會受到圖像采集、預處理、系統調度、模型編譯方式的影響。實際部署時應該把整個“攝像頭采集 - 圖像預處理 - 模型推理 - 動作解析 - 控制指令下發”的鏈路延遲一起測量而不是只測模型前向時間。下面給出一個典型的模型推理測時腳本幫助你評估自己的 VLA 模型在目標硬件上的真實延遲。# 文件路徑benchmark_inference.py # 演示用 CUDA Event 統計模型前向推理平均耗時 import torch def benchmark_step(model, inputs, warmup5, repeat50): model.eval() # 先跑幾輪 warmup避免顯存分配和算子預熱影響計時 for _ in range(warmup): with torch.no_grad(): _ model(**inputs) start_events [torch.cuda.Event(enable_timingTrue) for _ in range(repeat)] end_events [torch.cuda.Event(enable_timingTrue) for _ in range(repeat)] with torch.no_grad(): for i in range(repeat): start_events[i].record() _ model(**inputs) end_events[i].record() torch.cuda.synchronize() times [s.elapsed_time(e) for s, e in zip(start_events, end_events)] avg_ms sum(times) / len(times) print(faverage inference time: {avg_ms:.2f} ms)測時的時候有幾個容易踩坑的點必須做 warmup。第一次調用模型會觸發 CUDA kernel 加載和顯存分配不含 warmup 的測時數據會失真。GPU 計時必須同步。如果不調用torch.cuda.synchronize()拿到的只是任務提交時間不是實際完成時間。要監控顯存占用。VLA 推理不僅關心延遲還關心是否放得下。可以用torch.cuda.max_memory_allocated()統計峰值顯存。7. 與主流 VLA 方案的對比與選型建議為了把輕量 VLA 的定位講清楚這里給出一個與主流方案的對比。需要說明的是具體參數、訓練時間和延遲會隨版本、硬件和實現方式變化表中的數字主要反映常見公開測試狀態實際以官方發布為準。方案主干規模微調方式訓練成本推理延遲典型適用場景OpenVLA約 7B全量/部分微調多卡數天數百毫秒級對成功率要求高、不要求高實時性的研究PaliGemma 系列約 3B-7B全量/全參數微調多卡數天數百毫秒級通用視覺語言任務可改造為動作任務LLaMA-Rider約 7BSFT / RL多卡數天數百毫秒級游戲環境、具身智能研究本文討論的輕量 VLA約 1-4B 級主干僅訓練少量層單卡數小時10ms 級別實時性要求高的機器人部署這個表格不是直接比較“誰更強”而是想說明選型時必須考慮的維度第一訓練成本。如果你所在的團隊沒有多卡訓練條件比如只有一兩張消費級或單卡云端 GPU那么嘗試全量微調 7B 模型會非常吃力而單卡數小時這種訓練成本意味著個人開發者和中小團隊也具備實驗條件。第二推理延遲。如果目標是部署在實體機械臂上且要求 20Hz 以上的控制頻率那么數百毫秒延遲的 7B 方案幾乎不可用。輕量模型雖然不是所有任務都能贏過 7B但在實時閉環這一項上有決定性優勢。第三任務復雜度。如果任務是長時程、多階段、強常識推理的移動操作任務7B 模型的語義理解能力仍然有價值。輕量 VLA 更適合任務邊界較清晰、控制頻率要求高、場景相對固定的場景。我的選型建議是不要先看模型發布會而是先回答三個問題——你的機器人平臺允許的最大推理延遲是多少你的訓練資源能支撐多少天一輪實驗你的任務中語義推理占比高還是實時控制占比高答案會直接把你推向大模型路線或輕量路線。8. 落地實踐快速評估與最小閉環示例如果你看完前面幾章想知道“我能不能快速跑通這套思路”這里給出一個最小閉環路徑。第一步準備數據。VLA 訓練需要至少包含圖像、指令文本、動作標簽的數據集。可以先用公開機器人操作數據集驗證流程比如 LIBERO 或 MMBT 的子集再逐步替換成自己采集的真機數據。第二步確定基座模型。選擇一個支持視覺語言輸入的開源基座模型比如某些多模態 LLaVA 風格的模型或者以語言模型為主干、額外接入視覺編碼器。盡量選擇已發布權重、社區資料較多的模型這樣調試更容易。第三步凍結主干只訓練 embedding 和 LayerNorm。這一步對應前面第 5 章的代碼示例。第四步在仿真環境中驗證。先在仿真器里跑通回合制評估統計成功率確認模型確實從“隨機水平”提升到“策略水平”。仿真環境能節省大量真機調試時間。第五步真機小規模驗證。先把動作頻率和限制器跑起來再逐步放開控制權限。真機環境務必加裝安全限位和急停邏輯不能讓模型未經驗證就直接控制機械臂。下面是一個簡化版 VLA 推理函數的示例展示“圖像 指令 - 動作文本”的基本流程。# 文件路徑vla_inference.py # 演示VLA 推理中的基礎預處理與動作解析流程 import torch def predict_action(model, processor, image, instruction, max_new_tokens16): model.eval() # 將指令文本和圖像統一編碼為模型輸入 inputs processor( textinstruction, imagesimage, return_tensorspt, paddingTrue, ).to(model.device) # 控制生成長度VLA 只需要生成動作 token不需要長文本 with torch.no_grad(): output_ids model.generate( **inputs, max_new_tokensmax_new_tokens, do_sampleFalse, ) action_text processor.decode(output_ids[0], skip_special_tokensTrue) return parse_action(action_text)這里有個工程細節值得注意max_new_tokens不要設置太大。VLA 不需要模型生成完整自然語言說明只需要輸出動作參數。如果生成長度過長既浪費推理時間又容易在連續動作輸出中混入無關文本導致動作解析異常。動作解析函數parse_action需要結合你的動作空間來寫。連續動作可以解析為浮點數列表離散動作可以解析為預定義動作原語的索引。解析邏輯必須在訓練和推理階段保持一致否則模型輸出的動作文本無法正確落到控制層。9. 常見問題與排查思路下面這組問題是我結合 VLA 項目落地中比較常見的問題整理的適用于大多數輕量 VLA 工程。問題現象可能原因排查方式解決方案微調后效果還不如不微調動作空間與模型 token 映射不一致數據集標簽錯誤打印推理輸出檢查動作 token 與標簽對齊情況統一動作空間編碼清洗數據集推理延遲遠高于 11ms輸入序列過長視覺編碼器成為瓶頸未使用推理優化打印各模塊耗時檢查輸入 token 長度縮短窗口長度對視覺編碼器做量化或裁剪訓練顯存仍然不足基座模型加載占用高優化器狀態過多未開啟梯度檢查點監控顯存峰值檢查參與梯度更新的參數數量開啟 gradient checkpointing使用 bf16只保存可訓練參數模型動作輸出不穩定動作 token 生成長度過長解碼策略使用采樣檢查生成參數查看完整輸出文本設置較短 max_new_tokens使用貪心解碼仿真成功率高但真機失敗sim-to-real gap視覺域差異控制頻率不足對比仿真與真機圖像分布記錄真機實際延遲使用域隨機化提高推理吞吐增加視覺數據增強模型在長任務后期行為異常滑動窗口長度設計不合理因果上下文丟失分析任務中期輸出檢查窗口覆蓋范圍調大窗口長度或增加關鍵狀態記憶機制這里要重點說下“訓練顯存仍然不足”的問題。很多人以為只訓練 0.7% 參數顯存需求就會非常小。實際上模型加載后主干權重本身就占據大量顯存即使凍結參數不需要保存梯度前向計算的過程激活值仍然存在。因此真正落地時仍然建議使用 bf16、梯度檢查點并選擇盡可能小的基座模型。另外在真機部署前一定要記錄模型版本、訓練數據版本、關鍵超參和推理延遲指標。機器人項目出問題時最讓人頭疼的往往不是模型本身而是無法判斷現場表現對應的是哪一版模型、哪一批數據。把這些運行信息固化下來排障效率會高很多。10. 最佳實踐與工程建議這里給出幾條對實際項目更有幫助的工程建議。第一動作空間設計要盡量統一。VLA 模型對動作 token 的語義非常敏感。如果你今天用關節角度表示動作明天換成末端執行器位姿模型需要重新學習一套映射關系。建議在項目開始前就確定動作空間并在所有數據集中保持統一。第二窗口長度應該作為關鍵超參來調。滑動窗口注意力雖然高效但窗口長度直接決定模型能看多遠的“過去”。建議在驗證集上做一次窗口長度掃描觀察成功率隨窗口長度的變化曲線找到性能與延遲的平衡點。第三訓練過程和推理過程要使用同一套預處理。包括圖像尺寸、歸一化方式、指令模板、動作文本格式。預處理不一致是最容易被忽視的部署事故來源。第四部署時加入動作限制器。VLA 模型的輸出可能出現越界值或不合理動作。在控制層必須加物理限位比如關節角度范圍、末端速度上限、夾爪力矩限制。不要直接信任神經網絡輸出這是機器人安全的基本底線。第五建立從仿真到真機的漸進式驗證流程。不要跳過仿真直接上真機也不要在仿真里反復過擬合。推薦的順序是仿真小任務驗證 - 仿真多任務泛化 - 真機單任務驗證 - 真機多任務驗證。每一步都設定明確的成功率門檻下一個階段只在前一個階段通過后啟動。第六關注失效模式而不是平均成功率。機器人在真實場景中平均成功率不是唯一指標。某個托盤操作任務的平均成功率是 80%但如果失敗模式集中在“夾爪過度用力壓碎目標物體”這個風險在工業生產中就是不可接受的。建議額外統計失敗類型的分布針對性補充數據或增加后處理規則。11. 總結與后續學習方向楊立昆團隊的這項輕量 VLA 方案本質上是在回答一個問題在真實物理條件下我們需要多大的模型才夠用它的答案是不一定需要 7B更關鍵的是“在合適的位置做精準調整”。0.7% 的可訓練參數、6.5 小時的訓練時間、11 毫秒的推理延遲這三個數字互相配合把 VLA 從“實驗室研究品”往“可實際部署產品”的方向推進了一大步。對開發者的啟發是參數高效微調不只是為了省算力更是一種系統設計思路。它意味著你可以更快地試錯更快地收集數據反饋更快地把模型部署到邊緣設備上。這種迭代速度在具身智能這種“數據貴、實驗貴、試錯成本高”的領域里價值可能比單點精度提升更大。這篇文章從 VLA 基礎概念、參數機制、滑動窗口注意力、訓練成本、推理性能到工程選型做了比較完整的拆解。如果你想繼續深入下一步可以從這幾個方向展開一是閱讀該方案的完整論文和公開代碼理解滑動窗口注意力與動作 token 的具體實現二是嘗試在 LIBERO 或 MMBT 這類公開數據集上復現一個輕量訓練流程三是研究 LoRA、層歸一化微調、提示微調等方法在機器人任務上的橫向對比。最后提醒一點盡量用低成本手段先驗證“任務是否適合 VLA”再考慮擴大模型規模。對一個控制頻率要求高的固定場景任務輕量模型往往是更穩妥的起點對一個需要豐富常識推理的開放世界任務再考慮回到 7B 級方案。工程選型不是比誰參數多而是比誰更適合自己的約束條件。