ผมเลิกใช้ Opus กับทุกงานแล้ว แต่ยังใช้ Claude, Kimi, GPT อยู่ ค่าใช้จ่ายด้าน AI ลดลง 43% ในชั่วข้ามคืน

ค่าใช้จ่ายของเซสชันเดียว เมื่อวัดทั้งสองวิธี

ลองใช้ Droid หนึ่งเซสชันที่มีสามงาน: รีเซ็ตระบบรหัสผ่าน, เพิ่มส่วนหัวลิขสิทธิ์, และปรับปรุงบริการการเรียกเก็บเงิน รันทั้งสามงานบน Claude โมเดลชั้นนำอย่าง Opus จะมีค่าใช้จ่ายอยู่ที่ $0.84, $0.62, และ $1.41 รวมเป็น $2.87 สำหรับเซสชันนี้

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

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

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

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

ปัญหาที่ไม่มีใครวัด

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

เซสชันเดียวด้านบนสูญเสียไปประมาณ $1.25 ฟังดูเล็กน้อยจนกว่าคุณจะคูณมันด้วยจำนวนครั้ง ที่ 10,000 เซสชันต่อเดือน การตั้งค่าแบบเดียวกันเปลี่ยนค่าใช้จ่ายที่จำเป็น $16,400 เป็นค่าใช้จ่ายจริง $28,700 ซึ่งเท่ากับ $147,600 ต่อปี ที่จ่ายไปกับการจัดเส้นทางงานประจำผ่านโมเดลชั้นนำที่ไม่จำเป็นต้องใช้

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

→ กฎข้อที่ 1: จำแนกประเภทงานของคุณก่อนสิ่งอื่นใด:

text

1ดูงาน Droid  30 งานล่าสุดของคุณ จัดเป็นสองกลุ่ม:
2
3งานที่คู่ควรกับโมเดลชั้นนำ: งานที่เกี่ยวข้องกับสถาปัตยกรรมระบบ, การรับรองความถูกต้อง, การชำระเงิน,
4ความปลอดภัย, การพึ่งพาข้ามบริการ, อะไรก็ตามที่การผิดพลาดทำให้เสียเวลาในการดีบักหรือ
5ย้อนกลับ การปรับปรุงที่ซับซ้อนเกิน 100 บรรทัดของลอจิกทางธุรกิจ
6
7งานประจำ: อัปเดตเอกสาร, การเปลี่ยนแปลงคอนฟิก, การเพิ่มเทสต์ให้กับฟังก์ชันที่มีอยู่,
8การแก้ไขบั๊กเล็ก ๆ ที่มีสเปกชัดเจน, ส่วนหัวลิขสิทธิ์, การแก้ไข README,
9การสร้างโค้ดเทมเพลต, การโยกย้ายข้อมูลแบบง่าย
10
11นับแต่ละกลุ่ม
12
13จากข้อมูลระดับเซสชันของ Factory:
14งานประเภท "รีเซ็ตรหัสผ่าน": Opus $0.84 เทียบกับจัดเส้นทาง $0.09 ถูกกว่า 89%
15งานประเภท "เพิ่มส่วนหัวลิขสิทธิ์": Opus $0.62 เทียบกับจัดเส้นทาง $0.12 ถูกกว่า 81%
16
17คูณจำนวนงานประจำของคุณด้วยความแตกต่างนั้น
18ช่องว่างนั้นคือภาษีการเลือกโมเดลปัจจุบันของคุณ

→ กฎข้อที่ 2: วัดค่าใช้จ่ายจริง ไม่ใช่การคาดเดา:

text

1ดึงบันทึกเซสชัน Droid เดือนล่าสุดของคุณ
2
3สำหรับแต่ละเซสชัน:
4- ประเภทงาน (จากการจำแนกในกฎข้อ 1)
5- โมเดลที่ใช้
6- ค่าใช้จ่าย
7
8คำนวณ:
9- ค่าใช้จ่ายทั้งหมดของงานประจำที่ใช้โมเดลชั้นนำ
10- ต้นทุนของงานเหล่านั้นหากใช้โมเดลประสิทธิภาพสูง (ลดลง 80-90%)
11- เงินที่ประหยัดได้ต่อเดือนจากการจัดเส้นทาง
12
13นี่คือค่าพื้นฐานของคุณก่อนเปิดใช้งาน Factory Router
14ทีมส่วนใหญ่พบว่า 30-50% ของเซสชันเป็นงานประจำที่ทำงานบนโมเดลชั้นนำ

