Dictionary · ประสบการณ์นักพัฒนา · 168 / 301

Latency

เวลาที่ระบบ AI ใช้ตอบกลับ วัดได้ทั้งเวลากว่าตัวอักษรแรกจะโผล่และเวลารวมกว่าจะได้คำตอบครบ สองค่านี้ห่างกันมากในรุ่นที่คิดก่อนตอบ

Latency คือเวลาที่ระบบใช้ตั้งแต่เรากดส่งคำถามจนได้คำตอบกลับมา ฟังดูเป็นค่าเดียวแต่ในทางปฏิบัติมันคือสองค่าที่คนละเรื่องกัน เอกสารวัดผลของ NVIDIA นิยาม time to first token ว่าเป็นเวลาตั้งแต่ส่งคำขอจนได้รับ token แรกของคำตอบ และนิยาม end to end request latency ว่าเป็นเวลาตั้งแต่ส่งคำขอจนได้รับคำตอบครบทั้งก้อน โดยนับเวลารอคิว การจับกลุ่มคำขอ และเวลาเดินทางบนเครือข่ายรวมอยู่ในนั้นด้วย พูดแบบบ้านๆ ค่าแรกคือกว่าตัวอักษรแรกจะโผล่ ค่าที่สองคือกว่าจะได้อ่านจนจบ งานหนักที่กินเวลาช่วงนี้คือการทำ inference นั่นคือรัน model จริงเพื่อผลิตคำตอบ บน gpu ที่ส่วนใหญ่ต้องแบ่งกันใช้กับคำขอของคนอื่นในเวลาเดียวกัน ส่วนที่เหลือเป็นเวลารอคิวและเวลาบนเครือข่ายที่ถูกนับรวมอยู่ในค่านี้ด้วย เวลาสองฝ่ายในองค์กรเถียงกันว่าระบบเร็วหรือช้า ต้นเหตุมักไม่ใช่ใครโกหก แต่เป็นเพราะคนหนึ่งพูดถึงค่าแรกและอีกคนพูดถึงค่าที่สอง

กลไกข้างในอธิบายได้ด้วยสมการสั้นๆ เอกสารของ NVIDIA เขียนไว้ว่าเวลารวมเท่ากับ time to first token บวกเวลาที่ใช้ผลิตคำตอบที่เหลือ และนิยาม inter token latency ว่าเป็นเวลาเฉลี่ยระหว่าง token สองตัวที่ติดกัน คำนวณจากเวลารวมลบ time to first token แล้วหารด้วยจำนวน token ที่ผลิตออกมาลบหนึ่ง ส่วนคำว่า tokens per second ในเอกสารเดียวกันมีสองค่า ค่าหนึ่งคือ total tokens per second per system ซึ่งหมายถึงปริมาณ token ที่ระบบผลิตได้รวมทุกคำขอที่วิ่งพร้อมกัน อีกค่าหนึ่งคือ tokens per second per user ซึ่งคิดจากความยาวคำตอบหารด้วยเวลารวมของคำขอนั้น เจอตัวเลขนี้ที่ไหนจึงต้องถามก่อนว่าเป็นค่าฝั่งระบบหรือค่าที่ผู้ใช้คนเดียวได้รับ ตัวที่กินเวลามากที่สุดคือการผลิตคำตอบ คู่มือลดเวลาตอบของ openai ระบุว่าการตัดจำนวน token ฝั่งคำตอบลงครึ่งหนึ่งอาจลดเวลาตอบลงราวครึ่งหนึ่ง ขณะที่การตัดความยาว prompt ลงครึ่งหนึ่งช่วยได้เพียง 1 ถึง 5 เปอร์เซ็นต์ ตรงนี้เองที่อธิบายว่าทำไม reasoning-model จึงรู้สึกช้าทั้งที่ความเร็วตอนพิมพ์เท่าเดิม เอกสารของ OpenAI ระบุว่า reasoning token ไม่ถูกส่งออกมาให้เห็นผ่าน API แต่ยังกินที่ใน context window และถูกคิดเงินเป็น output token ตามปกติ แปลว่าช่วงคิดคือช่วงที่เครื่องผลิต token อยู่จริง เพียงแต่เราไม่เห็นมันบนหน้าจอ หน้าวัดผลอิสระอย่าง artificial-analysis จึงแยกสองค่านี้ออกจากกัน คือ time to first token ที่นับ token แรกที่ได้รับ ซึ่งถ้าเป็น model ที่ส่ง reasoning token ออกมาด้วย ค่านี้จะไปจบที่ reasoning token ตัวแรก กับ time to first answer token ที่นับเฉพาะตอนคำตอบจริงเริ่มปรากฏ ซึ่งวัดหลังช่วงคิดจบไปแล้ว ระยะห่างระหว่างสองค่านี้คือช่วงที่หน้าจอดูเหมือนไม่มีอะไรเกิดขึ้น

