Coding Agent ควรใช้ VPS สเปกเท่าไหร่ RAM กี่ GB ถึงจะพอ

Coding agent VPS ต้องการ RAM เท่าใด

เริ่มต้นที่ 4 GB ของ RAM และ 2 vCPU สำหรับ coding agent ที่ทำงานตลอดเวลาใน repository หนึ่งแห่ง ให้ขยับไปที่ 8 GB และ 4 vCPU ทันทีที่มี language server หรือการ build ด้วย Docker เข้ามาร่วมใน session ซึ่งเป็นสิ่งที่เกิดขึ้นในวันแรกสำหรับ repository ส่วนใหญ่ ตัว process ของ agent เองนั้นใช้ทรัพยากรน้อย สิ่งที่ทำให้ทรัพยากรในเครื่องเต็มคือ toolchain ที่ agent เรียกใช้งานแทนคุณ

[
  {
    "plan": "Minimum viable",
    "ram_gb": 4,
    "vcpu": 2,
    "disk_gb": 50
  },
  {
    "plan": "Comfortable",
    "ram_gb": 8,
    "vcpu": 4,
    "disk_gb": 100
  },
  {
    "plan": "Team, 4 sessions",
    "ram_gb": 16,
    "vcpu": 8,
    "disk_gb": 200
  }
]

ทุกแถวข้างต้นตั้งสมมติฐานว่าโมเดลทำงานที่อื่น โดยอยู่หลัง API ที่คุณเรียกผ่านเครือข่าย สมมติฐานนี้เป็นตัวตัดสินขนาดของระบบทั้งหมด ดังนั้นควรพิจารณาประเด็นนี้ให้ชัดเจนก่อนเป็นอันดับแรก

คุณกำลังรันตัว agent หรือรันตัว model อยู่?

Coding agent ที่เรียกใช้งาน cloud model ทำหน้าที่เป็น network client ที่มีการเชื่อมต่อกับ shell โดยจะส่งไฟล์และแผนงานไปยัง API จากนั้นรอการตอบกลับเพื่อแก้ไขไฟล์และรันคำสั่งในเครื่อง ในระหว่างที่รอการตอบกลับนั้นแทบจะไม่มีการใช้ CPU เลย หน่วยความจำที่ตัว agent ใช้มีขนาดเพียงไม่กี่ร้อยเมกะไบต์ ดังนั้นเครื่องที่มี CPU ระดับเริ่มต้นจึงเพียงพอต่อการใช้งาน

การรัน model ด้วยตนเองเป็นอีกผลิตภัณฑ์หนึ่งที่ต้องใช้ฮาร์ดแวร์ต่างกัน โดย weights ของ model จะถูกเก็บไว้ในหน่วยความจำตลอดเวลาที่เซิร์ฟเวอร์เปิดอยู่ สำหรับ model ขนาด 7 พันล้านพารามิเตอร์ที่ทำ quantization เหลือ 4 บิต จะต้องใช้หน่วยความจำประมาณ 5 GB สำหรับเก็บ weights เพียงอย่างเดียว ยังไม่รวม key/value cache ที่จะเพิ่มขึ้นตามความยาวของ context หากรันบน CPU เพียงอย่างเดียว vCPU ที่ใช้งานร่วมกับผู้อื่นจะสร้าง tokens ได้เพียงไม่กี่ตัวต่อวินาที ในขณะที่งานของ agent หนึ่งงานอาจต้องสร้าง tokens หลายพันตัว ดังนั้นงานที่ใช้เวลาไม่ถึงหนึ่งนาทีผ่าน API อาจต้องใช้เวลาเกือบหนึ่งชั่วโมงหากรันในเครื่อง หากนั่นคือสิ่งที่คุณต้องการ ให้เลือกขนาดเครื่องโดยเน้นที่ VRAM (หน่วยความจำบน GPU) และอ่าน สิ่งที่ VPS ที่มี GPU มอบให้คุณจริงๆ แทนที่จะอ่านหน้านี้

เนื้อหาทั้งหมดด้านล่างนี้ตั้งอยู่บนสมมติฐานของการใช้งานผ่าน cloud model

สิ่งที่ใช้หน่วยความจำจริง

