แดชบอร์ดของผู้ให้บริการห้าราย คีย์ API สามชุด ปฏิทินการหมุนเวียนสองชุด ความฝืดของงาน AI แบบหลายผู้ให้บริการไม่ปรากฏในบรรทัดงบประมาณใด ๆ — มันปรากฏในระยะเวลาที่คุณใช้ในการส่งมอบสิ่งใด ๆ และในสิ่งที่คุณหยุดพยายามทำเพราะต้นทุนการตั้งค่าไม่คุ้มค่า.
กิจวัตรเวลา 9 โมงเช้า
เปิดแล็ปท็อป กาแฟ ตรวจอีเมล เปิดแดชบอร์ดของ OpenAI ดูการใช้จ่ายเมื่อวาน คลิกตรวจการแจ้งเตือนใด ๆ เปิดคอนโซลของ Anthropic ตรวจยอดเครดิต ตรวจว่าคำเชิญผู้ดูแลระบบขององค์กรจากสัปดาห์ที่แล้วถูกดำเนินการแล้วหรือไม่ เปิด Google AI Studio ดูการใช้เรตลิมิตจากการทดสอบเอเจนต์ที่คุณรันข้ามคืน อาจจะเปิด Replicate หรือ Fireworks หากคุณมีโปรเจ็กต์เสริมที่รันอยู่ที่นั่น ตอนนี้ตรวจ 1Password เพื่อยืนยันว่าข้อมูลรับรองยังไม่ถูกหมุนเปลี่ยนตั้งแต่วันศุกร์
นี่คือส่วนหนึ่งของช่วงเช้าที่นักพัฒนาส่วนใหญ่ที่สร้างบน AI ไม่ค่อยพูดถึง งานก่อนเริ่มงาน 8–15 นาทีของการตรวจข้ามแดชบอร์ดที่คืบคลานเข้ามาในแต่ละวันเพราะไม่มีใครออกแบบรองรับ — มันค่อย ๆ เกิดขึ้น ทีละการสมัครผู้ให้บริการ จนกลายเป็นกิจวัตร เมื่อถึงเวลาที่คุณเริ่มงานที่วางแผนไว้จริง ๆ คุณได้จ่าย “ภาษีด้านประสิทธิภาพการทำงาน” ไปแล้ว ซึ่งคุณไม่ได้บันทึกไว้และไม่อาจเรียกคืนได้
สิ่งที่ไม่มีใครยอมรับอย่างเต็มปาก: นักพัฒนาส่วนใหญ่ที่รันงาน AI แบบหลายผู้ให้บริการได้สร้างกิจวัตรนี้เข้าไปในวันของตนโดยไม่รู้ตัว มันให้ความรู้สึกเหมือน “แค่คอยตามให้ทัน” แท้จริงแล้วมันคือค่าความสูญเสียจากการสลับบริบทที่ทบต้นทบไปทุกวันทำงานของปี และวรรณกรรมด้านผลิตภาพบอกชัดเจนมาหลายทศวรรษแล้วว่าความสนใจที่ถูกแบ่งแยกแบบนี้คือสิ่งที่ทำให้ความเร็วในการส่งมอบงานช้าลง
ความช้าลงนั้นไม่ใช่เรื่องนามธรรม มันปรากฏในสามรูปแบบที่จับต้องได้: ในระยะเวลาที่การเปลี่ยนแปลงเล็กน้อยใช้เวลาเพิ่มขึ้น ในจำนวนโมเดลที่คุณประเมินจริงก่อนตัดสินใจ และในสิ่งที่คุณหยุดพยายามเพราะต้นทุนการตั้งค่าไม่คุ้มที่จะลอง ไม่มีต้นทุนใดปรากฏบนบรรทัดงบประมาณ แต่ทั้งหมดนั้นเป็นจริง และทีมส่วนใหญ่ที่รันสแตกแบบหลายผู้ให้บริการประเมินความสูญเสียนี้ต่ำกว่าความเป็นจริงประมาณหนึ่งลำดับขั้น
ภาษีประสิทธิภาพซ่อนอยู่ที่ไหนจริง ๆ
ถ้าคุณถามนักพัฒนาที่รันสแตก AI แบบหลายผู้ให้บริการว่า “การจัดการคีย์ API ทำให้คุณช้าลงไหม?” คำตอบที่ตรงไปตรงมามักจะเป็น “ไม่เท่าไหร่” แต่ละแรงเสียดทานเล็กน้อย — ล็อกอิน 30 วินาทีตรงนี้ สลับบริบท 90 วินาทีตรงนั้น ค้นหาข้อมูลรับรองห้านาทีสัปดาห์ละครั้ง ไม่มีสิ่งใดรู้สึกเหมือนตัวการที่กินสัปดาห์ของคุณ มันรู้สึกเหมือนการดูแลระบบให้ไฟติดอยู่
นี่คือเหตุผลที่ต้นทุนนี้มองเห็นได้ยาก มันถูกจ่ายเป็นส่วนย่อยเล็กพอให้มองข้าม กระจายไปตามจุดสัมผัสมากพอที่ไม่มีจุดไหนโดดเด่น และเกิดซ้ำบ่อยพอที่คุณหยุดสังเกตความฝืดไปแล้ว งานวิจัยด้านผลิตภาพเรียกสิ่งนี้ว่า “ความสนใจตกค้าง” — เศษความตั้งใจที่ยังติดอยู่กับบริบทเดิมเมื่อคุณสลับไปบริบทใหม่ แดชบอร์ดไม่ใช่ต้นทุน เศษความสนใจที่สะสมต่างหากคือต้นทุน
จุดเสียดทานรายวันสี่ประการ
สี่จุดสัมผัสเฉพาะที่เป็นที่สะสมของต้นทุน แต่ละจุดเล็กน้อย ทั้งสี่รวมกันคือส่วนสำคัญของวันทำงาน
- การค้นหาข้อมูลรับรองเมื่อเริ่มโปรเจ็กต์ใหม่ คุณเปิดโปรเจ็กต์ลูกค้าหรือสร้างฟีเจอร์สาขาใหม่ สิ่งแรกที่ต้องมีคือคีย์ API ที่ถูกต้องสำหรับผู้ให้บริการที่งานนี้จะเรียก นั่นหมายถึงเปิดตัวจัดการความลับ หาเอนทรีที่ถูกต้อง คัดลอกคีย์ที่ถูกต้องไปยังไฟล์คอนฟิกที่ถูกต้อง และตรวจสอบอีกครั้งว่าคุณใช้สภาพแวดล้อมที่ถูกต้อง (dev / staging / prod) บนสแตกหลายผู้ให้บริการ สิ่งนี้เกิดขึ้นหลายครั้งต่อโปรเจ็กต์ — ครั้งละผู้ให้บริการ ความฝืดเล็กน้อยต่อครั้งสะสมขึ้นตลอดปีของโปรเจ็กต์
- การนำทางแดชบอร์ดระหว่างดีบัก คำขอล้มเหลว เป็นเรตลิมิต? โมเดลถูกยกเลิก? ปัญหาการยืนยันตัวตน? ถูกปฏิเสธตามนโยบายเนื้อหา? การหาคำตอบต้องไปที่แดชบอร์ดของผู้ให้บริการที่เกี่ยวข้อง ค้นหาบันทึกคำขอ และอ่านข้อผิดพลาดในรูปแบบเฉพาะของผู้ให้บริการแต่ละราย แต่ละรายจัดระเบียบต่างกัน บันทึกของ OpenAI โผล่มาต่างจากของ Anthropic ต่างจากของ Google คุณจะไม่สังเกตต้นทุนการสลับบริบทระหว่างสามแดชบอร์ดที่แตกต่างกัน จนกระทั่งวันนี้คุณเปิดถึงแดชบอร์ดที่สาม
- การตีความเรตลิมิตข้ามผู้ให้บริการ แต่ละผู้ให้บริการแสดงเรตลิมิตด้วยหน่วยต่างกัน OpenAI ใช้ tokens-per-minute และ requests-per-minute Anthropic ใช้ input tokens per minute และ output tokens per minute เป็นเพดานแยกกัน Google ใช้ requests-per-minute และ tokens-per-day เมื่อคุณชนลิมิต เส้นทางดีบักของคุณขึ้นกับผู้ให้บริการที่คุณดูอยู่ — และโมเดลความคิดที่ต้องใช้เป็นแบบเฉพาะผู้ให้บริการ นี่คือจุดเสียดทานที่กัดแรงที่สุดช่วงตอบสนองเหตุการณ์ เมื่อคุณไม่มีเวลาช้า
- การสลับเอกสารอ้างอิงเมื่ออ่านเอกสาร API คุณกำลังทำ tool use ข้ามสองผู้ให้บริการ เอกสารของ OpenAI โครงสร้างการใช้เครื่องมือเป็น functions พร้อมสคีมาที่เฉพาะเจาะจง เอกสารของ Anthropic โครงสร้างเป็นบล็อก tool_use พร้อมสคีมาเฉพาะ การอ่านทั้งสอง สลับแท็บ แปลแนวคิดในหัวข้ามสองรูปแบบ — นี่คือภาระทางความคิดที่ทำลายสมาธิโดยตรง ครึ่งชั่วโมงของการสลับแท็บเอกสารรู้สึกเหมือนสิบ นาที; เวลาที่เสียจริงใกล้ 45
ไม่มีสิ่งใดเลวร้ายถึงขั้นวิกฤตเป็นรายตัว วิกฤตคือมันเกิดทุกวัน วันละหลายครั้ง ทับซ้อนบนงานที่คุณวางแผนไว้จริง ๆ ต้นทุนความเร็วในการส่งมอบงานคือผลรวมของการสะดุดเล็ก ๆ น้อย ๆ เหล่านั้น คูณด้วยจำนวนวันทำงานในหนึ่งปี
หนึ่งชั่วโมงของงานหน้าตาเป็นอย่างไรในแต่ละการตั้งค่า
วิธีที่ชัดเจนที่สุดในการเห็นภาพคือเปรียบเทียบชั่วโมงเดียวกันบนสองการตั้งค่า: แบบรวมอิงผู้ให้บริการสามรายที่จัดการแยกกัน กับแบบปลายทางที่เข้ากันได้กับ OpenAI เพียงจุดเดียวหลัง ข้อมูลรับรองเดียว งานเดียวกัน นักพัฒนาคนเดียวกัน ผลลัพธ์เดียวกัน — ปริมาณงานที่ต้องทำต่างกันเพื่อไปถึงจุดนั้น
ภารกิจ: สร้างฟีเจอร์ใหม่ที่ใช้ Claude Sonnet 4.6 ในการสร้างหลัก ตกลงไปที่ GPT-5.5 หาก Claude โดนเรตลิมิต และใช้ Gemini 3.1 Pro เพื่อสกัดข้อมูลเชิงโครงสร้างจากผลลัพธ์ เวิร์กโฟลว์ข้ามผู้ให้บริการ — แบบที่กลายเป็นเรื่องปกติในปี 2026
| ขั้นตอน | การตั้งค่าหลายผู้ให้บริการ | การตั้งค่าปลายทางเดียว |
|---|---|---|
| นำข้อมูลรับรองที่ถูกต้องเข้าสู่โปรเจ็กต์ | เปิดแดชบอร์ดของผู้ให้บริการสามราย รายการในตัวจัดการความลับสามรายการ ~6 min. | คัดลอกคีย์ API เดียว ~30 sec. |
| ติดตั้งและตั้งค่า SDKs | Anthropic SDK (ติดตั้งแล้วสำหรับงานอื่น) Google AI SDK (ติดตั้ง + อ่านเอกสารการยืนยันตัวตน) OpenAI SDK (ติดตั้งแล้ว) ~15 min. | OpenAI SDK ติดตั้งแล้ว เปลี่ยน base_url ~30 sec. |
| เขียนคำขอทั้งสาม | รูปแบบคำขอต่างกันสามแบบ ตัวแยกการตอบกลับต่างกันสามชุด รูปแบบข้อผิดพลาดต่างกันสามแบบ ~25 min. | รูปแบบคำขอเดียวกันสำหรับทั้งสามโมเดล ~10 min. |
| ทดสอบว่ากลไกสำรองทำงานครบปลายทาง | ส่งคำขอไปที่ Claude จนโดนเรตลิมิต (หรือจำลองข้อผิดพลาด) ตรวจสอบกลไกสำรอง ~12 min. | ตรรกะเดียวกันแต่ทดสอบกับปลายทางเดียวที่มีรูปแบบข้อผิดพลาดสม่ำเสมอ ~5 min. |
| รวม | ~58 min | ~16 min |
ส่วนต่าง 40 นาทีไม่ใช่ประเด็นหลัก ประเด็นหลักคือการตั้งค่าแบบหลายผู้ให้บริการทำให้คุณต้องสลับบริบทสามครั้งในหนึ่งชั่วโมง — และต้นทุนการสลับบริบทนั้นมองไม่เห็นในใบบันทึกเวลาใด ๆ แต่เป็นจริงในปริมาณงานที่คุณส่งมอบได้ภายในวันศุกร์ การตั้งค่าปลายทางเดียวทำให้คุณอยู่ในโมเดลความคิดเดียว: SDK เดียว ผิวข้อผิดพลาดเดียว ชุดธรรมเนียมเดียว 40 นาทีที่คุณประหยัดได้เป็นเวลาจริงส่วนหนึ่ง ที่เหลือคือเศษความสนใจที่ไม่สะสมเมื่อคุณไม่ต้องเก็บความแปลกเฉพาะของผู้ให้บริการสามรายไว้ในหัวพร้อมกัน
รูปแบบที่ปรากฏ: บนสแตกหลายผู้ให้บริการ ฟีเจอร์ข้ามโมเดลง่าย ๆ ใช้เวลาสร้างนานขึ้น ~3–4 เท่าเมื่อเทียบกับการตั้งค่าปลายทางแบบรวม อัตราส่วนนี้ถือจริงทั้งงานง่ายและงานซับซ้อน เหตุผลไม่ใช่ความยากแบบดิบ — แต่เป็นภาระทางความคิดจากการสลับระหว่างธรรมเนียมของผู้ให้บริการสามรายในทุกขั้นตอนของงาน
อะไรเปลี่ยนเมื่อกิจวัตรรายวันสั้นลง
ต้นทุนมาเป็นส่วนย่อย ประโยชน์เมื่อคุณนำต้นทุนออกก็มาเป็นส่วนย่อย — แต่ส่วนย่อยนั้นทบกลับอีกทาง นักพัฒนาที่ได้คืนเวลา 30 นาทีต่อวันจากการสลับบริบทที่แตกเป็นส่วนจะได้คืนเวลาทำงานประมาณสองชั่วโมงครึ่งต่อสัปดาห์ ตลอดปี นั่นคือประมาณสามสัปดาห์ทำงานเต็มของผลิตภาพที่ได้คืนมา เวลาที่ได้คืนมาไม่ใช่ประโยชน์เดียว — และอาจไม่ใช่สิ่งสำคัญที่สุด มีผลรองสามประการที่สำคัญกว่าในทางปฏิบัติ
คุณทดลองมากขึ้น เพราะการทดลองนั้นต้นทุนต่ำ
บนการตั้งค่าแบบหลายผู้ให้บริการ การลองโมเดลใหม่หมายถึงต้องผ่าน พิธีการผสานการทำงาน: สมัครผู้ให้บริการหากคุณยังไม่มีบัญชี เพิ่มข้อมูลรับรอง ติดตั้ง SDK หากเป็นตัวใหม่ เขียน wrapper ปรับใช้งาน สำหรับนักพัฒนาส่วนใหญ่ เส้นแบ่งสำหรับ “คุ้มไหมที่จะลองโมเดลใหม่นี้?” อยู่ราว ๆ ความพยายามครึ่งวัน สิ่งใดที่ไม่ข้ามเส้นนั้นก็จะไม่ถูกลอง
บนการตั้งค่าปลายทางเดียว การลองโมเดลใหม่คือการเปลี่ยนค่าคอนฟิก เปลี่ยนพารามิเตอร์โมเดลในโค้ด ปรับใช้งาน รันชุดประเมิน เปรียบเทียบ เส้นแบ่งลดจากครึ่งวันเหลือสิบ นาที ทีมที่รันบนปลายทางแบบรวมทดสอบตัวเลือกโมเดลมากกว่า 3–5 เท่าสำหรับงานเดียวกันเมื่อเทียบกับทีมที่รันการเชื่อมต่อหลายผู้ให้บริการโดยตรง — และตัวเลือกที่เหมาะกว่าที่พวกเขาลงเอยด้วยสะท้อนการสำรวจที่กว้างขึ้น คุณทดลองมากขึ้นเพราะการทดลองมีต้นทุนต่ำลง
คุณขยับเร็วขึ้นเมื่อโมเดลใหม่ออก
ในปี 2026 สิ่งนี้สำคัญกว่าปีก่อน ๆ โมเดลระดับแนวหน้าปล่อยทุกไม่กี่สัปดาห์ บางครั้งเปลี่ยนเส้นพรมแดนด้านราคา–คุณภาพอย่างมีนัยสำคัญสำหรับเวิร์กโหลดที่คุณเคยส่งมอบบนตัวเลือกที่ดีที่สุดก่อนหน้า บนการเชื่อมต่อโดยตรงแบบหลายผู้ให้บริการ การประเมินโมเดลใหม่หมายถึงการตั้งค่าผู้ให้บริการใหม่ (หรือเพิ่มโมเดลใหม่เข้ากับการเชื่อมต่อของผู้ให้บริการที่มีอยู่ หรือร้อยโมเดลใหม่ผ่านการเปลี่ยนแปลงของ SDK) กว่าคุณจะมีการเปรียบเทียบที่ยุติธรรม ผ่านไปสองสัปดาห์และความได้เปรียบของผู้ลงมือก่อนก็หายไป
บนการตั้งค่าปลายทางเดียว โมเดลใหม่มักจะปรากฏในแคตตาล็อกของตัวรวมภายในไม่กี่ชั่วโมงหลังเปิดตัวสาธารณะ การทดสอบคือการเปลี่ยนพารามิเตอร์โมเดล การเปรียบเทียบเกิดขึ้นได้ภายในสิ้นวัน สิ่งนี้ทบต้นตลอดปี — ทีมบนปลายทางแบบรวมมักรันบนโมเดลที่เหมาะกับเวิร์กโหลดของตนมากกว่า เพราะต้นทุนการสลับเมื่อมีตัวเลือกที่ดีกว่าปรากฏไม่ใช่ปัจจัยชี้ขาดอีกต่อไป
คุณได้อำนาจในการกำกับเวลาของคุณกลับมา
ต้นทุนที่ยากจะอธิบายของกิจวัตรหลายผู้ให้บริการคือสิ่งที่นักพัฒนารู้สึกชัดที่สุดเมื่อมันหายไป 8–15 นาทีต่อวันของการตรวจแดชบอร์ด ค้นหาข้อมูลรับรอง และสลับบริบทข้ามผู้ให้บริการ ไม่ใช่แค่เวลา — แต่มันคือเวลาที่ใช้ไปกับงานบำรุงรักษาที่ไม่เกี่ยวกับสิ่งที่คุณอยากสร้าง เมื่อเวลานั้นหายไป เช้าก็เริ่มต่างออกไป คุณเปิดแล็ปท็อปและสิ่งแรกที่ทำคือสร้าง ความเป็นเจ้าของเหนือวิธีที่คุณเริ่มวันสำคัญกว่านาทีที่ประหยัดได้ และเป็นสิ่งที่นักพัฒนาที่เปลี่ยนไปแล้วรายงานอย่างสม่ำเสมอว่าเป็นการเปลี่ยนที่สำคัญที่สุด
การเปลี่ยนนิสัยตั้งแต่วันแรก
หากตอนนี้คุณรันการตั้งค่าแบบหลายผู้ให้บริการและต้นทุนข้างต้นคุ้น ๆ การย้ายส่วนใหญ่คือคำถามว่าคุณจะย้ายเวิร์กโหลดใดก่อน กรอบปฏิบัติจริงเกี่ยวกับการเปลี่ยนนี้เกิดขึ้นอย่างไร:
- เวิร์กโหลดแรกที่ย้ายควรเป็นฟีเจอร์ใหม่ ไม่ใช่สิ่งที่มีอยู่แล้ว เลือกฟีเจอร์ที่คุณยังไม่เริ่มสร้าง ชี้มันไปที่การตั้งค่าปลายทางเดียว และส่งมอบผ่านเวิร์กโฟลว์นั้น คุณจะเรียนรู้รูปแบบใหม่บนสิ่งที่ไม่มีต้นทุนการย้าย — ไม่มีการเชื่อมต่อที่มีอยู่ให้สร้างใหม่ ไม่มีทราฟฟิกโปรดักชันให้เสี่ยง พอฟีเจอร์ส่งมอบแล้ว คุณก็รู้ว่าการเปลี่ยนเวิร์กโฟลว์เหมาะกับคุณหรือไม่
- การย้ายครั้งที่สองคือสภาพแวดล้อมสำหรับการสร้างต้นแบบของคุณ ไม่ว่าคุณใช้สิ่งใดเพื่อทดสอบโมเดลใหม่กับเวิร์กโหลดของคุณ — eval harness สมุดบันทึกการวนปรับพรอมต์ สคริปต์เปรียบเทียบ A/B — ย้ายสิ่งนั้นไปที่การตั้งค่าปลายทางเดียวถัดไป ที่นี่คือจุดที่ประโยชน์ด้านการทดลองปรากฏก่อน และจุดที่เส้นแบ่งจาก “ครึ่งวันเพื่อเชื่อมต่อ” เป็น “การเปลี่ยนค่าคอนฟิก” เห็นได้ชัดที่สุด คุณจะเริ่มลองโมเดลมากขึ้นภายในสัปดาห์แรก
- เวิร์กโหลดโปรดักชันที่มีอยู่คือชุดสุดท้ายที่จะย้าย และไม่จำเป็นต้องย้ายทั้งหมด หากคุณมีเวิร์กโหลดโปรดักชันแบบโมเดลเดียวที่รันบนการเข้าถึงผู้ให้บริการโดยตรง — และมันมีเสถียรภาพ ปริมาณสูง และได้ประโยชน์จากราคาฝั่งองค์กรที่เจรจาไว้ — เวิร์กโหลดนั้นอาจเหมาะที่จะอยู่ที่เดิม แพทเทิร์นตัวรวมเป็นเครื่องมือสำหรับเวิร์กโหลดที่มันเข้ากันได้; ส่วนอื่น ๆ อยู่ที่เดิมได้ ทีมส่วนใหญ่ที่รันการตั้งค่าแบบผสมลงเอยด้วยการให้ตัวรวมจัดการงานหลายโมเดลและงานทดลอง และเข้าถึงผู้ให้บริการโดยตรงสำหรับเส้นทางโปรดักชันแบบโมเดลเดียว
- นิสัยการเปิดแดชบอร์ดใช้เวลาประมาณสองสัปดาห์กว่าจะเลิกได้ คุณยังจะเปิดแดชบอร์ดของ OpenAI ในสัปดาห์แรกหรือสองของการตั้งค่าใหม่ — เป็นนิสัย ไม่ใช่ความจำเป็น ภายในสัปดาห์ที่สาม กล้ามเนื้อความจำเปลี่ยน และกิจวัตรตอนเช้าเริ่มด้วยการลงมือทำงานแทนการตรวจข้ามแดชบอร์ด เวลาที่ได้คืนมาไม่ได้มาทั้งหมดตั้งแต่วันแรก; มันสะสมเมื่อรูปแบบนิสัยใหม่ตั้งตัว
สิ่งนี้ทำให้คุณอยู่ตรงไหน
AI แบบหลายผู้ให้บริการไม่ใช่ปัญหาเพราะผู้ให้บริการแต่ละรายแย่ ผู้ให้บริการแต่ละรายโอเค ปัญหาคือสิ่งที่เกิดขึ้นเมื่อคุณรันสามหรือสี่รายพร้อมกัน — ค่าการสลับบริบท พื้นผิวข้อมูลรับรอง การอ้างอิงเอกสารข้ามกัน ความกระจัดกระจายของแดชบอร์ด ไม่มีต้นทุนใดเลวร้ายถึงขั้นวิกฤตเป็นรายตัว วิกฤตคือมันเกิดทุกวัน วันละหลายครั้ง ทับซ้อนบนงานที่คุณวางแผนไว้จริง ๆ
ขั้นต่อไปเชิงปฏิบัติ: จับเวลาตัวเองหนึ่งสัปดาห์ ทุกครั้งที่คุณเปิดแดชบอร์ดผู้ให้บริการ สลับระหว่างเอกสารของผู้ให้บริการ หรือค้นหาข้อมูลรับรอง ให้จดบันทึกไว้ สิ้นสัปดาห์รวมเป็นนาที นักพัฒนาส่วนใหญ่ที่รันสแตกหลายผู้ให้บริการพบว่ายอดรวมทำให้พวกเขาประหลาดใจ — และการเปรียบเทียบกับการตั้งค่าปลายทางเดียวทำให้เหตุผลชัดเจนเอง งานชิ้นคู่กัน, 500 Models, One Endpoint: What That Actually Means for Your Stack, ครอบคลุมด้านสถาปัตยกรรมของการตัดสินใจเดียวกัน; ชิ้นนี้เกี่ยวกับความรู้สึกของการใช้ชีวิตกับมัน
ต้นทุนของ AI แบบหลายผู้ให้บริการถูกจ่ายด้วยความสนใจที่แตกเป็นส่วน ๆ ไม่ใช่ด้วยค่าใช้จ่าย API การฟื้นคืน เมื่อเกิดขึ้น ปรากฏในสามที่: เวลาที่ได้คืนในตอนเช้าของคุณ โมเดลที่คุณลองซึ่งคุณคงข้ามไป และอำนาจในการกำกับวิธีที่คุณเริ่มวัน ไม่มีสิ่งใดปรากฏบนบรรทัดงบประมาณ ทั้งสามอย่างเป็นจริง และนักพัฒนาที่เปลี่ยนไปแล้วให้คะแนนมันเหนือชั่วโมงที่ประหยัดได้จริงอย่างสม่ำเสมอ