Groq รัน Mixtral 8x7B-32k ที่ 500 T/s

• ในสถานการณ์ที่ความเร็วในการตอบสนองและต้นทุนการอนุมานกลายเป็นคอขวดของบริการ AI นั้น Groq ชูจุดเด่นด้าน โครงสร้างพื้นฐานสำหรับการอนุมานที่รวดเร็วและมีต้นทุนต่ำ อย่างชัดเจน
• จุดแตกต่างคือไม่ได้ใช้แนวทางที่มี GPU เป็นศูนย์กลาง แต่ใช้ สแตกที่อิง LPU ซึ่งพัฒนามาเพื่อการอนุมานโดยเฉพาะตั้งแต่ปี 2016
• GroqCloud ให้บริการสแตก LPU ในดาต้าเซ็นเตอร์ทั่วโลกเพื่อมอบค่าหน่วงต่ำ และระบุว่ามี นักพัฒนาและทีม 3 ล้านราย ใช้งาน
• นักพัฒนาสามารถเชื่อมต่อได้ค่อนข้างง่ายด้วยการเปลี่ยนเพียง base_url และ GROQ_API_KEY ในไคลเอนต์ที่รองรับ OpenAI
• Fintool ระบุว่าหลังนำ GroqCloud มาใช้ ความเร็วแชตเพิ่มขึ้น 7.41 เท่า และต้นทุนลดลง 89% ขณะที่ McLaren Formula 1 Team ก็เลือก Groq เป็นพาร์ตเนอร์ด้านการอนุมาน

---

แพลตฟอร์มการอนุมานที่รวดเร็วและต้นทุนต่ำ

• Groq มองว่า การอนุมาน (inference) คือเชื้อเพลิงหลักของ AI และชูแพลตฟอร์มการอนุมานที่รวดเร็วและมีต้นทุนต่ำซึ่งทำงานได้อย่างเสถียรในเวิร์กโหลดจริง
• ข้อความหลักบนหน้าเว็บไซต์ใกล้เคียงกับ “การอนุมานที่รวดเร็วและต้นทุนต่ำซึ่งไม่สะดุดแม้ในสถานการณ์จริง”
• บริษัทก่อตั้งในปี 2016 และอธิบายว่าจุดประสงค์ในการก่อตั้งคือ โฟกัสที่การอนุมานเพียงอย่างเดียว

สแตกเฉพาะสำหรับการอนุมานที่สร้างด้วย LPU

• Groq แตกต่างจากผู้เล่นรายอื่นที่พึ่งพา GPU โดยใช้ซิลิคอนของตัวเองเป็นจุดแข็งหลัก
• บริษัทบอกว่าเป็นผู้บุกเบิก LPU ในปี 2016 และอธิบายว่านี่คือชิปตัวแรกที่สร้างมาเพื่อการอนุมานโดยเฉพาะ
• การออกแบบของ LPU มุ่งเน้นให้การตอบสนองของโมเดลอัจฉริยะยังคงรวดเร็วและมีต้นทุนต่ำ
• ด้วยข้อความว่า “สิ่งที่ถูกนำไป deploy จริงคือเวิร์กโหลด ไม่ใช่เบนช์มาร์ก” บริษัทจึงเน้นย้ำสภาพแวดล้อมการใช้งานจริง

ดาต้าเซ็นเตอร์ทั่วโลกและ GroqCloud

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

การเชื่อมต่อสำหรับนักพัฒนาที่เข้ากันได้กับ OpenAI

• Groq เน้นการเชื่อมต่อแบบเข้ากันได้กับ OpenAI และระบุว่าสามารถสลับมาใช้ได้ด้วย “สองบรรทัด”
• ตัวอย่าง Python ตั้งค่าต่อไปนี้ในไคลเอนต์ openai.OpenAI
  • base_url="https://api.groq.com/openai/v1";
  • api_key=os.environ.get("GROQ_API_KEY")
• นักพัฒนาสามารถเริ่มต้นจากคอนโซลของ Groq หรือขอรับ API key ฟรีเพื่อใช้งานได้

กรณีลูกค้าและพาร์ตเนอร์ชิป

