เพิ่มพลังให้ Llama 2 70B ด้วย NVIDIA H100

ความมุ่งมั่นในด้านประสิทธิภาพของเอ็นจิ้นการตอบคำถามของ Perplexity ผลักดันให้เรานำเทคโนโลยีล่าสุดที่ NVIDIA และ AWS มีมาใช้ ในบล็อกนี้ เราตื่นเต้นที่จะแบ่งปันผลลัพธ์จากการทดลองล่าสุดของเรา ซึ่งเป็นการเปรียบเทียบการอนุมาน Llama 2 70B ข้ามการตั้งค่าฮาร์ดแวร์และซอฟต์แวร์ต่างๆ

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

ประสิทธิภาพที่เพิ่มขึ้นอย่างแท้จริงจากการเปลี่ยน GPU ของเราจาก NVIDIA A100 เป็น NVIDIA H100 คืออะไร โดยที่การตั้งค่าอื่นๆ ทั้งหมดยังคงเหมือนเดิม

ประสิทธิภาพที่เพิ่มขึ้นของการควอนไทเซชันแบบจุดลอยตัว 8 บิต (fp8) ซึ่ง H100 เพิ่มการรองรับแบบเนทีฟคืออะไร ต้นทุนด้านความแม่นยำของการควอนไทเซชันนี้คือเท่าใด

ความขนานของเทนเซอร์ (tensor parallelism) และขนาดแบตช์ (batch size) ส่งผลต่อความหน่วง (latency) และปริมาณงานของโทเค็น (token throughput) อย่างไร

เมื่อพิจารณาจากสิ่งข้างต้น การกำหนดค่าใดส่งผลให้เกิดความสมดุลที่สามารถปรับขนาดได้มากที่สุดระหว่างประสิทธิภาพและความคุ้มค่าด้านต้นทุน

เราทำการทดลองต่อไปนี้เป็นชุดการทดสอบประสิทธิภาพภายในเครื่องเพื่อหลีกเลี่ยงความหน่วงของเครือข่าย

ความหน่วง (Latency): เวลาทั้งหมดที่เซิร์ฟเวอร์การอนุมานใช้ในการสร้างการตอบกลับฉบับเต็ม

ปริมาณงาน (Throughput): จำนวนโทเค็นผลลัพธ์ ต่อวินาที ต่อ GPU ที่เซิร์ฟเวอร์การอนุมานสามารถสร้างได้ในทุกผู้ใช้และคำขอ

ปัจจัยเหล่านี้จะส่งผลต่อเมตริกสำคัญ ดังนั้นเราจึงรักษาให้คงที่ตลอดการทดลองในแต่ละครั้ง

ประสิทธิภาพจะปรับขนาดตามขนาดของ LLM พารามิเตอร์ที่มากขึ้นต้องใช้การคำนวณมากขึ้น ส่งผลให้การอนุมานช้าลง ตัวอย่างเช่น Llama 2 13B เร็กว่า Llama 2 70B เมื่อการตั้งค่าอื่นๆ เท่ากัน เรายึดติดกับ Llama 2 70B ในการทดลองนี้เพราะเราต้องการปรับให้เหมาะสมสำหรับการให้บริการโมเดลโอเพนซอร์สที่มีความสามารถมากที่สุด

จำนวนโทเค็นอินพุตและเอาต์พุตในแต่ละคู่คำขอ/การตอบกลับตัวอย่างสามารถมีอิทธิพลต่อการวัดประสิทธิภาพ โดยทั่วไป การสร้างโทเค็นเอาต์พุตจะครอบงำเวลาตอบสนองโดยรวม เมื่อข้อมูลตัวอย่างกระตุ้นให้เกิดการตอบกลับแบบ "ใช่/ไม่ใช่" จาก LLM เท่านั้น การตอบกลับจะเร็วกว่าเมื่อเทียบกับตัวอย่างที่ขอให้ LLM เขียนเรียงความ ชุดข้อมูลของเราประกอบด้วยคำขอสังเคราะห์ที่มีโทเค็นอินพุต 1024 โทเค็น ซึ่งกระตุ้นให้เกิดโทเค็นเอาต์พุต 512 โทเค็น การกระจายนี้ถูกเลือกให้ตรงกับการกระจายของการรับส่งข้อมูลที่สังเกตได้ บนการปรับใช้ Llama 2 70B สาธารณะของเรา

