Cloudflare Workers หรือ Vercel Functions: cold start ไม่ใช่ต้นทุนเดียว

สำหรับ API สั้นที่ใช้ CPU น้อย Cloudflare Workers มีโครงสร้างต้นทุนที่น่าสนใจและมีผลกระทบจาก cold start ต่ำในชุดทดสอบ Next.js ที่มีทราฟฟิกเบา ส่วน Vercel Functions เหมาะกับแอป Next.js ที่พึ่งพา Node.js มากและต้องการใช้ฟังก์ชันร่วมกับแพลตฟอร์มเว็บเดียวกัน คำตอบสำหรับผู้ใช้ในไทยยังขึ้นกับตำแหน่งฐานข้อมูล เวลาประมวลผล และข้อจำกัดของโค้ดที่ต้องรัน

หาก endpoint ต้องรอฐานข้อมูลหรือโมเดล AI ทั้งสองแพลตฟอร์มไม่คิดช่วงรอนั้นเป็นเวลา CPU ที่ใช้งานจริง แต่ Vercel Fluid Compute ยังคิดหน่วยความจำที่จัดสรรให้อินสแตนซ์ตลอดช่วงที่มีคำขอกำลังทำงาน คำขอที่รอนานจึงอาจมีต้นทุนต่างจาก API ที่จบเร็วมาก แม้ใช้ CPU ใกล้เคียงกัน การดูเพียงเวลาเริ่มฟังก์ชันหรือราคาต่อ invocation จึงตอบคำถามเรื่องค่าใช้จ่ายได้ไม่ครบ

ผล cold start บอกอะไรได้บ้าง

ในการทดสอบแอป Next.js นาน 48 ชั่วโมง รวม 3,044 คำขอ Cloudflare มีผลกระทบจาก cold start ต่ำที่สุดในชุดทดสอบ ขณะที่ Vercel ส่งหน้าเว็บได้เร็ว แต่คำขอ API พบ cold start บ่อยกว่า ผลนี้เป็นของแอปและการตั้งค่าที่ผู้ทดสอบนำไปวางบนแต่ละแพลตฟอร์ม ไม่ใช่ค่าความเร็วประจำตัวของทุก Worker หรือทุก Function

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

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

ชุดทดสอบยิงคำขอตามลำดับและเว้นช่วงระหว่างรอบเพื่อเปิดโอกาสให้ runtime หยุดทำงาน จึงสะท้อนภาวะทราฟฟิกต่ำมากกว่าชั่วโมงที่มีผู้ใช้พร้อมกันจำนวนมาก จุดยิงคำขออยู่ในสหรัฐฯ และใช้แพ็กเกจฟรีตามค่าเริ่มต้นของบริการ ผลจึงไม่ใช่คำพยากรณ์ความหน่วงสำหรับผู้ใช้ในประเทศไทย หรือข้อสรุปว่า endpoint ที่รอโมเดล AI จะตอบเร็วตามเส้นทาง API ในชุดทดสอบ

ใบราคาคิดค่าคนละช่วงของคำขอ

ตามตารางราคา Workers ของ Cloudflare แพ็กเกจ Paid มีค่าขั้นต่ำ 5 ดอลลาร์สหรัฐต่อเดือน พร้อมโควตา 10 ล้านคำขอและเวลา CPU 30 ล้านมิลลิวินาทีต่อเดือน ส่วนที่เกินคิด 0.30 ดอลลาร์ต่อหนึ่งล้านคำขอ และ 0.02 ดอลลาร์ต่อเวลา CPU หนึ่งล้านมิลลิวินาที การรอ I/O ไม่เพิ่มเวลา CPU ที่นำไปคิดราคา และแพลตฟอร์มไม่คิดค่าระยะเวลาที่คำขอเปิดค้างแยกต่างหาก

โครงสร้างนี้ทำให้คำขอที่ส่งไปยังบริการภายนอกแล้วรอคำตอบมีต้นทุนฝั่ง Workers หลัก ๆ จากการรับคำขอและการประมวลผลก่อนกับหลังรอ แต่คำว่าไม่คิดเวลารอไม่ได้หมายถึงไม่มีค่าใช้จ่ายเลย หากโค้ดต้องแปลงข้อมูลจำนวนมากก่อนส่งคำขอ หรือประมวลผลผลลัพธ์ขนาดใหญ่หลังได้รับคำตอบ เวลา CPU ยังคงเพิ่มตามงานนั้น ค่าฐานข้อมูล โมเดล AI และบริการอื่นก็เป็นรายการแยกจากราคา Workers

Workers Paid ยังตั้งเพดานเวลา CPU ต่อ invocation ได้ เพื่อจำกัดงานที่วนผิดปกติหรือใช้ทรัพยากรเกินคาด เพดานนี้ช่วยคุมความเสี่ยงด้านค่าใช้จ่าย แต่หากตั้งต่ำกว่าที่งานจำเป็นต้องใช้ คำขอจะจบด้วยข้อผิดพลาดแทนที่จะได้ผลลัพธ์ งานที่ต้องคำนวณหนักจึงต้องพิจารณาทั้งราคาต่อเวลา CPU และเวลาสูงสุดที่อนุญาตให้โค้ดทำงานจริง

ในราคา Fluid Compute ของ Vercel การใช้งาน Pro แยกคิด Active CPU, Provisioned Memory และ invocations โดยอัตราที่สิงคโปร์คือ 0.160 ดอลลาร์ต่อชั่วโมง CPU และ 0.0133 ดอลลาร์ต่อ GB-ชั่วโมงของหน่วยความจำ ส่วน invocation คิด 0.60 ดอลลาร์ต่อหนึ่งล้านครั้งก่อนนำเครดิตการใช้งานรายเดือนของ Pro มาหัก โควตา invocation ฟรีหนึ่งล้านครั้งในตารางเดียวกันเป็นสิทธิของ Hobby ไม่ใช่โควตาเพิ่มเติมของ Pro

เมื่อฟังก์ชัน Vercel รอ I/O การคิด Active CPU หยุด แต่หน่วยความจำที่จัดสรรยังถูกคิดจนคำขอสุดท้ายที่กำลังทำงานในอินสแตนซ์นั้นเสร็จ หากหลายคำขอรอพร้อมกันและใช้อินสแตนซ์เดียว ต้นทุนหน่วยความจำไม่ได้เพิ่มเป็นจำนวนเท่าของคำขอทุกครั้ง ในทางกลับกัน คำขอที่เข้ามาห่างกันและรอนานอาจทำให้อินสแตนซ์มีชีวิตเพื่อรับคำขอเพียงรายการเดียวตลอดช่วงรอ ความถี่และการซ้อนกันของคำขอจึงเปลี่ยนค่าใช้จ่ายต่อคำขอได้

ภูมิภาคเป็นส่วนหนึ่งของสูตร Vercel เพราะอัตรา CPU และหน่วยความจำแตกต่างกันตามที่ฟังก์ชันรัน การย้ายฟังก์ชันเข้าใกล้ผู้ใช้หรือฐานข้อมูลอาจเปลี่ยนทั้งเวลาตอบกลับและราคา compute พร้อมกัน การเทียบราคาโดยใช้ภูมิภาคหนึ่ง แต่ประเมินความหน่วงราวกับรันอีกภูมิภาคหนึ่ง จะทำให้ตัวเลขสองด้านนั้นไม่สอดคล้องกัน

API เบา งาน CPU หนัก และ endpoint ที่รอ AI

ตัวอย่างต่อไปนี้เป็นการคำนวณตามสมมติฐาน ไม่ใช่ผลทดสอบหรือใบเรียกเก็บเงินจริง สมมติว่ามีคำขอเพิ่มอีกหนึ่งล้านครั้งหลังใช้โควตาคำขอและเวลา CPU ที่รวมใน Workers Paid หมดแล้ว สำหรับ Vercel สมมติใช้ Pro รันที่สิงคโปร์ จัดสรรหน่วยความจำ 2 GB และแต่ละคำขอใช้อินสแตนซ์ตามเวลาที่ระบุโดยไม่มีคำขอซ้อนกัน ตัวเลข Vercel เป็นค่าใช้งานก่อนหักเครดิตแพ็กเกจ และตัวเลข Workers ไม่รวมค่าขั้นต่ำรายเดือน

• API เบา: สมมติหนึ่งคำขอใช้ CPU 5 มิลลิวินาที และเสร็จภายใน 50 มิลลิวินาที Workers มีค่าใช้จ่ายส่วนเพิ่มประมาณ 0.40 ดอลลาร์ต่อหนึ่งล้านคำขอ จากค่าคำขอและค่า CPU ส่วนสูตรของ Vercel ให้ประมาณ 1.19 ดอลลาร์เมื่อรวม CPU หน่วยความจำที่จัดสรร และ invocation แม้ช่วงเวลาต่อคำขอสั้นมาก ค่าหน่วยความจำก็ยังเป็นองค์ประกอบของบิล Vercel
• งาน CPU หนัก: สมมติหนึ่งคำขอใช้ CPU 200 มิลลิวินาที และเสร็จใน 250 มิลลิวินาที Workers มีค่าใช้จ่ายส่วนเพิ่มประมาณ 4.30 ดอลลาร์ต่อหนึ่งล้านคำขอ ส่วน Vercel ภายใต้สมมติฐานเดียวกันอยู่ที่ประมาณ 11.34 ดอลลาร์ เมื่อเพิ่มเวลาคำนวณ ต้นทุน CPU ของทั้งคู่เพิ่มขึ้น การตัดสินใจจึงต้องดูด้วยว่าโค้ดและไลบรารีที่ทำงานหนักนั้นรันบน runtime ที่เลือกได้จริงหรือไม่
• endpoint ที่รอ AI: สมมติหนึ่งคำขอใช้ CPU 20 มิลลิวินาที แต่เปิดค้างเพื่อรอผลรวม 10 วินาที Workers มีค่าใช้จ่ายส่วนเพิ่มประมาณ 0.70 ดอลลาร์ต่อหนึ่งล้านคำขอ ส่วนสูตร Vercel แบบไม่มีคำขอซ้อนกันให้ประมาณ 75.38 ดอลลาร์ ส่วนต่างส่วนใหญ่มาจากหน่วยความจำที่จัดสรรไว้ตลอดช่วงรอ ไม่ใช่จาก CPU ตัวเลข Vercel จะลดลงต่อคำขอได้หากอินสแตนซ์เดียวรองรับคำขอที่รอพร้อมกัน

ทั้งสามกรณีใช้เวลา CPU และเวลารวมต่อคำขอเท่ากันบนสองแพลตฟอร์มเพื่อให้เห็นผลของสูตรราคา สมมติฐานนี้ไม่ได้รับประกันว่าโค้ดจริงจะใช้เวลาเท่ากันบน runtime ต่างชนิดกัน และไม่ได้รวมช่วงเริ่มต้นของอินสแตนซ์ ค่าโอนข้อมูล ค่าฐานข้อมูล หรือค่าบริการโมเดล AI โดยเฉพาะกรณี AI จำนวนคำขอที่ซ้อนกันจริงอาจเปลี่ยนต้นทุนหน่วยความจำของ Vercel อย่างมาก

ตัวเลขส่วนเพิ่มของ Workers จะใช้ได้ต่อเมื่อโควตาทั้งคำขอและ CPU หมดแล้ว หากระบบยังเหลือโควตา ต้นทุนที่ปรากฏในบิลอาจต่ำกว่าตัวอย่าง ในฝั่ง Vercel เครดิตรายเดือนของ Pro อาจหักค่าใช้งานที่คำนวณได้ แต่ไม่เปลี่ยนวิธีที่ระบบนับ CPU หน่วยความจำ และ invocation การใช้ตัวเลขส่วนเพิ่มจึงช่วยอธิบายว่าคำขอประเภทใดดันต้นทุนขึ้น มากกว่าทำนายยอดบิลรายเดือนของทุกโครงการ

ความเข้ากันได้ของ Next.js อาจมาก่อนส่วนต่างราคา

แอป Next.js สามารถนำไปวางบนทั้งสองแพลตฟอร์มได้ แต่เส้นทางทำงานฝั่งเซิร์ฟเวอร์อาจใช้ API ของ Node.js ต่างกัน การแสดงหน้าเว็บได้สำเร็จไม่ได้แปลว่าแพ็กเกจที่ใช้เข้ารหัสไฟล์ เชื่อมต่อฐานข้อมูล หรือประมวลผลข้อมูลทุกตัวจะทำงานเหมือนกันในทุกเส้นทางของแอป สำหรับโครงการที่มี dependency ฝั่งเซิร์ฟเวอร์มาก ความเข้ากันได้ของ runtime อาจเป็นเงื่อนไขก่อนคำนวณความประหยัด

เอกสาร Node.js compatibility ของ Workers ระบุว่ารองรับ API ของ Node.js เพียงบางส่วน และบางโมดูลเป็น polyfill ที่ช่วยให้นำเข้าได้ แต่เรียกใช้เมธอดแล้วเกิดข้อผิดพลาดได้ สำหรับ compatibility date ตั้งแต่ 4 สิงหาคม 2026 ความเข้ากันได้ชุดดังกล่าวเปิดตามค่าเริ่มต้น การเปิดใช้งานอัตโนมัติจึงไม่ได้ทำให้ API ทุกตัวของ Node.js ใช้งานได้ครบ การตรวจเฉพาะว่าบิลด์ผ่านอาจไม่พบปัญหาที่เกิดขึ้นเมื่อคำขอวิ่งถึงโค้ดส่วนนั้นจริง

ฝั่ง Vercel มี Node.js coverage เต็มตามข้อจำกัดของ Vercel Functions ซึ่งระบุหน่วยความจำสูงสุด 2 GB สำหรับ Hobby และ 4 GB สำหรับ Pro พร้อมขนาดฟังก์ชันแบบไม่บีบอัดตามปกติ 250 MB เอกสารเดียวกันระบุว่าฟังก์ชันรันในภูมิภาค iad1 ตามค่าเริ่มต้นและเปลี่ยนได้ ข้อได้เปรียบด้าน API ของ Node.js จึงยังต้องพิจารณาคู่กับขนาดไฟล์ หน่วยความจำ และภูมิภาคที่โครงการต้องใช้

สำหรับแอปที่มีทั้งหน้าเว็บและ API การเลือกรันส่วนที่ต้องใช้ Node.js บน Vercel อาจลดงานปรับ dependency ส่วนบริการที่เป็น JavaScript ขนาดเล็กและใช้ API ที่ Workers รองรับอาจได้ประโยชน์จากโครงสร้างราคาของ Cloudflare นี่เป็นการประเมินลักษณะงาน ไม่ใช่ข้อสรุปว่าฟังก์ชันทั้งหมดของแอปหนึ่งควรอยู่แพลตฟอร์มเดียวกัน ต้นทุนการดูแลและการเชื่อมต่อระหว่างบริการยังเป็นส่วนของการตัดสินใจด้วย

ตำแหน่งผู้ใช้กับข้อมูลเปลี่ยนเวลาที่รู้สึกได้

ผู้ใช้ในไทยไม่ได้รอเพียง runtime เริ่มทำงาน เวลาตอบกลับยังรวมการเดินทางจากผู้ใช้ไปยังฟังก์ชัน การประมวลผลในฟังก์ชัน การไปกลับฐานข้อมูลหรือผู้ให้บริการ AI และการส่งคำตอบกลับมา หากฟังก์ชันอยู่ใกล้ผู้ใช้แต่ฐานข้อมูลอยู่ไกล คำขอที่อ่านข้อมูลหลายครั้งอาจเสียเวลาเดินทางระหว่างบริการมากกว่าส่วนต่าง cold start ที่เห็นในงาน API เบา

ฟังก์ชันที่รันใกล้ฐานข้อมูลอาจลดเวลาของการเรียกข้อมูล แต่ระยะทางจากผู้ใช้ไทยถึงฟังก์ชันอาจเพิ่มขึ้น ผลรวมขึ้นกับจำนวนรอบที่แอปติดต่อฐานข้อมูล ขนาดข้อมูล และรูปแบบการส่งคำตอบ สำหรับ endpoint AI การเริ่มส่งผลแบบสตรีมอาจทำให้ผู้ใช้เห็นคำตอบก่อนงานทั้งหมดเสร็จ ขณะที่ช่วงเวลาซึ่งคำขอยังทำงานอยู่ยังเกี่ยวข้องกับค่าหน่วยความจำของ Vercel

จึงควรแยกเวลาถึงไบต์แรกออกจากเวลาที่คำตอบครบ และแยกคำขอที่เริ่มอินสแตนซ์ใหม่ออกจากคำขอที่ใช้อินสแตนซ์เดิมเมื่อตีความผลทดสอบ หน้าเว็บแบบไดนามิก API ที่คำนวณสั้น และ endpoint ที่รอบริการภายนอกมีคอขวดคนละแห่ง การใช้ค่า latency ค่าเดียวแทนทุกเส้นทางจะบดบังทั้งประสบการณ์ผู้ใช้และต้นทุนที่เกิดขึ้นจริง

หากงานหลักเป็น API สั้นที่ใช้ฟังก์ชันของ Workers ได้ครบ Cloudflare มีเหตุผลด้านต้นทุนส่วนเพิ่มและผล cold start ในการทดสอบทราฟฟิกต่ำ หากแอป Next.js ผูกกับ Node.js มาก Vercel มีข้อได้เปรียบด้านความเข้ากันได้ของ runtime สำหรับงานที่รอ AI นาน คำตอบขึ้นกับเวลารอ หน่วยความจำที่จัดสรร จำนวนคำขอที่ซ้อนกัน และตำแหน่งบริการปลายทางพอ ๆ กับเวลาเริ่มฟังก์ชัน