→ กฎข้อที่ 3: เขียนคำอธิบายงานที่บ่งบอกความซับซ้อน:

text

1วิธีที่คุณอธิบายงานจะบ่งบอกความซับซ้อนให้ระบบจัดเส้นทางรับรู้
2
3สัญญาณความซับซ้อนต่ำ (จัดเส้นทางไปยังโมเดลประสิทธิภาพสูง):
4- "อัปเดตคอนฟิกแบบง่าย ไม่มีลอจิกทางธุรกิจ: เปลี่ยน timeout ใน config.yaml จาก 30 เป็น 60"
5- "เพิ่มคอมเมนต์ JSDoc ที่หายไปให้กับฟังก์ชันยูทิลิตี้ใน /helpers"
6- "อัปเดต README ให้สะท้อนขั้นตอนการ deploy ใหม่"
7
8สัญญาณความซับซ้อนสูง (จัดเส้นทางไปยังโมเดลชั้นนำ):
9- "ปรับปรุง middleware การรับรองความถูกต้องเพื่อรองรับการรวม SSO ใหม่ของเราข้าม 3 บริการ"
10- "ดีบัก race condition ในตัวประมวลผลการชำระเงินที่ปรากฏเฉพาะภายใต้โหลดพร้อมกัน"
11- "ออกแบบระบบจำกัดอัตราใหม่เพื่อรองรับเกณฑ์ต่อผู้เช่า"
12
13คำอธิบายงานที่เฉพาะเจาะจงและมีบริบทครบถ้วนช่วยเพิ่มความแม่นยำในการจัดเส้นทาง
14คำอธิบายที่คลุมเครือจะถูกจัดเส้นทางอย่างอนุรักษ์นิยมไปยังโมเดลชั้นนำ

→ กฎข้อที่ 4: คำนวณ ROI รายปีจากการจัดเส้นทาง:

text

1สูตรประมาณการประหยัดจาก Factory Router:
2
3เซสชันต่อเดือน: [N]
4ค่าใช้จ่ายเฉลี่ยต่อเซสชันโดยไม่จัดเส้นทาง: [ค่าพื้นฐาน Opus ใน $]
5เปอร์เซ็นต์งานประจำ: [% จากการตรวจสอบกฎข้อ 1]
6การลดต้นทุนงานประจำ: 80-90%
7
8ประมาณการประหยัดต่อเดือน:
9N × ค่าพื้นฐาน × %งานประจำ × 0.85 = จำนวนเงินที่ประหยัดได้ต่อเดือน
10
11รายปี: คูณ 12
12
13สำหรับทีมที่รัน 5,000 เซสชัน/เดือน ที่ค่าเฉลี่ย $2.87 โดยมีงานประจำ 40%:
145,000 × $2.87 × 0.40 × 0.85 = $4,879/เดือน = $58,548/ปี
15
16นี่คือขั้นต่ำ Missions (งานอัตโนมัติระยะยาว) จะเพิ่มเงินออมให้มากขึ้นอีก

→ กฎข้อที่ 5: บันทึกว่างานใดบ้างที่ต้องใช้โมเดลชั้นนำสำหรับโค้ดเบสของคุณ:

text

