Giao dịch crypto độ trễ thấp: Vị trí máy chủ sàn giao dịch, độ trễ API thực tế và nơi đặt bot của bạn 07/11/2026 – Posted in: Arbitrage Software, cryptoarbitrage software

Độ trễ thấp có ý nghĩa gì trong giao dịch crypto

Trả lời ngắn: giao dịch crypto độ trễ thấp nghĩa là rút ngắn khoảng thời gian từ khi giá thay đổi trên sàn đến khi lệnh của bạn tới matching engine của sàn đó. Phần lớn thời gian này là khoảng cách vật lý: các sàn lớn chạy engine ở những khu vực đám mây cụ thể, chủ yếu tại Tokyo, Singapore và Hồng Kông, và một bot đặt ở châu lục khác chậm hơn 150 đến 250 mili giây so với bot đặt ngay cạnh engine. Phần lớn thứ hai là chi phí phụ có thể tránh được: kết nối nguội, polling REST, đồng hồ đồng bộ kém và mã chậm.

Trong forex, độ trễ là câu chuyện về vài trung tâm dữ liệu nổi tiếng ở London, New York và Tokyo, và về cầu thanh khoản của các broker. Trong crypto, bức tranh khác hẳn. Không có khu trung tâm chung của các sàn: mỗi sàn tự chọn khu vực đám mây của mình, phần lớn nằm trên hạ tầng đám mây công cộng, và API của họ thường được đặt sau các mạng phân phối nội dung (CDN) khiến sàn trông có vẻ gần trong khi thực tế không phải vậy. Điều đó khiến việc đo vừa dễ hơn (bạn có thể thuê một máy chủ trong cùng khu vực đám mây với giá một bữa tối) vừa dễ gây hiểu lầm hơn (các phép thử hiển nhiên lại đo sai thứ).

Độ trễ quan trọng đến mức nào phụ thuộc vào chiến lược:

Nếu lợi thế của bạn đến từ các chênh lệch cấu trúc chậm, như arbitrage funding rate hoặc các giao dịch chuyển tiền bị giới hạn bởi phí rút tiền và thời gian xác nhận mạng, bạn không cần gì trong hướng dẫn này ngoài một máy chủ ổn định. Nếu bạn giao dịch chênh lệch giá giữa các sổ lệnh, độ trễ chính là khác biệt giữa khớp được lệnh và chạy theo giá.

Ngân sách độ trễ: từng mili giây đi đâu

"Độ trễ" không phải là một con số duy nhất. Một lệnh phản ứng với biến động thị trường đi qua một chuỗi các bước, và mỗi bước cộng thêm thời gian. Suy nghĩ theo kiểu ngân sách cho bạn biết phần nào bạn thay đổi được và phần nào không.

Quy luật rất rõ: hai yếu tố bạn kiểm soát được và được đo bằng hàng chục hoặc hàng trăm mili giây là máy chủ của bạn đặt ở đâu và kết nối của bạn có được giữ ấm hay không. Mọi thứ khác hoặc thuộc về sàn, hoặc nhỏ nếu phần mềm được viết hợp lý. Đó là lý do phần còn lại của hướng dẫn tập trung vào vị trí và cách đo.

Các sàn crypto đặt matching engine ở đâu

Các sàn hiếm khi công bố vị trí chính xác của matching engine, nhưng phần lớn chạy trên đám mây công cộng, và có thể suy ra khu vực từ các phép đo độ trễ thực hiện từ nhiều khu vực đám mây. Các phép đo độc lập do bên thứ ba công bố năm 2026 thống nhất với nhau về phần lớn các sàn lớn. Bảng dưới đây tóm tắt các khu vực được công bố công khai. Hãy coi đó là điểm xuất phát cho các phép thử của riêng bạn, không phải sự bảo đảm: các sàn có di chuyển (ví dụ, BitMEX được cho là đã chuyển engine từ Dublin sang Tokyo năm 2025).

Từ đó có hai kết luận thực tế. Thứ nhất, Tokyo là nơi gần nhất với một trung tâm giao dịch chung của crypto: một máy chủ ở đó chỉ cách Binance và vài sàn lớn khác vài mili giây, cách Hồng Kông khoảng 25 ms một chiều và Singapore khoảng 35 ms một chiều. Thứ hai, bất kỳ chiến lược nào ghép một sàn châu Á với Coinbase hoặc một sàn châu Âu đều có mức sàn vật lý 70 đến 120 ms một chiều giữa hai engine, dù bạn làm gì với máy chủ của mình.

