ผลลัพธ์ 76x ของ Browser-Agent จาก GPT-6.1 Sol: สิ่งที่ Asana วัดได้จริง

Asana เผยแพร่การศึกษาต้นทุนของบราวเซอร์เอเจนต์เมื่อวันที่ 8 ตุลาคม 2026 และนักพัฒนาของ GPT-6.1 Sol ก็เขียนเรื่องนี้ออกมาในวันถัดมา ภายใต้พาดหัวว่า "Asana ลดต้นทุนโมเดลลง 76 เท่าในการทดสอบบนเบราว์เซอร์ด้วย GPT-6.1 Sol" ตัวเลข 76 เท่านี้เป็นเรื่องจริงในแง่ที่มีคนวัดมันได้ แต่ไม่ใช่ข้อเท็จจริงเกี่ยวกับราคาของ GPT-6.1 Sol มันเป็นข้อเท็จจริงเกี่ยวกับสิ่งที่เกิดขึ้นเมื่อคุณซ่อมแคชพรอมป์ตที่พังบนบราวเซอร์เอเจนต์ แล้วจากนั้นสลับโมเดลที่อยู่เบื้องหลัง การปรับให้เหมาะสมแบบเดียวกันนี้ เมื่อรันบนโมเดลที่ Asana มีอยู่แล้วในโปรดักชัน ซึ่งบริษัทเรียกมันว่า Model B ลดต้นทุนได้ 29 เท่าด้วยตัวมันเอง GPT-6.1 Sol ให้ส่วนที่เหลืออีก 2.6 เท่า การทดลองเหล่านี้ดำเนินการโดย GPT-6 Astra ที่ทำงานอยู่ใน Codex และโมเดลที่อยู่เบื้องหลังเส้นฐานคือโมเดลของคู่แข่งที่ Asana เรียกว่า Model B ดังนั้นจึงมีโมเดลสองระดับจากผู้ขายรายเดียวกันและคู่แข่งอีกรายที่ไม่ได้เอ่ยชื่อ ปรากฏอยู่ในเรื่องนี้ทั้งหมด สิ่งที่ตามมาคือการแยกส่วนของผลลัพธ์ที่คุณลอกไปใช้ได้ในวันจันทร์ ออกจากส่วนที่เป็นของสแตกเฉพาะของ Asana

การเปรียบเทียบที่ระบุไว้อย่างแม่นยำ

สแตกของ Asana สำหรับงานนี้คือ StackAI แพลตฟอร์มระบบอัตโนมัติสำหรับเวิร์กโฟลว์ที่บริษัทเข้าซื้อมา ซึ่งรันบราวเซอร์เอเจนต์ที่นำทางเว็บไซต์ กรอกแบบฟอร์ม และรวบรวมข้อมูลได้โดยไม่ต้องเขียนโค้ด งานทดสอบนี้แคบและเจาะจง: เก็บข้อมูลหกฟิลด์สำหรับหนังสือ 32 เล่มจากแค็ตตาล็อกตัวอย่างสาธารณะ นั่นเป็นตัวแทนของสิ่งที่ลูกค้าบางรายนำไปใช้งาน และยังเล็กพอที่การศึกษาที่มีการรัน 144 ครั้งจะเสร็จภายในหนึ่งสัปดาห์

การออกแบบประกอบด้วยนโยบายแคชและสกรีนช็อตหกแบบ ที่งบประวัติสองระดับ สามการรันต่อเงื่อนไข ครอบคลุมสี่โมเดล — รวม 144 การรัน บวกการทดสอบติดตามผลอีก 12 การรัน ค่าใช้จ่ายคำนวณจากตัวนับโทเคนของผู้ให้บริการแต่ละราย และทุกคำตอบถูกให้คะแนนเทียบกับคำตอบอ้างอิงที่จัดเตรียมไว้อย่างอิสระ สี่โมเดลนั้นประกอบด้วยโมเดลแนวหน้าสามตัวที่ไม่เปิดเผยชื่อ (โมเดล A, B และ C) กับ GPT-6.1 Sol โมเดล A เป็นโมเดลที่เล็กกว่าและถูกกว่า จากอีกห้องแล็บหนึ่ง เปิดตัวฤดูใบไม้ร่วง 2025 ราคาเป็นครึ่งหนึ่งของ GPT-6.1 Sol โมเดล B คือโมเดลที่ใช้งานจริงในการผลิต อยู่ห้องแล็บเดียวกับ A เปิดตัวฤดูร้อน 2026 ราคาเท่ากับ GPT-6.1 Sol โมเดล C เป็นเวอร์ชันใหม่กว่าของโมเดล B เปิดตัวฤดูใบไม้ร่วง 2026 ราคาก็เท่ากับ GPT-6.1 Sol เช่นกัน ทั้งสามตัวไม่ถูกเปิดเผยชื่อในบทความทั้งสองฉบับ ดังนั้นผู้อ่านจึงไม่สามารถทำการเปรียบเทียบซ้ำได้ — ควรรู้ไว้ก่อนที่คุณจะมอง 29 เท่าเป็นตัวเลขเกี่ยวกับโมเดลของคนอื่น นี่เป็นตัวเลขที่ Asana และ OpenAI เผยแพร่ ไม่ใช่ตัวเลขที่ผ่านการตรวจสอบโดยอิสระ

