Cloud Run GPU รองรับอย่างเป็นทางการแล้ว - ทำให้การรันเวิร์กโหลด AI สำหรับทุกคนง่ายขึ้น

 (cloud.google.com)
1 คะแนน โดย GN⁺ 2025-06-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตอนนี้ Cloud Run รองรับ GPU อย่างเป็นทางการ (GA) แล้ว ทำให้การ รันเวิร์กโหลด AI ทำได้ง่ายยิ่งขึ้น
  • Cloud Run jobs ก็สามารถใช้ GPU ได้เช่นกัน เปิดความเป็นไปได้ใหม่สำหรับ งานประมวลผลแบบแบตช์ และงานแบบอะซิงโครนัส
  • เป็นสภาพแวดล้อมที่เหมาะกับ งานแบตช์ขนาดใหญ่ เช่น การประมวลผลภาพ การวิเคราะห์ภาษาธรรมชาติ และการแปลงสื่อ

Cloud Run GPU เปิดให้ใช้อย่างเป็นทางการและการเปลี่ยนแปลงสำคัญ

เริ่มรองรับ NVIDIA GPU ใน Cloud Run jobs

  • ก่อนหน้านี้ความสามารถด้าน GPU ของ Cloud Run ถูกใช้งานในบริการแบบอิงคำขอ เช่น การทำ inference แบบเรียลไทม์
  • ตอนนี้ Cloud Run jobs ก็รองรับ GPU อย่างเป็นทางการแล้ว ทำให้เกิดกรณีการใช้งานใหม่ ๆ
    • การ fine-tuning โมเดล: สามารถฝึกโมเดลที่ผ่านการ pre-train มาแล้วใหม่ให้เหมาะกับชุดข้อมูลเฉพาะได้อย่างง่ายดาย
    • Batch AI inference: เหมาะกับงานขนาดใหญ่ เช่น การวิเคราะห์ภาพ การประมวลผลภาษาธรรมชาติ หรือการสร้างระบบแนะนำ
    • การประมวลผลสื่อปริมาณมาก: สามารถใช้ GPU เพื่อประมวลผลวิดีโอทรานส์โค้ด การสร้างภาพขนาดย่อ และการแปลงภาพได้อย่างมีประสิทธิภาพ
  • Cloud Run job ที่ติดตั้ง GPU จะลดทรัพยากรโดยอัตโนมัติหลังงานเสร็จ ช่วยลดภาระในการดูแลจัดการให้เหลือน้อยที่สุด

ประสบการณ์จริงจากบริษัทที่เริ่มใช้งาน

  • vivo: Cloud Run ช่วยเร่งความเร็วในการพัฒนา AI application แบบวนซ้ำ และช่วยประหยัด ต้นทุนการดำเนินงานและบำรุงรักษา ได้มาก ฟีเจอร์ autoscaling ของ GPU ยังช่วยเพิ่มประสิทธิภาพการนำ AI ไปใช้ในตลาดต่างประเทศอย่างก้าวกระโดด
  • Wayfair: L4 GPU ให้ทั้งประสิทธิภาพสูงและ ราคาที่สมเหตุสมผล เมื่อทำงานร่วมกับ autoscaling ที่รวดเร็วของ Cloud Run ทำให้ลดต้นทุนได้ราว 85%
  • Midjourney: Cloud Run GPU มีประโยชน์มากสำหรับการประมวลผลภาพขนาดใหญ่ และด้วยสภาพแวดล้อมการพัฒนาที่เรียบง่ายชัดเจน ทำให้สามารถโฟกัสกับนวัตกรรมได้โดยไม่ต้องแบกรับภาระการดูแลอินฟราสตรักเจอร์ ความสามารถในการขยายของ GPU ยังช่วยให้การวิเคราะห์และประมวลผลภาพหลายล้านภาพทำได้ง่ายขึ้น

วิธีเริ่มต้นและทรัพยากร

