ความเร็วในการอนุมานสำหรับตัวแทนการเขียนโค้ด: TTFT เทียบกับ Throughput

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

การทดสอบ Cline ล่าสุดทำให้การแบ่งนั้นเห็นได้ชัดเจน ในงานแบบคัดออกสั้นๆ การตั้งค่าที่ใช้คลาวด์ชนะเพราะเริ่มต้นได้เร็วที่สุด ในการทดสอบการอนุมานแบบดิบที่ยาวกว่า การตั้งค่า DGX Spark ในพื้นที่ให้ผลลัพธ์ที่มีความเร็วต่อเนื่องสูงกว่ามากเมื่อเทียบกับ GPU สำหรับผู้บริโภคที่ใช้โมเดลเดียวกันพร้อมการถ่ายโอนหน่วยความจำหนัก สำหรับทีมที่เลือกว่าจะใช้ตัวแทนเขียนโค้ดที่ไหน ความแตกต่างนั้นสำคัญมาก.

การเปรียบเทียบอย่างรวดเร็ว: สิ่งที่การทดสอบแสดงให้เห็น

• การตั้งค่า Mac ที่ใช้คลาวด์ชนะงาน “Thunderdome” สั้นๆ ในเวลา 1.04 วินาที.
• การทดสอบเดียวกันวัด DGX Spark ที่ 42.9 โทเค็นต่อวินาทีในการแข่งขันการอนุมานโดยตรง.
• การตั้งค่า RTX 4090 ทำได้ 8.7 โทเค็นต่อวินาทีพร้อมการถ่ายโอน RAM หนัก.
• เวลาที่ใช้ในการแข่งขันการอนุมานโดยตรงอยู่ที่ 5.11 วินาทีสำหรับ Mac ที่ใช้คลาวด์, 21.83 วินาทีสำหรับ DGX Spark, และ 93.89 วินาทีสำหรับเวิร์กสเตชัน 4090.

รายละเอียดฮาร์ดแวร์ช่วยอธิบายช่องว่าง NVIDIA ภาพรวมระบบ DGX Spark เน้นการออกแบบหน่วยความจำรวม 128 GB ในขณะที่เครื่อง 4090 ในการทดสอบมี VRAM 24 GB และต้องถ่ายโอนโมเดล 120B จำนวนมากไปยัง RAM ของระบบ ซึ่งเปลี่ยนรูปแบบงานทั้งหมด.

ทำไม TTFT ถึงชนะการแข่งขันระยะสั้น

ในงานลำดับเล็กๆ เวลาในการรับโทเค็นแรกเป็นตัวตัดสินผู้ชนะ ระบบแรกที่เข้าใจคำสั่ง สร้างคำสั่งที่ถูกต้อง และดำเนินการจะได้เปรียบที่ระบบอื่นอาจไม่สามารถตามทัน นั่นคือสิ่งที่เกิดขึ้นในการทดสอบ Cline ระยะสั้น.

โครงสร้างพื้นฐานคลาวด์สามารถโดดเด่นในที่นี้เพราะแบ็กเอนด์ได้รับการปรับแต่งแล้วสำหรับเส้นทางตอบสนองที่รวดเร็ว หากงานของคุณส่วนใหญ่เป็นการจัดประเภทที่รวดเร็ว คำสั่งสั้นๆ หรือวงลูปตัวแทนเล็กๆ ที่คำตอบแรกสำคัญมากกว่าการทำงานระยะยาว TTFT ต่ำสามารถเอาชนะเครื่องในพื้นที่ที่แข็งแกร่งกว่าได้.

ทำไมความเร็วต่อเนื่องถึงสำคัญกว่าในเซสชันการเขียนโค้ดจริง

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

ที่ 42.9 โทเค็นต่อวินาที ผลลัพธ์ของ DGX Spark แสดงให้เห็นว่าเกิดอะไรขึ้นเมื่อโมเดลขนาดใหญ่สามารถอยู่ในหน่วยความจำที่รวดเร็วได้ ในทางตรงกันข้าม ผลลัพธ์ของ 4090 แสดงให้เห็นว่าการถ่ายโอนข้อมูลมีค่าใช้จ่ายสูงเพียงใดเมื่อโมเดลมีขนาดใหญ่เกินไปสำหรับ VRAM ในเครื่อง โมเดลในตระกูลเดียวกันสามารถให้ความรู้สึกที่แตกต่างกันอย่างมากขึ้นอยู่กับการจัดวางหน่วยความจำ ไม่ใช่แค่ยี่ห้อหรือราคาของ GPU เท่านั้น.

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

ขนาดของโมเดลเปลี่ยนแปลงเศรษฐศาสตร์

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

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

ตำแหน่งที่ ShareAI เข้ากันได้

ShareAI ช่วยเมื่อคำตอบที่ดีที่สุดไม่ใช่การใช้แบ็กเอนด์เดียวตลอดไป ด้วย โมเดลกว่า 150+ ผ่าน API เดียว, คุณสามารถรักษากระบวนการทำงานของการเขียนโค้ดให้คงที่ในขณะที่เปลี่ยนโมเดลหรือผู้ให้บริการตามงาน นั่นมีประโยชน์เมื่อหนึ่งงานต้องการ TTFT ต่ำ และอีกงานต้องการผลลัพธ์ที่ต่อเนื่องแข็งแกร่งขึ้นหรือราคาที่แตกต่างกัน.

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

วิธีเลือกสแต็กที่เหมาะสม

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

ขั้นตอนถัดไป

หากคุณกำลังประเมินความเร็วในการอนุมานสำหรับตัวแทนการเขียนโค้ด อย่าหยุดที่ตัวเลขพาดหัวเดียว วัดการตอบสนองเริ่มต้น อัตราการสร้างที่ต่อเนื่อง และการแลกเปลี่ยนการดำเนินงานที่สำคัญต่อทีมของคุณ จากนั้นเลือกชั้นการกำหนดเส้นทางที่ช่วยให้คุณปรับตัวได้เมื่อความสำคัญเหล่านั้นเปลี่ยนไป.