1ก่อนเปิดใช้งานการจัดเส้นทาง ให้กำหนดว่างานใดที่ต้องใช้โมเดลชั้นนำสำหรับโค้ดเบสของคุณ
2
3เขียนสิ่งนี้ครั้งเดียว วางเป็นเกณฑ์พื้นฐานในการให้คำแนะนำการจัดเส้นทาง:
4
5"สิ่งต่อไปนี้ต้องใช้โมเดลชั้นนำเสมอ:
6- การเปลี่ยนแปลงใด ๆ ที่เกี่ยวข้องกับ [เลเยอร์การรับรองความถูกต้อง/การชำระเงิน/ความปลอดภัย]
7- การปรับปรุงข้ามบริการที่มีไฟล์มากกว่า [N] ไฟล์
8- การเปลี่ยนแปลงคอนฟิกไปป์ไลน์ CI/CD
9- การโยกย้าย Schema ฐานข้อมูล
10- สิ่งใดก็ตามที่ถูกแฟล็กเป็น [P0/วิกฤต] ในระบบติดตามปัญหาของเรา
11
12ทุกอย่างอื่นมีสิทธิ์ได้รับการจัดเส้นทางไปยังโมเดลประสิทธิภาพสูง"
13
14นี่จะกลายเป็นเอกสารนโยบายการจัดเส้นทางของคุณ
15คุณจะอัปเดตเมื่อคุณเรียนรู้ว่างานใดที่ต้องใช้การดูแลแบบโมเดลชั้นนำในโค้ดเบสเฉพาะของคุณ

ทีมนักพัฒนา 10 คน, 1,000 เซสชัน/เดือน, งานประจำ 40%: ประหยัดได้ $13,776/ปี ทีมนักพัฒนา 50 คน, 5,000 เซสชัน/เดือน, งานประจำ 40%: ประหยัดได้ $58,548/ปี องค์กรระดับ Enterprise (Nvidia, Adobe): ประหยัดได้หกหลักต่อปี

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

0:28

→ กฎข้อที่ 6: เปิดใช้งาน Factory Router ในขั้นตอนเดียว:

text

1ใน Factory CLI หรือ Desktop App:
2
31. เปิดตัวเลือกโมเดล
42. เลือก "Factory Router"
53. เสร็จ
6
7ไม่ต้องกำหนดค่าใด ๆ เพื่อเริ่มต้น Router จะใช้ลอจิกการจัดเส้นทางเริ่มต้นทันที
8
9เพื่อยืนยันว่าเปิดใช้งานแล้ว:
10รันงานง่าย ๆ ("อัปเดตคอมเมนต์ในไฟล์นี้")
11ตรวจสอบบันทึกเซสชันสำหรับการระบุโมเดลที่ใช้
12คุณควรเห็นโมเดลประสิทธิภาพสูงจัดการงานนี้ ไม่ใช่ Opus
13
14หากคุณเห็น Opus จัดการงานง่าย ๆ ให้ตรวจสอบว่าเลือก Router อยู่และไม่ได้แทนที่ด้วยโมเดลเฉพาะ

→ กฎข้อที่ 7: ตั้งค่าคำแนะนำการจัดเส้นทางสำหรับโค้ดเบสของคุณ:

text

1คำแนะนำการจัดเส้นทางเป็นที่ปรึกษา ช่วยให้ Router ตัดสินใจได้ดีขึ้น
2สำหรับโค้ดเบสเฉพาะของคุณ ไม่ได้บังคับใช้โมเดล
3
4วางข้อความนี้เป็นจุดเริ่มต้นคำแนะนำการจัดเส้นทางและแก้ไขตามสแต็กของคุณ:
5
6"การเปลี่ยนแปลงด้านการรับรองความถูกต้อง, การชำระเงิน, และความปลอดภัย: โมเดลชั้นนำ
7การโยกย้ายฐานข้อมูลและการเปลี่ยนแปลง Schema: โมเดลชั้นนำ
8การเปลี่ยนแปลงสัญญา API ที่ส่งผลต่อผู้ใช้ภายนอก: โมเดลชั้นนำ
9
10การอัปเดตเอกสาร: โมเดลประสิทธิภาพสูง
11การเพิ่มเทสต์ให้กับฟังก์ชันที่มีอยู่: โมเดลประสิทธิภาพสูง
12การเปลี่ยนแปลงคอนฟิกและตัวแปรสภาพแวดล้อม: โมเดลประสิทธิภาพสูง
13การสร้างโค้ดเทมเพลตและโครงสร้างพื้นฐาน: โมเดลประสิทธิภาพสูง
14คอมเมนต์โค้ดและ JSDoc: โมเดลประสิทธิภาพสูง
15การอัปเดต README และ changelog: โมเดลประสิทธิภาพสูง
16
17ทุกอย่างอื่น: Router ตัดสินใจตามบริบทของงาน"