[
  {
    "label": "Agent CLI process, idle",
    "typical_mb": 250,
    "peak_mb": 600
  },
  {
    "label": "TypeScript language server",
    "typical_mb": 700,
    "peak_mb": 2000
  },
  {
    "label": "rust-analyzer, large workspace",
    "typical_mb": 1200,
    "peak_mb": 4000
  },
  {
    "label": "Headless Chrome, one tab",
    "typical_mb": 350,
    "peak_mb": 900
  },
  {
    "label": "Node test run, 4 workers",
    "typical_mb": 1600,
    "peak_mb": 3000
  },
  {
    "label": "Docker image build",
    "typical_mb": 800,
    "peak_mb": 2500
  }
]

ตัวเลขเหล่านี้เป็นค่าที่เผยแพร่โดยทั่วไปสำหรับโปรเจกต์ขนาดกลาง ให้ถือว่าเป็นแนวทางโดยประมาณ ไม่ใช่การรับประกันสำหรับโค้ดของคุณ

ตารางนี้มี 6 แถว และตัว agent เป็นส่วนที่ใช้ทรัพยากรน้อยที่สุด โดยจะอยู่ที่ประมาณ 250 MB ในขณะที่ไม่ได้ทำงาน เนื่องจากเก็บเพียงบทสนทนาและแคชไฟล์ขนาดเล็กไว้เท่านั้น TypeScript language server จะใช้หน่วยความจำประมาณ 2000 MB ในระหว่างการทำ index เพราะต้องสร้าง type graph สำหรับทุกไฟล์ที่เข้าถึงได้จาก tsconfig.json ของคุณ แล้วเก็บกราฟนั้นไว้ในหน่วยความจำเพื่อตอบสนองคำขอถัดไปได้อย่างรวดเร็ว rust-analyzer ใน workspace ขนาดใหญ่มักจะใช้หน่วยความจำเกิน 4000 MB ด้วยเหตุผลเดียวกัน โดยครอบคลุมทุก crate ใน workspace

Headless Chrome ใช้หน่วยความจำประมาณ 350 MB สำหรับตัวเบราว์เซอร์รวมหนึ่งแท็บ และทุกแท็บที่เปิดเพิ่มจะเป็นอีกหนึ่ง process ของระบบปฏิบัติการ การรัน Node test ด้วย worker สี่ตัวจะเท่ากับมี Node process สี่ตัว ดังนั้นจึงใช้หน่วยความจำสูงสุดใกล้เคียง 3000 MB การ build Docker image จะใช้หน่วยความจำสูงสุดใกล้เคียง 2500 MB เนื่องจากกระบวนการ build จะรัน compiler ของโปรเจกต์คุณเองภายใน container ในขณะที่ daemon ทำการเขียน layer ต่างๆ

sudo apt update && sudo apt install -y time
/usr/bin/time -v -o /tmp/build.rusage npm run build
grep "Maximum resident set size" /tmp/build.rusage

ให้ดูที่คอลัมน์ available ของ free -h ไม่ใช่คอลัมน์ free เนื่องจาก Linux จะนำหน้าหน่วยความจำที่ว่างอยู่ทั้งหมดไปใช้เป็น disk cache ดังนั้นค่า free จึงมีขนาดเล็กในเครื่องที่ทำงานปกติและไม่ได้บ่งบอกอะไร ส่วน available คือปริมาณหน่วยความจำที่ process ใหม่สามารถเรียกใช้ได้จริง

การกำหนดค่าสามรูปแบบที่ใช้งานได้จริง

ระดับเริ่มต้นขั้นต่ำ: 4 GB RAM, 2 vCPU, 50 GB disk. รองรับ agent session หนึ่งรายการ, repository หนึ่งแห่ง, language server หนึ่งตัว และงาน build ที่คุณรอได้ ระดับนี้ใช้งานได้จริง แต่จะเจอกับ out-of-memory killer ทันทีที่มีการรัน test ขนาดใหญ่พร้อมกับ indexing ของ language server ให้เพิ่ม swap และจำกัดจำนวน build workers ของคุณ

