
GitHub Actions hay GitLab CI: runner mới là biến số của hóa đơn

Nếu nhóm đã quản lý mã nguồn và pull request trên GitHub, GitHub Actions thường là lựa chọn thuận tiện. Nếu muốn đặt pipeline và kiểm tra bảo mật trong cùng quy trình GitLab, GitLab CI đáng cân nhắc. Để chọn theo chi phí, cần tính job chạy trên hệ điều hành nào, dùng runner của ai và còn bao nhiêu phút đi kèm; giá gói tài khoản không trả lời được ba câu hỏi đó.
Runner do nền tảng cung cấp tạo khoản sử dụng theo thời gian chạy. Runner tự quản lý chuyển phần chi phí máy và vận hành sang nhóm. Vì vậy, cùng một pipeline có thể dẫn tới hóa đơn khác nhau dù số lần chạy không đổi, còn phương án có ít tiền trả cho nền tảng hơn chưa chắc có tổng chi phí thấp hơn.
GitHub và GitLab đếm thời gian chạy khác nhau ra sao?
Với kho mã riêng tư, quy tắc tính phí GitHub Actions cho biết GitHub Free có 2.000 phút runner tiêu chuẩn mỗi tháng và GitHub Team có 3.000 phút. Phút đi kèm thuộc tài khoản sở hữu kho mã, được làm mới theo chu kỳ; thời gian vượt hạn mức mới phát sinh phí sử dụng runner do GitHub cung cấp. Runner tự quản lý không chịu phí sử dụng Actions, còn runner tiêu chuẩn do GitHub cung cấp được dùng miễn phí cho kho mã công khai.
Trên GitLab.com, cách tính compute minutes của GitLab lấy thời lượng từng job nhân với hệ số runner; namespace Free có 400 compute minutes mỗi tháng. Linux x86-64 cỡ small có hệ số 1, Windows cỡ medium cũng là 1, còn macOS M1 cỡ medium là 6. Hai lựa chọn Windows và macOS này vẫn được ghi ở trạng thái beta. Thời gian chờ job ở trạng thái pending không đi vào phép tính, nhưng các job chạy song song đều tiêu thụ hạn mức riêng.
Do đó, 2.000 phút của GitHub và 400 compute minutes của GitLab không phải hai lượng thời gian có thể đặt cạnh nhau rồi chọn số lớn hơn. Với GitLab, cấu hình runner quyết định tốc độ tiêu thụ hạn mức; với GitHub, loại runner quyết định đơn giá của phần sử dụng phải trả. Cả hai còn chịu ảnh hưởng từ những pipeline khác dùng chung hạn mức tài khoản hoặc namespace.
Cùng một pipeline trên Linux, Windows và macOS tốn bao nhiêu?

Xét một ví dụ giả định cho kho mã riêng tư: trong một tháng có 100 pipeline, mỗi pipeline chạy một job Linux 10 phút, một job Windows 5 phút và một job macOS 5 phút. Giả sử mọi job kết thúc đúng thời lượng đó, không chạy lại và được phép dùng các runner đã chọn. Đây là phép tính theo thời lượng đặt trước, không phải phép đo cho thấy job trên hai nền tảng có tốc độ hoặc cấu hình phần cứng tương đương.
Bảng giá runner của GitHub niêm yết 0,006 USD/phút cho Linux x64 hai lõi, 0,010 USD/phút cho Windows x64 hai lõi và 0,062 USD/phút cho macOS tiêu chuẩn. Khi toàn bộ phút trong ví dụ đều là phút phải trả, phần Linux là 1.000 × 0,006 = 6 USD; Windows là 500 × 0,010 = 5 USD; macOS là 500 × 0,062 = 31 USD. Tổng cộng là 42 USD, trong đó job macOS chiếm 31 USD dù chỉ dùng một phần tư tổng thời gian chạy.
GitHub làm tròn thời gian của từng job lên phút nguyên trước khi tính phí. Ví dụ dùng thời lượng nguyên phút nên chưa phát sinh phần chênh từ làm tròn; nếu chia một bước chạy thành nhiều job ngắn, tổng phút được ghi nhận có thể cao hơn thời gian thực cộng lại. Con số 42 USD cũng chỉ là chi phí runner ở đơn giá niêm yết, chưa gồm khoản lưu trữ artifact hoặc dịch vụ khác.
Với các runner GitLab.com đã nêu, một pipeline giả định tiêu thụ 10 × 1 + 5 × 1 + 5 × 6 = 45 compute minutes. Một trăm lần chạy cần 4.500 compute minutes: phần macOS đóng góp 3.000, Linux 1.000 và Windows 500. Đây là so sánh theo cùng thời lượng job; việc Windows và macOS còn ở beta khiến khả năng dùng đúng cấu hình đó là điều kiện của mô hình, không phải bảo đảm cho mọi nhóm.
Phút đi kèm thay đổi số tiền phải mua như thế nào?
GitLab bán 1.000 compute minutes bổ sung với giá 10 USD cho mỗi nhóm cấp cao nhất hoặc namespace cá nhân. Phút mua thêm được dùng sau hạn mức tháng; phần chưa dùng có thể chuyển sang tháng sau trong thời hạn 12 tháng kể từ ngày mua. Thời gian chạy trên runner riêng của khách hàng không bị trừ vào hạn mức compute minutes của GitLab.com.
Nếu namespace Free bắt đầu tháng với đủ 400 compute minutes và không có job nào khác, pipeline hỗn hợp cần mua đủ cho 4.100 phút vượt hạn mức. Vì phút bổ sung bán theo gói 1.000, số tiền cần chi là 50 USD cho năm gói; sau loạt pipeline còn 900 phút đã mua. Nếu hạn mức tháng đã hết từ trước, toàn bộ 4.500 phút cũng cần năm gói, nên khoản mua vẫn là 50 USD nhưng chỉ còn 500 phút. Số tiền mua theo gói và giá trị phút thực sự đã dùng là hai đại lượng khác nhau.
Ở phía GitHub, 42 USD là mức của ví dụ khi toàn bộ phút đi kèm đã hết. Nếu tài khoản còn hạn mức, một phần job chạy trên runner tiêu chuẩn sẽ được bao phủ và tiền trả cho runner thấp hơn; cần dùng số dư thực tế của chủ kho mã để tính khoản vượt. Có thể thấy tác động của hạn mức rõ hơn ở một biến thể chỉ chạy job Linux: 100 lần × 10 phút tạo 1.000 phút. Khối lượng đó nằm trong 2.000 phút đi kèm của GitHub Free nếu tài khoản chưa dùng phút nào, trong khi trên GitLab.com Free nó vượt 400 compute minutes và cần mua một gói bổ sung.
Runner tự quản lý chuyển chi phí sang đâu?