• McLaren Formula 1 Team ถูกยกเป็นกรณีพาร์ตเนอร์ที่เลือก Groq สำหรับการอนุมานระดับโลก
• McLaren F1 Team เลือก Groq สำหรับการตัดสินใจ การวิเคราะห์ การพัฒนา และอินไซต์แบบเรียลไทม์
• Kevin Scott, CTO ของ PGA of America กล่าวว่า งานที่ให้ความสำคัญกับประสิทธิภาพมากกว่าจะใช้ Groq
• Nicolas Bustamante, CEO ของ Fintool กล่าวว่า หลังนำ GroqCloud มาใช้ ได้พบการเปลี่ยนแปลงดังนี้
  • ความเร็วแชตเพิ่มขึ้น 7.41 เท่า
  • ต้นทุนลดลง 89%
  • ปริมาณการใช้โทเคนเพิ่มขึ้น 3 เท่า
• Abhigyan Arya, CTO ของ Opennote ระบุว่า Groq ช่วยลดต้นทุนและภาระด้านปฏิบัติการ และช่วยให้สามารถรักษาราคาของแพ็กเกจพรีเมียมสำหรับนักเรียนให้อยู่ในระดับเหมาะสมได้

ข่าวที่เผยแพร่พร้อมกัน

• Groq Raises $750 Million as Inference Demand Surges: รายการวันที่ 17 กันยายน 2025
• Day Zero Support for OpenAI Open Models: รายการวันที่ 5 สิงหาคม 2025
• From Speed to Scale: How Groq Is Optimized for MoE & Other Large Models: รายการวันที่ 27 พฤษภาคม 2025

[GN⁺]

ความคิดเห็นจาก Hacker News

• นี่เป็นหนึ่งในเดโมเทคโนโลยีที่น่าประทับใจที่สุดเท่าที่เคยเห็นมา และที่ชอบคือมันเป็น เดโมสาธารณะของจริง ที่ใครก็ลองใช้ได้ทันทีโดยไม่ต้องสมัคร
  การได้เห็นโทเคนไหลออกมาด้วยความเร็วบ้าคลั่งนั้นเหนือจริงมาก และยิ่งน่าตกใจเพราะปกติคุ้นกับความเร็วที่ช้ากว่านี้ไม่ถึง 1/5 ด้วยซ้ำ แปลกใจที่ยังไม่ถูกซื้อกิจการโดย Microsoft, Apple, Google หรือที่คล้ายกันด้วยพรีเมียมก้อนใหญ่

  • ถ้าเข้าใจถูก หมายความว่าชิปแต่ละตัวมีแรม 200MB เลยต้องใช้หลายแร็กเพื่อรัน LLM เดี่ยวหนึ่งตัว ซึ่งฟังดูไม่เหมือนความก้าวหน้าเท่าไร
    น่าจะต้องมีบอร์ด PCIe เดี่ยวที่ใส่แรมระดับหลายสิบถึงหลายร้อย GB พร้อมโปรเซสเซอร์ที่จัดการมันได้ดี
  • Perplexity Labs ก็มีเดโมสาธารณะของ Mixtral 8x7b แต่ไม่เร็วขนาดนี้
    https://labs.perplexity.ai/
  • อยากรู้จริง ๆ ว่าทำไมมันถึงยอดเยี่ยมขนาดนั้น เพราะยังไม่เข้าใจ
    ประเด็นสำคัญคือ TFLOPS/$ และ TFLOPS/W เป็นเท่าไร และเทียบกับ Nvidia, AMD, TPU อย่างไร ลองค้นคร่าว ๆ เหมือนว่า Groq อ้างอะไรคล้าย ๆ แบบนี้มาตั้งแต่ปี 2020 แล้ว แต่ผู้คนก็ยังยอมจ่ายพรีเมียมสูงให้ Nvidia อยู่ และ Groq ก็ดูไม่ได้สั่นคลอนตลาดนั้นมากนัก ถ้านำโมเดลที่เล็กกว่า ChatGPT มากมารันบนฮาร์ดแวร์ที่ใกล้เคียงกันหรือแรงกว่า มันก็อาจเร็วขึ้นได้ แต่นั่นไม่ได้แปลว่าเป็นจุดเปลี่ยนสำหรับโมเดลหรือกรณีใช้งานส่วนใหญ่ที่เวลาแฝงไม่ใช่ตัวชี้วัดหลัก
  • ทำไมต้องขายด้วย? ดูเหมือนการเอาชนะพวกเขาในเกมของพวกเขาเองจะสนุกกว่ามาก