Đặt máy chủ ở một quốc gia nào đó không thay đổi việc bạn được phép dùng sàn nào. Hãy tuân thủ điều khoản dịch vụ của từng sàn và quy định tại nơi bạn sinh sống; tuyệt đối không dùng máy chủ hoặc VPN để lách các hạn chế địa lý.

Cái bẫy CDN: vì sao ping nói dối

Sai lầm phổ biến nhất là đo độ trễ bằng ping hoặc bằng thời gian mở kết nối TCP tới tên máy chủ API. Gần như mọi sàn lớn đều đặt các endpoint REST và WebSocket công khai sau một CDN hoặc bộ cân bằng tải đám mây có các điểm biên trên toàn thế giới. Khi bạn kết nối tới api.binance.com từ châu Âu hoặc Bắc Mỹ, máy chủ trả lời bắt tay TCP của bạn là một nút biên ở thành phố gần đó, không phải matching engine ở Tokyo. Bắt tay chỉ mất vài mili giây; sau đó nút biên chuyển tiếp yêu cầu của bạn qua mạng xương sống của nhà cung cấp tới origin thật, và thời gian bị tiêu tốn chính ở đó.

Vì vậy, ping 5 ms tới tên máy chủ của sàn có thể đi cùng với thời gian yêu cầu thực tế 150 ms. Những con số duy nhất có ý nghĩa là những con số bao gồm cả quãng đường tới origin: thời gian tới byte đầu tiên của một phản hồi API thật trên kết nối đã mở sẵn, độ chênh giữa dấu thời gian sự kiện của chính sàn và thời điểm bạn nhận được trên WebSocket, và thời gian từ khi gửi lệnh đến khi nhận xác nhận.

Do BJF Trading Group đo ngày 7 tháng 11 năm 2026 từ một máy chủ web ở Montreal (Leaseweb), dùng endpoint thời gian công khai, hai lượt chạy gồm một yêu cầu nguội và 20 yêu cầu ấm cho mỗi sàn.

Những gì chúng tôi đo được từ máy chủ ở Montreal

Để thể hiện hiệu ứng bằng số liệu thật thay vì lời quảng cáo của nhà cung cấp, chúng tôi chạy một phép thăm dò nhỏ từ máy chủ web đang lưu trữ trang này, đặt tại Montreal. Với tám sàn, nó mở một kết nối, gửi một yêu cầu (nguội), sau đó gửi thêm 20 yêu cầu trên cùng kết nối keep-alive (ấm), với tốc độ bốn yêu cầu mỗi giây, và lặp lại toàn bộ lượt chạy hai lần. Endpoint là lệnh gọi thời gian máy chủ công khai của từng sàn, gần như không xử lý gì, nên kết quả gần với thời gian truyền thuần cộng thời gian gateway.

Phép thử nhỏ này cho ra bốn bài học:

• Thời gian kết nối là vô nghĩa khi có CDN phía trước. OKX trả lời bắt tay TCP trong 3 đến 4 ms, nhưng mọi yêu cầu thật đều mất khoảng 170 ms, vì công việc thực sự diễn ra ở Hồng Kông.
• Thứ hạng đi theo địa lý. Từ Montreal, Coinbase (bờ Đông Hoa Kỳ) nhanh nhất, Kraken (châu Âu) đứng thứ hai, còn các sàn châu Á tập trung ở mức 150 đến 225 ms. Từ Tokyo, thứ tự sẽ đảo ngược.
• Kết nối nguội rất đắt. Khi không có nút biên gần đó, mỗi vòng bắt tay đều vượt Thái Bình Dương: yêu cầu đầu tiên tới Gate.io mất khoảng 0.7 giây, các yêu cầu sau khoảng 0.18 giây. Một bot chỉ mở kết nối mới khi thấy tín hiệu thì đã thua rồi.
• Phần đuôi rất quan trọng. Trung vị của Bybit là 225 ms nhưng cứ mười yêu cầu thì có một yêu cầu mất hơn 400 ms. Một chân arbitrage chỉ nhanh bằng những trường hợp chậm của nó, vì vậy hãy luôn xem p90 và p99, không chỉ trung vị.