→ กฎข้อที่ 8: กำหนดค่าคำแนะนำการจัดเส้นทางสำหรับการกำกับดูแลระดับ Enterprise:

text

1สำหรับทีมที่รันเอเยนต์ในขนาดใหญ่ คำแนะนำการจัดเส้นทางกลายเป็นเอกสารการกำกับดูแล
2
3เทมเพลตมาตรฐานสำหรับอุตสาหกรรมที่มีการควบคุม (ธนาคาร, การดูแลสุขภาพ, Enterprise SaaS):
4
5"กฎการจัดเส้นทางที่มีความละเอียดอ่อนสูง:
6- สิ่งใดก็ตามที่เกี่ยวข้องกับ [PII / ข้อมูลทางการเงิน / การรับรองความถูกต้อง] = เฉพาะโมเดลชั้นนำ
7- การเปลี่ยนแปลง API ภายนอกใด ๆ = เฉพาะโมเดลชั้นนำ
8- สคริปต์การปรับใช้ใน Production = เฉพาะโมเดลชั้นนำ
9- งานตอบสนองต่อเหตุการณ์ = เฉพาะโมเดลชั้นนำ
10
11การจัดเส้นทางมาตรฐาน:
12- สภาพแวดล้อม Development, Staging, และ Test = Router ตัดสินใจ
13- เครื่องมือภายในและระบบอัตโนมัติ = เลือกใช้โมเดลประสิทธิภาพสูงเป็นหลัก
14- เอกสาร, การรายงาน, และการสื่อสาร = โมเดลประสิทธิภาพสูง
15
16นโยบายการแทนที่:
17นักพัฒนาคนใดก็ได้สามารถขอใช้โมเดลชั้นนำสำหรับงานได้
18Router ถือว่าสิ่งนี้เป็นการแทนที่แบบตายตัว ไม่ใช่คำแนะนำ
19บันทึกการแทนที่โมเดลชั้นนำทั้งหมดเพื่อตรวจสอบรายเดือน"
20
21บันทึกนี้เป็น ROUTING_POLICY.md ในโฟลเดอร์รากของโปรเจกต์
22อ้างอิงใน CLAUDE.md หรือไฟล์บริบทที่เทียบเท่า

→ กฎข้อที่ 9: รัน Missions โดยเปิดใช้งานการจัดเส้นทาง:

text

1Missions คืองานอัตโนมัติระยะยาวของ Factory
2ทำงานเป็นชั่วโมงหรือเป็นวัน ไม่ต้องมีการดูแล
3
4เมื่อเปิดใช้ Factory Router, Missions จะได้รับประโยชน์จากลอจิกการจัดเส้นทางเดียวกัน
5แต่ละขั้นตอนใน Mission จะถูกจัดเส้นทางอย่างเหมาะสม
6ขั้นตอนง่าย ๆ ใน Mission ที่ซับซ้อนจะทำงานบนโมเดลประสิทธิภาพสูง
7Mission จะจ่ายค่าใช้จ่ายระดับโมเดลชั้นนำเฉพาะเมื่อจำเป็นต้องใช้การคิดแบบโมเดลชั้นนำจริง ๆ
8
9วิธีกำหนดค่า:
10เปิดใช้งาน Factory Router ก่อนเริ่ม Mission ใด ๆ
11เพิ่มคำแนะนำการจัดเส้นทางที่สะท้อนโปรไฟล์ความซับซ้อนของ Mission:
12
13"Mission นี้เกี่ยวข้องกับ [งานหลักที่ซับซ้อนสูง] และ [งานสนับสนุนประจำ]
14งานหลัก (การตัดสินใจด้านสถาปัตยกรรม, การวิเคราะห์ความปลอดภัย): โมเดลชั้นนำ
15งานสนับสนุน (เอกสาร, คอนฟิก, โค้ดเทมเพลต): โมเดลประสิทธิภาพสูง
16ใช้โมเดลที่มีประสิทธิภาพสูงสุดเท่าที่มีสำหรับขั้นตอนใด ๆ
17ที่ไม่ต้องการการใช้เหตุผลตามที่ระบุข้างต้น"
18
19Missions ระยะยาวจะประหยัดได้มากกว่าเป็นสัดส่วนเพราะสะสมขั้นตอนประจำมากขึ้น

