GPT-6 Sol ความหน่วง: 102 วินาทีถึงโทเค็นแรก

คุณเปลี่ยนจาก gpt-6-astra ไปใช้ gpt-6-sol เพราะราคาโทเค็นลดลงจาก $10 และ $50 ต่อล้านเหลือ $2 และ $10 ใบแจ้งหนี้ดูดีเยี่ยม จากนั้นเวลาตอบสนอง p95 ของคุณเกินสองนาที โหลดบาลานเซอร์ของคุณเริ่มส่งคืนข้อผิดพลาดเกตเวย์หมดเวลา และฝ่ายสนับสนุนเต็มไปด้วยผู้คนที่ถามว่าทำไมหน้าเว็บค้าง

ไม่มีอะไรเสีย คุณเปลี่ยนลักษณะการทำงานของเวิร์กโหลด ไม่ใช่แค่ราคา

Artificial Analysis วัด GPT-6 Sol ที่ 115.2 โทเค็นเอาต์พุตต่อวินาที โดยมีเวลาถึงโทเค็นแรก 102.15 วินาที GPT-6 Luna วัดที่ 153.9 โทเค็นเอาต์พุตต่อวินาที โดยมีเวลาถึงโทเค็นแรก 124.23 วินาที ตัวเลขทั้งสองนี้มีข้อควรระวังอย่างมาก ซึ่งเป็นครึ่งแรกของบทความนี้ ครึ่งหลังคือสิ่งที่ควรทำกับมัน: วิธีวัดเวลาแฝงของโทเค็นแรกอย่างตรงไปตรงมาบนเวิร์กโหลดของคุณเอง และการเปลี่ยนแปลงการออกแบบสี่ประการที่จะช่วยให้โมเดล 100 วินาทีไม่ทำให้ API ของคุณล่มตามไปด้วย

สำหรับบริบทที่กว้างขึ้นของการเปิดตัว AI รุ่นใหม่สามรุ่นในสองวัน โปรดดูที่ สงครามราคาโมเดลเดือนกันยายน 2026

ตัวเลข และทุกสิ่งที่ผิดพลาดเกี่ยวกับการอ้างอิงมัน

อ่านคอลัมน์ข้อควรระวังก่อนคอลัมน์ตัวเลข

สามสิ่งที่คอลัมน์นั้นกำลังบอกคุณ

นี่คือตัวเลขของ Artificial Analysis ไม่ใช่ของ OpenAI OpenAI ได้เผยแพร่ราคา บริบท ความพร้อมใช้งาน และ ชุดคะแนนมาตรฐาน ในตอนเปิดตัว แต่ไม่ได้เผยแพร่ตัวเลขเวลาแฝงในเอกสารที่เราอ่าน ดังนั้น 102.15 วินาทีจึงเป็นการวัดจากบุคคลที่สามที่ใช้ระบบของตนเองบนเครือข่ายของตนเอง และคุณควรถือว่าเป็นการบ่งชี้แนวโน้มมากกว่าเป็นข้อกำหนด บันทึกไว้ในเอกสารของคุณเองตามที่เราบันทึกไว้ที่นี่

พวกเขากำลังอธิบายรูปแบบการคิด “สูงสุด” (max) ป้ายกำกับความพยายามปรากฏอยู่ทั่วไปในตารางมาตรฐานของทั้งสองผู้จำหน่ายตอนเปิดตัว: ต่ำ, ปานกลาง, สูง, สูงมาก, สูงสุด (low, medium, high, xhigh, max) Max คือจุดสูงสุดของขั้นนั้น และความพยายามในการคิดคือตัวแปรที่ใหญ่ที่สุดที่มีผลต่อเวลาแฝงของโทเค็นแรก การวัดค่าการกำหนดค่าที่ช้าที่สุดไม่ใช่การวัดค่าการกำหนดค่าที่คุณจะใช้งานจริง

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

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

เวลาถึงโทเค็นแรกไม่ใช่ชื่อที่ถูกต้องสำหรับสิ่งที่คุณกำลังวัด