Những con số này mô tả một máy chủ web trong một buổi chiều, không phải một hệ thống giao dịch, và chúng bao gồm thời gian xử lý gateway của từng sàn. Đây không phải bảng xếp hạng các sàn. Mục đích là cho thấy quy mô của các hiệu ứng: địa lý và cách xử lý kết nối chiếm hơn 90% độ trễ mà một bot ở xa phải chịu.

Từng bước: đo độ trễ sàn giao dịch đúng cách

Bạn có thể tái tạo một phép đo có ý nghĩa từ bất kỳ máy chủ nào trong vòng một giờ. Phương pháp dưới đây là cách chúng tôi khuyến nghị trước khi chọn khu vực hosting hoặc sau bất kỳ thay đổi hạ tầng nào.

Với bước 2, chỉ cần curl thông thường là đủ để bắt đầu. Lặp lại URL khiến curl tái sử dụng một kết nối; dòng đầu tiên là yêu cầu nguội, các dòng còn lại là yêu cầu ấm:

curl -s –rate 4/s -w "%{num_connects} %{time_connect} %{time_starttransfer}\n" -o /dev/null URL -o /dev/null URL -o /dev/null URL

Với bước 4 và 5, bạn cần vài dòng mã bằng ngôn ngữ mà bot của bạn sử dụng, vì phép đo phải đi qua cùng thư viện client, cùng bộ phân tích JSON và cùng thiết lập kết nối như khi giao dịch thật. Con số do một công cụ khác tạo ra chỉ cho bạn biết về công cụ đó.

Dữ liệu thị trường qua WebSocket và đồng bộ đồng hồ

Với mọi thứ nhạy cảm về thời gian, dữ liệu thị trường nên đến từ luồng WebSocket, không phải từ polling REST. Một vòng polling yêu cầu sổ lệnh mỗi 200 ms sẽ thêm trung bình 100 ms chờ trước khi nó thậm chí nhìn thấy thay đổi, cộng thêm thời gian yêu cầu, và nó tiêu tốn ngân sách giới hạn tần suất mà bạn cần cho việc đặt lệnh. Luồng WebSocket đẩy từng cập nhật ngay khi sàn phát ra. Chi tiết về luồng, sổ lệnh cục bộ và kiểm tra thứ tự được trình bày trong hướng dẫn kết nối với API sàn crypto cho arbitrage; ở đây chúng tôi tập trung vào thời gian.

Đo độ trễ luồng dữ liệu

Phần lớn tin nhắn WebSocket của sàn mang một dấu thời gian do sàn đặt: thời điểm sự kiện, thời điểm khớp lệnh hoặc thời điểm tin nhắn, thường tính bằng mili giây. Lấy thời điểm nhận cục bộ trừ đi giá trị này, bạn có độ trễ luồng dữ liệu, bao gồm cả độ trễ phát nội bộ của sàn và quãng đường mạng. Hãy ghi lại theo từng luồng, không chỉ là giá trị trung bình: snapshot độ sâu, cập nhật sổ lệnh gia tăng và luồng khớp lệnh có thể hoạt động khác nhau, còn các luồng tổng hợp phát mỗi 100 ms sẽ cho thấy dạng răng cưa.

Vì sao đồng hồ quan trọng

Phép đo một chiều chỉ chính xác bằng mức khớp nhau giữa đồng hồ của bạn và đồng hồ của sàn. Nếu đồng hồ máy chủ của bạn chậm 15 ms, mọi độ trễ luồng dữ liệu sẽ trông tốt hơn thực tế 15 ms. Trên máy chủ đám mây, hãy chạy chrony với dịch vụ thời gian của nhà cung cấp và kiểm tra chronyc tracking: độ lệch trong khoảng một mili giây là cơ sở vững chắc để so sánh các khu vực. Nhiều sàn cũng cung cấp endpoint thời gian máy chủ; so sánh nó với đồng hồ của bạn trong khi tính đến một nửa thời gian khứ hồi đo được sẽ cho một phép kiểm tra chéo sơ bộ. Các endpoint đặt lệnh chấp nhận cửa sổ nhận (tuổi tối đa cho phép của dấu thời gian yêu cầu) cũng sẽ từ chối lệnh khi đồng hồ của bạn bị lệch, đó là thêm một lý do để giữ nó đồng bộ.

