VPS cho GitLab Runner cần bao nhiêu vCPU dedicated?

Một VPS có thể chạy bao nhiêu CI job cùng lúc?

Một CI job cần hai vCPU chuyên dụng và lượng RAM đi kèm; cài đặt concurrent của runner quyết định bao nhiêu job như vậy chia sẻ cùng một VPS. Trong config.toml, concurrent giới hạn số job trên tất cả các runner đã đăng ký, còn limit giới hạn số job cho một runner đã đăng ký (0, giá trị mặc định, nghĩa là không giới hạn). Trang yêu cầu của GitLab nêu ba yếu tố để chọn cỡ: mức tải CPU của các job, lượng bộ nhớ chúng dùng và bao nhiêu job chạy đồng thời.

Các cỡ runner do GitLab lưu trữ so với VPS thế nào?

Các Linux runner do GitLab lưu trữ cấp 4 GB RAM cho mỗi vCPU; các gói Cobaltfell cấp 2 GB cho mỗi vCPU. Số vCPU khớp nhau một-một, khiến bảng này thành cách trực tiếp để chọn cỡ cho những pipeline vốn đã chạy trên GitLab.com. Những job dùng gần hết bộ nhớ của máy hiện tại cần gói Cobaltfell lớn hơn một cỡ, hoặc ít job chạy cùng lúc hơn.

Theo khảo sát của Cobaltfell ngày 2 tháng 11 năm 2026, một vCPU chuyên dụng trên bộ xử lý từ năm 2022 trở đi có giá trung vị là $8.20 một tháng tại các nhà cung cấp nhận crypto mà không cần kiểm tra giấy tờ, nên mỗi CI job song song hai vCPU tốn khoảng gấp đôi con số đó.

Mọi nhà cung cấp và mức giá đứng sau mức trung vị đó đều có trong một vCPU VPS chuyên dụng tốn bao nhiêu mỗi nhân vào tháng 11 năm 2026.

Vì sao nhân chuyên dụng lại quan trọng với CI và các job biên dịch?

Một bản build giữ CPU ở mức tải tối đa trong nhiều phút liền, đúng kiểu sử dụng mà các gói VPS chia sẻ được viết ra để hạn chế. Hai nhà cung cấp trong cùng khảo sát đó ghi điều này vào quy định của họ: điều khoản của Spartan Host cấm dùng hơn 50% số nhân được cấp trong hơn một giờ, và chính sách sử dụng hợp lý của Advin Servers giới hạn mức dùng CPU ở 75%.

Trên vCPU chia sẻ, chi phí còn hiện ra dưới dạng steal time. Một pipeline chạy nhanh vào đêm vắng lại kéo dài vào giờ cao điểm, và job bị timeout vì những lý do không liên quan đến code; steal time của CPU là gì và cách kiểm tra trên VPS chỉ cách đọc nó.

Tại Cobaltfell: Được phép chạy full load miễn là công việc của bạn cần: không có credit CPU, không có cửa sổ burst và không bị bóp hiệu năng sau vài phút ở mức 100%. Một vCPU là một luồng phần cứng của bộ xử lý máy chủ. Các luồng của bạn được ghim 1-1 vào VPS của bạn và không bao giờ được cho khách hàng khác mượn, và hai luồng của một lõi vật lý luôn đi cùng nhau, nên cứ mỗi 2 vCPU tạo thành một lõi nguyên vẹn mà không hàng xóm nào dùng chung. Không có hàng xóm trên các luồng, một pipeline có cache ấm mất khoảng thời gian như nhau ở mọi lần chạy, nên một job chậm là dấu hiệu chỉ về phía code. Quy tắc quy đổi vCPU sang nhân được giải thích trong một vCPU chuyên dụng là một nhân hay một luồng.

Làm sao để các bản build song song không tranh nhau cùng một vCPU?

Chia cho mỗi job một phần cố định của VPS và truyền cùng con số đó cho công cụ build. Các công cụ build không thống nhất về giá trị mặc định. GNU make chạy một recipe mỗi lần trừ khi được truyền -j. Cargo chạy đúng bằng số CPU logic. Ninja chạy song song dựa trên số CPU mà không cần ai bảo. Bốn bản build như vậy trên Fell 8 sẽ mỗi bản khởi chạy tám trình biên dịch: 32 tiến trình cho 8 luồng và 16 GB RAM.

Với Docker executor, mỗi job chạy trong container riêng, và [runners.docker] nhận một giới hạn cpus và một giới hạn memory cho container đó. Đặt cả hai, rồi khớp mức song song bên trong job:

concurrent = 4            # jobs at once, all runners together
check_interval = 3

[[runners]]
  name = "fell-8-docker"
  url = "https://gitlab.com"
  token = "REPLACE_WITH_YOUR_RUNNER_TOKEN"
  executor = "docker"
  limit = 4
  [runners.docker]
    image = "debian:13"
    cpus = "2"             # CPUs for each job container
    memory = "3g"          # leaves room for the system and Docker

variables:
  MAKEFLAGS: "-j2"          # GNU make
  CARGO_BUILD_JOBS: "2"     # cargo (build.jobs)

build:
  script:
    - make
    - cargo build --release
    - ninja -C build -j 2

Biên dịch Rust hoặc C++ cần gì trên một VPS?

Biên dịch cần luồng và bộ nhớ đi đôi với nhau: mỗi tiến trình biên dịch song song và mỗi bước link đều lấy phần RAM riêng của nó. Các translation unit C++ lớn và các crate Rust dùng nhiều generic là những điểm đỉnh bộ nhớ thường gặp, và bước link cuối của một binary lớn có thể cần nhiều hơn bất kỳ lần biên dịch đơn lẻ nào.

Một bản build bị kill vì thiếu bộ nhớ cần -j hoặc CARGO_BUILD_JOBS thấp hơn, không phải thêm vCPU: ít job hoàn thành hơn, nhiều job crash hơn. Giữ cache build trên ổ đĩa của chính VPS (Lưu trữ NVMe trên mọi gói) và dọn các image cũ bằng docker image prune, vì một runner bận rộn làm đầy ổ đĩa nhanh hơn mức các pipeline của nó gợi ý.

Một monorepo cần hàng chục gigabyte RAM cho mỗi bản build là địa hạt của bare-metal, thứ Cobaltfell không bán. Các bộ test dựa trên cơ sở dữ liệu có quy tắc chọn cỡ riêng, được đề cập trong PostgreSQL cần bao nhiêu CPU và RAM trên một VPS.

Runner trên VPS nên dùng executor nào?

Docker executor là lựa chọn mặc định đúng: hướng dẫn về executor của GitLab nói nó cấp cho mỗi bản build một môi trường sạch, biệt lập, trong khi Shell executor không cấp môi trường sạch cho mỗi bản build lẫn không bảo vệ hệ thống tệp của runner. Các executor Shell, SSH và VirtualBox đang ở chế độ bảo trì.

Ai có thể khởi chạy một job cũng quan trọng không kém: một merge request từ fork sẽ chạy chính code của nó trên VPS. Hướng dẫn bảo mật của GitHub nói rằng runner tự lưu trữ gần như không bao giờ nên dùng cho repository công khai, và lý lẽ tương tự áp dụng cho bất kỳ hệ thống CI nào chạy pull request không đáng tin cậy.

Các agent Forgejo, Woodpecker, Jenkins và GitHub Actions chọn cỡ theo cùng cách: đếm số job chồng lấn, cấp cho mỗi job số luồng và bộ nhớ cố định. Giá theo gói cho từng cỡ được liệt kê trong một VPS nhân chuyên dụng tốn bao nhiêu.