→ กฎข้อที่ 10: ตั้งค่านโยบายการ Failover ของผู้ให้บริการ:

text

1Factory Router จัดเส้นทางข้ามผู้ให้บริการเพื่อความน่าเชื่อถือ
2หากเส้นทางผู้ให้บริการหนึ่งลดประสิทธิภาพ เซสชันจะดำเนินการต่อผ่านผู้ให้บริการที่ทำงานได้ดี
3
4สำหรับทีม Enterprise ที่มีข้อกำหนดด้านเวลาทำงาน:
5
6"นโยบายการจัดเส้นทางเพื่อความน่าเชื่อถือ:
7- ผู้ให้บริการหลักต่อโมเดล: [ระบุผู้ให้บริการที่คุณต้องการ]
8- เงื่อนไขการ Failover: คำขอใด ๆ ที่ล้มเหลวหรือเกินเวลาแฝง [N] วินาที
9- ลักษณะการ Failover: โมเดลเดียวกัน, ผู้ให้บริการอื่น ถ้ามี
10  หากไม่มีโมเดลเดียวกัน ให้ยกระดับไปยังโมเดลชั้นนำถัดไป
11- TPM เฉพาะ: ยืนยันกับทีมบัญชี Factory สำหรับระดับของคุณ
12- เป้าหมาย: ความน่าเชื่อถือของคำขอ 99.9%+
13
14บันทึกเหตุการณ์ Failover ทั้งหมด ตรวจสอบรายสัปดาห์เพื่อดูรูปแบบสุขภาพของผู้ให้บริการ"

Terminal-Bench 2: อัตราผ่าน 99% ของ Opus ที่ต้นทุนต่ำกว่า 20% Legacy-Bench: อัตราผ่าน 96% ของ Opus ที่ต้นทุนต่ำกว่า 25% ความน่าเชื่อถือของคำขอ 99.9%+ ผ่านการจัดเส้นทางผู้ให้บริการ

3 / 3 | ระบบ: การรัน Factory ในระดับที่เงินออมทบต้น

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

Nvidia. Adobe. EY. Palo Alto Networks. Adyen. เหล่านี้คือลูกค้า Enterprise ของ Factory

ทีมที่รัน 5,000 เซสชันต่อเดือนจะประหยัดเงิน $58,548 ต่อปีจากการจัดเส้นทางเพียงอย่างเดียว ที่อัตรางานประจำ 40% ทีมที่ 50,000 เซสชันจะประหยัด $585,480 ตัวเลขคณิตศาสตร์เพิ่มเป็นเส้นตรงตามปริมาณ แต่บิลโทเคนของ Enterprise ไม่ได้เป็นเส้นตรง

ประเด็นที่ลึกกว่านั้นคือเรื่องสถาปัตยกรรม แพลตฟอร์มเอเยนต์ AI ส่วนใหญ่สร้างบนสมมติฐานโมเดลเดียว ทีมเดียว โมเดลเดียว ผู้ขายเดียว แพลตฟอร์มของ Factory ออกแบบให้ไม่ยึดติดกับโมเดลใดโมเดลหนึ่ง: LLM ใด ๆ (Claude, GPT, Gemini, Llama, โอเพนซอร์ส), อินเทอร์เฟซใด ๆ (CLI, Desktop, VS Code, Slack, GitHub, Linear, Jira, ไปป์ไลน์ CI), ทุกช่วงของวงจรชีวิตซอฟต์แวร์

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