สำหรับคนทำงาน เรื่องนี้แปลงเป็นสามข้อควรระวัง ข้อแรกคือความลึกของการคิดเป็นปุ่มที่ปรับได้และมันแลกกับเวลาโดยตรง เอกสาร extended thinking ของ Anthropic เขียนไว้ว่างบคิดที่สูงขึ้นทำให้วิเคราะห์ได้ครบถ้วนขึ้น โดยมีผลตอบแทนที่ลดหลั่นลงตามลักษณะงาน และแลกมาด้วย latency ที่เพิ่มขึ้น ข้อควรระวังคือหน้านั้นอธิบายโหมดกำหนดงบคิดเองด้วย budget_tokens ซึ่ง Anthropic ประกาศเลิกใช้บน Claude รุ่น 4.6 และรุ่น 4.7 ขึ้นไปปฏิเสธคำขอที่ใช้ค่านี้ ส่วนรุ่นปัจจุบันย้ายไปคุมความลึกของการคิดผ่าน adaptive thinking กับค่า effort แทน ฝั่งเอกสารของ OpenAI อธิบาย effort ว่าค่าที่ต่ำกว่าเน้นความเร็วและใช้ token น้อยลง ค่าที่สูงกว่าทำให้ model คิดครบถ้วนขึ้นเพื่อคุณภาพที่ดีขึ้น งานตอบคำถามซ้ำๆ จึงไม่จำเป็นต้องวิ่งบนตัวที่คิดหนักที่สุด องค์กรที่แคร์เวลาตอบมักใช้ model-routing ส่งงานง่ายไปหา slm ที่เล็กและเร็วกว่า แล้วเก็บตัวใหญ่ไว้เฉพาะเคสที่ต้องวิเคราะห์จริง ข้อสองคือ latency ที่สูงมากจะกลายเป็นปัญหาทางเทคนิค ไม่ใช่แค่ความรู้สึก เอกสารของ Anthropic แนะนำว่าในโหมดกำหนดงบคิดเอง ถ้าตั้งงบเกิน 32k token ควรย้ายไปใช้ระบบประมวลผลเป็นชุด เพราะคำขอที่รันนานจะไปชนเพดานเวลาของระบบและขีดจำกัดจำนวนการเชื่อมต่อที่เปิดค้างไว้ และหน้าเอกสารเรื่องการส่งคำตอบแบบทยอยของ Anthropic ก็ระบุว่าคำขอที่ตั้งค่า max_tokens ไว้สูง ชุดเครื่องมือของบริษัทบังคับให้ส่งแบบทยอยเพื่อเลี่ยง HTTP timeout ข้อสามคืออย่าเชื่อตัวเลขลอยๆ ตัวเลขความเร็วเปลี่ยนได้ทุกสัปดาห์ตามการปรับระบบของผู้ให้บริการและตามช่วงเวลาที่วัด เวลาใครยกตัวเลขมาอ้าง ให้ถามกลับสองคำถามคือวัดค่าไหนและวัดวันไหน แม้แต่หน้าวัดผลอิสระเองก็ไม่ได้จับเวลาทุกตัวเลขตรงๆ ตัวอย่างเช่น Artificial Analysis ระบุว่าค่าเวลาตอบรวมสำหรับคำตอบยาว 100 token ของเขาคำนวณขึ้นจาก time to first token และความเร็วในการผลิต token ไม่ใช่ค่าที่จับเวลามาทั้งก้อน