ระดับมาตรฐาน: 8 GB RAM, 4 vCPU, 100 GB disk. รองรับ agent หนึ่งรายการ, Docker, headless browser สำหรับการทดสอบ และมีพื้นที่เหลือสำหรับ build ที่พุ่งสูงขึ้นชั่วคราว นี่คือระดับที่นักพัฒนาส่วนใหญ่ควรเลือกใช้ การเพิ่มจำนวน vCPU เป็นสองเท่าจะช่วยลดระยะเวลารอ build ลงได้ประมาณครึ่งหนึ่ง ซึ่งคุณจะรู้สึกถึงความแตกต่างนี้ได้ชัดเจนกว่าเรื่องหน่วยความจำ

ระดับทีม: 16 GB RAM, 8 vCPU, 200 GB disk. รองรับสี่ session พร้อมกัน โดยแต่ละ session มี checkout และ toolchain ของตนเอง ให้เลือกขนาดตามช่วงที่ใช้งานสูงสุด เพราะ agent ที่ไม่ได้ใช้งานสี่ตัวแทบไม่มีต้นทุน แต่การรัน test สี่รายการพร้อมกันจะมีต้นทุนเป็นสี่เท่าของระดับมาตรฐานข้างต้น

ณ เดือนสิงหาคม 2026 ส่วนต่างราคาจากระดับเริ่มต้นไปจนถึงระดับทีมอยู่ที่ประมาณสี่เท่าของราคาต่อเดือนเมื่อชำระแบบรายปีสำหรับ VPS โดยราคาเริ่มต้นอยู่ที่หลักหน่วยดอลลาร์ต่อเดือน และสูงสุดที่หลักสิบดอลลาร์ต่อเดือน โปรดตรวจสอบรายการราคาปัจจุบันก่อนวางแผน เพราะตัวเลขมีการเปลี่ยนแปลงอยู่เสมอ ค่าใช้จ่ายส่วนใหญ่ไม่ได้อยู่ที่ตัวเซิร์ฟเวอร์ สำหรับผู้ที่ใช้งาน agent เป็นประจำทุกวัน ค่าใช้จ่ายจาก model API จะสูงกว่าค่าเซิร์ฟเวอร์อย่างรวดเร็ว ดังนั้นควร จำกัดงบประมาณการใช้งานของ agent ก่อนที่จะลดขนาดเซิร์ฟเวอร์ลง สำหรับขั้นตอนการ build โดยละเอียด คู่มือการรัน coding agent บน VPS จะครอบคลุมถึงการตั้งค่าบัญชีและการรักษา session ให้คงอยู่หลังจากที่คุณตัดการเชื่อมต่อ

เหตุผลที่พื้นที่ดิสก์หมดก่อนหน่วยความจำ RAM

[
  {
    "label": "Ubuntu 24.04 base and toolchain",
    "typical_gb": 6
  },
  {
    "label": "One JS monorepo checkout",
    "typical_gb": 3
  },
  {
    "label": "node_modules across 3 branches",
    "typical_gb": 4
  },
  {
    "label": "Docker images and build cache",
    "typical_gb": 20
  },
  {
    "label": "Agent logs and journal, 90 days",
    "typical_gb": 2
  }
]

เมื่อรวมรายการทั้งหมดเข้าด้วยกัน ดิสก์ขนาด 50 GB จะเกือบเต็มก่อนที่คุณจะเริ่มเขียนโค้ดแม้แต่บรรทัดเดียว รายการที่ใช้พื้นที่มากที่สุดคือ Docker ซึ่งใช้พื้นที่ประมาณ 20 GB เนื่องจาก BuildKit จะเก็บทุก intermediate layer ของทุกการ build ไว้จนกว่าคุณจะสั่งให้หยุด

docker system df
docker builder prune --filter until=168h

docker system df จะแสดงพื้นที่ที่สามารถเรียกคืนได้แยกตามหมวดหมู่ ดังนั้นให้รันคำสั่งนี้ก่อนและหลังการจัดการ ตัวกรอง until=168h จะลบ build cache ที่เก่ากว่าหนึ่งสัปดาห์และเก็บของสัปดาห์นี้ไว้ ซึ่งเป็น cache ที่ยังช่วยประหยัดเวลาให้คุณได้ ส่วน docker image prune -a จะทำงานหนักกว่านั้นโดยลบทุก image ที่ไม่มี container ใดใช้งานอยู่ ดังนั้นควรเตรียมใจว่าการ build ครั้งถัดไปจะต้องดาวน์โหลดใหม่ทั้งหมด

โปรเจกต์ Node มีลักษณะการเกิดปัญหาที่แปลกกว่านั้น npm install จะสร้างไฟล์ขนาดเล็กจำนวนหลายแสนไฟล์ ส่งผลให้ filesystem อาจขาดแคลน inodes ในขณะที่ df -h ยังคงรายงานว่ามีพื้นที่ว่างเหลืออยู่หลาย GB การเขียนไฟล์จึงล้มเหลวด้วยข้อความ No space left on device บนดิสก์ที่ดูเหมือนยังว่างอยู่ครึ่งหนึ่ง

df -h /
df -i /

หาก IUse% แสดงค่า 100 ให้ลบไดเรกทอรี node_modules ของ branch ที่คุณไม่ได้ใช้งานแล้ว หรือเปลี่ยนไปใช้ pnpm ซึ่งจะจัดเก็บ package แต่ละเวอร์ชันไว้เพียงชุดเดียวแล้วใช้ hard-link เชื่อมโยงไปยังทุกโปรเจกต์แทน

ไฟล์ log เป็นสาเหตุที่มักถูกมองข้าม Agent ที่ทำงานตลอดเวลาจะเขียนบันทึก session ลงไป และ systemd journal จะขยายขนาดจนกินพื้นที่ดิสก์ตามค่าเริ่มต้น

sudo journalctl --disk-usage
sudo journalctl --vacuum-size=200M
du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

กำหนดค่า SystemMaxUse=200M ใน /etc/systemd/journald.conf และรัน sudo systemctl restart systemd-journald เพื่อจำกัดขนาดให้ถาวร เนื่องจากการล้างข้อมูลเพียงครั้งเดียวจะช่วยคืนพื้นที่ได้แค่ในวันนี้เท่านั้น

Swap: สิ่งที่ได้รับและสิ่งที่ถูกบดบัง

การเพิ่ม Swap เป็นสิ่งที่คุ้มค่า เพราะช่วยเปลี่ยนสถานการณ์ที่หน่วยความจำเกินเพียงเล็กน้อยให้กลายเป็นการทำงานที่ช้าลง แทนที่จะทำให้โปรเซสหยุดทำงานไปเลย ควรตั้งขนาดไว้ที่ครึ่งหนึ่งของ RAM โดยสูงสุดไม่เกิน 4 GB สำหรับเครื่องที่ใช้คอมไพล์โปรแกรม การเพิ่มขนาดไปมากกว่านี้แทบไม่มีประโยชน์

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
swapon --show

swapon --show ควรแสดงรายการ /swapfile ตามขนาดที่คุณกำหนดไว้ หากไม่มีบรรทัด /etc/fstab ค่า Swap จะหายไปหลังจากรีบูตเครื่องครั้งถัดไป และเครื่องจะกลับไปทำงานในลักษณะเดิมโดยไม่มีการแจ้งเตือน หาก fallocate ตอบกลับด้วย Operation not supported ให้สร้างไฟล์ด้วย sudo dd if=/dev/zero of=/swapfile bs=1M count=4096 แล้วดำเนินการต่อจาก chmod

echo 'vm.swappiness = 10' | sudo tee /etc/sysctl.d/99-swappiness.conf
sudo sysctl --system

การตั้งค่า swappiness ไว้ต่ำจะบอกให้ kernel คืนพื้นที่ disk cache ก่อนที่จะผลักหน่วยความจำของโปรแกรมออกไปยังดิสก์ ซึ่งช่วยให้ language server ยังคงตอบสนองได้ดี

ส่วนสิ่งที่ Swap บดบังไว้คือ เมื่อโปรเซสต้องการหน่วยความจำมากกว่าที่เครื่องมีอยู่จริง kernel จะเสียเวลาไปกับการย้ายหน้าหน่วยความจำ (pages) ระหว่าง RAM กับดิสก์ แทนที่จะประมวลผลงานของคุณ ผลคือไม่มีอะไรพัง แต่ทุกอย่างจะทำงานช้าลงอย่างมาก และค่า load average จะพุ่งสูงขึ้นในขณะที่ CPU ไม่ได้ทำงานจริง

vmstat 1 10

ตัวเลขที่ไม่ใช่ศูนย์อย่างต่อเนื่องในคอลัมน์ si และ so หมายถึงมีการทำ swapping ตลอดเวลา วิธีแก้ไขคือการลด concurrency หรือเพิ่ม RAM ไม่ใช่การเพิ่ม Swap บนเครื่องขนาดเล็ก sudo apt install -y zram-tools จะให้ compressed swap ที่เก็บไว้ใน RAM ซึ่งปรับแต่งได้ใน /etc/default/zramswap วิธีนี้เร็วกว่า swap file มาก โดยเป็นการใช้ RAM เพื่อประหยัด RAM จึงช่วยได้เฉพาะกับ cold pages เท่านั้น ไม่ช่วยงานคอมไพล์ที่ต้องการ working memory จริงๆ

เหตุใด coding agent ของคุณจึงดูเหมือนค้าง

นี่เป็นความล้มเหลวที่วินิจฉัยผิดพลาดบ่อยที่สุดบนเครื่อง agent ขนาดเล็ก คำสั่งไม่ส่งผลลัพธ์ใดๆ กลับมา, agent รอคอย, และเซสชันดูเหมือนค้าง กระบวนการถูกยุติโดย OOM (out-of-memory) killer ของ kernel มันได้รับ SIGKILL จึงไม่สามารถพิมพ์ข้อความผิดพลาด, ล้าง log, หรือแจ้งให้ agent ทราบถึงสิ่งที่เกิดขึ้นได้ agent จึงเห็นเพียงผลลัพธ์ที่ว่างเปล่าและไม่มีข้อความแจ้งการจบการทำงาน

kernel มีการบันทึกเหตุการณ์นี้ไว้:

sudo dmesg -T | grep -iE "out of memory|killed process"
sudo journalctl -k -b | grep -i oom

บรรทัดจริงจะมีลักษณะดังนี้:

[Thu Aug  6 11:02:14 2026] Out of memory: Killed process 4711 (node) total-vm:4210880kB, anon-rss:3820104kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:8236kB oom_score_adj:0

anon-rss คือปริมาณหน่วยความจำที่กระบวนการนั้นถือครองอยู่ขณะที่มันถูกยุติ โปรดสังเกตว่ากระบวนการใดถูกเลือก: kernel ให้คะแนนโดยพิจารณาจากหน่วยความจำที่ใช้งานเป็นหลัก ดังนั้นมันจึงมักจะยุติ language server หรือตัว agent แทนที่จะเป็นตัว build ที่เป็นสาเหตุให้เครื่องเกินขีดจำกัด นี่คือเหตุผลที่อาการที่ปรากฏคือ "agent พัง"

ภายใน Docker เหตุการณ์เดียวกันจะทิ้งร่องรอยที่ชัดเจนกว่า container จะจบการทำงานด้วยรหัส 137 ซึ่งมาจาก 128 บวกกับสัญญาณ 9

docker ps -a
docker inspect "$(docker ps -lq)" | grep -i oomkilled

"OOMKilled": true ยืนยันว่า container ชนขีดจำกัดหน่วยความจำแทนที่จะ crash ด้วยตัวเอง

วิธีแก้ไขคือการกำหนดเพดานหน่วยความจำให้กับคำสั่งที่ใช้ทรัพยากรสูง เพื่อให้ตัว build ถูกยุติแทนที่จะเป็น agent:

systemd-run --user --scope -p MemoryMax=4G -- npm run build

ตอนนี้ตัว build จะถูกยุติที่ 4 GB และ agent จะยังคงทำงานอยู่ ซึ่งเปลี่ยนอาการค้างที่เป็นปริศนาให้กลายเป็นคำสั่งที่ล้มเหลวตามปกติพร้อมรหัสสถานะที่อ่านเข้าใจได้ วิธีนี้จำเป็นต้องใช้ systemd user session ดังนั้นให้รัน loginctl enable-linger $USER บนเครื่องที่คุณเข้าถึงผ่าน SSH เท่านั้น MemoryHigh= จะทำการจำกัดความเร็วของกระบวนการที่ขีดจำกัดแทนที่จะยุติการทำงาน ซึ่งมักจะเป็นการตั้งค่าที่เหมาะสมกว่าสำหรับ build ที่คุณต้องการให้มันทำงานจนเสร็จแม้จะช้าลงก็ตาม

จำกัดหน่วยความจำด้วย Compose memory limits

หากเครื่องมือของ agent ทำงานในคอนเทนเนอร์ ให้กำหนดเพดานหน่วยความจำไว้ในไฟล์ Compose เพื่อให้มีผลทุกครั้งที่รัน

services:
  agent:
    image: node:22-bookworm
    deploy:
      resources:
        limits:
          memory: 2g
          cpus: "1.5"

Docker Compose v2 ใช้ deploy.resources.limits บนไฟล์ docker compose up ปกติได้เลยโดยไม่ต้องพึ่งพา swarm mode ทั้งนี้คีย์ mem_limit: 2g แบบเดิมยังคงใช้งานได้ คู่มือฉบับเต็มเกี่ยวกับ Compose memory limits จะอธิบายเรื่องการจองหน่วยความจำและสิ่งที่เกิดขึ้นเมื่อคอนเทนเนอร์ใช้งานถึงเพดานที่กำหนด หากยังไม่มี Docker บนเซิร์ฟเวอร์ ให้ ติดตั้ง Docker บน VPS ก่อน

มีกับดักหนึ่งที่ทำให้เสียเวลาไปทั้งบ่าย คอนเทนเนอร์ที่ถูกจำกัดไว้ที่ 2 GB ยังคงอ่านค่า /proc/meminfo และจำนวน CPU ของโฮสต์ได้ เนื่องจากทั้งสองค่านี้ไม่ได้ถูกทำ namespaced ตัวรันการทดสอบที่เลือกจำนวน worker ตามจำนวน CPU จะพยายามเริ่ม worker 8 ตัวภายในคอนเทนเนอร์ขนาด 2 GB บนโฮสต์ที่มี 8 vCPU แล้วจะล้มเหลวด้วย exit code 137 ให้กำหนดค่าเหล่านี้ด้วยตนเอง:

npx jest --maxWorkers=2
export NODE_OPTIONS=--max-old-space-size=1536

--max-old-space-size มีหน่วยเป็น MB และใช้จำกัด V8 heap ให้ตั้งค่านี้ไว้ต่ำกว่าขีดจำกัดของคอนเทนเนอร์ เพื่อให้ Node แสดงข้อความแจ้งเตือนที่อ่านเข้าใจได้แทนที่จะหายไปเฉยๆ:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

ข้อความดังกล่าวมีประโยชน์มาก เพราะระบุขีดจำกัดที่ถูกใช้งานจนเต็มและระบุ process ที่เป็นต้นเหตุ ซึ่ง OOM killer ไม่เคยบอกข้อมูลเหล่านี้ให้ทราบ

การรัน agent หลายเซสชันบนเครื่องเดียว

ให้วางแผนตามจำนวนเซสชัน ไม่ใช่ตามจำนวนผู้ใช้งาน การรันสองเซสชันบน repository เดียวกันหมายถึงการมี language server สองตัว, แคชการ build สองชุดในหน่วยความจำ และการรัน test สองครั้งหาก agent ทั้งสองตัวทำงานพร้อมกัน นั่นคือเหตุผลที่แถวของทีมงานต้องเพิ่มขึ้นเป็น 16 GB

กำหนดเพดานการใช้งานสูงสุดให้กับผู้ใช้แต่ละราย เพื่อป้องกันไม่ให้เซสชันที่ทำงานผิดปกติเพียงเซสชันเดียวทำให้ทั้งเครื่องหยุดทำงาน:

id -u alice
sudo mkdir -p /etc/systemd/system/user-1001.slice.d
printf '[Slice]\nMemoryMax=6G\n' | sudo tee /etc/systemd/system/user-1001.slice.d/limit.conf
sudo systemctl daemon-reload
systemctl show user-1001.slice -p MemoryMax