Chạy job trên máy của nhóm bỏ được khoản phí sử dụng Actions cho runner tự quản lý và tránh trừ compute minutes của GitLab.com cho runner riêng. Đổi lại, nhóm trả tiền máy vật lý hoặc máy ảo, điện hoặc dịch vụ hạ tầng, lưu trữ, mạng và thời gian quản trị. Máy vẫn có thể phát sinh chi phí khi không có job, trong khi một runner dùng chung cho nhiều pipeline có cơ hội tận dụng năng lực tốt hơn.
Khả năng chạy đồng thời cũng là một phần của phép tính. Nếu nhiều job đến cùng lúc mà runner riêng không đủ chỗ, pipeline phải chờ hoặc nhóm phải cấp thêm máy; thời gian hoàn tất công việc khi đó có thể đổi dù phí theo phút của nền tảng giảm. Với job macOS, nhóm còn phải có môi trường macOS phù hợp. Các khoản này phụ thuộc hạ tầng và cách vận hành cụ thể, nên không thể lấy 42 USD hoặc 50 USD trong ví dụ làm ngưỡng chung để quyết định tự quản lý.
Runner riêng cũng cần được cập nhật và cách ly phù hợp với mã mà nó thực thi, nhất là khi pipeline nhận đóng góp từ nhiều người. Công sức vận hành đó là một phần của tổng chi phí, nhưng không có đơn giá cố định để cộng vào phép tính minh họa. Trước khi so hóa đơn, cần biết máy hiện có được dùng cho việc gì khác và liệu một job đang chờ runner có ảnh hưởng tới nhịp phát hành hay không.
Khi nào quy trình phát triển đáng ưu tiên hơn chênh lệch phút chạy?
GitLab CI có lợi thế về sự liền mạch nếu nhóm muốn quản lý mã nguồn, pipeline và kết quả quét bảo mật trong GitLab. Tài liệu SAST của GitLab cho biết khả năng quét cơ bản có trong Free và Premium, còn phân tích nâng cao cùng một số cách hiển thị phát hiện trong merge request thuộc Ultimate. Thêm job quét vào pipeline cũng tăng thời gian runner hoạt động, nên giá trị tích hợp cần được cân cùng hạn mức compute và cấp gói cần dùng.
GitHub Actions hợp với nhóm đã đặt kho mã, pull request và các bước tự động hóa ở GitHub. Khi quy trình cần nhiều công cụ bên ngoài, khoản thời gian thiết lập và duy trì các tích hợp ấy cũng có giá trị đối với nhóm, dù nó không xuất hiện trong phép nhân phút chạy. Chọn nền tảng vì thế là quyết định về nơi duy trì quy trình; chọn runner là quyết định về nơi chi trả tài nguyên thực thi.
Với một pipeline chủ yếu chạy Linux và còn phút đi kèm, chênh lệch phí runner có thể nhỏ hoặc bằng không. Khi job macOS xuất hiện thường xuyên, đơn giá GitHub và hệ số tiêu thụ GitLab khiến phần việc này nổi bật trong phép tính. Nếu nhóm chuyển nó sang runner riêng, câu hỏi quyết định trở thành chi phí duy trì năng lực chạy macOS và thời gian chờ có chấp nhận được hay không.
Đọc thêm:
Bài viết liên quan


Dùng GitLab Duo `/goal`: viết tiêu chí hoàn tất trước khi giao quyền sửa mã

GitHub Actions sẽ xóa lịch sử theo mốc mặc định 90 ngày từ 1/10

GitLab 19.4 giao cả mục tiêu cho agent, quyền ghi vẫn phải xin phép

pnpm hay npm: cache trống có thể đảo ngược kết quả tốc độ

Claude Code hay Codex CLI: loại tác vụ quan trọng hơn một bảng xếp hạng
Đăng ký bản tin
Nhận tin Web3, AI và tiền mã hóa mới nhất ngay trong hộp thư.