Đo riêng đường đi của lệnh

Độ trễ luồng dữ liệu cho bạn biết góc nhìn của bạn về thị trường cũ đến mức nào. Vòng khứ hồi của lệnh cho bạn biết mất bao lâu để hành động dựa trên góc nhìn đó. Hai giá trị này thường khác nhau: yêu cầu đặt lệnh phải qua xác thực, tính toán giới hạn tần suất và kiểm tra rủi ro mà luồng dữ liệu thị trường không phải qua. Một số sàn, trong đó có Binance, cung cấp endpoint thử lệnh để xác thực một lệnh đã ký mà không gửi tới matching engine; nó đo phần mạng và gateway. Nếu sàn cho phép đặt lệnh qua WebSocket hoặc phiên FIX, hãy đo cả phần đó, vì một phiên duy trì liên tục tránh được chi phí cho từng yêu cầu.

Chọn khu vực hosting cho arbitrage giữa hai sàn

Với một sàn duy nhất, câu trả lời đơn giản: thuê một máy chủ trong cùng khu vực đám mây với engine của sàn. Arbitrage giữa hai sàn là một bài toán hình học, vì các engine nằm ở những nơi khác nhau và bạn chỉ có thể ở cạnh một trong số đó.

Lấy ví dụ arbitrage phòng hộ giữa Binance (Tokyo) và Bybit (Singapore). Thời gian khứ hồi giữa hai khu vực khoảng 70 ms, tức khoảng 35 ms một chiều. Hãy xem các phương án chính:

Thời gian khứ hồi là giá trị điển hình ước lượng giữa các khu vực đám mây công cộng; hãy kiểm tra số liệu liên khu vực hiện tại của nhà cung cấp và tự đo từ máy chủ của bạn.

Nhận xét then chốt là thông tin luôn phải vượt qua khoảng cách giữa hai sàn. Nếu giá biến động trên Binance và báo giá cũ còn nằm trên Bybit, máy chủ ở Tokyo thấy biến động ngay lập tức và lệnh của nó đi 35 ms tới Singapore; máy chủ ở Singapore nhận biến động trễ 35 ms nhưng lệnh của nó đến ngay. Tổng thời gian là như nhau. Điều thay đổi là phần nào của chuỗi phải chờ, và do đó quyết định nào nên dẫn dắt lựa chọn:

• Đặt máy chủ cạnh sàn nơi lệnh phải thắng. Nếu lợi nhuận của bạn phụ thuộc vào việc khớp một báo giá trước các trader khác trên một sàn, hãy cạnh tranh tại nơi hàng đợi đó được quyết định. Ở đó, thông tin của mọi người về sàn kia đến với cùng tốc độ, nhưng lệnh của bạn không phải di chuyển.
• Đặt lệnh phòng hộ trên sổ lệnh sâu hơn. Chân đến sàn muộn hơn nên là chân ít nhạy cảm nhất với vài mili giây: sổ lệnh có thanh khoản cao hơn, nơi giá phòng hộ khó biến động nhiều.
• Biết nhanh trạng thái khớp lệnh. Ở cạnh sàn thường xảy ra khớp một phần giúp bạn xác định khối lượng phòng hộ dựa trên thông tin chính xác, giảm rủi ro chưa được phòng hộ.
• Chỉ tách khi có lợi. Hai tiến trình, mỗi khu vực một tiến trình, có thể mỗi bên giữ một sổ lệnh cục bộ và phản ứng tại chỗ, nhưng chúng phải phối hợp qua cùng đường truyền 70 ms. Điều này tăng độ phức tạp và các điểm lỗi, và chủ yếu đáng làm với các hệ thống chuyên nghiệp.

Với các chiến lược trải trên ba sàn châu Á trở lên, Tokyo thường là trung tâm thực tế vì có nhiều sàn lớn ở đó. Với các cặp có sàn Mỹ hoặc châu Âu, chân liên lục địa chiếm ưu thế và chiến lược phải chịu được 70 đến 120 ms một chiều, điều này loại trừ cạnh tranh thuần túy về tốc độ và ưu tiên các chênh lệch lớn hơn, kéo dài hơn.