NVIDIA TensorRT-LLM (รุ่น v0.5.0) เป็นไลบรารีโอเพนซอร์สสำหรับการเพิ่มประสิทธิภาพการอนุมาน LLM เปิดตัวในช่วงปลายปี 2023 โดยสังเคราะห์การเพิ่มประสิทธิภาพการอนุมานจำนวนมากของ NVIDIA และมีเลเยอร์การปรับแต่งที่ยืดหยุ่นสำหรับพารามิเตอร์สำคัญของการทดลองนี้ ได้แก่ ขนาดแบตช์, การควอนไทเซชัน และความขนานของเทนเซอร์

เราทำการทดลองผ่านแกนการกำหนดค่า 4 แกน: ความขนานของเทนเซอร์, สถาปัตยกรรม GPU, การควอนไทเซชัน และขนาดแบตช์สูงสุด แกนเหล่านี้เชื่อมโยงกันเนื่องจากแต่ละแกนแสดงถึงการแลกเปลี่ยนเกี่ยวกับทรัพยากรคอขวดที่สำคัญที่สุด นั่นคือ หน่วยความจำ GPU

สถาปัตยกรรม GPU Hopper (H100-HBM3-80GB / p5.48xlarge) รุ่นที่เก้าอัดแน่นไปด้วยรายการฟีเจอร์มากมายเหนือกว่ารุ่นก่อนหน้าอย่าง Ampere (A100-SXM4-80GB / p4de.24xlarge) รวมถึงอัตราการคำนวณที่เพิ่มขึ้น 2x-6x และแบนด์วิดท์หน่วยความจำ GPU เกือบ 2x แบนด์วิดท์หน่วยความจำ GPU เป็นเมตริกที่สำคัญสำหรับการอนุมาน เนื่องจากคอขวดความหน่วงหลักของการคูณเมทริกซ์ในการอนุมานมาจากการโหลดข้อมูลโมเดลระดับกิกะไบต์จากหน่วยความจำ GPU เข้าสู่รีจิสทรีการคำนวณ จากสถิติเหล่านี้ เราตั้งสมมติฐานว่าการเปรียบเทียบแบบตรงไปตรงมาระหว่าง NVIDIA H100 และ A100 จะแสดงการปรับปรุง 2x ทั้งในด้านความหน่วงและปริมาณงาน

ความแตกต่างสำคัญอีกประการหนึ่งระหว่าง NVIDIA H100 และ A100 คือ คอร์เทนเซอร์ของ H100 เพิ่มการรองรับคำสั่งจุดลอยตัว 8 บิต (fp8) แบบเนทีฟ ซึ่งเปิดประตูสู่การเพิ่มประสิทธิภาพเพิ่มเติมตามรายละเอียดด้านล่าง นี่คือเหตุผลที่เราใช้ fp8 และ fp16 โดยเฉพาะสำหรับ H100

เพื่อให้หน่วยความจำต่อ GPU คงที่ในการทดลองนี้ เราจึงยึดติดกับโหนดที่มีหน่วยความจำ GPU 8x80GB สำหรับทั้ง NVIDIA A100 และ H100 นอกจากจะช่วยให้มีขนาดแบตช์ที่สูงขึ้นแล้ว หน่วยความจำ GPU ยังมีความสำคัญเนื่องจากพารามิเตอร์ของโมเดลจะถูกโหลดลงในหน่วยความจำ GPU ระหว่างการเริ่มต้นเซิร์ฟเวอร์เพื่อให้เข้าถึงได้อย่างรวดเร็ว ตัวอย่างเช่น หากพารามิเตอร์แต่ละตัวจาก 70 พันล้านพารามิเตอร์ในโมเดลของเราเป็นตัวเลขจุดลอยตัว 16 บิต โมเดลจะมีขนาดประมาณ 140GB ซึ่งไม่สามารถใส่ลงใน GPU เดี่ยวได้ ดังนั้นจึงจำเป็นต้องมีความขนานของเทนเซอร์ ซึ่งเราจะอธิบายด้านล่าง