ห้ากฎสุดท้ายจะสร้างระบบ Factory ที่สมบูรณ์รอบ Router

→ กฎข้อที่ 11: วัดเงินออมจากการจัดเส้นทางทุกสัปดาห์:

text

1กำหนดกิจวัตรประจำสัปดาห์เพื่อติดตามประสิทธิภาพของ Router
2
3ตรวจสอบในบันทึกเซสชันของ Factory:
41. จำนวนเซสชันทั้งหมดในสัปดาห์นี้
52. การกระจายโมเดล (งาน % ที่ไปยังแต่ละโมเดล)
63. ค่าใช้จ่ายเมื่อจัดเส้นทางเทียบกับค่าพื้นฐาน (Opus สำหรับทุกอย่าง)
74. เซสชันใดที่ Router ยกระดับไปยังโมเดลชั้นนำ (สัญญาณคุณภาพ)
8
9รูปแบบรายงาน:
10> เซสชัน: [N]
11> การใช้โมเดลประสิทธิภาพสูง: [%]
12> การใช้โมเดลชั้นนำ: [%]
13> ค่าใช้จ่ายจริง: $[จำนวน]
14> ค่าพื้นฐาน (Opus ทั้งหมด) จะเป็น: $[คำนวณ]
15> เงินออมรายสัปดาห์: $[จำนวน]
16> การยกระดับไปยังโมเดลชั้นนำ: [N] (ตรวจสอบเพื่อปรับปรุงคำแนะนำการจัดเส้นทาง)
17
18หากอัตราการยกระดับสูงกว่า 10% ให้ตรวจสอบคำแนะนำการจัดเส้นทางของคุณ
19การยกระดับมากเกินไปหมายความว่างานประจำกำลังถูกอธิบายว่าซับซ้อน

→ กฎข้อที่ 12: ประเมินความพร้อมของ Agent ก่อนเปิดตัวเต็มรูปแบบ:

text

1ก่อนปรับใช้ Factory Router สำหรับทั้งทีม ให้รันการประเมินความพร้อมของ Agent ของ Factory
2
3มันประเมินสัญญาณ 100+ รายการใน:
4- สุขภาพของโค้ดเบส (ความครอบคลุมของเทสต์, ความน่าเชื่อถือของ CI, เอกสาร)
5- วุฒิภาวะของเวิร์กโฟลว์ (กระบวนการ PR, มาตรฐานการตรวจสอบโค้ด, ไปป์ไลน์การปรับใช้)
6- ความพร้อมของทีม (ความคุ้นเคยกับเครื่องมือ Agentic, ระบบอัตโนมัติที่มีอยู่)
7
8ใช้ผลลัพธ์เพื่อจัดลำดับความสำคัญของเวิร์กโฟลว์ที่จะจัดเส้นทางก่อน
9
10เวิร์กโฟลว์ที่มีความพร้อมสูง: ปรับใช้ Router ทันที, เปิดใช้งานการจัดเส้นทางทั้งหมด
11เวิร์กโฟลว์ที่มีความพร้อมปานกลาง: ปรับใช้ Router ด้วยคำแนะนำที่อนุรักษ์นิยม, งานโมเดลชั้นนำมากขึ้น
12เวิร์กโฟลว์ที่มีความพร้อมต่ำ: สร้างความพร้อมก่อนจัดเส้นทาง
13เครื่องมือ Agentic บนโค้ดเบสที่ไม่ได้เตรียมพร้อมจะใช้เวลาบนโมเดลชั้นนำมากขึ้นในการแก้ไขข้อผิดพลาด
14
15เงินออมจาก Router สูงที่สุดในสภาพแวดล้อมที่มีความพร้อมสูง

→ กฎข้อที่ 13: สร้างพูลโมเดลของคุณอย่างตั้งใจ:

text