Độ trễ biến thành tiền như thế nào

Chênh lệch giá giữa hai sổ lệnh không phải là một giải thưởng cố định. Các trader khác cũng thấy nó, market maker cập nhật báo giá, và chênh lệch biến mất trong một khoảng thời gian phụ thuộc vào tài sản và sàn. Một cách đơn giản để suy nghĩ là giả định mỗi cơ hội tồn tại trong một khoảng thời gian ngẫu nhiên với tuổi thọ trung bình, rồi hỏi khả năng nó vẫn còn khi lệnh của bạn đến là bao nhiêu.

Trong mô hình này, xác suất một chênh lệch vẫn còn sau thời gian phản ứng L mili giây là exp(−L / τ), trong đó τ là tuổi thọ trung bình của chênh lệch. Kết quả cho ba thời gian phản ứng, tương ứng gần đúng với máy chủ cùng khu vực (5 ms), ở khu vực lân cận (40 ms) và ở châu lục khác (150 ms):

Giờ hãy gắn tiền vào. Giả sử một chiến lược tìm thấy 200 tín hiệu mỗi ngày với lợi thế ròng 0.10% trên giao dịch 5,000 USDT, tức 5 USDT cho mỗi tín hiệu bắt được, và một tín hiệu bị lỡ trung bình tốn 1.5 USDT, vì một chân đã khớp và phải đóng lại. Với các chênh lệch có tuổi thọ 200 ms:

Các con số là giả định, nhưng kết luận thì vững chắc: chuyển bot từ châu lục khác về đúng khu vực có thể nhân kết quả của cùng một chiến lược lên nhiều lần, còn chuyển từ khu vực lân cận về cùng khu vực mang lại cải thiện nhỏ hơn nhưng vẫn đáng kể. Nó cũng cho thấy giới hạn: với các chênh lệch tồn tại từ một giây trở lên, độ trễ hầu như không quan trọng, và phí, trượt giá cùng tồn kho mới quyết định kết quả. Trước khi chi tiền cho hạ tầng, hãy kiểm tra các chênh lệch bạn giao dịch thực sự kéo dài bao lâu; công cụ quét arbitrage crypto miễn phí cho phép bạn theo dõi trực tiếp chênh lệch giá thực tế giữa các sàn.

Colocation, VPS và điều gì thực tế với trader độc lập

Trong forex và chứng khoán, colocation nghĩa là thuê chỗ đặt máy trong cùng trung tâm dữ liệu với máy chủ của sàn hoặc broker, và các trung tâm chính đều đã được biết rõ (xem hướng dẫn về VPS arbitrage forex và các trung tâm colocation). Trong crypto, thứ tương đương với phần lớn trader đơn giản là một máy chủ ảo trong cùng khu vực đám mây với sàn. Vì bản thân engine chạy trên đám mây đó, một máy chủ cùng khu vực đã chỉ cách nó một hoặc hai mili giây, với chi phí vài chục đô la mỗi tháng.

Trong một khu vực, availability zone có thể tạo thêm khác biệt cỡ một phần mili giây. Điều này chỉ quan trọng khi bạn cạnh tranh với market maker chuyên nghiệp trên các cặp thanh khoản cao nhất, và chỉ đáng thử sau khi bạn đã xử lý các hạng mục lớn hơn: khu vực, kết nối ấm, dữ liệu WebSocket và mã của chính bạn. Các nguyên tắc chung về việc máy chủ cần nhanh đến đâu, và vì sao độ trễ thấp quan trọng hơn cấu hình cao, được trình bày trong VPS của bạn cần nhanh đến mức nào cho arbitrage.

Độ trễ bên trong phần mềm của chính bạn

Khi máy chủ đã ở đúng chỗ, các độ trễ còn lại phần lớn là do tự gây ra. Các thủ phạm thường gặp, theo thứ tự chúng tôi hay thấy:

