Nếu bạn đang xây robot manipulation bằng VLM/VLA, câu hỏi thực tế không chỉ là "model nào thông minh nhất?" mà là "khi nào đáng trả thêm latency, token và FLOPs cho model thông minh hơn?". Paper DIRECT: When and Where Should You Allocate Test-Time Compute in Embodied Planners? của Jadelynn Dao, Milan Ganai và cộng sự đặt đúng câu hỏi đó cho embodied planners. Thay vì luôn dùng planner mạnh nhất, DIRECT học một router nhẹ để đọc scene image cùng instruction, rồi chọn planner có trade-off tốt nhất giữa chất lượng và chi phí.
Điểm đáng chú ý là paper không coi test-time compute như một nút volume đơn giản. Trong robotics, tăng compute ở inference có thể đến từ chain-of-thought reasoning, model size lớn hơn, hoặc memory history dài hơn. Ba trục này tạo ra ba kiểu năng lực khác nhau: reasoning giúp khi task có ràng buộc ẩn, model lớn giúp command được nhiều skill hơn, còn memory giúp khi robot phải nhớ lịch sử không còn nhìn thấy trong frame hiện tại. DIRECT biến nhận xét đó thành một hệ thống routing có thể chạy trước planner, chi phí chỉ khoảng vài chục mili giây, nhưng có thể tiết kiệm nhiều giây hoặc hàng chục giây mỗi lần replanning.
Nguồn gốc cần đọc là project page chính thức tại https://jadee-dao.github.io/direct/ và arXiv 2606.12402, đăng ngày 10/06/2026. Project page có video overview, hardware demos trên Franka/DROID, hình framework và số liệu chính. Nút code trên project page hiện ghi Code (coming soon), nên tại thời điểm viết bài này chưa có GitHub repo chính thức để clone. Vì vậy phần "cài đặt" bên dưới sẽ đi theo hướng reproduction tối thiểu: dựng một router tương tự DIRECT bằng Python, embedding image/text, ma trận quality-cost và một pool planner có sẵn trong lab của bạn. Khi repo chính thức được mở, workflow này vẫn là cách đọc code rất nhanh vì nó bám sát các module paper mô tả.
Ý tưởng paper
Trong nhiều stack robot hiện đại, hệ thống được chia thành hai tầng. Tầng trên là VLM planner: nhận ảnh scene và instruction ngôn ngữ tự nhiên, rồi tách task thành các primitive sub-skills như pick banana, place in white bin, wipe table, close drawer. Tầng dưới là language-conditioned policy hoặc VLA policy thực thi từng sub-skill trên robot. Cách chia này rất hấp dẫn vì planner có thể hiểu mục tiêu ngôn ngữ, còn policy thấp xử lý điều khiển liên tục.
Vấn đề là planner thường phải được gọi nhiều lần. Với task dài, robot hoàn thành một bước, scene thay đổi, transition detector kích hoạt replanning, planner lại sinh bước tiếp theo. Nếu planner là model thinking chậm, mỗi lần gọi có thể mất hàng chục giây. Trong lab, latency này gây khó chịu. Trong sản phẩm thật, nó làm robot đứng chờ, tăng rủi ro timeout, giảm throughput và khiến chi phí API/GPU tăng rất nhanh.
DIRECT bắt đầu từ một quan sát đơn giản: không phải task nào cũng cần cùng mức suy luận. Nếu instruction là "put the red cup in the bin" và object rõ ràng, model rẻ có thể đủ. Nếu instruction là "place the fruits from heaviest to lightest", robot phải suy luận quan hệ ẩn giữa banana, lime, apple, strawberry; khi đó thinking model đáng tiền hơn. Nếu goal từng được nói ở đầu episode nhưng hiện không còn thấy trong camera, memory planner có thể cần thiết. Router của DIRECT cố gắng dự đoán nhu cầu này trước khi gọi planner đắt.
Có thể hiểu DIRECT như một dispatcher:
RGB scene / multi-view stack + language instruction
|
v
Frozen vision encoder + frozen text encoder
|
v
Lightweight router
|
+--> cheap planner: no-thinking / small / no-memory
+--> expensive planner: thinking / large / memory
+--> intermediate planner nếu pool có nhiều model
|
v
Primitive skill plan
|
v
Low-level VLA policy executes on robot
Điểm quan trọng là router không tự điều khiển robot. Nó chỉ chọn planner. Planner được chọn vẫn sinh skill sequence, và skill sequence đó vẫn được policy thấp thực thi. Nhờ vậy DIRECT có thể ghép vào nhiều hệ robot hiện có mà không cần train lại toàn bộ VLA.
Kiến trúc của DIRECT
Paper định nghĩa một pool planner cố định M = {m1, ..., mK}. Mỗi planner nhận task x = (I, l), trong đó I là ảnh scene hoặc stack nhiều view, l là instruction. Planner trả về chuỗi primitive sub-skills. Với mỗi task và mỗi planner, nhóm tác giả đo hai đại lượng:
| Ký hiệu | Ý nghĩa | Ví dụ |
|---|---|---|
q_i,k |
quality score của planner k trên task i |
success rate hoặc progress score |
c_i,k |
inference cost của planner k trên task i |
latency, token cost hoặc FLOPs |
Từ đó, training data của router là hai ma trận Q và C trên lưới task-planner. Trong simulation, quality có thể lấy từ benchmark rollout. Trên hardware, việc chạy mọi planner trên mọi scene thật là quá đắt, nên paper dùng synthetic data: lấy scene không trùng evaluation, dùng VLM lớn sinh candidate instruction và reference skill decomposition, chạy từng planner để lấy sequence và latency, rồi dùng LLM judge chấm chất lượng so với reference.
Router nhận embedding phi(x) của task. Paper dùng frozen SigLIP-family vision encoder cho image, frozen BGE-M3 text encoder cho instruction, rồi concat hai embedding. Router architectures được sweep khá rộng: linear model, KNN, pairwise preference KNN, k-means, one-versus-rest classifier và two-layer MLP. Vì embedding pass và router chỉ tốn khoảng 20-50 ms, overhead này nhỏ so với planner VLM thường mất hơn 1 giây, và đặc biệt nhỏ so với thinking planner có thể mất hàng chục giây.
Routing objective không phải chỉ chọn planner có quality cao nhất. Nếu làm vậy, router sẽ luôn chọn model mạnh nhất. DIRECT dùng utility U(q, c) để cân bằng quality và cost. Một cách dễ hình dung là:
utility = predicted_quality - lambda * predicted_cost
chosen_planner = argmax_k utility(task, planner_k)
Paper cho biết regression head thường tốt vì nó học tín hiệu quality và cost giàu hơn một nhãn hard label. Khi deploy, router nhìn task mới, tính embedding, dự đoán planner index, rồi gọi planner đó. Với multi-stage task, router có thể được gọi lại sau mỗi bước vì scene mới có thể dễ hoặc khó hơn scene trước.
Ba trục test-time compute
Chain-of-thought: reasoning không phải lúc nào cũng đáng
Trên VLABench, nhóm tác giả so sánh các cặp planner no-thinking và thinking. Thinking model có thể xử lý ràng buộc semantic, physical hoặc spatial ẩn tốt hơn, nhưng phải sinh nhiều token hơn. Kết quả đáng nhớ: với Qwen3-VL 8B Instruct và Qwen3-VL 8B Thinking, khoảng 44% task được Instruct match hoặc vượt Thinking, trong khi latency chỉ dưới 2% của Thinking, tức nhanh hơn khoảng 63 lần theo project page.
Điều này không có nghĩa "đừng dùng reasoning". Nó có nghĩa reasoning nên là tài nguyên được phân bổ. Nếu task đơn giản, thinking là lãng phí. Nếu task có ambiguity, thứ tự, ràng buộc vật lý hoặc world knowledge, thinking có thể cứu task. DIRECT học ranh giới đó từ scene và instruction.
Model size: lớn hơn không tạo đường cong mượt
Paper cũng quét Qwen3-VL Instruct từ 2B tới 235B trên VLABench. Kết quả không monotonic: score và latency không tăng/giảm theo một đường đẹp. Có trường hợp model nhỏ hơn sinh dài hơn nên chạy chậm hơn model lớn. Khi phân tích theo skill, model size chủ yếu mở rộng breadth of skills mà planner command được ổn định. Model lớn hữu ích khi task cần skill mà model nhỏ hay gọi sai, ví dụ fold hoặc close trong hardware validation, nhưng không cần thiết cho các bước put/place rõ ràng.
Đây là insight quan trọng cho team triển khai. Nếu bạn đang dùng một VLM 70B hoặc 235B cho mọi instruction robot, có khả năng bạn đang overspend ở nhiều task. Một router nhỏ có thể giữ model lớn như "specialist" chỉ dùng khi skill coverage của model nhỏ không đủ.
Memory: chỉ trả recall overhead khi cần nhớ
Long-horizon task thường cần memory, nhưng memory có nhiều dạng. Paper nhắc tới FrameSamp và TokenDrop để giảm token hình ảnh, SimpleSG và GroundSG để tóm tắt lịch sử thành language subgoals, và MemER để recall keyframes trước đó. Trên RoboMME, không có memory architecture nào thắng mọi difficulty tier. Với task dễ cần recall ngắn, FrameSamp có thể vượt MemER với chi phí FLOPs thấp hơn khoảng một bậc độ lớn. Với task khó cần nhớ xa, MemER hoặc GroundSG lại dẫn đầu.
Thông điệp thực dụng: đừng nhét toàn bộ history vào mọi prompt chỉ vì model context window cho phép. Trong robot, history dài vừa tốn compute vừa có thể làm nhiễu nếu current scene đã đủ. DIRECT biến memory thành một lựa chọn có điều kiện.
Cài đặt bản reproduction tối thiểu
Vì repo chính thức chưa public, cách bắt đầu tốt nhất là dựng một skeleton độc lập. Bạn cần bốn phần: dataset task, pool planner, embedding model và router model. Với beginner, nên làm offline trước, chưa cần robot thật.
conda create -n direct-router python=3.11 -y
conda activate direct-router
pip install torch torchvision transformers sentence-transformers scikit-learn pandas numpy pillow tqdm
Một cấu trúc thư mục tối thiểu:
direct-router/
data/
tasks.csv # task_id, image_path, instruction
planner_scores.csv # task_id, planner_id, quality, cost
routers/
train_router.py
infer_router.py
planners/
cheap_planner.py
thinking_planner.py
tasks.csv có thể bắt đầu bằng vài trăm scene từ simulator hoặc log robot cũ. planner_scores.csv là phần đắt nhất: bạn phải chạy mỗi planner trên mỗi task, ghi quality và latency. Với simulation, quality là success/progress. Với hardware hoặc dataset offline, bạn có thể chấm bằng rule-based evaluator nếu có state, hoặc LLM judge nếu chỉ có instruction và plan text.
Pseudo-code training:
image_emb = siglip(image)
text_emb = bge_m3(instruction)
x = concat(image_emb, text_emb)
for planner in planners:
y_quality[planner] = measured_quality(task, planner)
y_cost[planner] = measured_cost(task, planner)
router.fit(x, y_quality, y_cost)
Với scikit-learn, bạn có thể train một RandomForestRegressor hoặc MLPRegressor để dự đoán vector quality và cost cho từng planner. Khi đã dự đoán được hai vector này, chọn planner bằng utility:
utility = q_hat - lambda_cost * normalize(c_hat)
planner_id = utility.argmax()
Hãy chia train/validation theo scene, không chỉ shuffle từng row. Nếu cùng một scene xuất hiện cả train và validation với instruction gần giống nhau, router sẽ overfit vào visual shortcut và trông tốt hơn thực tế.
Training router nên đo gì?
Bạn cần logging đủ chi tiết. Tối thiểu mỗi planner call nên lưu:
| Trường | Vì sao cần |
|---|---|
task_id |
nối lại với scene và instruction |
planner_id |
biết planner nào sinh plan |
plan_text |
debug khi quality thấp |
latency_ms |
cost chính cho autoregressive planner |
tokens_in, tokens_out |
kiểm tra verbosity |
success hoặc progress |
label quality |
failure_reason |
phân tích khi router chọn sai |
Một lỗi phổ biến là train router bằng nhãn "planner mạnh nhất" nhưng không lưu cost. Như vậy router chỉ học imitation của expensive planner, không học trade-off. DIRECT nhấn mạnh phải có cả quality và cost. Bạn có thể đặt lambda_cost thấp nếu ưu tiên success, hoặc tăng dần khi muốn latency ổn định hơn. Trong production, nên chọn lambda_cost dựa trên SLA: robot được phép đứng chờ 2 giây, 5 giây hay 20 giây?
Inference trong robot stack
Ở runtime, DIRECT-style routing nên nằm ngay trước high-level planner:
camera frames + current instruction
|
v
router.predict()
|
+-- cheap planner nếu task rõ ràng
+-- thinking/large/memory planner nếu task khó
|
v
skill plan
|
v
low-level VLA / controller
Với task nhiều bước, đừng route một lần rồi giữ planner cố định đến hết episode. Paper cho thấy multi-step grocery bagging là nơi per-step routing rất đáng giá: bước dễ dùng no-thinking, bước khó mới dùng thinking. Điều này hợp với robot thật vì sau mỗi pick/place, scene đã đổi. Instruction tổng vẫn là một, nhưng subgoal kế tiếp có thể thay đổi độ khó.
Khi deploy, cần thêm guardrail. Nếu router chọn cheap planner nhưng planner trả plan rỗng, plan chứa skill ngoài allowlist, hoặc confidence thấp, hãy fallback sang planner mạnh hơn. DIRECT paper tập trung vào routing hiệu quả; trong hệ sản phẩm, bạn vẫn cần validation layer để chặn plan nguy hiểm.
Kết quả chính
Paper báo cáo hơn 270.000 simulated routing decisions và 245 hardware trajectories trên ba trục compute. Trên VLABench, DIRECT đạt routing efficiency tốt nhất trong các cấu hình thinking/non-thinking được so sánh, thường giữ gần quality của expensive planner với latency thấp hơn. Trên model-size routing, cumulative routing qua 2B, 4B, 8B và 32B biến scaling curve vốn erratic thành cải thiện monotonic; ở điểm 32B, router tăng success thêm 5,1 điểm và giảm average latency 32,4 giây so với chọn model đó trực tiếp.
Kết quả hardware dễ nhớ nhất là multi-step grocery bagging: task yêu cầu đặt trái cây từ nặng đến nhẹ vào thùng trắng. No-thinking Qwen3.5-VL 9B đạt 47,62% success với 2,19 s latency. Thinking đạt 90,48% với 19,58 s. DIRECT đạt 95,24% với 6,85 s. Nói cách khác, router không chỉ nhanh hơn thinking mà còn nhỉnh hơn success trong thí nghiệm này vì nó quyết định lại theo từng subgoal.
| Planner | Success | Latency |
|---|---|---|
| Qwen3.5-VL 9B No Thinking | 47,62% | 2,19 s |
| Qwen3.5-VL 9B Thinking | 90,48% | 19,58 s |
| DIRECT | 95,24% | 6,85 s |
Với memory routing trên DROID, paper cho thấy DIRECT gần oracle hơn memory-free baseline và random/OOD routing, trong khi xử lý ít frame hơn full memory planner. Đây là bằng chứng thực nghiệm cho luận điểm cốt lõi: memory là compute, và compute nên được cấp theo nhu cầu.
Khi nào nên dùng DIRECT?
DIRECT hợp nhất với các lab đang có nhiều planner: một model nhỏ chạy nhanh, một model thinking, một model lớn, hoặc một variant có memory. Nếu bạn chỉ có một planner, router không tạo thêm năng lực. Nhưng nếu bạn đã có hai hoặc nhiều lựa chọn với cost khác nhau, DIRECT là cách có hệ thống để tránh policy kiểu "luôn dùng model đắt nhất" hoặc "luôn dùng model rẻ nhất".
Với người mới, bài VLA Models trong robotics giúp nắm tầng VLA thấp. Bài OpenVLA deep dive cho thấy cách policy sinh action, còn Embodied AI 2026 landscape đặt DIRECT vào bối cảnh embodied foundation models. Điểm mới của DIRECT nằm ở tầng planner: nó không thay policy, mà điều phối test-time compute cho planner.
Hạn chế
DIRECT được train offline trên một pool planner cố định. Nếu bạn thêm model mới, đổi API latency, hoặc thay hardware, nên thu lại quality-cost data và train lại router. Cost cũng phụ thuộc deployment: cùng một model có thể rẻ trên local GPU nhưng chậm qua API, hoặc ngược lại. Cuối cùng, router hiện chọn trong pool có sẵn, không tạo capability mới; nếu mọi planner đều không biết skill cần thiết, routing không cứu được task.
Tuy vậy, paper đưa ra một hướng rất thực tế cho robotics: thay vì chỉ hỏi "model lớn nhất là gì?", hãy hỏi "task này có thật sự cần model lớn không?". Với robot chạy ngoài đời, câu hỏi đó quyết định latency, chi phí và độ mượt của trải nghiệm.
