# GitLab Runner VPS ต้องใช้ dedicated vCPU กี่ตัว?

> ต้องใช้ VPS อะไรสำหรับ GitLab Runner? ประมาณ 2 dedicated vCPU ต่อหนึ่ง CI job แบบขนาน 2 ถึง 16 vCPU การกำหนดขนาด และไม่ต้อง KYC ที่ Cobaltfell

- URL: https://cobaltfell.com/th/vps-for-ci-builds/
- อัปเดตล่าสุด: 2026-11-02
- ผู้เผยแพร่: Cobaltfell (https://cobaltfell.com)

ฉันต้องใช้ VPS อะไรสำหรับ GitLab Runner หรือ CI/CD pipeline? VPS แบบ dedicated vCPU รัน job ได้กี่งานพร้อมกัน, ขนาดของ hosted runner ของ GitLab เปรียบเทียบกันอย่างไร และวิธีป้องกันไม่ให้ build แบบขนานแย่ง thread กัน

**คำตอบแบบสั้น — ฉันต้องใช้ VPS อะไรสำหรับ GitLab Runner หรือ CI/CD pipeline?**

GitLab Runner บน VPS ต้องใช้ประมาณ 2 vCPU แบบเฉพาะ (dedicated) ต่อหนึ่ง CI job ที่รันพร้อมกัน: บน **Cobaltfell** แพ็ก Fell 2 รับได้หนึ่ง job, Fell 4 สอง job และ Fell 8 สี่ job GitLab hosted Linux runner แบบ default มี 2 vCPU และ RAM 8 GB (ตรวจสอบเมื่อ 2 พฤศจิกายน 2026) ดังนั้นแพ็ก Cobaltfell ที่มีจำนวน vCPU เท่ากันจึงมีหน่วยความจำครึ่งหนึ่ง และ build ที่กิน RAM มากต้องใช้ขนาดที่ใหญ่ขึ้นไปอีกหนึ่งขั้น

## VPS หนึ่งเครื่องรัน CI job พร้อมกันได้กี่ job?

**หนึ่ง CI job ต้องใช้ 2 vCPU แบบเฉพาะและ RAM ที่มาคู่กัน; การตั้งค่า `concurrent` ของ runner เป็นตัวกำหนดว่าจะมี job แบบนี้กี่ตัวแชร์ VPS เครื่องเดียวกัน** ใน `config.toml`, `concurrent` จำกัดจำนวน job ข้าม runner ที่ลงทะเบียนไว้ทั้งหมด และ `limit` จำกัดจำนวน job สำหรับ runner ที่ลงทะเบียนไว้หนึ่งตัว (`0` ซึ่งเป็นค่า default หมายถึงไม่จำกัด) หน้าข้อกำหนดของ GitLab ระบุปัจจัยสามอย่างที่ใช้กำหนดขนาด: CPU load ของ job, การใช้หน่วยความจำ และจำนวน job ที่รันพร้อมกัน

*จุดเริ่มต้นนำมาจากค่า default ของเครื่องมือ ไม่ใช่จากการวัดเวลา ผล YABS และ Geekbench 6 ของเราเอง พร้อมด้วย steal time ที่เราวัดได้ จะถูกเผยแพร่พร้อมวันที่เมื่อเครื่องทดสอบเครื่องแรกของเราส่งมอบแล้ว จนถึงตอนนั้นเราจะไม่กล่าวอ้างตัวเลขประสิทธิภาพใดๆ ของเราเอง*

| แพ็กเกจ | vCPU | RAM | concurrent | พอดี |
| --- | --- | --- | --- | --- |
| Fell 2 | 2 | 4 GB | 1 | หนึ่ง pipeline ต่อครั้ง: โปรเจกต์ส่วนตัวหรือทีมที่ push ไม่กี่ครั้งต่อชั่วโมง |
| Fell 4 | 4 | 8 GB | 2 | สอง job สั้น ๆ พร้อมกัน หรือหนึ่ง build ยาวบนสี่ thread |
| Fell 8 | 8 | 16 GB | 4 | สี่ job ที่ 2 vCPU หรือสอง job ที่ 4 vCPU |
| Fell 16 | 16 | 32 GB | 4 ถึง 8 | ทีมที่ merge request เริ่มหลาย pipeline พร้อมกัน |

## ขนาด hosted runner ของ GitLab เทียบกับ VPS เป็นอย่างไร?

**GitLab hosted Linux runner ให้ RAM 4 GB ต่อ vCPU; แพ็ก Cobaltfell ให้ 2 GB ต่อ vCPU** จำนวน vCPU ตรงกันแบบหนึ่งต่อหนึ่ง ทำให้ตารางนี้เป็นวิธีตรงไปตรงมาในการเลือกขนาดสำหรับ pipeline ที่รันบน GitLab.com อยู่แล้ว job ที่ใช้หน่วยความจำเกือบทั้งหมดของเครื่องปัจจุบันต้องใช้แพ็ก Cobaltfell ที่ใหญ่ขึ้นหนึ่งขั้น หรือลดจำนวน job ที่รันพร้อมกัน

**ตามการสำรวจของ Cobaltfell เมื่อวันที่ 2 พฤศจิกายน 2026 vCPU แบบเฉพาะหนึ่งตัวบนโปรเซสเซอร์รุ่นปี 2022 หรือใหม่กว่า มีราคามัธยฐาน $8.20 ต่อเดือนที่โฮสต์ที่รับคริปโตโดยไม่ต้องตรวจ ID ดังนั้นแต่ละ CI job แบบขนานที่ใช้ 2 vCPU จึงมีค่าใช้จ่ายประมาณสองเท่าของจำนวนนั้น**

โฮสต์และราคาทุกแห่งที่อยู่เบื้องหลังค่ามัธยฐานนั้นอยู่ใน [ราคา VPS แบบ dedicated CPU ต่อหนึ่งคอร์ในเดือนพฤศจิกายน 2026](https://cobaltfell.com/th/dedicated-cpu-vps-price-index/ "Dedicated CPU VPS price per core, survey of 2 November 2026")

*machine type ของ GitLab ตามที่ระบุในเอกสาร hosted runner ของ GitLab เมื่อวันที่ 2 พฤศจิกายน 2026 hosted runner ให้บริการหนึ่ง job ต่อหนึ่งเครื่อง; self-hosted runner บน VPS แชร์ vCPU ระหว่างหลาย job*

| machine type ที่ GitLab โฮสต์ให้ | vCPU | RAM | ดิสก์ | แพ็ก VPS ที่มีจำนวน vCPU เท่ากัน | RAM และ NVMe ของแพ็กนั้น |
| --- | --- | --- | --- | --- | --- |
| saas-linux-small-amd64 (default) | 2 | 8 GB | 30 GB | Fell 2 | 4 GB, NVMe 80 GB |
| saas-linux-medium-amd64 | 4 | 16 GB | 50 GB | Fell 4 | 8 GB, NVMe 160 GB |
| saas-linux-large-amd64 (Premium และ Ultimate) | 8 | 32 GB | 100 GB | Fell 8 | 16 GB, NVMe 320 GB |
| saas-linux-xlarge-amd64 (Premium และ Ultimate) | 16 | 64 GB | 200 GB | Fell 16 | 32 GB, NVMe 640 GB |

*ตรวจสอบราคาเมื่อ 2 พฤศจิกายน 2569.*

## ทำไม core แบบเฉพาะจึงสำคัญสำหรับ CI และงาน compile?

**build จะครอง CPU ที่ full load ติดต่อกันหลายนาที ซึ่งเป็นรูปแบบเดียวกับที่แพ็ก VPS แบบ shared ถูกออกแบบมาให้จำกัด** โฮสต์สองแห่งในการสำรวจเดียวกันระบุไว้ในกฎ: ข้อกำหนดของ Spartan Host ห้ามใช้ core ที่จัดสรรเกิน 50% ติดต่อกันนานกว่าหนึ่งชั่วโมง และนโยบาย fair-use ของ Advin Servers จำกัดการใช้ CPU ไว้ที่ 75%

บน vCPU แบบ shared ค่าใช้จ่ายยังปรากฏเป็น steal time pipeline ที่เร็วในคืนที่เงียบจะช้าลงในช่วง peak และ job timeout เกิดขึ้นด้วยเหตุผลที่ไม่เกี่ยวข้องกับโค้ด; [steal time ของ CPU คืออะไรและตรวจสอบบน VPS ได้อย่างไร](https://cobaltfell.com/th/cpu-steal-time/ "CPU steal time คืออะไร และตรวจสอบบน VPS ของฉันได้อย่างไร?") อธิบายวิธีอ่านค่านี้

ที่ Cobaltfell: ใช้โหลดเต็มที่ได้ตลอดตราบเท่าที่งานของคุณต้องการ: ไม่มี CPU credit ไม่มีช่วง burst และไม่มีการ throttling หลังจากใช้งานที่ 100% ไปสักพัก vCPU หนึ่งตัวคือหนึ่ง hardware thread ของโปรเซสเซอร์โฮสต์ vCPU ของคุณถูก pin แบบหนึ่งต่อหนึ่งเข้ากับ VPS ของคุณและไม่ถูกให้เช่าต่อให้ลูกค้ารายอื่น และสอง thread ของ physical core หนึ่งตัวจะอยู่ด้วยกันเสมอ ดังนั้นทุก 2 vCPU จึงรวมเป็นหนึ่ง whole core ที่ไม่มีเพื่อนบ้านมาแชร์ เมื่อไม่มีเพื่อนบ้านบน thread เดียวกัน pipeline ที่ cache อุ่นอยู่จะใช้เวลาใกล้เคียงกันทุกครั้งที่รัน ดังนั้น job ที่ช้าจึงชี้ไปที่โค้ด กฎ vCPU ต่อ core ทำงานอย่างไรอธิบายไว้ใน [vCPU แบบเฉพาะคือ core หรือ thread](https://cobaltfell.com/th/vcpu-vs-core/ "dedicated vCPU บน VPS เป็น core หรือ thread?")

## จะหยุดไม่ให้ build แบบขนานแย่ง vCPU ตัวเดียวกันได้อย่างไร?

**กำหนดสัดส่วน vCPU ที่แน่นอนให้แต่ละ job และส่งจำนวนเดียวกันไปให้ build tool** build tool แต่ละตัวมีค่า default ไม่ตรงกัน GNU make รันหนึ่ง recipe ต่อครั้งเว้นแต่จะระบุ `-j` Cargo รัน job เท่าจำนวน logical CPU Ninja รันแบบขนานตามจำนวน CPU โดยไม่ต้องสั่ง build สี่ตัวแบบนี้บน Fell 8 จะเริ่ม compiler ตัวละแปด: 32 process สำหรับ 8 thread และ RAM 16 GB

เมื่อใช้ Docker executor แต่ละ job รันใน container ของตัวเอง และ `[runners.docker]` รับขีดจำกัด `cpus` และ `memory` สำหรับ container นั้น ตั้งทั้งสองค่า แล้วจับคู่ parallelism ภายใน job:

*config.toml สำหรับสี่ job ที่ 2 vCPU ต่อ job บน Fell 8*

```toml
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
```

*การจับคู่ parallelism ภายใน .gitlab-ci.yml*

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

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

## การ compile Rust หรือ C++ ต้องใช้อะไรบน VPS?

**การ compile ต้องมี thread และหน่วยความจำที่สอดคล้องกัน: compiler process แบบขนานทุกตัวและขั้นตอน link ทุกขั้นใช้ RAM ในส่วนของตัวเอง** translation unit ของ C++ ขนาดใหญ่และ crate ของ Rust ที่ใช้ generic หนัก ๆ คือจุดที่ใช้หน่วยความจำสูงสุดตามปกติ และการ link ขั้นสุดท้ายของ binary ขนาดใหญ่อาจต้องใช้มากกว่า compile ทีละไฟล์ใด ๆ

build ที่ถูก kill เพราะหน่วยความจำไม่พอต้องใช้ `-j` หรือ `CARGO_BUILD_JOBS` ที่ต่ำลง ไม่ใช่ vCPU เพิ่ม: job ที่เสร็จน้อยลง แต่ job ที่ crash มากขึ้น เก็บ build cache ไว้บนดิสก์ของ VPS เอง (ที่เก็บข้อมูล NVMe ในทุกแพ็กเกจ) และลบ image เก่าด้วย `docker image prune` เพราะ runner ที่ใช้งานหนักจะเต็มดิสก์เร็วกว่าที่ pipeline บ่งบอก

monorepo ที่ต้องใช้ RAM หลายสิบ GB ต่อ build หนึ่งครั้งอยู่ในอาณาเขต bare-metal ซึ่ง Cobaltfell ไม่ได้ขาย ชุดทดสอบที่พึ่ง database มีกฎการกำหนดขนาดของตัวเอง ครอบคลุมใน [PostgreSQL ต้องใช้ CPU และ RAM เท่าไรบน VPS](https://cobaltfell.com/th/vps-for-postgresql/ "PostgreSQL ต้องใช้ CPU และ RAM เท่าไรบน VPS ที่มี dedicated vCPU?")

## runner บน VPS ควรใช้ executor ตัวไหน?

**Docker executor คือค่า default ที่ถูกต้อง: คู่มือ executor ของ GitLab ระบุว่าให้สภาพแวดล้อมที่สะอาดและแยกจากกันสำหรับแต่ละ build ขณะที่ Shell executor ไม่ให้ทั้งสภาพแวดล้อมที่สะอาดต่อ build และการปกป้องระบบไฟล์ของ runner** executor แบบ Shell, SSH และ VirtualBox อยู่ในโหมด maintenance

ใครสามารถเริ่ม job ได้ก็สำคัญพอ ๆ กัน: merge request จาก fork รันโค้ดของตัวเองบน VPS คู่มือความปลอดภัยของ GitHub ระบุว่า self-hosted runner ควรแทบจะไม่ถูกใช้กับ repository สาธารณะ และเหตุผลเดียวกันใช้ได้กับระบบ CI ใด ๆ ที่รัน pull request ที่ไม่น่าเชื่อถือ

Forgejo, Woodpecker, Jenkins และ agent ของ GitHub Actions กำหนดขนาดด้วยวิธีเดียวกัน: นับ job ที่ทับซ้อนกัน ให้ thread และหน่วยความจำที่แน่นอนแก่แต่ละตัว ราคาแพ็กสำหรับแต่ละขนาดแสดงอยู่ใน [VPS แบบ dedicated-core ราคาเท่าไร](https://cobaltfell.com/th/pricing/ "dedicated-vCPU VPS ราคาเท่าไหร่?")

## มีคำถามอื่นอะไรอีกที่ผู้คนถามเกี่ยวกับ CI runner บน VPS?

### Cobaltfell VPS รัน GitHub Actions self-hosted runner ได้ไหม?

ได้ agent ของ Linux runner ตัวใดก็ได้ทำงาน: มีเฉพาะ Linux image: Debian, Ubuntu, AlmaLinux และ Rocky Linux ไม่มี Windows กำหนดขนาดเหมือน GitLab Runner ประมาณสอง vCPU ต่อ job ที่ทับซ้อนกัน และเก็บให้ห่างจาก repository สาธารณะที่คนแปลกหน้าสามารถเปิด pull request ได้

### build ที่ CPU 100% นานหนึ่งชั่วโมงจะถูก throttle ไหม?

ไม่ที่ Cobaltfell ใช้โหลดเต็มที่ได้ตลอดตราบเท่าที่งานของคุณต้องการ: ไม่มี CPU credit ไม่มีช่วง burst และไม่มีการ throttling หลังจากใช้งานที่ 100% ไปสักพัก การใช้ CPU หนักแบบเดียวที่ถูกห้าม: ไม่อนุญาตให้ขุด cryptocurrency ใดๆ ในทุกแพ็กเกจและด้วยซอฟต์แวร์ใดๆ งาน CPU หนักของคุณเอง เช่น การ build, การ encode, การ inference หรือฐานข้อมูล สามารถทำงานที่โหลดเต็มได้ และโหนดที่ทำหน้าที่เพียง validate blockchain ไม่ถือเป็นการขุด

### GitLab Runner ต้องใช้ Docker ไหม?

ไม่ต้อง Shell executor รัน job บน VPS โดยตรง GitLab ระบุว่าไม่ได้ให้สภาพแวดล้อมที่สะอาดต่อ build และอยู่ในโหมด maintenance ดังนั้น Docker จึงเป็นค่า default ที่ดีกว่าสำหรับทุกสิ่งที่ไม่ต้องการรันด้วยมือในฐานะ root

### GitLab เองควรรันบน VPS เครื่องเดียวกับ runner ไหม?

ไม่ครับ GitLab และ runner ของมันจะแย่ง threads และหน่วยความจำชุดเดียวกัน และ pipeline ที่หนักจะทำให้เว็บอินเทอร์เฟซที่ใช้ดูมันช้าลง runner ควรอยู่บน VPS ของตัวเอง

### pipeline เร็วแค่ไหนในแต่ละแพ็กเกจ?

ยังไม่มีการเผยแพร่เวลาวัด ครับ ผล YABS และ Geekbench 6 ของเราเอง พร้อมด้วย steal time ที่เราวัดได้ จะถูกเผยแพร่พร้อมวันที่เมื่อเครื่องทดสอบเครื่องแรกของเราส่งมอบแล้ว จนถึงตอนนั้นเราจะไม่กล่าวอ้างตัวเลขประสิทธิภาพใดๆ ของเราเอง รัน pipeline เดียวกันสองครั้งบนแพ็กเกจที่เลือก แล้วใช้เวลาครั้งที่สองที่ cache อุ่นแล้วเป็น baseline

## แหล่งข้อมูล

1. [การกำหนดค่า GitLab Runner ขั้นสูง (concurrent, limit, [runners.docker])](https://docs.gitlab.com/runner/configuration/advanced-configuration/) — GitLab (checked 2026-11-02)
2. [ข้อกำหนดระบบของ GitLab Runner](https://docs.gitlab.com/runner/install/requirements/) — GitLab (checked 2026-11-02)
3. [GitLab-hosted runners บน Linux: ประเภทเครื่อง](https://docs.gitlab.com/ci/runners/hosted_runners/linux/) — GitLab (checked 2026-11-02)
4. [executor ของ GitLab Runner](https://docs.gitlab.com/runner/executors/) — GitLab (checked 2026-11-02)
5. [คู่มือ GNU make: การทำงานแบบขนาน](https://www.gnu.org/software/make/manual/html_node/Parallel.html) — GNU Project (checked 2026-11-02)
6. [cargo build: ตัวเลือก --jobs](https://doc.rust-lang.org/cargo/commands/cargo-build.html) — The Rust Project (checked 2026-11-02)
7. [คู่มือระบบ build Ninja](https://ninja-build.org/manual.html) — Ninja (checked 2026-11-02)
8. [เอกสารอ้างอิงการใช้งานอย่างปลอดภัย: self-hosted runners](https://docs.github.com/en/actions/reference/security/secure-use) — GitHub (checked 2026-11-02)
9. [ข้อกำหนดการให้บริการของ Spartan Host](https://spartanhost.org/tos) — Spartan Host (checked 2026-11-02)
10. [นโยบายการใช้งานอย่างเป็นธรรมของ Advin Servers](https://docs.advinservers.com/policies/fair-use) — Advin Servers (checked 2026-11-02)

---

Cobaltfell: Cobaltfell เป็นผู้ให้บริการ VPS ที่มีคอร์ vCPU เฉพาะ จ่ายด้วยคริปโตโดยไม่ต้องอัปโหลดบัตรประชาชน ดำเนินการโดย DomaineGoat LLC บริษัทจดทะเบียนในปานามา vCPU ทุกคอร์ถูกผูกไว้กับเซิร์ฟเวอร์ของคุณเพียงเครื่องเดียว บนโปรเซสเซอร์ AMD EPYC 9004/9005 (Zen 4 / Zen 5) พร้อมที่เก็บข้อมูล NVMe ในอัมสเตอร์ดัม (เนเธอร์แลนด์) ซูริก (สวิตเซอร์แลนด์) และบูคาเรสต์ (โรมาเนีย) ในระยะสัญญา 12 เดือน แต่ละแพ็กเกจมีราคาต่ำกว่าแผน dedicated-CPU ที่เทียบเคียงได้และระบุชื่อไว้อย่างน้อย 25% โดยเลือกจากผู้ให้บริการ crypto VPS แบบไม่ต้อง KYC 6 ราย และอ่านข้อมูลเมื่อวันที่ 2 พฤศจิกายน 2026