บทสรุป

  • การรองรับ GPU อย่างเป็นทางการของ Cloud Run มอบศักยภาพในการขยายงานอย่างก้าวกระโดดให้กับเวิร์กโหลดเฉพาะทางหลากหลายรูปแบบ เช่น AI, การประมวลผลแบบแบตช์ขนาดใหญ่, การแปลงสื่อ
  • บริษัทต่าง ๆ ได้พิสูจน์แล้วถึงข้อดีในหลายด้าน ทั้งต้นทุน ประสิทธิภาพการดำเนินงาน และความสามารถในการขยายระบบ
  • ด้วยการตั้งค่าที่ง่ายและสื่อการเรียนรู้ที่หลากหลาย ทุกคนจึงเริ่มต้นใช้งานเวิร์กโหลด GPU บนคลาวด์ได้ไม่ยาก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-06-05
ความคิดเห็นจาก Hacker News

  • ฉันชอบ Google Cloud Run มาก และมักจะแนะนำอย่างจริงจังว่าเป็นตัวเลือกที่ดีที่สุด แต่สำหรับ Cloud Run GPU กลับรู้สึกว่าแนะนำได้ยาก การคิดค่าบริการแบบอิงจำนวนอินสแตนซ์ไม่มีประสิทธิภาพ และตัวเลือก GPU ก็มีจำกัด อีกทั้งเวลาต้องโหลด/ถอดโมเดลเข้าออกจากหน่วยความจำ GPU ประสิทธิภาพจะตก ทำให้มีข้อจำกัดว่าในสภาพแวดล้อม serverless มันช้า พอเทียบต้นทุนจริงแล้ว หากใช้งานเพียง 30% ของทั้งวัน การจับคู่ VM+GPU ก็ยังคุ้มกว่า (ลิงก์บล็อกที่เกี่ยวข้อง)

    • รองประธาน Google ขอบคุณสำหรับฟีดแบ็ก โดยทั่วไปเห็นด้วยว่าในโครงสร้างราคาปัจจุบัน หากต้องการความจุของบริการแบบค่อนข้างคงที่ การ provision VM ล่วงหน้าจะคุ้มค่ากว่า ในทางกลับกัน Cloud Run GPU เหมาะที่สุดกับสภาพแวดล้อมอย่างผลิตภัณฑ์ใหม่หรือแอป AI ที่มีความต้องการพุ่งขึ้นกะทันหัน ซึ่งต้องการต้นทุน idle ต่ำที่สุด เริ่มต้นได้เร็วมาก และมีทราฟฟิกที่มาไม่บ่อยและไม่สม่ำเสมอ

    • Cloud Run ดูเป็นบริการที่ยอดเยี่ยมจริง ๆ ประสบการณ์คือใช้งานง่ายกว่า AWS ECS/Fargate มาก

    • ปัญหาใหญ่ที่สุดคือไว้ใจการใช้ VM บน GCP ไม่ได้ และคลาวด์รายใหญ่ทุกเจ้าก็มีปัญหานี้เหมือนกัน บน AWS แทบหา GPU 80GB ไม่ได้ถ้าไม่มีการจองระยะยาว และราคาก็สูงเกินจริง GCP ก็ทั้งแพงและความพร้อมใช้งานต่ำไม่ต่างกัน บริษัทใหญ่ชอบพูดว่าตัวเองเป็นมิตรกับสตาร์ตอัป แต่จากประสบการณ์จริงไม่ใช่เลย neo-cloud อย่าง runpod, nebius, lambda กลับให้บริการดีกว่ามาก คลาวด์รายใหญ่กำลังชินกับดีมานด์คงที่ และไม่ใส่ใจสตาร์ตอัป ซึ่งน่าจะเป็นความผิดพลาดที่กระทบต่อการเติบโตระยะยาวอย่างหนัก

    • ฉันมีประสบการณ์ตรงกันข้ามกับ Cloud Run เพราะเจอการสเกลเอาต์/รีสตาร์ตแบบไม่ทราบสาเหตุ สุดท้ายถึงขั้นซื้อบริการซัพพอร์ตแบบเสียเงินเพื่อสอบถาม แต่ก็หาคำตอบไม่ได้ สุดท้ายเลยย้ายไปดูแล VM เอง หลังจากนั้นดีขึ้นไหมก็ไม่แน่ใจ

    • เรื่องที่บอกว่า Cloud Run ดีที่สุดนั้น ฉันอยากเห็นตัวเลขจริงเอง มันดีสำหรับโปรเจ็กต์เล่น ๆ แต่ในงานจริงคือหลุมเผาเงิน ระหว่างโปรเจ็กต์เจอปัญหา autoscaling ต่อเนื่อง แม้ scale to zero จะดูดีในทางทฤษฎี แต่ในความเป็นจริงช่วง warm-up มักมีหลายคอนเทนเนอร์ถูกเปิดขึ้นมาสำหรับคำขอเดียวและค้างอยู่นาน บางคอนเทนเนอร์ก็ถูกคิดเงินต่อทั้งที่ไม่เห็นการใช้ CPU หรือเครือข่ายอย่างชัดเจน Java หรือ Python ก็มี cold start ช้ามาก ส่วน Go/C++/Rust ฉันยังไม่มีประสบการณ์จึงไม่แน่ใจ

  • นอกจากความซับซ้อนของคลาวด์รายใหญ่แล้ว ยังน่ากังวลเรื่องการคิดเงินแบบ YOLO ไม่จำกัด จนเสี่ยงให้บัตรเครดิตโดนรูดเกลี้ยงข้ามคืน สรุปแล้วฉันจะอยู่กับ Modal และ vast.ai ต่อไป

    • ในมุมของผู้ใช้ส่วนตัว/โปรเจ็กต์เล็ก การที่ GCP ไม่มีเพดานค่าใช้จ่าย (CAP) ถือเป็นจุดอ่อนใหญ่ สำหรับ Cloud Run อย่างน้อยยังพอจำกัดค่าใช้จ่ายทางอ้อมได้ด้วยการตั้งข้อจำกัด concurrency และจำนวนอินสแตนซ์ แต่ก็ยังไม่ใช่ CAP ที่แท้จริง

    • ฉันเคยลืมปิดอินสแตนซ์บน AWS จนโดนค่าใช้จ่ายสูง เลยรู้สึกว่า scale to zero และการคิดเงินเป็นวินาทีของ Cloud Run เป็นข้อดีมาก ถ้ามันเริ่มได้เร็วจริง ก็น่าจะเหมาะกับเวิร์กโหลดของฉันมาก

    • บน Cloud Run สามารถจำกัดค่าใช้จ่ายสูงสุดทางอ้อมได้ด้วยการตั้งจำนวนอินสแตนซ์สูงสุด ส่วน hard cap ในยุค App Engine นั้นมีผลข้างเคียงคือพอบริการเริ่มติดกระแสจริง ๆ (เช่น ถูกโพสต์บน HN) มันจะหยุดทำงานไปเลย ส่วนตัวคิดว่าการจัดการงบประมาณแบบอิงการแจ้งเตือนดีกว่า

    • นี่เองคือเหตุผลที่ฉันทิ้ง Datadog ออกจากโปรดักชันจริง แพลตฟอร์มทั้งหลายคุ้มไหมกับการต้องยอมรับภาพลักษณ์ด้านลบที่เกิดจากการที่ผู้ใช้โดนคิดเงินเกินเพราะความผิดพลาด

    • ยังไม่ชัดเจนว่า Modal หรือ vast.ai ป้องกันการคิดเงินแบบ YOLO ได้อย่างไร เป็นโครงสร้างจ่ายล่วงหน้าหรือมี CAP โดยตรงกันแน่ก็น่าสงสัย

  • พอลองเทียบราคาเองแล้วก็ไม่รู้สึกว่ามีข้อได้เปรียบชัดเจน ได้สรุปราคาต่อชั่วโมงของ Google, runpod.io, vast.ai เป็น ตาราง:

      1x L4 24GB:  google: $0.71, runpod.io: $0.43, 스팟: $0.22  
  4x L4 24GB:  google: $4.00, runpod.io: $1.72, 스팟: $0.88  
  1x A100 80GB: google: $5.07, runpod.io: $1.64, 스팟: $0.82, vast.ai $0.880, 스팟: $0.501  
  1x H100 80GB: google: $11.06, runpod.io: $2.79, 스팟: $1.65, vast.ai $1.535, 스팟: $0.473  
  8x H200 141GB: google: $88.08, runpod.io: $31.92, vast.ai $15.470, 스팟: $14.563

    ราคาของ Google ดูเหมือนอิงจากการรันตลอด 24/7 เป็นเดือน ขณะที่ runpod.io และ vast.ai คิดเงินเป็นวินาที ส่วนราคาสปอตของ Google GPU หาไม่เจอ

    • สามารถดูราคาสปอตได้ทันทีในหน้า "สร้าง Compute Instance" เช่น 1xH100 spot บน GCP อยู่ที่ $2.55 ต่อชั่วโมง และถ้าใช้นานก็มีส่วนลดเพิ่ม ลูกค้าองค์กรจริง ๆ อาจต่อรองส่วนลดจากราคานี้ได้อีก มีแต่ผู้ใช้ทั่วไปที่จ่ายราคาเต็มแบบนี้

    • อยากรู้แหล่งที่มาของราคาจาก vast.ai เพราะจากหน้าเว็บ ตัวเลือก 8xH200 ส่วนใหญ่ดูเหมือนจะอยู่ที่ $21.65 ต่อชั่วโมงขึ้นไป

    • อยากรู้ว่ามีหลักฐานอะไรที่บอกว่าราคาของ Google ตั้งอยู่บนสมมติฐาน 24/7 เพราะใน หน้าราคาอย่างเป็นทางการของ Cloud Run ระบุว่าคิดเงินตามการใช้งานจริงเป็นหน่วย 100 มิลลิวินาที และในคำอธิบาย autoscaling ก็เขียนว่าอินสแตนซ์ที่ว่างจะถูกลดลงอัตโนมัติหลังรอ 15 นาที (Cloud Run PM)

    • สงสัยว่าใน Cloud Run GPU เลือกได้แค่ 1xL4 ไม่ใช่หรือ

    • ถ้าราคาของ Google ก็คิดเป็นวินาทีเหมือนกัน การใช้งานน้อยกว่า 20 นาทีอาจกลับกลายเป็นว่า Google คุ้มกว่าก็ได้

  • ฉันเป็นแฟนตัวยงของ Modal และใช้ serverless scale-to-zero GPU มานานแล้ว เวลาต้องการก็สเกลอัปได้ง่ายในขนาดใหญ่ พร้อมลดภาระการพัฒนาอย่างมาก น่าสนใจที่ผู้ให้บริการรายใหญ่เริ่มลงมาเล่นในตลาดนี้ เหตุผลที่ฉันย้ายมา Modal ก็เพราะคลาวด์รายใหญ่เดิมไม่มีความสามารถแบบนี้ให้ (เช่น AWS Lambda ไม่รองรับ GPU) เลยสงสัยว่าต่อไปคลาวด์หลักทุกเจ้าจะมุ่งไปทางบริการแบบนี้หรือไม่

    • Modal ยอดเยี่ยมจริง ๆ รายละเอียดเชิงลึกของ LP solver ที่เผยแพร่เองก็น่าประทับใจ ถ้าเป็นนักพัฒนา Python ก็แนะนำ Coiled ด้วย แม้จะไม่เร็วเท่า Modal แต่ก็สปินอัป GPU VM ได้ง่าย และทุกอย่างรันอยู่ในบัญชีคลาวด์ของตัวเอง มีระบบจัดการแพ็กเกจที่สะดวก เช่น การซิงก์ CUDA driver/ไลบรารี Python (หมายเหตุ: สังกัด Coiled แต่แนะนำจากใจ)

    • การรองรับเวิร์กโหลดที่ต้องปฏิบัติตาม HIPAA ก็เป็นข้อดีที่เหนือความคาดหมาย

    • ความเร็ว cold start ของ Modal เร็วที่สุดสำหรับโมเดลขนาดเกิน 10GB

    • เอกสารของ Modal ก็จัดทำได้ดีมากเช่นกัน

  • เหตุผลใหญ่ที่สุดที่ Cloud Run ดีกว่าบริการอื่นคือ autoscale และ scale-to-zero ตอนที่ไม่มีการใช้งานจริงก็แทบไม่เสียค่าใช้จ่ายเลย และยังตั้งจำนวนอินสแตนซ์สูงสุดเพื่อควบคุมค่าใช้จ่ายสูงสุดได้อย่างมั่นคง แต่ทั้งหมดนี้พูดถึงกรณีใช้เวอร์ชัน CPU เท่านั้น ซึ่งมันเชื่อถือได้มากและใช้งานง่ายมาก

    • แต่ Cloud Run ปกติก็มักมีเวลา cold start ที่นานอยู่บ่อย ๆ (ประมาณ 3~30 วินาที) จึงมีปัญหาเรื่อง latency เมื่อใช้ scale-to-zero

  • DataCrunch ผู้ให้บริการ GPU cloud รายเล็กจากยุโรป (ไม่มีความเกี่ยวข้องกัน) ให้บริการ Nvidia GPU VM ถูกกว่า RunPod เป็นต้น

    1x A100 80GB 1.37 ยูโร/ชั่วโมง
    1x H100 80GB 2.19 ยูโร/ชั่วโมง

    • บน lambda.ai มี VM แบบ 1x H100 80GB ที่ราคา $2.49 ต่อชั่วโมง ซึ่งเมื่อคิดอัตราแลกเปลี่ยนก็พอดี 2.19 ยูโร เลยสงสัยว่านี่เป็นเรื่องบังเอิญหรือในอุตสาหกรรมมีเพดานราคาที่มองไม่เห็นกันแน่

    • บน Vast.ai สามารถใช้ 2x A100 แบบ P2P ได้ในราคา $0.8/ชั่วโมง (แปลว่า A100 หนึ่งตัว $0.4/ชั่วโมง) ตัวฉันเองก็เป็นแค่ผู้ใช้ที่พอใจคนหนึ่งเท่านั้น แต่ต้องระวังเรื่องความเร็วเครือข่ายด้วย บางโฮสต์แชร์แบนด์วิดท์กัน ทำให้ความเร็วจริงอาจไม่ตรงกับที่โฆษณาไว้ ต้องระวังถ้าต้องย้ายข้อมูลปริมาณมาก

  • VP/GM ที่ดูแล Cloud Run/GKE พร้อมตอบคำถามเกี่ยวกับเรื่องนี้ ขอบคุณสำหรับความสนใจอย่างมาก

  • ฉันชอบ Cloud Run และฟีเจอร์ใหม่ก็ดูน่าสนใจ แต่สิ่งที่น่าเสียดายคือเคยอยากรัน self hosted GitHub runners แล้วทำไม่ได้เพราะปัญหาเรื่องสิทธิ์ root อีกทั้งฟีเจอร์ worker pool ที่เพิ่งเพิ่มมาก็ในทางปฏิบัติต้องเขียน scaler เอง จึงไม่ใช่ความสามารถที่มีมาให้ในตัว

    • Eng Manager ที่ดูแล Serverless และ Worker Pools Autoscaling ตอนนี้กำลังกำหนดโรดแมปอย่างจริงจัง และคิดว่าจะช่วยได้มากหากมีการส่งอีเมลตัวอย่างเวิร์กโหลดที่ใช้งานจริงมาให้ ยินดีรับฟังความคิดเห็นเกี่ยวกับ worker pools และเวิร์กโหลดที่ต้องการการสเกล

  • หลังจากเคยโดนเรียกเก็บเงิน $1000 เพราะเปิดรันทดสอบโมเดลบน vertex.ai ทิ้งไว้แล้วลืมปิด คราวนี้ Cloud Run น่าจะกลายเป็นบริการ go to ของฉัน ตลอดหลายปีที่ผ่านมาใช้งาน Cloud Run ทั้งกับไมโครเซอร์วิสโปรดักชันและโปรเจ็กต์งานอดิเรก รู้สึกพอใจกับทั้งความเรียบง่ายและความคุ้มค่า

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

    • คำอธิบายคือโดยพื้นฐานแล้วถูกต้อง แต่ cold start อาจช้ามาก (30~60 วินาที) ซึ่งเป็นข้อเสียของ scale to zero อีกทั้งต้องระวังด้วยว่ายังมีค่าบริการรายเดือนเล็กน้อยบางอย่าง เช่น การเก็บคอนเทนเนอร์

    • ยังมีทางเลือกอื่นอีกหลายรายที่รองรับ serverless GPU inference เช่น Runpod, vast, coreweave, replicate