ความขนานของเทนเซอร์หมายถึงจำนวนอุปกรณ์ GPU ที่ใช้ในการรันเซิร์ฟเวอร์การอนุมาน เมื่อเราจัดสรรจำนวน GPU TensorRT-LLM จะรวมทรัพยากรเข้าด้วยกันเพื่อช่วยให้เราบรรลุขีดจำกัดหน่วยความจำขั้นต่ำที่จำเป็นสำหรับการรัน Llama 2 70B สมมติฐานของเราคือความขนานของเทนเซอร์ที่ต่ำกว่าจะส่งผลให้มีความหน่วงสูงขึ้น (เนื่องจากใช้ทรัพยากรน้อยลงในการตอบสนองแต่ละแบตช์) แต่มีปริมาณงานต่อ GPU สูงขึ้น (เนื่องจากการใช้งานที่ดีขึ้น) เมื่อเทียบกับความขนานของเทนเซอร์ที่สูงกว่า

การควอนไทเซชันคือการลดความแม่นยำในน้ำหนักและการเปิดใช้งานที่ใช้โดยโครงข่ายประสาทเทียม เราใช้เทคนิคนี้เพื่อลดการใช้หน่วยความจำ GPU ลงครึ่งหนึ่งเมื่อเราเปลี่ยนจาก fp16 เป็น fp8 ซึ่งทำให้สามารถรันโมเดลเดียวกันด้วยการใช้หน่วยความจำ GPU รวมที่ต่ำกว่า ช่วยให้มีความขนานของเทนเซอร์ที่ต่ำลง ซึ่งช่วยเพิ่มปริมาณงาน

การใช้งานการควอนไทเซชันมีโอกาสที่จะลดทอนความแม่นยำ ดังนั้น เราจึงประเมินความแม่นยำสำหรับความแม่นยำที่แตกต่างกันโดยการเปรียบเทียบสถิติความงุนงง (perplexity) ซึ่งเป็นการวัดว่า LLM ทำนายโทเค็นถัดไปในประโยคได้ดีเพียงใด บนคอร์ปัส WikiText สำหรับจุดลอยตัว 8 บิตและน้ำหนัก 8 บิตพร้อมการเปิดใช้งาน 8 บิตและ SmoothQuant (w8a8 SQ) ไม่มี 98เปลี่ยนแปลงที่มีนัยสำคัญในความงุนงง (< 1%) เมื่อเทียบกับ fp16 บน WikiText ดังนั้นเราจึงมั่นใจที่จะดำเนินการต่อ อย่างไรก็ตาม w4a16 แสดงการเปลี่ยนแปลงที่สำคัญ 7% ในความงุนงง ซึ่งอาจเกิดจากความแม่นยำที่ต่ำกว่าและการแปลงแบบไดนามิกที่จำเป็นระหว่าง int4 และ fp16

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

ในกรณีของ Llama 2 70B (ซึ่งมี 80 เลเยอร์), fp16 ที่มีขนาดแบตช์ 32 สำหรับขนาดบริบท 4096 ขนาดของแคช KV จะสูงถึง 40 GB ซึ่งในท้ายที่สุดจะป้องกันไม่ให้ Llama 2 70B fp16 ซึ่งเฉพาะน้ำหนักอย่างเดียวก็กินพื้นที่ 140GB สามารถใส่ลงในหน่วยความจำ GPU 160GB ที่มีอยู่ที่ความขนานของเทนเซอร์ 2 (TP-2) ได้อย่างสบายๆ

เราได้กวาดผ่านชุดค่าผสมที่เข้ากันได้ของตัวแปร 4 ตัวของการทดลองและนำเสนอแนวโน้มที่มีประโยชน์ที่สุดด้านล่าง