1Factory Router ดึงจากพูลของโมเดลชั้นนำและโมเดลประสิทธิภาพสูง
2พูลที่คุณกำหนดค่าส่งผลต่อตัวเลือกการจัดเส้นทางที่มี
3
4พูลเริ่มต้นที่แนะนำ:
5
6ระดับชั้นนำ (งานซับซ้อน):
7- Claude Opus (เวอร์ชันล่าสุด)
8- GPT-5.2 (หากอยู่ในรายชื่อผู้ให้บริการที่อนุมัติของคุณ)
9
10ระดับประสิทธิภาพสูง (งานประจำ):
11- Kimi K2.6 (คุ้มค่าที่สุดต่อจุด F1 สำหรับงานโค้ด)
12- MiniMax M2.7 (ต้นทุนต่ำที่สุดสำหรับงานง่าย)
13
14เพิ่มโมเดลเมื่อคุณตรวจสอบประสิทธิภาพบนโค้ดเบสของคุณ
15เริ่มต้นด้วยโครงสร้างสองระดับ
16ขยายเป็นสามระดับ (ชั้นนำ / กลาง / ประสิทธิภาพสูง) เมื่อคุณมีข้อมูลการจัดเส้นทางแล้ว
17
18บันทึกว่าโมเดลใดได้รับการอนุมัติสำหรับข้อกำหนดการปฏิบัติตามข้อกำหนดใด
19หากองค์กรของคุณจำกัดผู้ให้บริการโมเดลบางราย ให้กำหนดค่าพูลตามนั้น
20มีโมเดลโอเพนซอร์สที่โฮสต์ในสหรัฐอเมริกาผ่าน Factory สำหรับสภาพแวดล้อมที่ต้องการที่อยู่ข้อมูล

→ กฎข้อที่ 14: รวมการจัดเส้นทางเข้ากับไปป์ไลน์ CI ของคุณ:

text

1Factory ทำงานในไปป์ไลน์ CI การจัดเส้นทางก็ใช้ที่นั่นด้วย
2
3เพิ่ม Factory Router ลงในเวิร์กโฟลว์ GitHub Actions ของคุณ:
4
5สำหรับการตรวจสอบ Pull Request:
6"จัดเส้นทางงานตรวจสอบ PR ตามขอบเขตการเปลี่ยนแปลงไฟล์
7- การเปลี่ยนแปลงไฟล์ความปลอดภัยและการรับรองความถูกต้อง: โมเดลชั้นนำ
8- ไฟล์เทสต์: โมเดลประสิทธิภาพสูง
9- การเปลี่ยนแปลงเอกสาร: โมเดลประสิทธิภาพสูง
10- PR แบบผสม: จัดเส้นทางทีละส่วนถ้าเป็นไปได้, มิฉะนั้นใช้โมเดลชั้นนำสำหรับการตรวจสอบทั้งหมด"
11
12สำหรับ QA อัตโนมัติ:
13"จัดเส้นทางงาน QA ตามความซับซ้อนของเทสต์
14- เทสต์ end-to-end เส้นทางวิกฤต: โมเดลชั้นนำ
15- การสร้าง Unit Test: โมเดลประสิทธิภาพสูง
16- ชุดเทสต์ Regression: โมเดลประสิทธิภาพสูง"
17
18การจัดเส้นทาง CI จะทบต้นเงินออมเพราะมันทำงานทุก commit
19ความแตกต่างของต้นทุนระหว่าง Opus และ Kimi K2.6 ในการสร้างเทสต์จาก 100 commit ต่อวันนั้นมีนัยสำคัญ

→ กฎข้อที่ 15: จัดตั้งการตรวจสอบนโยบายการจัดเส้นทางรายเดือน:

text