• ปัญหาหลักของ Groq LPU คือ ไม่มี HBM เลย และมีเพียง SRAM ความเร็วสูงมากขนาดเล็ก 230MiB เท่านั้น
  มันเร็วกว่า HBM3 อยู่ 20 เท่าจริง แต่ก็เลยต้องใช้ LPU ราว 256 ตัว หรือระดับ 4 แร็กเซิร์ฟเวอร์ เพื่อให้บริการโมเดลเดี่ยวหนึ่งตัว ขณะที่ H200 ตัวเดียวก็ให้บริการโมเดลแบบนี้ได้ค่อนข้างสมเหตุสมผล ถ้าเป็นโมเดลเดี่ยวที่มีลูกค้าเยอะก็อาจเหมาะ แต่พอถึงจุดที่ต้องมีหลายโมเดลและมีการฟाइनจูนจำนวนมากกับ LoRA อันดับสูงจำนวนมาก มันก็ใช้งานยากขึ้น และยังไม่เหมาะกับการติดตั้งแบบ on-premise ด้วย เพราะจุดเด่นหลักคือการรวมผู้ใช้จำนวนมากมาใช้โมเดลเดียวกัน
  https://wow.groq.com/groqcard-accelerator/
  https://twitter.com/tomjaguarpaw/status/1759615563586744334

  • ในมุมวิศวกรของ Groq ผมไม่ค่อยเข้าใจว่าทำไมการ ขยายการประมวลผล ออกไปนอกการ์ดเดี่ยวหรือโหนดเดี่ยวถึงถูกมองว่าเป็นปัญหา
    ผมชอบอุปมาเรื่องโรงงานรถยนต์ คุณสร้างรถได้ด้วยสว่านหนึ่งหรือสองตัว แต่โรงงานอัตโนมัติสมัยใหม่มีสว่านเป็นร้อย ถ้ามีสว่านตัวเดียว คุณอาจสร้างรถได้หลายแบบ แต่สายการประกอบในโรงงานจะสร้างได้เฉพาะรถที่มีสเปกแบบหนึ่งเท่านั้น ซึ่งไม่ได้แปลว่าโรงงานไม่มีประสิทธิภาพ ส่วนที่ว่าพวก H200 ทำงานได้ค่อนข้างดีนั้น อาจสมเหตุสมผลสำหรับงานปฏิสัมพันธ์กับมนุษย์แบบ synchronous แต่ก็ยังถกเถียงกันได้ ผมอยากเห็นตัวอย่างจาก Nvidia ที่โมเดลขนาด 30B+ พารามิเตอร์ทำ RAG ระหว่างสนทนาและยังตอบกลับด้วยเสียงได้ภายใน 1 วินาที
  • Groq ระบุในบทความว่าใช้ 576 ชิป เพื่อให้ได้ผลลัพธ์นี้
    ยังต้องคิดเพิ่มด้วยว่าแต่ละผู้ใช้ต้องมี KV cache แยกต่างหาก ซึ่งอาจเพิ่มอีกหลาย GB ต่อผู้ใช้ ในฐานะคนนอกที่ประเมินแบบมืออาชีพ ผมมองว่าต้นทุนขายของระบบที่ทำตัวเลขประสิทธิภาพแบบนี้ได้น่าจะเกินหลายล้านดอลลาร์ และการจะตัดค่าเสื่อมตามการใช้งานที่คาดไว้เพื่อให้ลงกับราคาทฤษฎีที่เปิดเผยออกมาดูไม่สมจริง จากมุมมองของประสิทธิภาพจริงต่อดอลลาร์ มันดูไม่น่าจะใช้งานได้จริงนัก แต่ถ้าไม่สนต้นทุน มันก็เป็นเดโมที่เจ๋งมากและแสดงประสิทธิภาพระดับบ้าคลั่งจริง
    https://www.nextplatform.com/2023/11/27/groq-says-it-can-dep...
  • ถ้าเป้าหมายคือเวลาแฝงต่ำ ต้องระวัง HBM ให้มาก ไม่ใช่แค่เรื่องเวลาแฝงเอง แต่ ความไม่เป็นดีเทอร์มินิสติก ก็เป็นปัญหาด้วย
    ข้อดีใหญ่ของสถาปัตยกรรม LPU คือสามารถสร้างระบบหลายร้อยชิปด้วยอินเตอร์คอนเนกต์ที่เร็ว และยังรู้จังหวะเวลาที่แน่นอนของทั้งระบบได้ถึงระดับ ppm พอเริ่มใส่องค์ประกอบที่ไม่เป็นดีเทอร์มินิสติก การรับประกันเรื่องเวลาแฝงก็จะหายไปอย่างรวดเร็ว
  • อุปกรณ์ของ Groq เหมาะมากกับ การอนุมานแบบแบตช์ขนาดเล็ก เพราะมี SRAM
    แต่ผมยังไม่แน่ใจว่ามันได้เปรียบด้านโทเคน/วินาที/ดอลลาร์หรือไม่ โดยเฉพาะสำหรับผู้ใช้แบตช์ขนาดกลางถึงใหญ่ที่ซื้อซิลิคอนจำนวนมากได้ ตามสถาปัตยกรรมแล้ว Groq ดูไม่น่าจะเร็วขึ้นเมื่อขนาดแบตช์เกิน 1 ไปแล้ว ขณะที่การ์ดของ Nvidia น่าจะเพิ่ม throughput ได้อย่างมีนัยสำคัญเมื่อขนาดแบตช์ขึ้นไปถึงระดับ 100
  • อาจมีวิธีที่ทำให้ใส่โมเดลฐานหนึ่งตัวกับ LoRA หลายตัวได้ โดยแทบไม่ใช้แรมมากไปกว่าที่ใช้กับโมเดลฐานเพียงตัวเดียว
    เช่น ฟाइनจูนโดยเปลี่ยนน้ำหนักเพียงประมาณ 0.1% และในแต่ละการคำนวณค่อยคำนวณความต่างของค่า activation ในชั้นเอาต์พุต แทนที่จะคำนวณความต่างของน้ำหนัก