รูปที่ 1 - ความหน่วงของคำขอที่มีขนาดแบตช์ต่างกันข้ามการกำหนดค่าที่แตกต่างกันห้าแบบ โดยทั้งหมดมีความขนานของเทนเซอร์ 8 ซึ่งให้ความหน่วงที่ดีที่สุดด้วย GPU ที่มีอยู่ 8 ตัว ภายในแต่ละการกำหนดค่า โดยทั่วไปความหน่วงจะเพิ่มขึ้นเป็นสองเท่าเมื่อเพิ่มขนาดแบตช์จาก 1 → 32 และเพิ่มขึ้นเป็นสองเท่าอีกครั้งจาก 32 → 128 ที่ขนาดแบตช์ที่ใหญ่พอสมควร H100 จะลดความหน่วงลงประมาณครึ่งหนึ่งเมื่อเทียบกับ A100 A100 ใช้ความแม่นยำแบบผสมเนื่องจากสถาปัตยกรรมขาดการรองรับ fp8 แบบเนทีฟ w8a8 กับ SmoothQuant (SQ) มีไว้เพื่อให้คล้ายกับ fp8

การปรับปรุงความหน่วงของการควอนไทเซชันอยู่ที่ประมาณ 10% เมื่อเปรียบเทียบ H100 fp16 → fp8 และ A100 fp16 → w8a8 กับ SmoothQuant อย่างไรก็ตาม w4a16 มีประสิทธิภาพที่ดีกว่าที่ขนาดแบตช์ต่ำและแย่กว่าที่ขนาดแบตช์สูงเมื่อเทียบกับ fp16 สิ่งนี้อาจเกิดจากหลายปัจจัย รวมถึงเคอร์เนลการคำนวณที่ได้รับการปรับแต่งน้อยกว่า, เวลาในการแคสต์ระหว่าง int4 และ fp16, และความจริงที่ว่า w4a16 ยังคงใช้จุดลอยตัว 16 บิตสำหรับการเปิดใช้งาน ส่งผลให้ไม่มีการประหยัดในมิติของแคช KV เนื่องจาก w4a16 ยังแสดงความแม่นยำที่ต่ำกว่าด้วย เราจึงสรุปได้ว่าเราควรยึดติดกับ w8a8 SQ สำหรับ A100s และ fp8 สำหรับ H100s

รูปที่ 2 - ปริมาณงานข้ามการกำหนดค่า TP-8 ด้วยสถาปัตยกรรม การควอนไทเซชัน และขนาดแบตช์ที่แตกต่างกัน สำหรับแต่ละสถาปัตยกรรมและการควอนไทเซชัน ขนาดแบตช์ถูกเลือกเป็นค่าที่ใหญ่ที่สุดที่ปฏิบัติตามข้อกำหนดความหน่วงที่ 25600ms (20 โทเค็นต่อวินาทีสำหรับ 512 โทเค็น) เพื่อให้เราเปรียบเทียบการกำหนดค่าที่มีความหน่วงใกล้เคียงกัน ภายใต้ข้อกำหนดนี้ H100 ที่มี BS-128 บรรลุปริมาณงาน 228% เมื่อเทียบกับ A100 BS-64 ที่ใช้การควอนไทเซชันเดียวกัน (fp16) และยังมี latency การตอบสนองที่ต่ำกว่าแม้ว่าขนาดแบตช์จะเพิ่มขึ้นเป็นสองเท่าก็ตาม การควอนไทเซชันด้วย fp8 ช่วยปรับปรุงปัจจัยนี้เป็น 251%

ในสองรูปแรกของเรา เรานำเสนอเฉพาะการกำหนดค่าของ TP-8 เท่านั้น H100 บรรลุความหน่วง 54% และปริมาณงาน 184% เมื่อเทียบกับ A100 เมื่อทั้งคู่ใช้ fp16 / BS-128 / TP-8 ซึ่งปรับ 99เป็นความหน่วง 49% และปริมาณงาน 202% เมื่อใช้ fp8 บน H100 การปรับปรุงประสิทธิภาพนี้สามารถมาจากพลังการประมวลผลและแบนด์วิดท์หน่วยความจำที่เพิ่มขึ้นระหว่าง H100 และ A100 เป็นที่น่าสังเกตว่าความแตกต่างจะเด่นชัดน้อยกว่าภายใต้ขนาดแบตช์ที่ต่ำกว่าซึ่งการใช้อาจต่ำกว่า

