Research at scale: Orchestrating ML for systematic trading

Optiver · 2025 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bối cảnh

• Theo Optiver, giao dịch hệ thống dựa vào sức mạnh của "cỗ máy nghiên cứu": thí nghiệm hôm nay thành model, tín hiệu, kiểm tra rủi ro và hạn mức vị thế ngày mai. Vòng nghiên cứu: đặt giả thuyết → chạy thí nghiệm → đánh giá → chỉnh giả thuyết hoặc đưa vào quyết định production. Cái khó là chạy vòng này lặp lại được trên hàng nghìn công cụ tài chính và hàng chục năm dữ liệu.
• Mục tiêu duy nhất: rút ngắn vòng từ ý tưởng tới kết quả đã kiểm chứng. Bốn thứ phục vụ mục tiêu đó: chi phí (HPC đắt; gấp đôi compute trên mỗi đô là lợi thế), dung lượng (đủ dư địa mà vẫn dùng cao), năng lực (đoán trước nhu cầu 12–24 tháng), tính đúng (tái lập và truy vết là bắt buộc).

Thay đổi chính

• Bài toán số học của pipeline: trên giấy là tuyến tính (tạo feature → train → mô phỏng). Tạo feature một ngày thị trường mất 1 giờ thì 1.000 ngày giao dịch mất khoảng sáu tuần; chia theo ngày thì về lại khoảng một giờ. Thêm 100 công cụ là hơn 100.000 job; chạy tuần tự thành khoảng 11 năm. Song song hoá không còn là lựa chọn, và đồ thị tính toán trở nên khó suy luận, dễ sinh điểm nóng tài nguyên.
• Ba cách mở rộng compute (theo Optiver): toàn on-prem (máy mới có thể bỏ không nếu đoán sai nhu cầu, kẹt ở thế hệ phần cứng cũ, rủi ro chuỗi cung ứng); on-prem + tràn sang cloud lúc đỉnh (vướng data gravity: chuyển hay nhân bản hàng trăm PB chậm và đắt; bản sao trễ hoặc hỏng cho kết quả khác; môi trường lệch nhau; code người dùng nhiễm "nếu cloud thì X"); toàn cloud (ít kiểm soát phần cứng, chi phí cộng dồn, lock-in, và vẫn gặp data gravity giữa các region).
• Cách Optiver làm: coi nhiều DC on-prem và nhiều region cloud là mặc định ngay từ đầu. Hạn chế "burst job này đi" tuỳ hứng; quyết định vị trí chạy trước cho từng team, workload, giai đoạn nghiên cứu; khi có thể thì đưa workload tới dữ liệu chứ không đưa dữ liệu tới workload. Hai lớp trừu tượng: compute (mọi cụm sau một giao diện chung, đổi vị trí là đổi policy/config) và dữ liệu (một catalog chung trên S3, NFS, Postgres, Delta Table).
• Từ DAG do scheduler giữ sang điều phối trong process: kiểu truyền thống giao cả DAG cho Slurm; không hợp khi muốn một giai đoạn chạy on-prem, giai đoạn khác trên GPU cloud, và không thể bắt researcher tự cắt DAG theo ranh giới scheduler. Optiver đưa phần quyết định "node nào sẵn sàng chạy tiếp" vào một thư viện Python chạy cạnh code người dùng: GraphRunner. Nó giữ đồ thị trong chính process đã dựng nó và gửi từng node sẵn sàng tới scheduler on-prem, scheduler cloud hoặc pool thread/process local. Scheduler chỉ thấy từng task; quyết định vị trí chuyển từ "cụm nào chạy cả pipeline" sang "cụm nào chạy node này".

Vì sao

• Kết quả theo Optiver: dùng on-prem ở mức cao, dư địa "không giới hạn" qua cloud khi thật sự cần, ít bất ngờ từ data gravity; researcher chỉ lo chạy gì, không lo chạy ở đâu.

Bài học cho SWE

• Ở quy mô nghiên cứu, tổ hợp (ngày × công cụ × model × người) làm bùng nổ số job; phải thiết kế cho song song từ đầu.
• Data gravity là ràng buộc hạng nhất của mọi kiến trúc hybrid; quyết định vị trí trước thay vì tràn tuỳ hứng.
• Giữ đồ thị ở phía client cho phép định tuyến từng node tới nhiều backend mà không lộ độ phức tạp cho người dùng.

Liên quan

• Hudson River Trading 2026 (cũng vướng WAN giữa các site) · Two Sigma 2016 · Optiver 2026
• Hạ tầng nghiên cứu định lượng (dữ liệu thị trường, feature, backtest) · Nền tảng ML (feature, training, serving, giám sát model) · Chi phí hạ tầng và build vs buy