• Mở kết nối khi cần. Giữ kết nối REST sống bằng connection pool, định kỳ gửi một yêu cầu nhẹ để kết nối nhàn rỗi không bị đóng, và chủ động kết nối lại WebSocket trước thời gian phiên tối đa của sàn.
• Polling thay vì streaming. Dùng dữ liệu thị trường qua WebSocket và, khi có thể, đặt lệnh qua WebSocket hoặc FIX.
• Xử lý nặng trên đường nóng. Ghi log ra đĩa, phân tích từng trường của các tin nhắn JSON lớn, hay tính lại toàn bộ sổ lệnh sau mỗi cập nhật đều cộng thêm mili giây. Hãy làm tối thiểu trước khi gửi lệnh và hoãn phần còn lại.
• Hình phạt giới hạn tần suất. Bot vượt quá giới hạn trọng số yêu cầu sẽ bị từ chối hoặc tạm khóa, tức là độ trễ vô hạn. Hãy lập ngân sách yêu cầu cho từng sàn và giảm tốc trước khi chạm giới hạn, không phải sau đó.
• Thu gom rác và tranh chấp CPU. Trên một VPS chia sẻ nhỏ, các người dùng khác và các lần tạm dừng dọn bộ nhớ có thể thêm hàng chục mili giây vào những thời điểm ngẫu nhiên. Điều đó lộ ra ở p99, không phải ở giá trị trung bình.
• Gửi các chân lệnh tuần tự. Nếu hai chân của lệnh phòng hộ độc lập với nhau, hãy gửi song song thay vì chờ xác nhận đầu tiên.

Phần mềm VIP Crypto Arbitrage của BJF Trading Group kết nối với các sàn spot và futures tập trung qua API gốc của họ và chạy trên máy chủ do bạn chọn, vì vậy các nguyên tắc về vị trí trong hướng dẫn này áp dụng trực tiếp cho nó. Về logic của chính các chiến lược dựa trên độ trễ, xem hướng dẫn arbitrage độ trễ, và để có bức tranh tổng thể về các chiến lược liên sàn, xem tổng quan về arbitrage crypto.

Rủi ro và giới hạn

• Độ trễ tự nó không phải là lợi thế. Nhanh chỉ có ích nếu chiến lược có lãi sau phí, trượt giá và chi phí tồn kho. Một bot nhanh với lợi thế âm chỉ mất tiền nhanh hơn.
• Vị trí thay đổi. Các sàn di chuyển engine và đổi nhà cung cấp CDN. Một khu vực đúng năm ngoái có thể không còn đúng hôm nay; hãy đo lại thường xuyên.
• Phép đo mang tính cục bộ. Các con số Montreal của chúng tôi, và mọi bảng được công bố, chỉ mô tả một địa điểm và một thời điểm. Chỉ những phép đo từ máy chủ của chính bạn, qua phần mềm của chính bạn, mới có giá trị cho quyết định của bạn.
• Độ trễ phía sàn chiếm ưu thế khi căng thẳng. Khi thị trường biến động dữ dội, gateway xếp hàng các yêu cầu và xác nhận chậm lại với tất cả mọi người. Chiến lược của bạn phải chịu được điều này, ví dụ bằng cách giới hạn quy mô vị thế khi thời gian xác nhận tăng lên.
• Cuộc chạy đua vũ trang không có hồi kết. Trên các cặp thanh khoản cao nhất, các công ty chuyên nghiệp đầu tư vào tốc độ nhiều hơn rất nhiều so với khả năng của một trader độc lập. Hãy tìm những chênh lệch kéo dài đủ lâu cho hệ thống của bạn thay vì cạnh tranh ở những chênh lệch ngắn nhất.
• Tuân thủ. Vị trí máy chủ không thay đổi tư cách pháp lý của bạn. Chỉ dùng các sàn và sản phẩm mà bạn được phép sử dụng, và tôn trọng điều khoản API cũng như giới hạn tần suất.

Câu hỏi thường gặp

Bài viết này mang tính giáo dục và không phải lời khuyên tài chính. Các số liệu độ trễ trong bảng Montreal do BJF Trading Group đo ngày 7 tháng 11 năm 2026 từ một máy chủ và không phải bảng xếp hạng các sàn; thông tin khu vực dựa trên các phép đo của bên thứ ba được công bố công khai và có thể thay đổi. Các số liệu và biểu đồ được đánh dấu là minh họa hoặc ước lượng là mô hình và giá trị điển hình, không phải phép đo của bất kỳ sàn hay trader cụ thể nào.