ในโมเดลที่ไม่ได้เน้นการคิด เวลาถึงโทเค็นแรกโดยประมาณคือเครือข่ายบวกคิวบวกการเติมข้อมูลล่วงหน้า มันจะปรับตามความยาวของ prompt และอยู่ที่หลักร้อยมิลลิวินาที

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

มีสองผลลัพธ์ตามมา และทั้งสองอย่างสร้างปัญหาในการใช้งานจริง

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

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

ผลลัพธ์ที่สองคือการจัดอันดับจะพลิกผันขึ้นอยู่กับความยาวของการตอบกลับ Luna มีอัตราโทเค็นที่เร็วกว่าแต่เริ่มต้นช้ากว่า เมื่อนำเส้นทั้งสองมาเปรียบเทียบกัน พวกมันจะตัดกันที่ประมาณ 10,100 โทเค็นเอาต์พุต: ต่ำกว่านั้น Sol จะเสร็จก่อนแม้ว่าจะสร้างช้ากว่า และสูงกว่านั้น อัตราของ Luna ก็คุ้มค่ากับเวลารอที่นานกว่า ในทางปฏิบัติแล้ว สิ่งที่คุณให้บริการแก่ผู้ใช้เกือบจะไม่มีการตอบกลับที่ยาวถึง 10,000 โทเค็น ดังนั้นสำหรับเวิร์กโหลดส่วนใหญ่ โมเดลที่เริ่มต้นช้ากว่าก็คือโมเดลที่ช้ากว่านั่นเอง

อะไรจะพังก่อนเป็นอย่างแรก

ความล้มเหลวไม่ค่อยเกิดจากการเรียกโมเดลโดยตรง แต่มันคือทุกสิ่งทุกอย่างที่ห่อหุ้มอยู่รอบๆ ที่ถูกกำหนดขนาดไว้สำหรับ API ที่รวดเร็ว

การหมดเวลาเมื่อไม่ได้ใช้งาน (Idle timeouts) โหลดบาลานเซอร์, รีเวิร์สพร็อกซี, API เกตเวย์ และแพลตฟอร์มไร้เซิร์ฟเวอร์ ทั้งหมดจะจำกัดระยะเวลาที่การเชื่อมต่อสามารถคงอยู่ได้โดยไม่มีข้อมูลไหลผ่าน ค่าเริ่มต้นจำนวนมากจะอยู่ต่ำกว่าสองนาทีมาก อย่าเชื่อตัวเลขที่คุณอ่านในบล็อกโพสต์ รวมถึงบทความนี้: ไปอ่านการตั้งค่าของคุณเอง การแก้ไขมักจะเป็นคำสั่งเดียว เช่น proxy_read_timeout บน nginx บวกกับการตั้งค่าที่ตรงกันในทุกฮอปที่อยู่ด้านหน้า รวมถึงการตั้งค่าหมดเวลาของ SDK ของไคลเอ็นต์เอง

การลองใหม่ (Retries) นโยบายการลองใหม่ที่สมเหตุสมผลที่ 300 มิลลิวินาทีจะอันตรายที่ 100 วินาที การพยายามสามครั้งพร้อม backoff ตอนนี้กลายเป็นการร้องขอห้านาที และการพยายามใหม่จำนวนมากในช่วงเวลาที่ช้าจะเพิ่มภาระงานพร้อมกันมากขึ้นไปยังปลายทางเดิมที่กำลังมีปัญหาอยู่แล้ว จำกัดการพยายาม ใช้ circuit breaker และทำให้ทุกการเรียกใช้งานเป็น idempotent เพื่อให้การลองใหม่ไม่เรียกเก็บเงินซ้ำหรือเขียนข้อมูลซ้ำ

ความพร้อมกัน (Concurrency) ซึ่งเป็นสิ่งที่ผู้คนมองข้าม กฎของ Little ระบุว่าจำนวนคำขอที่กำลังดำเนินการอยู่เท่ากับอัตราการเข้าถึงคูณด้วยเวลาในระบบ ด้วยคำขอหนึ่งครั้งต่อวินาทีและการเรียกใช้งาน 120 วินาที คุณต้องมีคำขอที่กำลังดำเนินการอยู่พร้อมกันถึง 120 ครั้งจึงจะตามทัน การเชื่อมต่อเหล่านั้นจะครอบครองซ็อกเก็ต, เธรด หรือการเรียกใช้ฟังก์ชันเป็นเวลาสองนาทีแต่ละครั้ง และไม่มีส่วนใดปรากฏในบิลโทเค็น โมเดลที่มีราคาถูกต่อการเรียกใช้งานยังคงมีราคาแพงต่อวินาทีของความจุที่ถูกครอบครอง

ส่วนติดต่อผู้ใช้ (The user interface) ไม่มีตัวหมุนใดจะอยู่รอดได้ 102 วินาที หากระยะการคิดอยู่ในเส้นทางการร้องขอแบบซิงโครนัสของคุณ การแก้ไขคือการออกแบบเชิงสถาปัตยกรรม ไม่ใช่แค่การตกแต่ง

วิธีวัดผลบนเวิร์กโหลดของคุณเอง

ตัวเลขจากผู้จำหน่ายและบุคคลที่สามเป็นสมมติฐานเริ่มต้น Prompt ของคุณ ภูมิภาคของคุณ การตั้งค่าความพยายาม และรูปแบบการรับส่งข้อมูลของคุณเป็นตัวกำหนดตัวเลขที่แท้จริง

curl -N -s -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} first_byte=%{time_starttransfer} total=%{time_total}\n' \
  https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-6-sol","input":"Summarise this OpenAPI operation.","stream":true}'

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

การจับเวลา delta ของเนื้อหาแรกคือการวัดที่สำคัญ:

import time
from openai import OpenAI

client = OpenAI(timeout=600)

t0 = time.perf_counter()
first_content = None

with client.responses.stream(
    model="gpt-6-sol",
    input=PROMPT,
    reasoning={"effort": "low"},
) as stream:
    for event in stream:
        if event.type == "response.output_text.delta" and first_content is None:
            first_content = time.perf_counter() - t0
    total = time.perf_counter() - t0

print(f"ttft={first_content:.2f}s total={total:.2f}s")

ชื่อฟิลด์และเหตุการณ์ในส่วนย่อยเหล่านี้มาจากรูปแบบ OpenAI API ปัจจุบัน ไม่ใช่จากการประกาศเปิดตัว GPT-6 ดังนั้นโปรดตรวจสอบกับเอกสารอ้างอิงก่อนที่จะนำไปใช้งาน วินัยในการวัดผลคือสิ่งที่สำคัญ: บันทึกเวลาถึงโทเค็นเนื้อหาแรกและเวลารวมเป็นเมตริกแยกกัน เก็บไว้ตามแต่ละโมเดลและระดับความพยายาม และรายงาน p95 แทนค่าเฉลี่ย เวลาแฝงของโทเค็นแรกในโมเดลที่เน้นการคิดมีการกระจายตัวแบบหางยาว (long tail) และค่าเฉลี่ยจะซ่อนคำขอที่หมดเวลาไว้

รันสิ่งนั้นเป็นการตรวจสอบตามกำหนดเวลา แทนที่จะเป็นครั้งเดียว บันทึกคำขอสตรีมมิงใน Apidog, ยืนยันเวลาตอบสนอง, และรันสถานการณ์ตามกำหนดเวลาใน CI เพื่อให้การถดถอยจากฝั่งผู้ให้บริการหรือการเปลี่ยนแปลงระดับความพยายามแสดงเป็นผลการทดสอบที่ล้มเหลวแทนที่จะเป็นตั๋วสนับสนุน โปรเจกต์เดียวกันนี้ยังช่วยให้งานส่วนหน้าหลีกเลี่ยงการรอได้: ชี้ไคลเอ็นต์ไปยัง Apidog mock ของ endpoint ของคุณเอง เพื่อไม่ให้ใครถูกบล็อกสองนาทีต่อการทำซ้ำในขณะที่การผสานรวมจริงยังคงอยู่ หากคุณต้องการพื้นฐานเบื้องหลังเมตริก คู่มือของเราเกี่ยวกับ เวลาแฝงของ API ครอบคลุมคำศัพท์ที่เกี่ยวข้อง

