‘LLM in a Flash’ ที่ทำให้การอนุมาน LLM มีประสิทธิภาพได้ด้วยหน่วยความจำที่จำกัด

 (huggingface.co)
1 คะแนน โดย GN⁺ 2023-12-22 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • LLM in a Flash จัดเก็บพารามิเตอร์ของ LLM ที่มีขนาดใหญ่กว่า DRAM ไว้ในแฟลชเมมโมรี และดึงเข้ามาใน DRAM เฉพาะส่วนที่จำเป็น ทำให้สามารถทำอนุมานได้แม้บนอุปกรณ์ที่มีหน่วยความจำจำกัด
  • อิงจาก โมเดลต้นทุนการอนุมาน ที่สะท้อนลักษณะการเข้าถึงของแฟลชเมมโมรี เพื่อลดปริมาณข้อมูลที่ต้องรับส่ง และกระตุ้นให้อ่านเป็นชังก์ที่ใหญ่และต่อเนื่องมากขึ้น
  • windowing นำเซลล์ประสาทที่เคยถูกกระตุ้นก่อนหน้ากลับมาใช้ซ้ำ และ row-column bundling ใช้ประโยชน์จากจุดแข็งของแฟลชในการเข้าถึงแบบลำดับเพื่อลดคอขวด
  • เมื่อนำสองเทคนิคนี้มารวมกัน จะสามารถรันโมเดลที่มีขนาดใหญ่กว่า DRAM ที่ใช้งานได้สูงสุด 2 เท่า และให้การอนุมานเร็วขึ้นเมื่อเทียบกับการโหลดแบบง่าย ๆ คือ CPU 4~5 เท่า และ GPU 20~25 เท่า
  • เมื่อผสานการรับรู้ความเบาบาง การโหลดแบบปรับตามบริบท และการออกแบบที่ยึดฮาร์ดแวร์เป็นศูนย์กลางเข้าด้วยกัน ความเป็นไปได้ในการรัน LLM บนอุปกรณ์ที่มี ข้อจำกัดด้านหน่วยความจำ ก็เพิ่มสูงขึ้น

การอนุมาน LLM บนพื้นฐานแฟลชเมมโมรี

  • โมเดลภาษาขนาดใหญ่ให้ประสิทธิภาพสูงในงานประมวลผลภาษาธรรมชาติที่หลากหลาย แต่ด้วย ปริมาณการคำนวณและความต้องการหน่วยความจำ ที่สูง จึงรันได้ยากบนอุปกรณ์ที่มี DRAM จำกัด
  • LLM in a Flash รับมือกับข้อจำกัดนี้ด้วยการเก็บพารามิเตอร์ของโมเดลไว้ใน แฟลชเมมโมรี และนำเฉพาะข้อมูลที่จำเป็นระหว่างการอนุมานเข้ามาใน DRAM แบบออนดีมานด์
  • แกนกลางของแนวทางนี้คือ โมเดลต้นทุนการอนุมาน ที่ออกแบบให้สอดคล้องกับการทำงานของแฟลชเมมโมรี
    • ปรับให้เหมาะสมเพื่อลดปริมาณข้อมูลที่ส่งจากแฟลช
    • ออกแบบให้อ่านข้อมูลเป็นชังก์ที่ใหญ่และต่อเนื่องมากขึ้น

สองเทคนิคเพื่อลดปริมาณการส่งข้อมูลและรูปแบบการอ่าน

  • windowing นำเซลล์ประสาทที่เคยถูกกระตุ้นก่อนหน้ากลับมาใช้ซ้ำ เพื่อลดปริมาณข้อมูลที่ต้องย้ายจากแฟลชไปยัง DRAM
  • row-column bundling ปรับให้สอดคล้องกับคุณลักษณะที่แฟลชเมมโมรีถนัดการเข้าถึงข้อมูลแบบลำดับ โดยเพิ่มขนาดของชังก์ข้อมูลที่อ่านจากแฟลช
  • หากใช้สองเทคนิคร่วมกัน จะสามารถรันโมเดลที่มีขนาดใหญ่กว่าหน่วยความจำ DRAM ที่ใช้งานได้สูงสุด 2 เท่า
  • การเพิ่มขึ้นของความเร็วในการอนุมานเมื่อเทียบกับวิธีโหลดแบบง่าย ๆ แตกต่างกันไปตามฮาร์ดแวร์
    • บน CPU เร็วขึ้น 4~5 เท่า
    • บน GPU เร็วขึ้น 20~25 เท่า
  • การออกแบบนี้ผสาน การรับรู้ความเบาบาง, การโหลดแบบปรับตามบริบท และการออกแบบที่ยึดฮาร์ดแวร์เป็นศูนย์กลาง เพื่อทำให้การอนุมาน LLM เป็นไปได้ในสภาพแวดล้อมที่มีข้อจำกัดด้านหน่วยความจำ

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

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

 
GN⁺ 2023-12-22
ความคิดเห็นจาก Hacker News

  • บทความวิจัยนั้นต่อยอดจากเทคนิคการใช้ประโยชน์จากความเบาบาง (sparsity) ใน งานวิจัย Deja Vu ซึ่งเองก็ค่อนข้างซับซ้อนอยู่แล้ว จึงใช้เวลาทำความเข้าใจพอสมควร
    Deja Vu มองว่าแม้โมเดลที่มีความเบาบางของน้ำหนักต่ำ ก็ยังมี “ความเบาบางเชิงบริบท (contextual sparsity)” สูง กล่าวคือเวกเตอร์ผลลัพธ์จากการคูณเมทริกซ์จะมีค่า 0 เกิดขึ้นจำนวนมาก แต่ตำแหน่งที่กลายเป็น 0 จะเปลี่ยนไปตามอินพุต
    หากใช้ประโยชน์จากความเบาบางนี้ ก็สามารถข้ามการโหลดบางแถวของเมทริกซ์ได้ และเพื่อให้ได้ประสิทธิภาพเพิ่มขึ้น ต้องคาดการณ์ล่วงหน้าว่าควรข้ามแถวใด ซึ่งการคาดการณ์นั้นทำได้ด้วยเมทริกซ์อันดับต่ำ
    งานวิจัยของ Apple เสนอว่าการค้นพบนี้ไม่เพียงช่วยเรื่องประสิทธิภาพการโหลดจาก RAM เท่านั้น แต่ยังช่วยการโหลดจาก หน่วยความจำแฟลช โดยไม่ต้องแลกกับแบนด์วิดท์มากนักด้วย
    เมทริกซ์ attention ค่อนข้างเบา และส่วนที่ควรโหลดแบบเบาบางคือ FFN อีกทั้งหากคาดการณ์เอาต์พุตของชั้น ReLU แทนอินพุตของ FFN จะได้ความเบาบางที่ดีกว่ามาก หากคาดการณ์ได้ว่า “ช่องเวกเตอร์นี้จะมีค่าเป็นลบหลังการคูณเมทริกซ์และก่อน ReLU” ก็ไม่ต้องโหลดคอลัมน์เมทริกซ์นั้น และส่งออกเป็น 0 ได้เลย
    ข้อเสนอคือแถวส่วนใหญ่ของ FFN ไม่จำเป็นต้องโหลดเลย และควรเก็บแคชแถวที่เพิ่งถูกใช้ล่าสุดไว้สำหรับแต่ละ FFN แล้วค่อยอัปเดตจากแฟลชเมื่อจำเป็น ยังมีรายละเอียดเพิ่มเติมเกี่ยวกับความสัมพันธ์ระหว่างการโหลดเป็นชังก์กับชั้น projection แต่แก่นของ insight น่าจะอยู่ตรงนี้
    FFN คือ Feed Forward Network และใน Transformer มันเป็นบล็อกที่มีขนาดใหญ่ที่สุดกลุ่มหนึ่ง

  • อยากรู้ว่า ต้องไม่โหลดโมเดลสักเท่าไร ก่อนที่ประสิทธิภาพจริงจะเริ่มต่างออกไป
    เช่น หากต้องการรักษาประสิทธิภาพไว้ที่ 90% ของกรณีที่โหลดทั้งหมดลง RAM จะใช้หน่วยความจำแค่ครึ่งเดียวได้ไหม หรือต้องใช้ 90% หรือ 95% กันแน่
    สุดท้ายแล้วประเด็นคือเมื่อเราลด RAM ลง ประสิทธิภาพจะลดจากค่าสูงสุดเร็วแค่ไหน กราฟเปรียบเทียบอัลกอริทึมนี้กับอัลกอริทึมพื้นฐานในสถานการณ์ RAM น้อย ซึ่งเป็นคนละเรื่องกัน แต่ก็เป็นคำถามที่ดี
    หากสามารถให้ประสิทธิภาพที่ดีได้โดยไม่ต้องโหลดโมเดลขนาด 8GB ทั้งหมดลงหน่วยความจำโทรศัพท์ ก็ชัดเจนว่ามีประโยชน์

    • Apple รันโมเดลที่มีขนาดเป็น สองเท่าของหน่วยความจำที่มีอยู่ ไม่รู้ว่านั่นเป็นจุดเหมาะสมที่สุดที่พวกเขาพบหรือไม่ หรือหากยอมแลกกับเวลาตอบสนองจะใช้โมเดลที่ใหญ่กว่านี้ได้ไหม
      บทความวิจัยฉบับเต็มน่าอ่าน และเป็นงานที่น่าสนใจทีเดียว: https://arxiv.org/pdf/2312.11514
      ส่วนที่บทความวิจัยเน้นคือเทคนิคเสริมกันสองอย่างเพื่อทำให้การถ่ายโอนข้อมูลน้อยที่สุด และเพิ่ม throughput ของหน่วยความจำแฟลชให้มากที่สุด
      Windowing เป็นวิธีที่นำค่า activation ของโทเค็นที่เพิ่งคำนวณมาใช้ซ้ำ และโหลดเฉพาะพารามิเตอร์ที่จำเป็นสำหรับโทเค็นไม่กี่ตัวก่อนหน้า จึงลดจำนวนคำขอ I/O สำหรับการโหลดน้ำหนัก
      Row-column bundling คือการจัดเก็บโดยนำแถวและคอลัมน์ของชั้น up-projection และ down-projection มาต่อกัน เพื่อให้สามารถอ่านชังก์ต่อเนื่องขนาดใหญ่ขึ้นจากแฟลช และเพิ่ม throughput ด้วยการอ่านชังก์ขนาดใหญ่
    • แค่ลองจัดระเบียบความคิดเท่านั้น ไม่ใช่คำอธิบายที่อ้างอิงได้เป็นทางการ
      ในทางทฤษฎี เวลา inference ต่อโทเค็นเดียวเมื่อบางส่วนของโมเดลอยู่ในแฟลช ควรเท่ากับเวลา inference ตอนที่โมเดลทั้งหมดอยู่ใน RAM บวกกับเวลาโหลดส่วนของโมเดลที่อยู่ในแฟลช
      สมมติว่าไม่จำเป็นต้องเขียนกลับไปยังแฟลช แต่ผมไม่ใช่ผู้เชี่ยวชาญด้าน LLM จึงอาจผิดได้
      หากมีจำนวนชั้นมากกว่า 10 มาก ๆ ก็น่าจะโหลดทีละชั้นโดยเหลือ RAM ไว้เพียงส่วนเล็ก ๆ ได้ LLM ทั่วไปมีชั้นเป็นหลักหลายสิบ จึงฟังดูเป็นไปได้
      หากระหว่าง inference RAM ไม่ใช่คอขวด ก็น่าจะสามารถ ถ่ายโอนแบบ DMA ชั้นถัดไปจากแฟลชไปยัง RAM ขณะกำลังทำ inference ชั้นปัจจุบันได้ แต่ในระบบโปรเซสเซอร์เดี่ยวคงทำได้ไม่ดีนักเพราะคอขวดที่ RAM
      ถ้าเป็นระบบโปรเซสเซอร์คู่ อาจให้โปรเซสเซอร์ตัวหนึ่งโหลดชั้นถัดไปเข้า RAM ขณะที่อีกตัวทำ inference ชั้นก่อนหน้า จึงอาจรัน LLM ขนาดใหญ่มากได้แม้ใช้ RAM น้อย
      ตอนนี้ผมนั่งอยู่ข้างกองชิ้นส่วนที่จะใช้ประกอบเครื่อง LLM AI เครื่องใหม่ เป็น z840 แบบโปรเซสเซอร์คู่ เลยตั้งตารอที่จะได้ลองจับของพวกนี้ด้วยตัวเอง

  • สิ่งที่สังเกตได้คือ อุปกรณ์ของ Apple มี RAM น้อยมาก เมื่อเทียบกับอุปกรณ์ลักษณะเดียวกันของคู่แข่ง
    ส่วนหนึ่งเป็นเพราะทีมซอฟต์แวร์ของ Apple ใช้ภาษาที่มีประสิทธิภาพกว่าอย่าง Objective-C และอีกส่วนหนึ่งเพราะแอป iOS ไม่จำเป็นต้องรองรับความละเอียดหน้าจอที่หลากหลายมหาศาล จึงมีกรณีที่ต้องโหลดเท็กซ์เจอร์ความละเอียดสูงแล้วค่อยย่อขนาดลงค่อนข้างน้อย
    อีกอย่าง แม้จะซื้อในสเกลระดับ Apple RAM ก็ไม่ได้ถูกลงมากนัก ดังนั้นการเพิ่ม RAM จึงกระทบมาร์จินมากกว่าการเพิ่มฟีเจอร์อื่น
    แต่ LLM โดยธรรมชาติแล้วกิน RAM มาก ทางเลือกทั้งหมดนี้จึงย้อนกลับมาเป็นปัญหา ไม่ว่าจะใช้เทคนิคประหยัดหน่วยความจำแบบใด คู่แข่งที่มี RAM มากกว่าก็จะสามารถใส่โมเดลที่ใหญ่กว่า ดีกว่า และฉลาดกว่าได้

    • ยิ่งไปกว่านั้น Mac เดสก์ท็อปส่วนใหญ่ในปัจจุบัน อัปเกรด RAM ไม่ได้
      ผมกำลังอยากซื้อ Mac เร็ว ๆ นี้ แต่ลังเลมากว่าควรสั่ง RAM เท่าไรดี งบมีจำกัดเลยยิ่งตัดสินใจยาก ถ้าไม่ติดข้อจำกัดคงเลือกอย่างน้อย 32GB
      ยังแอบหวังว่า Apple จะเปลี่ยนนโยบายราคา RAM อยู่ แต่ก็คงเป็นความหวังลม ๆ แล้ง ๆ มากกว่า
    • ขอเสริมสองอย่างเกี่ยวกับวิธีที่ทำให้ “RAM น้อย” เป็นไปได้: อุปกรณ์ Apple รองรับ memory compression: https://www.lifewire.com/understanding-compressed-memory-os-...
      ดู implementation ที่เกี่ยวข้องได้ด้วย: https://opensource.apple.com/source/xnu/xnu-2050.18.24/libke...
      อีกอย่าง อุปกรณ์ Apple รองรับฟีเจอร์ที่เรียกว่า “jetsam” ซึ่งจะคืนหน่วยความจำโดยปิดแอปที่ไม่ได้ใช้งานหรืออยู่เบื้องหลัง เพื่อให้แอปที่มีลำดับความสำคัญสูงทำงานต่อได้อย่างลื่นไหล: https://developer.apple.com/documentation/xcode/identifying-...
    • เหตุผลเดียวที่ยังใช้ Mac อยู่คือความคุ้นเคย และเพราะ MacBook Air เงียบ
      ถ้ามีโน้ตบุ๊ก Linux ที่เงียบหรือแทบไม่มีเสียงแนะนำ ก็ยินดีรับฟัง ส่วนใหญ่พัดลมจะหมุนแรง และผมยอมสละประสิทธิภาพ CPU บางส่วนเพื่อความเงียบได้ ถ้ามีโหมดเงียบที่เปิดปิดง่ายก็ยิ่งดี
      เท่าที่เคยเห็นยังไม่มีอะไรเทียบความเงียบของ MacBook Air ได้ และถ้ามีเครื่องไหนที่พิสูจน์ว่าผมคิดผิดก็ยินดีฟังมาก
      แน่นอน ถ้าราคาถูกกว่าหรือเปลี่ยน RAM ได้ก็ยิ่งดี ปกติผมใช้ MacBook Air เป็นหลักกับบริการบนเว็บ และเป็นเทอร์มินัลระยะไกลสำหรับเชื่อมต่อไปยังเซิร์ฟเวอร์ Linux ที่ใช้คอมไพล์โปรเจกต์ใหญ่ ๆ รวมถึงงานโฮม/เซลฟ์โฮสติ้ง
    • ไม่แน่ใจว่าการตีความนี้ถูกไหม แต่ดูเหมือน Apple กำลังเดิมพันว่าในระยะยาว หากมี สถาปัตยกรรม CPU/GPU ที่เหมาะสม หน่วยความจำแฟลชจะเทียบเท่า RAM ได้
      เห็นได้ชัดว่ากำหนดเวลาถูกเร่งเข้ามา แต่ผมก็ไม่ได้คิดว่าสมมติฐานของพวกเขาผิด

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

    • ใช่ เรื่องนี้ช่วยปรับปรุงส่วนนั้นได้มาก แม้ไม่มีเทคนิคนี้ก็รัน LLM บนโทรศัพท์ได้อยู่แล้ว ปัญหาคือจะใช้โมเดลได้ใหญ่แค่ไหน ต้อง quantize หนักแค่ไหน และโมเดลที่เหลือบางตัวให้ผลลัพธ์ดีพอหรือไม่
      ตัวอย่างเช่น เมื่อวานมี GitHub Discussion เกี่ยวกับการรัน LLM บนชิป Apple A-series (iPhone) ถูกโพสต์ขึ้นที่นี่: https://news.ycombinator.com/item?id=38703161
    • ใช่ เป้าหมายสุดท้ายคือการ รันโมเดลที่ใหญ่ขึ้นบนโทรศัพท์ เพราะ DRAM ของโทรศัพท์มีข้อจำกัดมาก
    • ไม่แน่ใจนัก แต่ดูเหมือนว่านั่นจะเป็นหนึ่งในจุดขายของ Pixel รุ่นใหม่

  • ชอบที่บทความช่วงหลัง ๆ เรียกสิ่งนี้ว่า LLM ไม่ใช่ “AI” เพราะจะได้รู้ว่าเป็นเนื้อหาเกี่ยวกับเทคโนโลยีเฉพาะ ไม่ใช่คำโฆษณาเกินจริง

    • ที่นี่คือ Hugging Face ถ้าดูจากกลุ่มผู้อ่านแล้ว การไม่เขียนให้เฉพาะเจาะจงต่างหากที่คงจะแปลกมาก

  • สงสัยว่าสิ่งนี้ต่างจาก FlashAttention อย่างไร ใช้คำคล้ายกัน แต่ถ้าไม่อธิบายความต่างในบทคัดย่อก็ทำให้งง
    แก้ไข: ดูเหมือนเป็นการขยายกลไกคนละสองแบบภายในเฟรมเวิร์กแฟลช ชื่อ论文น่าจะตั้งให้ดีกว่านี้ได้ แต่มีอธิบายไว้ในไม่กี่หน้าแรก

  • ในบทสรุป ผมคาดว่าจะมีส่วนอย่าง “ฟีเจอร์นี้จะถูกเปิดให้ผู้ใช้ใช้อย่างไร” แต่อาจเป็นเรื่องนอกขอบเขตของ论文ก็ได้
    สงสัยว่าฟีเจอร์แบบนี้จะถูกยกขึ้นมาเป็น API call หรือการตั้งค่าใน CoreML เช่นต้องระบุแฟล็ก use_flash หรือจะเป็น runtime optimization ที่ผู้ใช้มองไม่เห็น
    และก็สงสัยด้วยว่ามีใครรู้จัก presentation หรือ talk ดี ๆ ที่ Apple อธิบาย roadmap การพัฒนา CoreML, Metal ฯลฯ ไหม

  • Apple ซื้อบริษัทอิหร่านไปหรือเปล่า?

    • ทีมส่วนใหญ่ดูเหมือนมาจาก XNOR.ai ซึ่ง Apple ซื้อกิจการไปในปี 2020[0] บริษัทตั้งอยู่ที่ Seattle และผู้ก่อตั้งดูเหมือนมีเชื้อสายอิหร่าน
      [0]: https://www.geekwire.com/2020/exclusive-apple-acquires-xnor-...
    • ผมก็คิดแบบเดียวกัน ส่วนใหญ่จบจาก Sharif ซึ่งเทียบได้กับ Stanford ของอิหร่าน

  • รู้ว่าแนวทางต่างกัน แต่ทั้งสองอย่างก็ใช้ประโยชน์จากหน่วยความจำแฟลช เลยคาดว่าบทความนี้น่าจะกล่าวถึง FlashAttention [1] อย่างน้อยสักหน่อย
    [1] https://arxiv.org/abs/2205.14135

    • เท่าที่ผมรู้ FlashAttention ไม่ได้เกี่ยวข้องกับหน่วยความจำแฟลชเลย
      ตามที่ผมเข้าใจ FlashAttention เป็นเรื่องของรูปแบบการเข้าถึงที่ใช้หน่วยความจำภายในเครื่อง โดยเฉพาะ SRAM ให้ดีขึ้น เช่น การเก็บข้อมูลไว้ในแคช L1 ของ CPU หรือชั้นที่เทียบเท่าบน GPU
      กล่าวอีกอย่างคือ FlashAttention เกี่ยวกับส่วนที่เร็วกกว่า DRAM ส่วนบทความนี้พูดถึงการ offload ไปยังส่วนที่ช้ากว่า DRAM ให้ดีขึ้น

  • ในประโยค “โมเดล OPT 6.7B เช่น แสดง ความเบาบาง 97% ที่เห็นได้ชัดภายในเลเยอร์ FFN” มีใครรู้ไหมว่าตัวชี้วัดนี้หมายถึงอะไรกันแน่?
    สงสัยว่าหมายถึง 97% ของค่าของเลเยอร์เป็น 0 หรือหมายถึงว่าสามารถบีบอัดให้เหลือ 3% ของขนาดเดิมได้

    • หมายถึง 97% ของเอาต์พุตของเลเยอร์นั้นเป็น 0 และมีเพียง 3% ที่ถูก activate ในช่วงเวลาหนึ่ง
      แต่เพราะ 3% ที่ถูก activate นั้นไม่ได้คงที่ จึงไม่สามารถตัด 97% ที่เหลือทิ้งไปทั้งหมดได้ บทความดูเหมือนจะบอกว่าสามารถทำนาย 3% ที่ active ได้ค่อนข้างแม่นยำ ทำให้เร็วขึ้นได้โดยไม่สูญเสียความแม่นยำมากเกินไป