บันไดของผลลัพธ์ ตัวเลขของ Asana เองทั้งหมด:

• การผลิตพื้นฐานบน Model B — อย่างน้อย $36.21 ต่อการรัน อย่างน้อย 22.5 นาทีต่อการรัน การรันพื้นฐานบางรอบชนขีดจำกัดขั้นตอนก่อนที่จะทำงานเสร็จ ดังนั้นค่าเฉลี่ยจึงเป็นค่าต่ำสุด而非ค่าเฉลี่ยที่แท้จริง

• Model B, เอเจนต์ — $1.24 ต่อการรัน เร็วกว่าค่าพื้นฐาน 4 เท่า ลดต้นทุนลง 29 เท่า

• GPT-6.1 Sol เอเจนต์ที่ปรับให้เหมาะสมแบบเดียวกัน — $0.47 ต่อการรันหนึ่งครั้ง ใช้เวลาประมาณสี่นาที ลดต้นทุนลง 76 เท่า และเร็วขึ้น 5 เท่า

• GPT-6.1 Sol ก่อนเทียบกับหลังการแก้ไข — จาก $1.97 เหลือ $0.47 ต่อการรัน ลดลง 4 เท่าจากเฉพาะการเปลี่ยนแปลงแคชและการตัดทอน

เนื่องจาก baseline เป็นขอบล่าง 76x จึงเป็นค่าต่ำสุดในตัวเอง การตีความที่ตรงไปตรงมาคือ "อย่างน้อย 76x" ไม่ใช่ "76x"

สิ่งที่เปลี่ยนแปลงไปจริง ๆ และทำไมมันจึงไม่ใช่ฟีเจอร์ของโมเดล

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

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

การแก้ไขนี้มีสองส่วน อย่างแรก แคชประวัติด้วย โดยมีเครื่องหมายแคชบนผลลัพธ์เครื่องมือล่าสุด อย่างที่สอง หยุดแก้ไขมันทุกครั้งที่เรียก: เก็บสกรีนช็อตไว้และตัดออกเป็นชุด ๆ ในอัตราส่วน 20 ต่อ 1 ดังนั้นเอเจนต์จะถือไว้ได้สูงสุด 20 แล้วจึงตัดกลับเหลืออันล่าสุดเพียงอันเดียว จากนั้นประมาณ 19 การเรียกติดต่อกันจะใช้คำนำหน้าที่ไม่เปลี่ยนแปลงซ้ำ เพิ่มงบประมาณประวัติจาก 120,000 เป็น 480,000 ตัวอักษร เพื่อให้ข้อความเก่าหยุดถูกตัด และผลคำนวณก็ลงตัว: บน GPT-6.1 Sol การเรียกแต่ละครั้งมีค่าใช้จ่ายลดลงประมาณ 3 เท่า เพราะ 89% ของอินพุตมาจากแคช

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

จุดที่การเลือกโมเดลให้ผลจริง

ตัดการแก้ไขเวิร์กโฟลว์ออกแล้วเปรียบเทียบแบบเดียวกันกับแบบเดียวกัน: ที่เอเจนต์ที่ปรับให้เหมาะสมตัวเดียวกัน GPT-6.1 Sol ทำงานได้ถูกกว่า Model B 2.6 เท่า ที่ราคาที่ประกาศไว้เท่ากัน ปัจจัยเพิ่มเติมคือพฤติกรรมการเข้าแคช ไม่ใช่ตารางราคา Sol อ่านอินพุต 89% จากแคช Asana ไม่ได้เผยแพร่สัดส่วนที่เทียบเท่าสำหรับ Model B ดังนั้น 2.6 เท่าจึงเป็นผลลัพธ์ที่วัดได้โดยไม่มีการแยกส่วนที่เผยแพร่ มองว่ามันเป็น "โมเดลนี้ บนเวิร์กโหลดนี้ ใช้แคชได้ดีกว่า" ไม่ใช่เป็นข้อได้เปรียบ 2.6 เท่าโดยทั่วไปเหนือโมเดลที่เราไม่สามารถระบุชื่อได้

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

สำหรับใครก็ตามที่กำลังคิดคำนวณต้นทุนนี้: อัตรา API มาตรฐานของ GPT-6.1 Sol อยู่ที่ $2.00 ต่อล้านโทเค็นอินพุต, $0.10 ต่อล้านโทเค็นอินพุตที่แคชไว้ และ $10.00 ต่อล้านโทเค็นเอาต์พุต ส่วนส่วนลดการอ่านจากแคชของมันคือ 0.05 เท่าของอัตราอินพุต — ซึ่งลึกที่สุดในบัตรราคาปัจจุบันของ OpenAI ส่วน GPT-6 Astra โมเดลที่ทำงานด้านวิศวกรรมใน Codex คิดราคาอินพุต $10.00 และเอาต์พุต $50.00 ซึ่งเป็นช่องว่างห้าเท่าที่กรอบการเปิดตัวของ OpenAI ใช้เป็นจุดเน้น เหตุผลที่การศึกษานี้ให้ผลลัพธ์การรันที่ $0.47 แทนที่จะเป็น $2 นั้นไม่ใช่เพราะบัตรราคา แต่เป็นเพราะ 89% ของคำขอที่มีความซ้ำซากสูงถูกคิดเงินในอัตราเพียงหนึ่งในยี่สิบของอัตราอินพุต บนเอเจนต์ที่ใช้แคชหนัก ๆ บรรทัดส่วนลดมีผลมากกว่าราคาที่พาดหัว และในรายการผู้ให้บริการในแคตตาล็อกของเราเอง ราคาตั้งขายของผู้ให้บริการส่งผ่านพร้อมกับมาร์กอัป 0% ดังนั้นผู้ขายที่ขยับมาตรวัดอินพุตแบบแคชก็จะขยับมันบนบิลของคุณในวันเดียวกัน

ตัวเลขอีกตัวหนึ่งในการศึกษา: งบประมาณประวัติเป็นตัวกำหนดว่าเอเจนต์จะตอบหรือไม่เลย

ต้นทุนต่อการรันคือตัวเลขที่ทุกคนมักอ้างถึง แต่ผลลัพธ์ที่มีประโยชน์กว่าของการศึกษานี้อยู่ที่ความน่าเชื่อถือ และนั่นคือสิ่งที่ผู้ปฏิบัติงานควรอ่านเป็นอันดับแรก

• ที่งบประมาณ 120,000 ตัวอักษร Model C ไม่ได้ตอบเลยในการรันทั้ง 18 ครั้งของมัน และ GPT-6.1 Sol ตอบ 3 จาก 18 ครั้ง — การรันส่วนใหญ่ชนขีดจำกัดขั้นตอนโดยไม่สร้างคำตอบ

• ที่ 480,000 อักขระ ทุกการรันบนโมเดลทั้งสองได้ตอบ โดยแต่ละการรันมีคำตอบที่ถูกต้อง

• โมเดลรุ่นใหม่กว่าใช้ budget ที่เล็กกว่าหมดเร็วขึ้น: Model C ตัดประวัติของตนครั้งแรกเมื่อการเรียกครั้งที่ 10 ส่วน Model A เมื่อการเรียกครั้งที่ 64

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

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

สิ่งที่ควรนำไปจากสิ่งนี้ ตามลำดับ

หากคุณรันเบราว์เซอร์หรือเอเจนต์ที่ใช้คอมพิวเตอร์ มีคันโยกสามข้อในงานศึกษาของ Asana ที่ควรดึงก่อนที่คุณจะดูเรตการ์ด:

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

• ตัดแต่งเป็นชุดๆ การติดตามผลของ Asana พบว่าการเก็บภาพหน้าจอทุกภาพมีค่าใช้จ่าย 1.2x ที่ต่ำกว่าต่อการเรียกใช้เมื่อเทียบกับเงื่อนไขการตัดแต่งที่ดีที่สุดบน Model B และ GPT-6.1 Sol และต่ำกว่าประมาณ 5% บน Model C การตัดแต่งยังคงมีความสำคัญสำหรับงานที่ยาว หน้าต่างบริบทขนาดเล็ก และการอ่านแคชที่มีค่าใช้จ่ายสูง — แต่เหตุผลที่สนับสนุนอัตราส่วนชุด 20:1 คือความเสถียรของแคช ไม่ใช่ตัวภาพหน้าจอเอง

• ตั้งค่างบประมาณประวัติ (history budget) ต่อโมเดลหนึ่ง ๆ และตรวจสอบมันเทียบกับเพดานจำนวนขั้นตอน (step cap) ของคุณ งบประมาณที่พอเหมาะกับโมเดลหนึ่งอาจทำให้โมเดลถัดไปขาดแคลนได้

แนวป้องกันสองข้อจากการศึกษานี้เป็นสิ่งที่มองข้ามได้ง่ายและไม่ควรละเลย ไม่มีการรันใดที่ไปถึงงบประมาณ 480,000 ตัวอักษร ดังนั้นงบประมาณนี้จึงไม่เคยเป็นข้อจำกัดของการรันเหล่านี้ แต่เอเจนต์ที่ค่อย ๆ เบี่ยงเบนจะเติบโตเข้าหาขีดจำกัดบริบทของตัวเอง และหากแคชเสีย ทุกการเรียกจะต้องจ่ายเต็มราคา การจำกัดจำนวนขั้น โทเคน และค่าใช้จ่ายต่อการรัน คือสิ่งที่กำหนดขอบเขตของการรันที่แย่ อีกประการหนึ่ง การศึกษาใช้การรันสามหรือสี่ครั้งต่อเงื่อนไข โดยมีจำนวนการเรียกที่ผันแปร ซึ่ง Asana เองกล่าวว่าเพียงพอที่จะแสดงรูปแบบกว้าง ๆ แต่ไม่เพียงพอที่จะแยกเงื่อนไขที่ต่างกันเพียงไม่กี่เปอร์เซ็นต์ อย่าตีความส่วนต่าง 5% จากสิ่งนี้แล้วสร้างไปป์ไลน์ของคุณใหม่โดยยึดสิ่งนั้น

ส่วนที่ใหม่จริง ๆ และส่วนที่ไม่ได้ใหม่จริง ๆ

ข้อควรระวังเกี่ยวกับการตั้งค่านี้ควรกล่าวไว้อย่างตรงไปตรงมา: โมเดลสี่ตัว โดยสามตัวไม่ระบุชื่อ งานแคบ ๆ เพียงงานเดียวที่มี 32 เล่ม ตัวนับที่ติดตั้งเครื่องมือวัดของ Asana เอง และเอกสารที่ผู้ขายเขียนขึ้นเองซึ่งเป็นที่โฮสต์ผลลัพธ์นี้ ไม่มีสิ่งใดตรงนี้ที่ถูกทำซ้ำนอก Asana แต่กลไกนั้นระบุไว้อย่างครบถ้วน — ประวัติแบบต่อท้ายเท่านั้น (append-only) เครื่องหมายแคชบนผลลัพธ์เครื่องมือตัวสุดท้าย การตัดทิ้งแบบเป็นชุด งบประมาณที่ใหญ่ขึ้น วัดการอ่านแคชด้วยตัวนับของผู้ให้บริการ — และมันเป็นข้อค้นพบประเภทที่ยังคงใช้ได้แม้ถูกระบุแหล่งที่ผิดแล็บ 76x เป็นตัวเลขของ Asana บนภาระงานของ Asana เหตุผลที่มันคุ้มค่าจะอ่านก็คือ มันแสดงให้เห็นกฎที่คุณทดสอบได้ในบ่ายเดียว: เอเจนต์ที่แก้ไขประวัติของตัวเองในทุกสเต็ปกำลังจ่ายราคาเต็มสำหรับบทสนทนาที่มันมีไปแล้ว