ตัวอย่างจากบทสนทนาจริง

หัวหน้าฝ่ายบริการลูกค้า: ตั้งแต่เปลี่ยนไปใช้ model ตัวใหม่ ทีมบ่นกันทั้งวันว่าระบบช้าลงมาก แต่ฝ่าย IT ยืนยันว่าความเร็วเท่าเดิม ตกลงใครถูกคะ

ฝ่าย IT: ถูกทั้งคู่ครับ ตอนคำตอบไหลออกมาแล้วความเร็วเท่าเดิมจริง แต่ตัวใหม่เป็น model ที่คิดก่อนตอบ ช่วงที่มันคิดอยู่หน้าจอยังว่างเปล่า คนใช้ก็นับเวลาช่วงนั้นเป็นความช้าไปด้วย สิ่งที่ทีมรู้สึกคือเวลากว่าคำตอบจะเริ่มโผล่ ส่วนที่เราวัดคือความเร็วต่อ token หลังคำตอบเริ่มแล้ว คนละค่ากันครับ

หัวหน้าฝ่ายบริการลูกค้า: แล้วงานตอบคำถามลูกค้าที่ถามซ้ำๆ ทุกวัน จำเป็นต้องให้มันคิดเยอะขนาดนั้นไหม

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

ระวังสับสนกับ

  • streaming : streaming คือวิธีทยอยส่งคำตอบออกมาทีละส่วนระหว่างที่ยังผลิตไม่เสร็จ ส่วน latency คือค่าเวลาที่ถูกวัด เปิด streaming แล้วผู้ใช้เห็นตัวอักษรแรกเร็วขึ้นจริง และคู่มือของ OpenAI ยังระบุว่า streaming และการทยอยประมวลผลเป็นส่วนย่อยช่วยลดเวลารวมได้จริงเมื่อมองระบบพร้อมผู้ใช้เป็นภาพเดียวกัน เพราะผู้ใช้อ่านคำตอบจบเร็วขึ้น ส่วนการแสดงขั้นตอนการทำงานและหน้าจอรอโหลดต่างหากที่คู่มือจัดว่าให้ผลทางความรู้สึกเป็นหลัก
  • output-tokens : output token คือจำนวนที่ model ผลิตออกมา เป็นตัวขับหลักของเวลาตอบตามคู่มือของ OpenAI แต่คนละหน่วยกับ latency หน่วยหนึ่งนับเป็นจำนวน อีกหน่วยนับเป็นวินาที งานที่ต้องตอบยาวกว่าจึงช้ากว่าโดยธรรมชาติแม้รันบนเครื่องเดียวกัน
  • throughput : throughput คือปริมาณงานที่ระบบรองรับได้ต่อหน่วยเวลาเมื่อรวมทุกคำขอ ส่วน latency คือเวลาของคำขอเดียว สองค่านี้ดึงกันคนละทาง เพราะเอกสารของ NVIDIA นับเวลารอคิวและการจับกลุ่มคำขอไว้ในเวลารวมด้วย ระบบที่จับกลุ่มคำขอเพื่อดัน throughput ให้สูงจึงอาจทำให้คำขอแต่ละตัวรอนานขึ้น

ดูคำนี้ใน Knowledge Atlas →

■ ไม่อยากพลาดของใหม่

อ่านจบแล้วอยากตามเรื่อง AI แบบนี้ต่อทุกวัน เรามีสรุปข่าวภาษาไทยส่งทาง LINE ทุกเช้า กดเพิ่มเพื่อนไว้ได้เลย ไม่มีค่าใช้จ่าย

เพิ่มเพื่อนใน LINE →
QR เพิ่มเพื่อน LINE ของ TRAINIAC AIคอมพิวเตอร์สแกนด้วยมือถือได้เลย

DXObservability