Docker หรือ DigitalOcean: sandbox สำหรับ AI agent คิดเงินคนละจังหวะ

ถ้าทีมเริ่มงานกับ coding agent บนเครื่องนักพัฒนา แล้วต้องส่งงานที่ใช้เวลานานขึ้นไปทำต่อบนคลาวด์ Docker Cloud Sandboxes เหมาะกว่า เพราะ รายละเอียด Cloud Sandboxes ของ Docker ระบุว่าย้ายระบบไฟล์ของ sandbox ไปกลับระหว่างสองสภาพแวดล้อมได้ โดยขนาด Small คิด 0.14 ดอลลาร์ต่อชั่วโมงที่เปิดรัน ส่วนทีมที่ต้องหยุดงาน รักษาสถานะ แล้วแยก session เพื่อทดลองหลายทาง จะได้วงจรงานที่ตรงกว่าจาก DigitalOcean Harness Runtime ทั้งสองทางเลือกจึงเริ่มคิดต้นทุนในจังหวะต่างกันตามสิ่งที่ทีมปล่อยให้ทำงานหรือเก็บค้างไว้

สำหรับขนาดที่เทียบกันได้ Docker Small ให้ 2 vCPU กับหน่วยความจำ 4 GiB ส่วน ราคาของ DigitalOcean Harness Runtime แยก CPU 0.044 ดอลลาร์ต่อ vCPU-hour หน่วยความจำ 0.0095 ดอลลาร์ต่อ GB-hour และพื้นที่ session หรือ checkpoint อย่างละ 0.05 ดอลลาร์ต่อ GiB-month ค่า CPU ที่เรียกเก็บขณะนี้อิง 25% ของ vCPU ที่จัดสรร แม้ตารางราคาจะอธิบายการคิดตาม CPU ที่ใช้จริงซึ่งยังไม่เริ่มใช้ ดังนั้นการเทียบตัวเลขต่อชั่วโมงโดยหยิบอัตราเต็มกำลังจากตารางมาอ่านเป็นบิลปัจจุบันจะทำให้ประมาณการผิด

เงินเริ่มเดินเมื่อ sandbox อยู่ในสถานะใด

Docker คิด compute ตามวินาทีที่ sandbox บนคลาวด์รัน โดยขนาดเครื่องที่เลือกกำหนดอัตราต่อเวลา หาก agent รอคำตอบจากบริการภายนอก แต่ sandbox ยังเปิดอยู่ เวลาเรียกเก็บยังเดินต่อในอัตราเดิม เมื่อหยุดพัก ค่า compute เป็นศูนย์ โดย volume การส่งข้อมูลออก และการโฮสต์ public image กับ Kit ไม่มีค่าใช้จ่ายเพิ่มภายใต้ราคา Cloud Sandboxes ที่เผยแพร่ ข้อดีคือคาดงบ sandbox จากขนาดเครื่องและเวลารันได้ค่อนข้างตรง แต่เวลาที่ agent ว่างภายในเครื่องที่ยังเปิดอยู่ก็ยังมีราคา

DigitalOcean แยกมิเตอร์ออกเป็น CPU หน่วยความจำ และสิ่งที่เก็บไว้ หน่วยความจำอิงค่าสูงสุดที่ session ใช้ ไม่ใช่เพียงขนาดเครื่องที่เลือก ส่วน CPU ตามกติกาชั่วคราวผูกกับสัดส่วนเครื่องที่จัดสรร จึงยังไม่ลดตามช่วงที่กระบวนการรอเฉย ๆ การ pause หยุดค่า compute แต่ volume กับ checkpoint ที่ยังเก็บไว้ยังมีค่าใช้จ่ายตามพื้นที่และเวลา นอกจากนี้ egress สาธารณะคิด 0.01 ดอลลาร์ต่อ GiB; การใช้โมเดลและเครื่องมือบางอย่างผ่าน Action Gateway อาจเพิ่มรายการในบิลอีกต่างหาก

ความหมายของคำว่า “รอ” จึงต้องแยกให้ชัด หาก agent กำลังอยู่ใน run เดียวและรอการตอบกลับของเครื่องมือ DigitalOcean ไม่หยุด session กลาง run จึงยังมีค่า compute ตามกติกาปัจจุบัน แต่ถ้า run จบแล้ว session ว่างจนระบบ pause ค่า compute จะหยุดภายหลังช่วงรอที่กำหนด การหยุดเครื่องโดยตั้งใจทันทีหลังจบ run จะลดเวลารันได้เร็วกว่าการรอให้ระบบทำเอง ทั้งสองแบบยังต้องจ่ายค่าโมเดลหรือบริการภายนอกตามผู้ให้บริการที่ใช้จริง

อีกส่วนที่มักหลุดจากตัวเลขต่อชั่วโมงคือบัญชี DigitalOcean ต้องมีเงินจ่ายล่วงหน้า และไม่มีเพดานใช้จ่ายแยกสำหรับแต่ละ session หรือเฉพาะผลิตภัณฑ์นี้ หากยอดเงินคงเหลือหมด session อาจถูกพัก แต่ checkpoint ที่เก็บไว้ยังสะสมค่า storage ต่อ ความเสี่ยงของงานที่รันหลายกิ่งจึงอยู่ที่ยอดรวมของทีมด้วย ไม่ใช่ราคาเครื่องหนึ่งตัวเพียงลำพัง ส่วน Docker แยกค่า inference ไปตามผู้ให้บริการโมเดลที่ทีมใช้ ทำให้ต้นทุนของ agent ทั้งงานอาจสูงกว่าค่า sandbox เมื่อเรียกโมเดลบ่อย

สามสถานการณ์: งานหนัก งานรอ และงานค้างคืน

ลองสมมติให้ใช้ Docker Small เทียบ DigitalOcean Medium ซึ่งต่างมี 2 vCPU และหน่วยความจำประมาณ 4 หน่วย โดยสมมติว่า DigitalOcean ใช้หน่วยความจำสูงสุด 4 GB ตลอดช่วงที่รัน ตัวเลขต่อไปนี้เป็นค่า sandbox จากราคาที่เผยแพร่ ไม่รวมภาษี ค่าโมเดล คำสั่งเครื่องมือที่คิดแยก หรือข้อมูลส่งออก เวลาสำหรับพื้นที่เก็บใช้เดือนสมมติ 30 วัน ผลลัพธ์จึงเป็นวิธีแยกส่วนบิลของงานตัวอย่าง ไม่ใช่ใบเสนอราคาสำหรับบัญชีหนึ่ง

ชื่อขนาดเครื่องของสองผู้ขายไม่ใช่มาตรวัดความเร็วเดียวกัน และหน่วยความจำในตารางก็ใช้ GiB กับ GB ต่างกัน การคำนวณนี้จงใจตรึงจำนวน vCPU และสมมติการใช้หน่วยความจำเพื่อเทียบโครงสร้างบิล ไม่ได้อ้างว่า agent จะทำงานเสร็จในเวลาเท่ากันบนสองบริการ หากงานจริงใช้หน่วยความจำน้อยกว่า 4 GB ยอด DigitalOcean จะต่ำกว่าตัวอย่าง ส่วน Docker ยังคิดตามขนาดเครื่องที่เลือก ไม่ลดลงตามการใช้หน่วยความจำจริง

• ทำงานเต็ม CPU หนึ่งชั่วโมง: Docker Small คิด 0.14 ดอลลาร์ DigitalOcean Medium ตามเงื่อนไขปัจจุบันคิด CPU 2 × 25% × 0.044 = 0.022 ดอลลาร์ บวกหน่วยความจำ 4 × 0.0095 = 0.038 ดอลลาร์ รวม 0.060 ดอลลาร์ก่อนค่าเก็บข้อมูล หากภายหลังเริ่มคิด CPU ตามการใช้จริง งานที่ใช้ CPU เต็มทั้งชั่วโมงจะเป็น 2 × 0.044 + 0.038 = 0.126 ดอลลาร์ ซึ่งเป็นตัวเลขเต็มกำลังในตาราง ไม่ใช่ยอดที่ใช้ตั้งงบจากกติกาช่วงนี้
• ทำงานสิบนาทีแล้วรอเครื่องมือภายนอกห้าสิบนาทีใน run เดียว: เมื่อ sandbox เปิดรันครบชั่วโมง Docker ยังคงเป็น 0.14 ดอลลาร์ และ DigitalOcean ยังเป็น 0.060 ดอลลาร์ตามกติกา 25% ก่อนค่าอื่น สมมติในอนาคตว่าระบบคิด CPU ตามการใช้จริง และ CPU ทั้งสองแกนทำงานเต็มเฉพาะสิบนาที ค่า CPU จะประมาณ 0.0147 ดอลลาร์ บวกหน่วยความจำ 0.038 ดอลลาร์ รวมประมาณ 0.0527 ดอลลาร์ แต่ตัวเลขหลังเป็นสถานการณ์จำลองของกติกาที่ยังไม่เริ่มใช้
• พักข้ามคืนสิบสองชั่วโมง: สมมติว่าจบ run แล้วสั่ง pause ทันที และ DigitalOcean เก็บ volume ขนาด 1 GiB พร้อม checkpoint อีก 1 GiB ตลอดช่วงพัก ทั้งสองบริการไม่มีค่า compute ในช่วงนั้น ส่วนพื้นที่สองรายการของ DigitalOcean รวมประมาณ 0.0017 ดอลลาร์จากอัตรา 0.05 ดอลลาร์ต่อ GiB-month ต่อรายการ หากไม่ได้สร้าง checkpoint ก็ไม่ควรนับค่า checkpoint โดยอัตโนมัติ ข้อมูลที่เก็บจริงและจำนวนคืนที่ค้างไว้จะกำหนดค่าใช้จ่ายรวม

กรณีรอเครื่องมือยังมีอีกแบบที่ให้ผลต่างกัน: ถ้า run จบหลังสิบนาที แล้วปล่อย DigitalOcean session ว่างต่อ ระบบจะ pause อัตโนมัติหลังว่าง 15 นาที สมมติไม่มีงานอื่นปลุก session และใช้หน่วยความจำสูงสุดเท่าเดิม ค่า compute สำหรับเวลารันรวม 25 นาทีจะประมาณ 0.025 ดอลลาร์ ก่อนค่าพื้นที่เก็บ การแยก “รออยู่ใน run” ออกจาก “ว่างระหว่าง run” จึงสำคัญกว่าการดูเพียงเวลาเริ่มและจบงาน ขณะที่การพักข้ามคืนให้ดูพื้นที่ checkpoint และ volume แยกกัน เพราะการ pause ไม่ได้แปลว่ามี checkpoint เพิ่มขึ้นเสมอไป

ถ้าปล่อย session สมมติเดิมให้รันต่อเนื่องสิบสองชั่วโมงโดยไม่มีการพัก Docker จะคิดค่า sandbox 1.68 ดอลลาร์ ส่วน DigitalOcean ตามสัดส่วน CPU ช่วงนี้และสมมติฐานหน่วยความจำเดิมจะคิดค่า compute 0.72 ดอลลาร์ก่อนรายการอื่น การพักทันทีหลังงานจบจึงมีผลกับทั้งคู่ แต่การเก็บสถานะข้ามคืนจะทำให้ฝั่ง DigitalOcean ยังมีบรรทัดค่า storage อยู่ ตัวเลขเปรียบเทียบนี้ไม่ได้รวมว่าระหว่างสิบสองชั่วโมง agent อาจทำงานได้มากต่างกันตามประสิทธิภาพจริงของสภาพแวดล้อม

การย้ายจากเครื่องกับการแยก session เป็นคนละงาน

Docker เหมาะเมื่อชุดไฟล์ที่ agent แก้บนเครื่องต้องไปต่อบนเครื่องคลาวด์ โดยคำสั่งย้ายจะจับภาพระบบไฟล์ใน sandbox แล้วสร้าง sandbox ปลายทางจากภาพนั้น กลไกนี้ส่งต่อไฟล์ที่อยู่ภายใน sandbox แต่ไม่ได้ย้ายกระบวนการที่กำลังรันหรือหน่วยความจำแบบสด การย้ายจึงควรเกิดตรงจุดที่งานหยุดได้อย่างปลอดภัย โดยเฉพาะงานทดสอบที่เขียนไฟล์ระหว่างทางหรือ agent ที่กำลังเรียก API ภายนอก ทั้งต้นทางและปลายทางเป็นสภาพแวดล้อมแยกกันหลังย้าย ไฟล์ที่แก้ต่อในฝั่งหนึ่งไม่ได้ประสานไปอีกฝั่งเอง

ขอบเขตของไฟล์ก็มีผลต่อคำว่า “ย้าย” โฟลเดอร์งานบนเครื่องที่ mount เข้า sandbox แต่อยู่นอกระบบไฟล์ภายใน ไม่ได้ติดไปกับภาพที่ส่งขึ้นคลาวด์ และ secret ที่จัดการแยกจาก agent ไม่ได้ย้ายตามไฟล์ เครือข่ายปลายทางใช้กฎของคลาวด์ ไม่ได้สืบทอดกฎ local โดยตรง ในทางกลับกัน credential ที่ agent เขียนไว้เป็นไฟล์ภายใน sandbox อาจติดไปกับภาพระบบไฟล์ ความต่างนี้ทำให้ทีมต้องจัดที่อยู่ของโค้ดและสิทธิ์ปลายทางให้ตรงก่อนส่งงานยาวออกจากเครื่อง

ฝั่ง DigitalOcean เอกสารวงจร session อธิบายว่า pause เก็บกระบวนการ หน่วยความจำ และ workspace ไว้เพื่อ resume และ session ที่ว่างจะ pause อัตโนมัติหลัง 15 นาที แต่จะไม่หยุดกลาง run อีกทั้ง checkpoint และ fork ต้องทำที่ขอบเขตระหว่าง run สิ่งนี้เหมาะกับงานที่ต้องลองแก้ปัญหาหลายทางจากฐานเดียวกัน: fork สร้าง session ลูกที่เป็นอิสระ ส่วน session ต้นฉบับยังอยู่ ทีมจึงทดลองทางเลือกโดยไม่เขียนทับสถานะต้นทาง แต่แต่ละกิ่งกินโควตา session และอาจสร้างค่า compute กับพื้นที่ของตัวเอง

ในงาน coding agent ที่รันยาว ความต่างมีผลต่อวิธีแบ่งงาน หากต้องปิดแล็ปท็อประหว่างที่ agent ยังทำต่อ การส่ง snapshot ของ Docker ไปคลาวด์แก้ปัญหาการพึ่งเครื่องส่วนตัว หากต้องหยุดกลับมาแก้แนวเดิมหรือแตกทางเลือกจากสถานะที่บันทึกไว้ DigitalOcean ให้จุดควบคุมละเอียดกว่า อย่างไรก็ตาม run ยาวต่อเนื่องที่ไม่สิ้นสุดก่อนเช้าไม่อาจอาศัย auto-pause ของ DigitalOcean ลดค่าเครื่องระหว่างทางได้ วงจรของ run จึงเป็นส่วนหนึ่งของการออกแบบต้นทุน ไม่ใช่เพียงรายละเอียดของ API

Docker กำหนดอายุการรันของ Cloud Sandbox โดยค่าเริ่มต้นเป็นหนึ่งชั่วโมงและขยายได้สูงสุดยี่สิบสี่ชั่วโมงต่อ session งานที่ยาวเกินช่วงที่ตั้งไว้จึงต้องมีแผนต่ออายุหรือเก็บผลลัพธ์ก่อนถึงกำหนด โดยเฉพาะงานที่ต้องปล่อยข้ามคืน ความต่อเนื่องของไฟล์หลังการย้ายไม่ได้รับประกันว่าการเชื่อมต่อเครือข่ายที่เปิดค้างหรือกระบวนการในหน่วยความจำจะกลับมาทำต่อ จังหวะย้ายจึงควรเป็นขอบเขตงานที่บันทึกสถานะลงไฟล์เรียบร้อยแล้ว ส่วน DigitalOcean ให้พักและกลับมาที่สถานะของ session เดิมเมื่อ run ถึงจุดที่พักได้

Secrets และขอบเขตเครือข่ายมีผลต่อการย้ายงาน

ทั้งสองบริการใช้ sandbox แบบ microVM สำหรับแยกการรันของ agent แต่การเก็บ credential ต้องดูระดับที่ agent เข้าถึงจริง Cloud Sandboxes เก็บ secret นอกตัว agent และ proxy เติมค่าจริงเมื่อมีคำขอ พร้อมนโยบายกำหนดปลายทางเครือข่ายให้ sandbox สิ่งนี้ลดโอกาสที่ agent จะเห็น token ตรง ๆ ระหว่างการใช้งานตามช่องทางที่ระบบจัดการไว้ ทว่าความปลอดภัยของงานที่ย้ายขึ้นคลาวด์ยังขึ้นกับไฟล์ credential ที่อยู่ในระบบไฟล์และนโยบายปลายทางที่ตั้งไว้ใหม่

สำหรับ DigitalOcean คู่มือ secrets ของ Harness Runtime แยก env ที่แสดงค่าในข้อมูลตั้งค่า ออกจาก secret ปกติที่เก็บในระบบจัดการและไม่แสดงใน API response แต่ secret ปกติยังถูกส่งเข้า sandbox เป็น environment variable จึงอ่านได้โดย agent หรือกระบวนการที่ agent เริ่ม ส่วน scoped secret ผูก credential กับปลายทาง HTTPS ที่กำหนดและส่งเพียง handle เข้า sandbox เพื่อลดการเปิดเผยค่าจริง ความสามารถรับรอง handle ที่ปลายทางยังทยอยเปิดใช้ในโครงสร้างพื้นฐานบางส่วน จึงต้องทดสอบการยืนยันตัวตนก่อนพึ่งวิธีนี้กับงานจริง

เมื่อ agent ต้องเข้าถึง GitHub หรือ API ของโมเดล ความต่างระหว่าง “ไม่ปรากฏในหน้าตั้งค่า” กับ “อ่านไม่ได้ใน sandbox” เป็นเรื่องสิทธิ์ที่ต้องตัดสินใจตั้งแต่ต้น การให้ token สิทธิ์กว้างแก่ agent แม้จะเก็บใน secret store ก็ยังเปิดทางให้คำสั่งภายในใช้ token นั้นได้ หาก workflow ต้อง fork หลายกิ่ง ควรคิดด้วยว่ากิ่งใหม่ได้รับสภาพแวดล้อมที่มีสิทธิ์เท่าใด เพราะจำนวน session ที่เพิ่มขึ้นหมายถึงจำนวนจุดที่เรียกบริการภายนอกได้พร้อมกัน

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

โควตาที่เหลือหลังหยุดงาน

ค่า compute เป็นศูนย์ไม่ได้หมายถึงช่องสำหรับงานใหม่กลับมาทันที โควตาเริ่มต้นของ Docker ระบุ 10 sandbox ที่รันพร้อมกันและ 50 sandbox ที่เก็บไว้ การหยุด sandbox คืนช่องรันพร้อมกันตามปกติ แต่ยังนับในจำนวนที่เก็บไว้ และบัญชีจริงอาจมีเพดานต่างจากค่าเริ่มต้น หากทีมวางแผนปล่อย agent หลายชุดพร้อมกัน ต้องดูทั้งจำนวนที่กำลังรันกับงานเก่าที่ค้างในระบบ ไม่ใช่ดูเพียงบิลรายชั่วโมง

ฝั่ง Docker ยังมีข้อแตกต่างระหว่างโควตาการรันกับโควตาการเก็บ: งานที่หยุดช่วยเปิดที่ให้เครื่องใหม่ แต่ไม่ได้ลบผลลัพธ์หรือคืนช่องเก็บอัตโนมัติ การเก็บ sandbox ไว้จำนวนมากเพื่อกลับมาดูโค้ดจึงอาจชนเพดานก่อนค่า compute จะเป็นปัญหา ใน DigitalOcean สถานะ pause ก็ยังใช้ช่อง session เช่นกัน จึงมีต้นทุนเชิงความจุของทีมแม้ช่วงนั้นไม่มีค่าเครื่อง ข้อจำกัดเหล่านี้เป็นเหตุผลที่ต้องนับจำนวนงานพร้อมกันควบคู่กับชั่วโมงที่รันจริง

DigitalOcean นับ session ที่ pause อยู่ในเพดาน active session ของทีมด้วย การลบ session จึงเป็นสิ่งที่คืนช่องให้สร้างงานใหม่ ส่วน fork แต่ละกิ่งเพิ่มจำนวน session ที่ต้องบริหาร แม้กิ่งนั้นจะหยุดเพื่อประหยัด compute ภายหลัง การเลือกบริการจึงผูกกับรูปแบบงานจริง: Docker เด่นเมื่อไฟล์งานต้องข้ามจากเครื่องส่วนตัวไปคลาวด์และกลับมา ส่วน DigitalOcean เด่นเมื่อสถานะเดียวต้องถูกพักหรือแตกเป็นหลายแนวทาง พร้อมต้นทุนพื้นที่และจำนวน session ที่ยังค้างหลังหยุดรัน

อ่านเพิ่มเติม:

• Claude Code หรือ Codex: ไม่มีตัวไหนชนะทุกงาน แม้อัตรารับโค้ดต่างกัน