สี่การเปลี่ยนแปลงที่ช่วยได้จริง

แยกการเรียกใช้การคิดออกจากเส้นทางซิงโครนัส รับคำขอ ส่งคืน 202 Accepted พร้อม job id ทันที และส่งผลลัพธ์ผ่านการ polling หรือ webhook นี่คือการเปลี่ยนแปลงเดียวที่ทำให้ปัญหาอื่นๆ ทั้งหมดเล็กลง เพราะ 102 วินาทีจะไม่ถูกใช้ภายในคำขอ HTTP ที่บางสิ่งอยู่เหนือรออยู่

กำหนดเส้นทางตามความพยายาม ไม่ใช่ตามโมเดล ตัวเลขที่วัดได้อธิบายถึงการคิดสูงสุด (max reasoning) การรับส่งข้อมูลส่วนใหญ่ไม่จำเป็นต้องใช้มัน จำแนกงานก่อน ส่งงานส่วนใหญ่ที่เป็นประจำด้วยความพยายามต่ำ และสงวนการตั้งค่าที่แพงสำหรับกรณีที่จำเป็นจริงๆ ด้วยเหตุผลนี้เองที่ OpenAI รายงานผลมาตรฐานการเปิดตัวตามระดับความพยายาม ดังนั้นการตั้งค่านี้จึงเป็นปัจจัยสำคัญในการตัดสินใจออกแบบ ไม่ใช่แค่รายละเอียดการปรับแต่ง

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

จัดงบประมาณเวลาจริงแยกต่างหากจากโทเค็น ต้นทุนต่อภารกิจและเวลาแฝงต่อภารกิจเป็นปัจจัยอิสระ และการเปิดตัวในเดือนกันยายนได้เปลี่ยนหนึ่งในนั้นอย่างมาก ให้มีงบประมาณเวลาแฝงต่อ endpoint ควบคู่ไปกับงบประมาณค่าใช้จ่าย และถือว่าการถดถอยใดๆ ในทั้งสองอย่างเป็นตัวบล็อกการเปิดตัว

สิ่งหนึ่งที่ไม่ควรถือเอาเอง: การเปิดตัวการแคช prompt ของ GPT-6 ช่วยลดราคาการอ่านอินพุตที่แคชไว้ได้ 90% และเพิ่มอัตราการเข้าถึง ซึ่งเป็นการประหยัดที่แท้จริง ไม่มีผู้จำหน่ายรายใดเผยแพร่การอ้างสิทธิ์เรื่องเวลาแฝงสำหรับมัน ดังนั้นให้ถือว่าการปรับปรุงโทเค็นแรกจากการแคชเป็นสิ่งที่ต้องวัดผลมากกว่าที่จะวางแผนไว้

โมเดลราคาถูกไม่ใช่โมเดลที่เร็ว

GPT-6 Sol ที่ราคา $2 และ $10 ต่อล้านโทเค็นเป็นการเคลื่อนไหวราคาที่แท้จริง และผลลัพธ์มาตรฐานที่อยู่เบื้องหลังก็แข็งแกร่ง แต่ไม่มีสิ่งใดทำให้มันเริ่มต้นได้เร็ว จากการวัดเวลาแฝงสาธารณะเพียงหนึ่งเดียวที่มีอยู่ โมเดลที่ช่วยให้คุณประหยัดค่าโทเค็นของ Astra ได้ 80% ต้องใช้เวลานานกว่าหนึ่งนาทีครึ่งก่อนที่จะพูดอะไรออกมา และโมเดลน้องที่ราคาถูกกว่าก็ยังใช้เวลานานกว่านั้นอีก

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