• ภายนอกดูน่าประทับใจมาก แต่หากไม่มีเบนช์มาร์กก็ควรตั้งข้อสงสัยไว้พอสมควร
  เพราะมีวิธีอ้อมหลายแบบ เช่น การทำ quantization แบบหนัก ที่ยอมลดคุณภาพลงเพื่อเพิ่มความเร็ว หากไม่ใช่แบบนั้น ก็อยากเห็นพัฒนาการของ LLM token/วินาทีดำเนินต่อไปเหมือนกับคำสั่ง CPU/วินาทีเมื่อหลายสิบปีก่อน

  • เห็นด้วยกับท่าทีแบบนักวิทยาศาสตร์ที่ควรเข้าหาเรื่องนี้ด้วยความสงสัยเป็นพื้นฐาน
    ตอนนี้เปิดทั้งแอปแชตและ API ให้ทุกคนลองใช้ และเปรียบเทียบคุณภาพเอาต์พุตกับผู้ให้บริการรายอื่นได้
  • อย่างที่ tome พูดไว้ก่อนหน้านี้ เราไม่ได้ทำ quantization และค่า activation ทั้งหมดเป็น FP16
    มีเบนช์มาร์กอิสระด้วย: https://artificialanalysis.ai/models/llama-2-chat-70b
  • ในเดโม Llama 70B ก่อนหน้านี้ก็อ้างว่ารันแบบไม่ทำ quantization
    https://twitter.com/lifebypixels/status/1757619926360096852
    แต่ในคอมเมนต์นี้กลับบอกว่า “ข้อมูลบางส่วนถูกเก็บเป็น FP8 ตอนบันทึก” ซึ่งไม่แน่ใจว่าหมายถึงอะไรแน่: https://news.ycombinator.com/item?id=39432025
  • ตอนทำเบนช์มาร์กกับ Groq มีการถามว่าใช้ quantization หรือไม่ และได้รับการยืนยันว่ารันโมเดลแบบ FP-16 เต็มรูปแบบ
    เป็นจุดที่ควรถามและสำคัญมาก ลิงก์เบนช์มาร์ก: https://artificialanalysis.ai/
    คำถามนี้ถามถึง API ไม่ใช่เดโมแชต
  • อาจจะเป็นการฝืนอุปมาเกินไป แต่ LLM เข้าสู่ยุคทรานซิสเตอร์แล้วหรือยัง?
    พอมองสัตว์ประหลาดขนาด 70B พารามิเตอร์ ก็ยังเหมือนกำลังสร้าง ENIAC ด้วยหลอดสุญญากาศอยู่ กล่าวคือสงสัยว่า ตอนนี้เราอยู่ในจุดที่พร้อมจะปรับปรุง LLM token/วินาทีอย่างสม่ำเสมอทุกปีแล้วหรือยัง หรือก่อนหน้านั้นยังต้องมีการทะลุข้อจำกัดครั้งใหญ่อีกสักหนึ่งหรือสองครั้ง

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

  • อาจเป็นบั๊กของเว็บอินเทอร์เฟซ แต่ผมป้อนพรอมป์ต์ให้โมเดล Mixtral และได้คำตอบแล้ว จากนั้นเปลี่ยนดรอปดาวน์เป็น Llama แล้วป้อนพรอมป์ต์เดิมอีกครั้ง ปรากฏว่าได้ คำตอบเหมือนกันทุกประการ
    อาจเป็นแคช หรือโมเดลที่ถูกเรียกจริงไม่ได้เปลี่ยน หรืออาจเป็นอย่างอื่น
  • Haskell ดูเป็นทางเลือกที่ค่อนข้างแปลกในสายแมชชีนเลิร์นนิง
    อยากรู้ว่าการเลือกนี้มีข้อดีพิเศษอะไรไหม และแนะนำให้ทีมอื่นใช้ตามได้หรือเปล่า รวมถึงอยากรู้ว่าส่วนไหนของโปรเจกต์ใช้ Haskell และส่วนไหนไม่ใช้
  • เท่าที่เข้าใจคือกำลังใช้ฮาร์ดแวร์เฉพาะทางเพื่อเร่งความเร็วการสร้างโทเค็น ซึ่งการสร้างโทเค็นนั้นผูกกับ latency ของความเร็วการคำนวณอย่างมาก
    แต่โดยปกติการสร้างโทเค็นต้องใช้แค่การคูณเมทริกซ์หนึ่งมิติ อย่างไรก็ตามพอใส่พรอมป์ต์ยาวประมาณ 100 โทเค็น บริการกลับช้าลงมาก ซึ่งเดาว่าน่าจะเพราะต้องคูณเมทริกซ์สองมิติ เลยสงสัยว่ากำลังทำอะไรอยู่เพื่อเพิ่มความเร็วการคำนวณในช่วง การประมวลผลพรอมป์ต์
  • ดูเหมือนเป็นหนึ่งในไม่กี่บริษัทที่มุ่งเป้าไปที่การอนุมานแบบ latency ต่ำจริงจัง และไม่ได้โฟกัสแค่ throughput กับต้นทุนต่อการอนุมานที่ตามมา
    เลยอยากรู้ว่ามองตลาดหลักไว้ที่ไหน
  • ขอบคุณสำหรับ AMA อยากรู้ว่าต้องใช้ GroqCard กี่ใบในการรันเดโม และใช้รุ่นใหม่กว่าที่มี SRAM มากกว่า 230MB ตามที่เห็นออนไลน์หรือไม่
    คิดว่าตัวเลขนี้น่าจะมีผลต่อการใช้ประโยชน์จากการประมวลผลแบบแบตช์และการลดต้นทุน นอกจากนี้ถ้าสามารถรวม TTS pipeline เข้าไปในสแตกได้ ก็น่าจะทำให้เกิดการโทรที่มี latency ต่ำมากได้จริง สมมติว่าใช้ผลิตภัณฑ์นี้อยู่: https://www.bittware.com/products/groq/

• เป็นเดโมที่น่าประทับใจ
  แต่ด้วยข้อกำหนดด้านฮาร์ดแวร์และต้นทุน ดูเหมือนว่าจะเข้าถึงได้ยากหากไม่ใช่บริษัทใหญ่ เลยอยากรู้ว่าคิดว่าระดับราคาที่นักพัฒนาแบบงานอดิเรกพอจ่ายไหวจะเป็นไปได้เมื่อไร เดโม CNN Vapi ก็น่าประทับใจ แต่ https://smarterchild.chat/ ที่แชร์กันเมื่อไม่กี่สัปดาห์ก่อนก็สนทนาได้เป็นธรรมชาติด้วย latency เสียงที่ต่ำมากเช่นกัน จากการคุยกันในเธรดนั้นดูเหมือนว่าจะทำโดย https://www.sindarin.tech/ เลยอยากรู้ว่าใช้ Groq LPU หรือใช้ของอย่างอื่น ผมมองว่าถ้าไปถึงราว 50 t/s ก็เพียงพอสำหรับการโต้ตอบแบบเรียลไทม์แล้ว สูงกว่านั้นมีประโยชน์กับการสร้างข้อมูลจำนวนมากให้เร็วขึ้น แต่เกินกว่าความเร็วที่มนุษย์รับไหวมากจนประโยชน์เชิงประสบการณ์เริ่มลดลง อาจมีประโยชน์กับการสื่อสารระหว่าง AI หรือการส่งผ่านความรู้และบริบท ถ้าอย่างนั้น ผลิตภัณฑ์ LPU ที่โฟกัสเฉพาะปฏิสัมพันธ์ AI-มนุษย์ก็น่าจะทำได้ด้วยประสิทธิภาพที่ต่ำกว่ามากและต้นทุนที่ต่ำกว่ามากหรือเปล่า
  https://news.ycombinator.com/item?id=39180237

  • การเข้าถึงผ่าน token API แบบบริการรับประกัน ต้นทุนต่อโทเค็น ต่ำกว่าผู้ให้บริการรายอื่นทั้งหมด
    ดู https://wow.groq.com ส่วนฝั่งขายฮาร์ดแวร์นั้นมุ่งเน้นการขายทั้งระบบ และในทางปฏิบัติก็เหมาะกับองค์กรหรือสถาบันวิจัยเท่านั้น
  • หากต้องการโต้ตอบกับระบบ AI แบบเรียลไทม์ จำเป็นต้องมี ความเร็วสูงกว่า 50 t/s มาก
    เพราะเอาต์พุตของ LLM ส่วนใหญ่จะถูกใช้กับการคิดในใจภายใน การวางแผน RAG การสรุป ฯลฯ และมีเพียงเอาต์พุตสุดท้ายเท่านั้นที่ส่งถึงผู้ใช้ ลองจินตนาการถึง GPT-5 ที่เร็วมาก ๆ ซึ่งในช่วงเวลาที่คุณกะพริบตาไม่กี่ครั้ง มันสามารถวางแผนคำตอบได้หลายรอบ ค้นเว็บ เขียนรีวิวหนังสือ ถกเถียงกับตัวเอง กลั่นกรองสิ่งที่พบ วิจารณ์คำตอบของตัวเอง แล้วเขียนใหม่อีกครั้ง
  • เมื่อดูจากขนาดทีมของ Sindarin ที่น่าจะมีราว 3 คน มันดูใกล้เคียงกับการนำเทคโนโลยีที่มีอยู่มาประกอบกันอย่างชาญฉลาดมาก
    มี speech API ที่ให้การถอดเสียงแบบเรียลไทม์ระดับคำอยู่แล้ว และ Google ก็มีเหมือนกัน เคล็ดลับสำคัญน่าจะเป็นการทำ pipeline ระหว่างการรู้จำเสียง → LLM → TTS ได้ดีมาก ไม่ได้จะลดทอนผลงานนะ ตรงกันข้าม ผมสนใจเพราะอยากรู้ว่าจะทำซ้ำผลลัพธ์แบบนั้นได้อย่างไร

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

• ถ้าหน้าเว็บเข้าถึงฟอนต์บางตัวไม่ได้ มันจะทำงานล้มเหลวและพยายามส่งคำขอซ้ำต่อไปเรื่อย ๆ
  ที่เจอเรื่องนี้ก็เพราะเบราว์เซอร์บล็อกสิ่งที่แทบจะเป็นตัวติดตามแบบนี้โดยค่าเริ่มต้น
  https://fonts.gstatic.com/s/notosansarabic/[...]
  https://fonts.gstatic.com/s/notosanshebrew/[...]
  https://fonts.gstatic.com/s/notosanssc/[...]

  • ดูเหมือนเป็นวิธีแสดงให้ Google เห็นว่าเว็บนี้ได้รับความนิยมและน่าสนใจแค่ไหนในฐานะเป้าหมายการเข้าซื้อกิจการ โดยไม่ต้องติดตั้งตัวติดตามของ Google ลงบนเว็บไซต์โดยตรง
  • ต่อให้พยายามใช้ การแทนที่ฟอนต์ ด้วยปลั๊กอินด้านความเป็นส่วนตัว ก็ยังเจอปัญหาเดียวกัน
    การมี dependency แบบนี้ค่อนข้างแปลกทีเดียว

• ขอถามแบบคนยังใหม่กับเรื่องนี้หน่อย ว่าทำไมสิ่งนี้ถึงน่าประทับใจ?
  ถ้าอยากให้ตอบเร็วขึ้น ก็แค่ทุ่มการประมวลผลเพิ่มไม่ใช่หรือ? การที่มีคิวเกิดขึ้นตอนมีโหลด ก็แค่แสดงให้เห็น trade-off ระหว่างจำนวนคำขอที่ประมวลผลได้ต่อหน่วยเวลา กับปริมาณการประมวลผลที่ต้องใส่เพิ่มเพื่อให้ตอบกลับเร็วขึ้นไม่ใช่หรือ? กราฟนี้ของ NVIDIA ดูเหมือนจะบอกว่า H100 รัน llama v2 70B ได้เกิน 500 tok/s
  https://raw.githubusercontent.com/NVIDIA/TensorRT-LLM/rel/do...

  • การเพิ่มการประมวลผลอาจช่วยให้ throughput ดีขึ้นได้ แต่ latency ระหว่างโทเค็น นั้นปรับให้ดีขึ้นได้ไม่ง่าย
    โดยทั่วไปการสร้างผลลัพธ์มักติดคอขวดที่เวลาซึ่งใช้ในการวิ่งผ่านเครือข่ายต่อหนึ่งโทเค็น ถ้าจะทำให้เร็วขึ้นก็ต้องทำให้การคำนวณนั้นเร็วขึ้นจริง ๆ และหลังจากใช้ตัวเลือกชัด ๆ อย่าง accelerator ที่เร็วที่สุดหรือ cache ไปหมดแล้ว ก็จะกลายเป็นปัญหาที่ยาก
  • การอนุมานของ LLM เป็นปัญหาที่ เป็นลำดับโดยเนื้อแท้
    ทำแบบขนานเพิ่มขึ้นก็ไม่ได้ทำให้เร็วขึ้น คุณสร้างโทเค็นที่ 101 ก่อนสร้างโทเค็นที่ 100 ไม่ได้
  • throughput ของโทเค็นกับ latency เป็นคนละเรื่องกัน
    throughput ของโทเค็นคือ throughput ของ GPU/ระบบโดยรวม ส่วน latency คือ throughput ของโทเค็นสำหรับผู้ใช้แต่ละราย Groq ให้ latency ต่ำมาก หรือก็คือ throughput ของโทเค็นต่อผู้ใช้สูงมาก แต่ยังไม่มีตัวเลข throughput ของโทเค็นรวมทั้งระบบ ในทางกลับกัน ตัวเลขของ Nvidia ตรงนี้แสดง throughput ของโทเค็นทั้ง GPU/ระบบ ถึงแม้บน H100 จะได้ 1.5k t/s จริง แต่ในแง่ latency แล้ว throughput ของโทเค็นต่อผู้ใช้อาจต่ำกว่านั้นมาก เช่น 20 t/s ตัวชี้วัดที่สำคัญจริง ๆ คือ ต้นทุนต่อโทเค็น การที่ Groq รันได้ด้วย latency ต่ำไม่ได้แปลว่าจะทำได้ในราคาถูก วิธีประมาณคร่าว ๆ ที่ใช้ได้คือเอาต้นทุนของระบบหารด้วย throughput โทเค็นต่อวินาทีของทั้งระบบ แต่เพราะไม่มี throughput ต่อวินาทีรวมของระบบ Groq จึงพูดเรื่องประสิทธิภาพได้ยาก และตอนนี้ก็อาจกำลังอุดหนุนต้นทุนระบบเพื่อทำ PR แล้วค่อยขึ้นราคาทีหลัง
  • สุดท้ายก็ดูจะขึ้นอยู่กับว่าต้นทุนอินฟราของบทความต้นฉบับคือเท่าไร
    H100 มีต้นทุนการผลิตเพียงราว 3,300 ดอลลาร์ แต่โดยเฉลี่ยขายกันราว 30,000 ดอลลาร์
    https://www.hpcwire.com/2023/08/17/nvidia-h100-are-550000-gp...
  • ดูเหมือน Nvidia จะเขียนตัวเลข throughput สูงสุดในกรณีประมวลผลแบบ batch เช่น 50 tok/s สำหรับ 10 พรอมป์ต์ที่ต่างกันซึ่งรันพร้อมกัน
    ในแง่ความเร็วล้วน ๆ Groq LPU เหนือกว่า H100 อย่างชัดเจน แต่โดยพื้นฐานแล้วนี่คือระบบที่ราคาแพงกว่า 500 เท่าแต่เร็วกว่า 10 เท่า และดูเหมือนบริษัทที่ทำธุรกิจบล็อกเชนกำลังโหมการตลาดชิปที่เดิมตั้งใจทำไว้สำหรับขุดคริปโตให้กลายเป็นชิปสำหรับ LLM inference อีกอย่างที่บังเอิญน่าขำมากคือทุกครั้งที่มีคนโพสต์ลิงก์นี้พร้อมอาการทึ่งทุกสัปดาห์ ก็จะมีวิศวกรของ Groq มารออยู่ในคอมเมนต์พร้อมตอบทุกอย่างเสมอ

• อันนี้ไม่เกี่ยวอะไรกับโมเดล Grok ของ x.ai เลยใช่ไหม?
  ลองใช้แล้ว ความเร็วถือว่าน่าประทับใจมาก

  • ไม่เกี่ยวกับ Elon เลย และ Groq ของเราใช้ชื่อนี้ก่อน
    ในสาย AI มันเป็นชื่อที่เลือกได้อย่างเป็นธรรมชาติเพราะเชื่อมโยงกับจิตวิญญาณแบบแฮกเกอร์ และเครื่องหมายการค้าเป็นของเรา ไม่ใช่ของ Elon
    https://wow.groq.com/hey-elon-its-time-to-cease-de-grok/
  • ถ้าไม่มีคอมเมนต์นี้ ฉันคงนึกว่าเป็นของที่ Twitter ทำ
  • ยังมีของเล่นเด็กชื่อ Grok ที่ใช้ LLM คุยกับเด็กด้วย

• ทั้ง Groq และ Mixtral ทำให้อ้าปากค้างได้ทั้งคู่
  ผมลองใช้พรอมป์ต์ด้านล่างนี้: สร้างไฟล์ GitLab CI yaml สำหรับโปรเจ็กต์ frontend/backend แบบไฮบริด ที่มี Node frontend อยู่ใต้ /frontend แพ็กด้วย yarn และ build ด้วย vite แล้วนำไปวางใน /backend/public ส่วน backend เป็นเซิร์ฟเวอร์ Python Flask

  • ถึงอย่างนั้นมันก็ยังพลาดกับโค้ด Python ง่าย ๆ
    particles = np.zeros((2, 3)) # position, velocity, and acceleration
particles[:, 0] = [0.0, 0.0, 0.0] # initial position