Fly.io รองรับ GPU แล้ว

 (fly.io)
1 คะแนน โดย GN⁺ 2024-02-14 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Fly.io ซึ่งรันแอปใกล้กับผู้ใช้ เพิ่ม การรองรับ GPU แล้ว ทำให้สามารถวาง AI inference ไว้ใกล้ edge แทนที่จะอยู่ในรีเจียนศูนย์กลางได้
  • แอปสามารถแนบ Nvidia A100 เพื่อใช้ CUDA และ VRAM ขนาดใหญ่ได้ เหมาะสำหรับงานรู้จำเสียงพูด, การแบ่งข้อความ, สรุปบทความ, สร้างภาพ และรันโมเดลช่วยเขียนโค้ด
  • แอป GPU ที่ใช้ Ollama สามารถดีพลอยได้ด้วยการระบุ vm.size = "a100-40gb" และอิมเมจ ollama/ollama ใน fly.toml แล้วใช้ fly apps create และ fly deploy
  • ในรีเจียนที่รองรับ GPU สามารถรันโปรแกรมเดียวกันด้วย IP สาธารณะและใบรับรอง TLS เดียวกันได้ และขยายไปยัง รีเจียน Amsterdam ได้ด้วยคำสั่งเช่น fly scale count 2 --region ams
  • A100 40GB ราคา $2.50 ต่อชั่วโมง, A100 80GB ราคา $3.50, L40s ราคา $2.50 และหากตั้งค่าเริ่ม/หยุดอัตโนมัติ ก็หลีกเลี่ยง การคิดค่าบริการชั่วโมง GPU เมื่อไม่มีคำขอได้

รัน GPU ใกล้กับผู้ใช้

  • Fly.io เป็นคลาวด์ที่ให้รันแอปแบบ full-stack หรือแพลตฟอร์มพัฒนาที่ใช้ Fly Machines API ใกล้กับผู้ใช้ และได้เพิ่ม การรันด้วย GPU เข้าไป
  • Fly.io GPU เชื่อมต่อ Nvidia A100 เข้ากับแอป ทำให้ใช้ CUDA และ VRAM ที่มากกว่า 4090 ในเครื่องได้
  • งาน AI/ML ที่นำไปใช้ได้มีดังนี้
    • รู้จำเสียงพูด
    • การแบ่งข้อความ
    • การสรุปบทความ
    • การสังเคราะห์ภาพ
    • ผู้ช่วยเขียนโปรแกรมโดยใช้โมเดลที่เลือก เช่น DeepSeek-Coder

ดีพลอยแอป GPU ด้วย Ollama

  • Fly.io ตั้งเป้าให้ผู้ใช้ดีพลอยโมเดลที่ชอบและโค้ดที่เขียนเองบน backbone คลาวด์ของ Fly.io
  • แอป GPU ที่ใช้ Ollama สามารถรันได้ด้วยเพียงการตั้งค่า fly.toml และคำสั่งดีพลอย
    • app = "sandwich_ai"
    • primary_region = "ord"
    • vm.size = "a100-40gb"
    • อิมเมจสำหรับ build คือ ollama/ollama
    • เมานต์วอลุ่ม 100gb ที่ /root/.ollama
  • คำสั่งสำหรับรันมีดังนี้
fly apps create sandwich_ai && fly deploy

Inference ที่ทำใกล้กับรีเจียน

  • จุดที่ Fly.io เน้นไม่ใช่แค่การให้บริการ GPU แต่คือ edge inference
  • แอปตัวอย่างมีโครงสร้างให้ผู้ใช้ใส่วัตถุดิบที่มีในครัว แล้วรับสูตรแซนด์วิช
  • หากดีพลอยด้วย primary_region = "ord" ผู้ใช้ใกล้ Chicago จะได้รับสูตรแซนด์วิชอย่างรวดเร็ว
  • ผู้ใช้ที่อยู่นอก Chicago เช่น ผู้ใช้ใน Amsterdam อาจใช้เวลานานขึ้น เพราะคำขอต้องข้ามมหาสมุทรแอตแลนติก
  • ในรีเจียนที่รองรับ GPU สามารถรันโปรแกรมเดียวกันด้วยที่อยู่ IP สาธารณะเดียวกันและใบรับรอง TLS เดียวกันได้
  • การขยายไป Amsterdam ทำได้ด้วยคำสั่งต่อไปนี้
fly scale count 2 --region ams

ใช้ GPU เฉพาะเมื่อมีคำขอ

  • GPU เป็นอุปกรณ์ประมวลผลขนานที่ทรงพลัง แต่ไม่ถูก ดังนั้นสำหรับแอปขนาดเล็ก การตั้งค่าให้จ่ายเฉพาะตอนมีผู้ใช้ส่งคำขอจึงได้เปรียบ
  • สามารถตั้งค่าเริ่มอัตโนมัติและหยุดอัตโนมัติได้ในส่วน services ของ fly.toml
[[services]]
  internal_port = 8080
  protocol = "tcp"
  auto_stop_machines = true
  auto_start_machines = true
  min_machines_running = 0
  • auto_stop_machines = true และ auto_start_machines = true เป็นการตั้งค่าให้หยุดเครื่องเมื่อไม่มีคำขอ และเริ่มใหม่เมื่อจำเป็น
  • หาก min_machines_running = 0 จะไม่ต้องจ่าย ค่าใช้จ่ายชั่วโมง GPU เมื่อไม่มีคำขอสูตรแซนด์วิช

GPU ที่ให้บริการและทรัพยากรพื้นฐาน

  • GPU ใช้งานได้ในหลายรีเจียนของสหรัฐฯ และ EU รวมถึง Sydney
  • เป้าหมายการดีพลอยและราคามีดังนี้
  • แอปที่ดีพลอยบน GPU จะใช้คอร์ CPU AMD EPYC 8 คอร์เป็นค่าเริ่มต้น
  • สามารถแนบวอลุ่มได้สูงสุด 500GB
  • อาจมีส่วนลดสำหรับ reserved instances และ dedicated hosts ด้วย

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

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

 
GN⁺ 2024-02-14
ความเห็นจาก Hacker News

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

    • เคยทดสอบเพื่อจะย้ายไป Fly.io แต่แม้แต่การ deploy แบบง่าย ๆ ก็ยังมีช่วงที่การเชื่อมต่อหลุดไปหลายวินาทีระหว่างสลับระบบ ลองรัน watch -n 2 curl ตอน deploy ก็เห็นได้เอง และเป็นแบบนั้นกับทุก strategy ที่มีในเอกสาร รวมถึง blue-green
      อย่างแย่ที่สุดก็หวังว่าแค่ตัดการเชื่อมต่อเดิมเร็วกว่าปกติ แต่การเชื่อมต่อใหม่ไม่ควรหลุด และดีที่สุดคือรออย่างนุ่มนวลจนการเชื่อมต่อเดิมจบลง แต่ของจริงกลับเป็น การสลับที่ downtime เต็มรูปแบบ ทุกครั้ง พอมองจาก network topology ที่อธิบายในบล็อกก็รู้สึกว่าตั้งแต่แรกมันคงทำให้ถูกต้องจริง ๆ ได้ยาก
      ปกติไม่ค่อยคอมเมนต์เชิงลบกับบริการไหน แต่แม้ส่งหลักฐานเป็นวิดีโอไปแล้ว ฝั่งซัพพอร์ตก็ยังตอบเหมือนเราทำอะไรแปลก ๆ ซึ่งสำหรับบริษัทด้านอินฟราฯ ถือว่าน่าหงุดหงิดมาก ตอนนี้เลยไม่แนะนำแล้วนอกจากแอปเล่น ๆ
      ผมก็เคยสร้างระบบ deploy สำหรับ Kubernetes ที่ค่อนข้างใหญ่เหมือนกัน ดังนั้นนี่ไม่ใช่คำพูดจากคนที่ไม่รู้จัก Kubernetes แน่ ๆ ตลาดสำหรับ การ deploy แบบ Heroku ที่ทำได้ดีจริง ยังมีอยู่ชัดเจน แต่ตอนนี้ยังไม่มีใครทำได้ดี หรือไม่ก็ทรัพยากรคอมพิวต์น้อยเกินไปแบบไม่น่าเชื่อหรือราคาแพงเกินไป
    • รบกวนส่งอีเมลมาที่ @fly.io โดยใช้ตัวอักษร 2 ตัวแรกของชื่อผู้ใช้ไว้ข้างหน้า อยากดูว่าเจอปัญหาอะไรบ้างและอยากช่วยปรับปรุงสถานการณ์ในแบบที่พอทำได้
    • ใช่เลย ความน่าเชื่อถือและซัพพอร์ต แย่มาก ครั้งหนึ่ง deploy ไม่ได้อยู่ 2 วัน แล้วสุดท้ายก็ได้รับคำตอบให้ไปใช้บริษัทอื่นจริง ๆ
      ยังมีเรื่องฐานข้อมูลแบบ unmanaged ที่ถูกแพ็กเกจให้ดูเหมือน managed, downtime แบบสุ่ม และอีกหลายอย่าง แต่ผมย้ายออกมาเมื่อหลายเดือนก่อนเพราะมันยังไม่ใช่บริการที่พร้อมสำหรับโปรดักชัน
    • น่าเสียดายแต่นี่เป็นแพตเทิร์นที่พบได้ค่อนข้างบ่อย ในบรรดาคนรู้จักที่เริ่มใช้ Fly มีประมาณครึ่งหนึ่งที่ย้ายออกไปที่อื่น
      ตอนแรกผมคาดหวังกับ Fly มาก ถึงขั้นสร้าง orchestrator ทั้งตัวบน Fly Machines แต่ก็เจอ เหตุขัดข้องยาวหลายวัน และกว่าจะได้คำตอบก็ใช้เวลาหลายวันเหมือนกัน
      Kubernetes อาจซับซ้อน แต่ความซับซ้อนนั้นอย่างน้อยก็ยังควบคุมได้ และเป็นเส้นทางที่ผ่านการพิสูจน์มาแล้วมากมาย
    • ผมรันหลายบริการบน Fly มาเกือบ 1 ปีแล้ว และยังไม่เจอปัญหาอะไร

  • ผมเป็นผู้เขียนโพสต์และเป็น Developer Relations ของ Fly.io ถ้ามีคำถามก็ยินดีตอบ GPU เปิดให้ใช้งานจริงอย่างเป็นทางการ เมื่อวานนี้ และถ้าเทพแห่งอัลกอริทึมป้องกันการฉ้อโกงอนุญาต ก็ทดลองกันได้เต็มที่เลย
    กลับกัน ผมแปลกใจที่บทความอธิบายว่า “GPU” จริง ๆ คืออะไร ไม่ค่อยได้รับความสนใจที่นี่: https://fly.io/blog/what-are-these-gpus-really/

    • อยากรู้ความเห็นเรื่อง การทำ inference บนฮาร์ดแวร์ของ Apple โดยเฉพาะ ผมใช้เวลาเยอะมากกับการปรับ local inference บน Apple Silicon แบบ on-premise หรือสภาพแวดล้อมบนโต๊ะทำงาน และถึงจะนับรวมงานที่ลงไปกับฝั่งอย่าง GGUF แล้ว ผมก็ยังคิดว่ายังมีพื้นที่ให้ไปได้อีกมาก
      ข้อได้เปรียบด้าน process node และการเข้าถึง SoC/HBM ก่อน จะอยู่นานพอให้ซอฟต์แวร์ตามทันไหม? อุปกรณ์ Metal ระดับสูงของ Apple ดูแพงก็จริง แต่พอเทียบกับ NVIDIA ที่มีแบนด์วิดท์หน่วยความจำระดับสูงพอสมควรในกลุ่ม 64GB+ พร้อม FP vector unit เฉพาะทาง ภาพมันก็ดูต่างออกไป
      ถ้าแพลตฟอร์มอย่าง fly.io สามารถย้าย workload สำหรับ inference เข้าออกจากอุปกรณ์ได้ ก็น่าจะให้อิสระกับแอปพลิเคชันที่เน้น edge ได้มากทีเดียว
    • จังหวะพอดีเลย กำลังประเมิน บริการ GPU แบบ serverless สำหรับโปรเจกต์ที่จะมาถึง เห็นจากประกาศว่าคิดเงินรายชั่วโมง เลยสงสัยว่าตอน scale down เป็น 0 จะคิดเป็นนาที/วินาทีไหม
      ใน workflow สำหรับ segmentation ภาพทางการแพทย์ ใช้เวลาประมาณ 5 นาทีต่อไฟล์
    • ยินดีกับการเปิดตัว แต่ก็สงสัยว่า กลุ่มผู้ใช้เป้าหมาย ของบริการนี้คือใคร เป็นการใช้งานหลักสำหรับลูกค้า fly.io เดิมที่อยากอยู่ภายใน sandbox ของ fly.io ต่อไปหรือเปล่า?
    • อยากรู้ว่า cold start เร็วแค่ไหน และถ้าเทียบกับผู้ให้บริการ GPU รายอื่นอย่าง runpod หรือ modal แล้วเป็นอย่างไร
    • ไม่ใช่คำถาม แต่ลิงก์ “Lovelace L40s are coming soon (pricing TBD)” ขึ้น 404

  • เท่าที่ทราบ Fly ใช้ Firecracker กับ VM ผมติดตาม Firecracker มาพักหนึ่งและเคยใช้ในโปรเจกต์ด้วย ซึ่งโดยพื้นฐานแล้วมันไม่รองรับ GPU และก็ไม่มีแผนจะรองรับด้วย [1]
    เลยอยากรู้ว่า Fly แก้โจทย์การรองรับ GPU เองบน Firecracker อย่างไร เมื่อก่อนพวกเขาเคยเขียนบทความเทคนิคละเอียดมากเกี่ยวกับการทำฟีเจอร์บางอย่าง หวังว่าคราวหลังจะมีบทความเกี่ยวกับการรองรับ GPU ออกมาด้วย
    [1]: https://github.com/firecracker-microvm/firecracker/issues/11...

    • สรุปสั้น ๆ คือเครื่อง GPU ไม่ได้ใช้ Firecracker แต่ใช้ Cloud Hypervisor

  • การที่รองรับ scale down จนเหลือ 0 ได้เป็นเรื่องเจ๋งมาก มีประโยชน์มากโดยเฉพาะกับการทำเว็บทดลองที่มีผู้ใช้น้อยจนยากจะอธิบายต้นทุนของเซิร์ฟเวอร์เล็ก ๆ ได้
    อยากเห็นตัวอย่างว่าคำขอหนึ่งครั้งจะถูกคิดค่าใช้จ่ายเป็นเวลาประมาณไหน แน่นอนว่าคงต่างกันไป แต่สงสัยว่าเป็น 2 วินาที หรือแบบ “ขั้นต่ำ 60 วินาทีต่อการ spin up”

    • คิดเงินตั้งแต่ตอนบูตเครื่องจนถึงตอนหยุด ไม่มีเวลาขั้นต่ำแบบบังคับ แต่โดยทั่วไปแล้วถ้าน้อยกว่า 5 วินาทีก็มักยากที่จะให้เครื่องทำงานที่มีความหมายได้
      สำหรับเครื่อง GPU อาจต้องรัน ราว 30 วินาที กว่าจะเริ่มคุ้มค่าใช้งาน ทั้งนี้ขึ้นกับขนาดข้อมูลที่จะต้องโหลดเข้าไปในหน่วยความจำของ GPU

  • แม้จะเริ่มใช้ Fly.io ตั้งแต่ช่วงแรก แต่ ยังไม่พร้อมสำหรับ production ควรแก้ฟีเจอร์พื้นฐานให้เรียบร้อยก่อนค่อยเพิ่มฟีเจอร์ใหม่

    • น่าเสียดายแต่ก็เป็นเรื่องจริง ตอนแรกคาดหวังกับผลิตภัณฑ์นี้มาก แต่สุดท้ายก็เลิกใช้ fly.io และกลับไปใช้ App Platform ของ DigitalOcean
      ถึงจะต้องตั้งค่าเพิ่มอีกหน่อยและราคาก็แพงกว่าพอสมควร แต่ใน production ต้องการ ความเสถียร ปล่อยให้ลูกค้าโทรมาเพราะบริการล่มไม่ได้
    • ในบรรดาบริการที่ “ดูดีภายนอก” นี่เป็นโฮสติงที่ไม่นิ่งที่สุดเท่าที่เคยใช้มา หลายอย่างพังพร้อมกันบ่อยมาก ขณะที่หน้า status ก็ยังเขียวตลอด จนทั้งเวลางานประชุมและวันหยุดสุดสัปดาห์พังไปหมด
      ซอฟต์แวร์จะพังก็เข้าใจได้ แต่ท่าทีของ Fly ในการรับมือ incident นั้นไม่เป็นมืออาชีพและยังไม่เป็นผู้ใหญ่พอ โดยพื้นฐานคือจ่ายแพงกว่า 10 เท่าเพื่อบริการที่ไม่เสถียรแต่ “หน้าตาดี”
      ตอนนี้ใช้ Hetzner + Kamal ได้ฮาร์ดแวร์ดีกว่ามากในราคาแค่หนึ่งในสี่ ทำงานเสถียร ราคาคาดเดาได้ และไม่มีเรื่องเดือนหน้าจ่ายเพิ่มอีก 25% ทั้งที่ใช้เท่าเดิม
      https://news.ycombinator.com/item?id=36808296
    • เสียดายที่เห็นคอมเมนต์แบบนี้บน HN มันไม่ค่อยสร้างสรรค์นัก ควรระบุให้ชัดว่า ฟีเจอร์พื้นฐาน ที่ว่าคืออะไร และต้องแก้อะไรบ้าง

  • แยกจากเรื่องการเปิดตัว GPU ก็อยากให้ Fly มี บริการทดแทน S3 ด้วย ตอนนี้กลับไปแนะนำโปรเจกต์ GNU Affero ซึ่งสำหรับฝั่งองค์กรถือเป็นอุปสรรค
    ถ้าต้องออกจาก Fly เพื่อเก็บ asset ของผู้ใช้ ก็จะทำให้ใช้ Fly ในโปรเจกต์ถัดไปได้ยากขึ้น ชอบความเรียบง่าย ความคุ้มค่า และ VPN ที่มีมาให้ในตัว เลยยิ่งน่าเสียดาย

    • อาจสนใจ Tigris preview: https://www.tigrisdata.com/
      มีพูดถึงที่นี่ด้วย: https://benhoyt.com/writings/flyio-and-tigris/ และที่นี่: https://news.ycombinator.com/item?id=39360870
      https://fly.io/docs/reference/tigris/
    • การเป็น AGPL ไม่ได้แปลว่าต้องเปิดเผยทุกอย่างที่สร้างอยู่บนบริการนั้น จะเกี่ยวเฉพาะส่วนที่ลิงก์เข้ากับมันและการแก้ไขในส่วนนั้นเท่านั้น
      ถ้าเข้าถึงบริการแบบ S3 ผ่าน HTTPS API อย่างเดียว โค้ดของคุณก็จะไม่ถูก AGPL ครอบไปด้วยเพราะเหตุนี้
    • ตอนนี้มี บริการทดแทน S3 ที่รับรู้ภูมิภาค แบบเบต้าอยู่: https://community.fly.io/t/global-caching-object-storage-on-...
    • เร็ว ๆ นี้จะมีบริการทดแทน S3 ชื่อ Tigris เป็นอีกบริษัทหนึ่งต่างหาก แต่จะถูกรวมเข้ากับ flyctl และทำงานบนโครงสร้างพื้นฐานของ Fly.io: https://benhoyt.com/writings/flyio-and-tigris/
    • พูดถึงเรื่องนี้พอดีเลย: https://news.ycombinator.com/item?id=39360870

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

    • มีไอเดียบางอย่าง แต่ยังไม่มีคำตอบที่ชัดเจน น่าจะเป็นคนที่กำลังสร้าง แพลตฟอร์มโฮสติง มั้ง อะไรที่ภายนอกอาจดูไม่เหมือนแพลตฟอร์มโฮสติง แต่จริง ๆ แล้วใช่
    • Fly คือ เครือข่าย edge ในทางทฤษฎี ถ้า GPU อยู่ข้างเซิร์ฟเวอร์ และเซิร์ฟเวอร์อยู่ใกล้ผู้ใช้ แอปก็อาจเร็วมากอย่างที่บทความเน้นไว้
      แต่ในความเป็นจริง inference เองใช้เวลานานอยู่แล้ว ความต่างนั้นอาจไม่ได้สำคัญมากนัก
    • สรุปคือมีเหตุผลเล็ก ๆ หลายข้อที่อาจทำให้สนใจ Fly GPU โดยเฉพาะถ้าใช้งาน Fly อยู่แล้ว แต่ถ้ารันอยู่บนคลาวด์อื่นอยู่แล้ว ก็ยังไม่มีเหตุผลเด็ดขาดเพียงข้อเดียว
      ถ้างาน GPU อยู่ในดาต้าเซ็นเตอร์เดียวกัน หรืออย่างน้อยอยู่กับผู้ให้บริการคลาวด์เดียวกัน ก็อาจเป็นข้อได้เปรียบมาก เคยเจอ A100 หมดในหลายผู้ให้บริการอยู่บ่อย ๆ และแม้แต่ผู้ให้บริการรายใหญ่ก็เจอมาแล้วหลายครั้ง ถ้าไม่ได้ผูกกับรีเจียนใดรีเจียนหนึ่งก็จะเป็นปัญหาน้อยลง
      ไม่ใช่ทุกผู้ให้บริการที่จะมีโมเดล on-demand แบบ scale down เป็น 0 ที่ใช้งานได้ดี ไม่รู้ว่าระยะยาว Fly จะทำได้ดีแค่ไหน แต่อาจเป็นข้อดีอีกข้อหนึ่ง
      สตาร์ตอัปสายแข่งราคามักอยู่ไม่รอดนาน โครงสร้างแทบจะเป็นแบบอยู่รอดจริงแค่ไม่กี่รายจาก 100 ราย
      ถ้าใช้งาน Fly อยู่แล้ว และแค่ประเมินเดโมเทคโนโลยีแบบปิดเป็นครั้งคราว Fly GPU ก็อาจเป็นตัวเลือกเริ่มต้นที่แทบไม่ต้องคิดมาก แน่นอนว่าการไปใช้บริการของ Hugging Face อาจเป็นทางเลือกที่พบได้บ่อยกว่า
      หลายบริษัทก็มีเหตุผลหลายอย่างที่ทำให้ดูแลฮาร์ดแวร์เองไม่ได้ อย่างเก่งก็แค่ไปเช่าแร็กในดาต้าเซ็นเตอร์อื่น ซึ่งสำหรับ use case เล็ก ๆ ก็ไม่ได้คุ้มค่าเสมอไป บางกรณีต้องใช้ A100 แต่รันไม่บ่อย เช่น งานวิเคราะห์รายสัปดาห์ ถ้าใช้น้อยกว่าชั่วโมงต่อสัปดาห์ บริการสายแข่งราคาก็อาจไม่ได้ดึงดูดนัก
    • ฝั่งบริการโฮสติงนั้นดูเหมือนจะยังไม่เกิด การแข่งขันกดราคาจนติดพื้น เท่าไร ส่วนใหญ่แพงกว่า GCP หลายเท่า และราคา public ของ GCP เองก็สูงกว่าราคาที่ลูกค้าองค์กรจ่ายจริงอยู่หลายเท่าแล้ว

  • ไม่ว่าจะเป็นตัวอย่างสูตรอาหารหรือ use case ของ LLM แบบไหนก็ตาม ดูเป็นตัวอย่างที่แย่มากสำหรับการเน้น edge inference เพราะต่อให้ latency ไปกลับเพิ่มอีกหลายร้อย ms ก็แทบไม่กระทบอะไร

    • use case ที่ดีกว่าน่าจะเป็น ผู้ช่วยเสียง บน edge อย่างชัดเจน ใน workflow แบบ เสียง→ข้อความ→ค้นหา/GPT→สร้างเสียงตอบกลับนั้น ระดับ ms มีความสำคัญ
      เพียงแต่เป็นพื้นที่ที่เสี่ยงต่อการถูกนำไปใช้ในทางที่ผิดสูง เลยดูเหมือนว่ายังไม่มีใครอยากเข้าไปยุ่งนัก น่าจะมีพูดถึงในบทความถัดไป และถ้าเป็นแบบนั้นก็คงต้องสร้าง GPT ออนไลน์สไตล์ Perplexity เอง ตอนนี้เหมือนจงใจเปิดตัวแบบธรรมดา ๆ เพื่อดูว่าจะมีไอเดียอื่นโผล่มาไหม
    • เห็นด้วย นึก กรณีใช้งานทางธุรกิจ สำหรับการรัน LLM บน edge ไม่ออกเลย นี่คือช่วงเวลาแบบ Pets.com ของวงการ AI หรือเปล่า?

  • อยากรู้ว่ามีใครเคยลองใช้ประสิทธิภาพแล้วบ้างไหม ความรู้สึกแรกคือดูค่อนข้างแพง ตัวอย่างเช่นเมื่อเทียบกับเครื่อง CPU ของ Hetzner

    • ที่อื่นไม่แน่ใจ แต่บน DigitalOcean สามารถใช้ A100 รุ่น RAM 90GB ได้ในราคา 1.15 ดอลลาร์ต่อชั่วโมง ถูกกว่าประมาณ 3 เท่า
      แม้แต่ H100 ก็ยังหาได้ถูกกว่านี้ที่ 2.24 ดอลลาร์ต่อชั่วโมง
      เลยทำให้ดูค่อนข้างแพง แต่ก็อาจเป็นเพราะความต้องการของลูกค้าสูงและอุปทานไม่พอ

  • กำลังรัน Uptime Kuma บน free tier ของ Fly.io เพื่อมอนิเตอร์ uptime อยู่ ทำงานได้ดีมากและพอใจมาก

    • แล้วถ้า Uptime Kuma ล่ม จะได้รับการแจ้งเตือนจากอะไร?