ในขณะที่เราสร้างแพลตฟอร์มของเรา เราต้องการปฏิบัติตามข้อกำหนดความหน่วงบางประการสำหรับผู้ใช้ของเราในขณะที่เพิ่มปริมาณงานให้สูงสุด ดังนั้น แทนที่จะเปรียบเทียบ A100 กับ H100 ที่ขนาดแบตช์เดียวกัน จริงๆ แล้วมันสมเหตุสมผลกว่าสำหรับเราที่จะเปรียบเทียบปริมาณงานของพวกเขาภายใต้การกำหนดค่าที่ตรงตามข้อกำหนดความหน่วงเท่านั้น เรากำหนดจุดตัดที่ความหน่วง 25600ms สำหรับการเสร็จสิ้นโทเค็นเอาต์พุต 512 โทเค็น และพบว่า H100 / TP-8 / fp8 / BS-128 ให้ปริมาณงาน 251% เมื่อเทียบกับ A100 / TP-8 / fp16 / BS-64 เนื่องจากสามารถประมวลผลขนาดแบตช์เป็นสองเท่าที่ความหน่วงต่ำกว่า เมื่อพิจารณาว่าการควอนไทเซชันช่วยประหยัดหน่วยความจำ GPU ตอนนี้เราจำเป็นต้องประเมินว่าความขนานของเทนเซอร์สามารถเพิ่มเลเยอร์การเพิ่มประสิทธิภาพถัดไปได้อย่างไร

รูปที่ 3 - ความหน่วงข้ามขนาดแบตช์ที่แตกต่างกันและความขนานของเทนเซอร์สำหรับ H100 fp8 โดยทั่วไปความหน่วงจะเพิ่มขึ้นเป็นสองเท่าเมื่อเพิ่มขนาดแบตช์จาก 1 → 32 และเพิ่มขึ้นเป็นสองเท่าอีกครั้งจาก 32 → 128 TP-2 ช้ากว่า TP-8 ประมาณสองเท่าอย่างสม่ำเสมอเมื่อขนาดแบตช์เท่ากัน การเพิ่มความขนานของเทนเซอร์เป็นสองเท่าพร้อมกับเพิ่มขนาดแบตช์เป็นสองเท่าช่วยให้ความหน่วงค่อนข้างเสถียรเนื่องจากจำนวนแบตช์ที่ประมวลผลต่อ GPU ยังคงเท่าเดิม

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

รูปที่ 4 - ปริมาณงานข้ามขนาดแบตช์ที่แตกต่างกันและความขนานของเทนเซอร์สำหรับ H100 fp8 ปริมาณงานสูงสุดมาจาก TP-2 BS-128 ที่ 460% เมื่อเทียบกับเบสไลน์ของ A100/TP-8/fp16/BS-64 อย่างไรก็ตาม TP-2 BS-128 ยังเป็นผลลัพธ์ที่ช้าที่สุดในรูปที่ 3

การกำหนดค่าที่เพิ่มปริมาณงานสูงสุดของการทดลองของเราคือ H100 / fp8 / TP-2 / BS-128 ที่ 767 โทเค็นเอาต์พุตต่อวินาทีต่อ GPU นี่เป็นการปรับปรุง 460% เหนือ A100 / fp16 / TP-8 / BS-64 อย่างไรก็ตาม มันแลกมาด้วยความหน่วงที่เพิ่มขึ้นเป็นสองเท่า ซึ่งใกล้เคียงกับ 42000ms สำหรับโทเค็นเอาต์พุต 512 โทเค็น ดังนั้นจึงอาจไม่เหมาะสำหรับการกำหนดค่าในการผลิต ผลลัพธ์ของ TP-4 BS-128 (626 โทเค็น/วินาที/GPU ที่เวลาตอบสนอง 26188ms) และ TP-2 BS-32 (435 โทเค็น/วินาที/GPU ที่เวลาตอบสนอง 18821ms) อาจแสดงถึงการแลกเปลี่ยนที่ดีกว่าในเมตริกสำคัญของเรา

ผลลัพธ์ของเราแสดงให้เห็นว่า:

เราบรรลุความหน่วง 54% และปริมาณงาน 184% โดยใช้ H100 เมื่อเทียบกับ A100 ภายใต้การกำหนดค่าเดียวกัน ซึ่งปรับปรุงเป็น 49% และ 202% ตามลำดับเมื่อ H100 ใช้ประโยชน์จากการรองรับ fp8 แบบเนทีฟ