1คำแนะนำการจัดเส้นทางควรพัฒนาไปพร้อมกับการเติบโตของโค้ดเบสและทีมของคุณ
2
3วาระการตรวจสอบรายเดือน (30 นาที):
4
51. รายงานต้นทุน: ตามจริงเทียบกับค่าพื้นฐาน, แนวโน้มการประหยัด
62. การวิเคราะห์การยกระดับ: งานใดที่ถูกยกระดับและเพราะอะไร
73. อัปเดตคำแนะนำการจัดเส้นทาง: คำแนะนำปัจจุบันยังสะท้อนความซับซ้อนของโค้ดเบสอยู่หรือไม่?
84. การประเมินโมเดลใหม่: มีโมเดลใหม่ในพูลที่ควรเพิ่มหรือไม่?
95. ข้อเสนอแนะจากทีม: นักพัฒนาแทนที่ Router บ่อยครั้งหรือไม่? เพราะอะไร?
10
11คำถามที่บ่งบอกว่าคำแนะนำการจัดเส้นทางของคุณจำเป็นต้องอัปเดต:
12- อัตราการยกระดับสูงกว่า 15%: คำแนะนำก้าวร้าวเกินไปต่อโมเดลประสิทธิภาพสูง
13- อัตราการยกระดับต่ำกว่า 2%: คำแนะนำอาจอนุรักษ์นิยมเกินไป, ปล่อยให้เงินออมหายไป
14- อัตราการแทนที่ของนักพัฒนาสูงกว่า 20%: Router ไม่ตรงกับความคาดหวังของนักพัฒนา
15
16อัปเดต ROUTING_POLICY.md หลังการตรวจสอบทุกครั้ง

หากไม่มี Factory Router: ทุกเซสชันทำงานบนโมเดลชั้นนำ โดยไม่คำนึงถึงประเภทงาน หากมี Factory Router: งานประจำบนโมเดลประสิทธิภาพสูง, งานซับซ้อนบนโมเดลชั้นนำ ผลลัพธ์: ลดต้นทุน 20-43% โดยรักษาประสิทธิภาพเกณฑ์มาตรฐานของโมเดลชั้นนำได้ 96-99%

บทสรุป

นี่คือตัวเลขที่ได้

40-60% ของเซสชัน Droid ด้านวิศวกรรมเป็นงานประจำในทีมส่วนใหญ่ เซสชันเหล่านั้นบน Opus: เฉลี่ย $2.87 ต่อเซสชัน เซสชันเหล่านั้นเมื่อจัดเส้นทาง: เฉลี่ย $1.62 ที่ 10,000 เซสชันต่อเดือน: ประหยัดได้ $147,600 ต่อปี

ตัวเลขเกณฑ์มาตรฐานยังคงใช้ได้: อัตราผ่าน 99% ของ Opus บน Terminal-Bench 2 ที่ต้นทุนต่ำกว่า 20% 96% บน Legacy-Bench ที่ต้นทุนต่ำกว่า 25% แคชพร้อมท์ยังคง intact ข้ามการสลับโมเดล ดังนั้นคุณภาพจึงไม่ลดลงเมื่อ Router เปลี่ยนโมเดลกลางเซสชัน การ Failover ของผู้ให้บริการทำให้เซสชันทำงานต่อเนื่องด้วยความน่าเชื่อถือ 99.9%+

Factory Router อยู่ในช่วงพรีวิวการวิจัยแบบส่วนตัว คุณเลือกมันครั้งเดียวในตัวเลือกโมเดล ไม่ต้องตั้งค่าเพิ่มเติม

สิ่งที่ฉันยังพยายามทำความเข้าใจ: คำแนะนำการจัดเส้นทางแบบที่ปรึกษาทำงานได้ดีเพียงใดกับโค้ดเบสประเภทต่าง ๆ การตั้งกฎเช่น "การเปลี่ยนแปลง Auth = โมเดลชั้นนำ, การปรับแต่งเอกสาร = งานประจำ" ฟังดูสะอาดบนกระดาษ จะเกิดอะไรขึ้นเมื่องานอยู่ตรงกลาง? นั่นคือกรณีขอบที่ควรจับตาดูเมื่อทีมเริ่มใช้สิ่งนี้มากขึ้น

15 กฎข้างต้นคือระบบการติดตั้ง เริ่มต้นด้วยกฎข้อที่ 1 และ 6

factory.com

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

บุ๊กมาร์กไว้ก่อนที่มันจะถูกฝัง

ถ้าสิ่งนี้มีประโยชน์ แชร์ให้กับคนที่ต้องการมัน