แทนที่ 1001 ด้วย UID ที่ id -u แสดงผลออกมา systemctl show ควรจะแสดงค่า MemoryMax=6442450944 หลังจากที่ผู้ใช้ล็อกอินเข้าสู่ระบบแล้ว เมื่อทุกกระบวนการในเซสชันของผู้ใช้นั้นใช้หน่วยความจำเกิน 6 GB เคอร์เนลจะสั่งยุติกระบวนการภายใน slice ของผู้ใช้นั้น และเซสชันอื่น ๆ ทั้งหมดจะยังคงทำงานต่อไป สำหรับ agent ที่รันเป็น service แทนที่จะรันใน terminal ให้ใส่ MemoryMax= ลงใน unit file ของ service นั้นแทน ซึ่งเป็นรูปแบบที่ควรปฏิบัติตามเมื่อคุณ โฮสต์ agent ด้วยตนเองในรูปแบบ service ที่ทำงานตลอดเวลา

FAQ

RAM ขนาด 2 GB เพียงพอสำหรับ coding agent หรือไม่?

สำหรับตัวกระบวนการของ agent นั้นเพียงพอ แต่สำหรับงานที่ต้องประมวลผลมักจะไม่พอ ตัว agent เองใช้ RAM ประมาณ 250 MB แต่ TypeScript language server เพียงตัวเดียวอาจใช้ RAM สูงถึง 2000 MB ใน repository ขนาดกลาง ซึ่งจะทำให้เครื่องที่มี RAM 2 GB ต้องเริ่มใช้งาน swap ทันที RAM 2 GB เหมาะสำหรับการแก้ไขไฟล์ config และสคริปต์ขนาดเล็กเท่านั้น ควรใช้ RAM ขนาด 4 GB เป็นค่าเริ่มต้นสำหรับงานที่ต้องมีการคอมไพล์หรือรันชุดทดสอบ

จำเป็นต้องใช้ GPU เพื่อรัน coding agent บน VPS หรือไม่?

ไม่จำเป็นหาก agent เรียกใช้งานโมเดลผ่าน API บนคลาวด์ ภาระงานดังกล่าวขึ้นอยู่กับความเร็วเครือข่าย ดังนั้น VPS ที่ใช้ CPU ปกติจึงเป็นตัวเลือกที่เหมาะสมที่สุด ส่วน GPU จะกลายเป็นทรัพยากรที่ไม่ได้ใช้งานแต่มีราคาสูงกว่ามาก คุณจะจำเป็นต้องใช้ GPU ก็ต่อเมื่อรันโมเดลบนเครื่องเดียวกัน ซึ่งในกรณีนั้นประเด็นจะเปลี่ยนจาก RAM ไปเป็น VRAM และขนาดของโมเดลแทน

ควรเพิ่ม swap ให้กับ VPS ของ agent เท่าใด?

ควรเพิ่มประมาณครึ่งหนึ่งของ RAM โดยสูงสุดไม่เกิน 4 GB swap ช่วยป้องกันกรณีที่การใช้งานหน่วยความจำเกินขีดจำกัดชั่วคราว เพราะ kernel สามารถย้ายข้อมูลที่ไม่ได้ใช้งานไปยังดิสก์แทนการสั่ง kill กระบวนการทิ้ง แต่มันไม่ได้เป็นการเพิ่มหน่วยความจำที่ใช้งานได้จริง หาก vmstat 1 แสดงให้เห็นว่ามีการรับส่งข้อมูลอย่างต่อเนื่องในคอลัมน์ si และ so แสดงว่าเครื่องกำลังเกิดสภาวะ thrashing ซึ่งวิธีแก้ไขคือการลดจำนวน worker ที่ทำงานขนานกันหรืออัปเกรดแผนการใช้งานให้สูงขึ้น

ทำไม coding agent ของฉันถึงค้างระหว่างการ build?

การ build มักถูกสั่งยุติโดย OOM killer ของ kernel ซึ่งจะส่งสัญญาณ SIGKILL ทำให้ไม่มีข้อความแจ้งเตือนใดๆ ปรากฏขึ้น และ agent จะรอการตอบกลับจาก pipe ที่ไม่มีวันได้รับข้อมูล ให้รันคำสั่ง sudo dmesg -T | grep -i "killed process" แล้วตรวจสอบชื่อกระบวนการและค่า anon-rss ของมัน วิธีแก้ไขคือจำกัดการ build ด้วย systemd-run --user --scope -p MemoryMax=4G และลดจำนวน worker ลง หรืออัปเกรด RAM ให้สูงขึ้นหนึ่งระดับ