เมื่อเพิ่มปริมาณงานสูงสุดภายใต้ข้อจำกัดความหน่วง H100 / fp8 / TP-8 / BS-128 ให้ปริมาณงาน 251% เมื่อเทียบกับ A100 / fp16 / TP-8 / BS-64 เนื่องจากสามารถประมวลผลแบตช์สองเท่าด้วยความเร็วที่เร็วกว่า

ด้วยการใช้ประโยชน์จาก H100 กับ TP-2 พร้อม fp8 เราสามารถบรรลุปริมาณงาน 373% ของ A100 / fp16 / TP-8 / BS-128 โดยมีความหน่วงเพิ่มขึ้นน้อยกว่า 10%

ขนาดแบตช์และความขนานของเทนเซอร์นำเสนอการแลกเปลี่ยนระหว่างปริมาณงานและความหน่วงสำหรับผู้ดำเนินการระบบอนุมาน LLM

ผลลัพธ์เหล่านี้ทำให้เรารู้สึกมั่นใจเกี่ยวกับการเปลี่ยนผ่านอย่างเต็มรูปแบบไปยัง GPU H100 ในสแต็กฮาร์ดแวร์ที่ขับเคลื่อนด้วย A100 ของเราก่อนหน้านี้ เราตื่นเต้นที่จะสามารถยืนยันการเพิ่มประสิทธิภาพที่โฆษณาโดย NVIDIA และรอคอยความก้าวหน้าครั้งต่อไปในฮาร์ดแวร์เร่งความเร็ว

พรมแดนถัดไปของเราสำหรับการเพิ่มประสิทธิภาพคือการตรวจสอบความแม่นยำและผลกระทบด้านประสิทธิภาพของ structured sparsity และความแม่นยำ int4 ซึ่งอาจช่วยลดพื้นที่หน่วยความจำ GPU ของ Llama 2 70B ได้อย่างมากและให้การปรับปรุงความหน่วงสูงถึง 2x เราตื่นเต้นที่จะเดินทางต่อไปในการอนุมานที่รวดเร็วปานสายฟ้าและหวังว่าจะช่วยให้ผู้ใช้ของเราสามารถสร้างแอปพลิเคชันที่มีประสิทธิภาพบนแพลตฟอร์มของเรา

ในอนาคตอันใกล้นี้ pplx-api จะยกเลิกขีดจำกัดอัตราและเสนอ Perplexity LLM แบบกำหนดเองเพิ่มเติม รวมถึง LLM ที่ขับเคลื่อนด้วยอินเทอร์เน็ตพร้อมการเชื่อมโยงข้อเท็จจริง (grounding)

ลงชื่อสมัครใช้ Perplexity Pro ได้ที่ perplexity.ai/pro รับสิทธิ์เข้าถึง pplx-api ที่ล้ำสมัยของเรา และใช้ประโยชน์จากความสามารถขั้นสูงเหล่านี้ในโปรเจกต์ของคุณ ค้นพบเพิ่มเติมเกี่ยวกับ pplx-api บน บล็อก ของเรา

สนใจร่วมกำหนดอนาคตของ AI หรือไม่? เรากำลังเปิดรับสมัครงาน! ร่วมเป็นส่วนหนึ่งของทีมที่ขับเคลื่อนโครงสร้างพื้นฐาน LLM เชิงสร้างสรรค์ขนาดมหาศาล สำรวจโอกาสต่างๆ ได้ที่ Perplexity Careers

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

การตั้งค่าการทดลอง

เมตริกสำคัญ:

ค่าคงที่:

โมเดล AI

ชุดข้อมูลโทเค็นอินพุต/เอาต์พุต

เวอร์ชันซอฟต์แวร์

ตัวแปร

สถาปัตยกรรม GPU

ความขนานของเทนเซอร์ (Tensor Parallelism)

การควอนไทเซชัน (Quantization)

ขนาดแบตช์ (Batch Size)

ผลลัพธ์

บทสรุป

มีอะไรต่อไป

ผู้เขียน: