คู่มือการตัดสินใจสำหรับผู้นำฝ่ายวิศวกรรม
ทีมวิศวกรรมของคุณควรโฮสต์โมเดลโค้ดดิ้งแบบ Open-Weight เองหรือไม่?
วิศวกร 2,000 คนของ Revolut บอกว่าขึ้นอยู่กับปริมาณงาน ไม่ใช่อุดมการณ์
คำตอบขึ้นอยู่กับจำนวนวิศวกร ทักษะด้าน GPU และ ops ภายในองค์กร และความต้องการด้าน data residency ไม่ใช่แค่คุณภาพของโมเดลอย่างเดียว Revolut โฮสต์โมเดล open-weight เองที่ขนาดวิศวกรราว 2,000 คน และลดค่าใช้จ่าย API ระดับแนวหน้าลงประมาณ 90% แต่ยังเก็บเครื่องมือระดับแนวหน้าไว้ใช้สำหรับปัญหาที่ยากที่สุด ทีมขนาดเล็กกว่านี้มักจะพบว่า API ระดับแนวหน้ายังคุ้มค่ากว่าในการใช้งาน
เผยแพร่เมื่อ
สรุปประเด็นสำคัญ
- ที่ขนาดวิศวกรราว 2,000 คน Revolut โฮสต์ GLM ของ Z.ai เองบน GPU Nvidia B200 จำนวน 56 ตัว และลดต้นทุน token แบบผสมลงเหลือประมาณหนึ่งในสิบของค่าใช้จ่าย Anthropic และ OpenAI ก่อนหน้านี้
- Lead time (จำนวนวันตั้งแต่เริ่มหยิบฟีเจอร์มาทำจนพร้อม merge) ดีขึ้นมากกว่าเวลาที่ใช้เขียนโค้ด คือประมาณ 70% เทียบกับ 60% ซึ่งเป็นหลักฐานว่าคอขวดจริงไม่เคยอยู่ที่การเขียนโค้ดอย่างเดียว
- ผลลัพธ์ที่ดีขึ้นสัมพันธ์กับการยกเลิกโควต้า token ไม่ใช่แค่การเปลี่ยนโมเดลอย่างเดียว เมื่อ token ไม่ขาดแคลนอีกต่อไป วิศวกรก็เริ่มใช้ AI กับอีเมล ตั๋วงาน และเอกสารด้วย
- การโฮสต์เองต้องใช้งานด้านโครงสร้างพื้นฐานจริงจัง ไม่ใช่แค่ดาวน์โหลดเวทมา: การปรับ context length, quantization และ parallelism ช่วยลด time-to-first-token ลง 88% โดยใช้จำนวน GPU เท่าเดิม
- Revolut ยังคงเก็บ Claude Code ของ Anthropic, Codex ของ OpenAI และ Gemini ของ Google ไว้เป็นข้อยกเว้นระดับแนวหน้าสำหรับปัญหาที่ยากที่สุด ไม่ใช่ตัวเลือกหลักที่ใช้ทุกวัน
คู่มือฉบับเต็ม
แตะที่หัวข้อใดก็ได้เพื่อเปิดอ่าน
เกี่ยวกับคู่มือนี้
นี่คือคู่มือสำหรับผู้นำฝ่ายวิศวกรรมที่กำลังตัดสินใจว่าจะโฮสต์โมเดลโค้ดดิ้งแบบ open-weight เองหรือไม่ เช่น GLM ของ Z.ai แทนการจ่ายเงินตามจำนวนที่นั่งหรือ token ให้กับ API ระดับแนวหน้า บทความนี้อ้างอิงจากข้อมูลที่ Revolut เปิดเผยต่อสาธารณะ: ธนาคารที่ย้ายวิศวกรส่วนใหญ่จากทั้งหมดราว 2,000 คนออกจากการเก็บเงินตาม token โดยยังคงใช้ Claude Code ของ Anthropic, Codex ของ OpenAI และ Gemini ของ Google สำหรับปัญหาที่ยากที่สุด บทเรียนไม่ได้อยู่ที่ Revolut เลือกโมเดลไหน แต่อยู่ที่สิ่งที่เปลี่ยนไปเมื่อ token ไม่ถูกจำกัดปริมาณอีกต่อไป
โฮสต์เองเทียบกับ API หรือแผนรายที่นั่งระดับแนวหน้า: เช็กลิสต์การตัดสินใจ
| ปัจจัย | เอียงไปทางโฮสต์ open-weight เอง | เอียงไปทาง API หรือแผนรายที่นั่งระดับแนวหน้า |
|---|---|---|
| ขนาดทีมและปริมาณการใช้ token | วิศวกรหลักร้อยถึงหลักพันคนที่สร้างปริมาณ token รายวันสูงและคงที่ เช่นที่สเกลวิศวกรราว 2,000 คนของ Revolut | ทีมขนาดเล็กหรือขนาดกลางที่ภาระด้าน GPU และ ops จะมีต้นทุนมากกว่าบิล API ที่กำลังจะมาแทนที่ |
| ทักษะด้าน GPU และ ops ภายในองค์กร | คุณมีโครงสร้างพื้นฐาน GPU อยู่แล้ว หรือจ้างคนมาดูแลได้: การปรับแต่ง serving stack, quantization และการวางแผน capacity เป็นงานที่เกิดขึ้นจริงและต่อเนื่อง | ไม่มีทีมโครงสร้างพื้นฐาน ML โดยเฉพาะ และไม่อยากสร้างทีมขึ้นมาเพียงเพื่อ serve โมเดลโค้ดดิ้ง |
| Data residency และการปฏิบัติตามกฎระเบียบ | โค้ดหรือ context ต้องไม่ออกจากโครงสร้างพื้นฐานที่คุณควบคุม หรือผู้กำกับดูแลต้องการให้ระบุชัดเจนว่า inference เกิดขึ้นที่ไหน | เงื่อนไขการจัดการข้อมูลมาตรฐานของผู้ให้บริการตอบโจทย์ข้อกำหนดด้านการปฏิบัติตามกฎระเบียบและ data residency ของคุณอยู่แล้ว |
| ตัวเลือกสำรองสำหรับปัญหาที่ยากที่สุด | มีงบสำหรับใช้ API ระดับแนวหน้าเป็นครั้งคราว เผื่อไว้สำหรับงานส่วนน้อยที่โมเดล open-weight จัดการได้ไม่ดี | งานส่วนใหญ่ของคุณเป็นปัญหาที่ยากและหลากหลายแบบที่โมเดลระดับแนวหน้าถูกปรับแต่งมาเพื่อรับมือ ไม่ใช่งานเขียนโค้ดประจำวัน |
| ความคาดการณ์ได้ของค่าใช้จ่าย เทียบกับความยืดหยุ่น | คุณต้องการต้นทุนโครงสร้างพื้นฐานที่คงที่และคาดการณ์ได้ แทนบิลที่เปลี่ยนไปตามการใช้งานและการเปลี่ยนราคาของโมเดล | คุณต้องการเปลี่ยนโมเดลหรือผู้ให้บริการได้อย่างรวดเร็วโดยไม่ต้องปรับแต่ง serving stack ใหม่ และการใช้งานไม่สม่ำเสมอมากเกินกว่าจะกำหนดขนาด GPU ได้ |
กรณีศึกษาต้นทางสิ่งที่ Revolut ทำและวัดผลจริง
David Abitbol ผู้ดูแลงานปฏิบัติการด้าน AI ของ Revolut อธิบายการ rollout นี้ในงานบรรยายที่ AI Engineer's New York conference ช่วงปลายปี 2026 Revolut ติดตามตัวเลขสองตัวจากกลุ่มตัวอย่างวิศวกรราว 2,000 คน ได้แก่ เวลาที่ใช้เขียนโค้ดเป็นชั่วโมง และ lead time เป็นวันตั้งแต่เริ่มหยิบฟีเจอร์มาทำจนถูก merge และพร้อม deploy
การ rollout ช่วงแรกของ Gemini ของ Google ที่เข้าถึงข้อมูลภายในได้ ช่วยให้ตัวชี้วัดทั้งสองดีขึ้นเล็กน้อย ส่วนใหญ่มาจากการแทนที่การค้นเอกสารประกอบ ต่อมา Claude Code ของ Anthropic ถูกนำออกใช้ภายใต้โควต้า token ต่อวิศวกรที่เข้มงวด หลังจากวิศวกรบางคนใช้จนค่าใช้จ่ายสูงโดยไม่ได้ผลลัพธ์ชัดเจน และ Abitbol กล่าวว่าในช่วงแรกแทบไม่เห็นผลที่วัดได้
สิ่งที่ทำให้ตัวเลขเปลี่ยนไปคือการโฮสต์โมเดล open-weight เองอย่าง GLM ของ Z.ai ซึ่งเริ่มใช้ราวเดือนเมษายน 2026 โดยไม่มีการจำกัด token เลย เวลาเขียนโค้ดดีขึ้นประมาณ 60% และ lead time ดีขึ้นประมาณ 70% ปัจจุบัน Revolut ใช้โมเดลที่โฮสต์เองเป็นตัวเลือกหลักสำหรับงานเขียนโค้ดประจำวัน ด้วยค่าใช้จ่ายที่คงที่และคาดการณ์ได้ และเก็บเครื่องมือระดับแนวหน้าไว้เป็นข้อยกเว้นสำหรับปัญหาที่ยากที่สุด
ที่ขนาดวิศวกรราว 2,000 คน การ serve โมเดลนี้ต้องใช้ GPU Nvidia B200 จำนวน 56 ตัว โดยตั้งเป้า time-to-first-token ให้ต่ำกว่าสามวินาที (เริ่มมีการร้องเรียนเมื่อเกินห้าวินาที) ต้นทุนแบบผสมออกมาอยู่ที่ประมาณ $0.30 ต่อล้าน token ซึ่งอยู่ที่ราวหนึ่งในสิบของค่าใช้จ่ายที่ Revolut เคยจ่ายให้ Anthropic และ OpenAI รวมกัน
บทเรียนที่แท้จริงบทเรียนไม่ได้อยู่ที่โมเดล แต่อยู่ที่การจำกัดปริมาณ
การตีความข้อมูลของ Abitbol เองคือส่วนที่มีประโยชน์ที่สุด: lead time ดีขึ้นมากกว่าเวลาเขียนโค้ด ซึ่งหมายความว่าการเขียนโค้ดไม่เคยเป็นคอขวดหลัก เมื่อไม่มีใครต้องเก็บ token ไว้สำหรับตั๋วงานที่ยากที่สุดของไตรมาส วิศวกรก็เริ่มใช้ AI กับอีเมล Jira, Confluence และงานอื่น ๆ ที่อยู่รอบ ๆ ฟีเจอร์ ไม่ใช่แค่ตัวโค้ดเอง
บทเรียนนี้ใช้ได้ไม่ว่าทีมจะใช้โมเดลไหน ทีมที่ใช้ API ระดับแนวหน้าแล้วกำหนดโควต้า token ต่อวิศวกร หรือจำกัดการใช้งานเพื่อคุมต้นทุน กำลังสร้างปัญหาการจำกัดปริมาณแบบเดียวกับที่ Revolut แก้ไปด้วยการยกเลิกข้อจำกัด วิธีแก้ไม่จำเป็นต้องเป็นการโฮสต์เองเสมอไป บางครั้งก็เป็นแผนราคาที่ถูกกว่าหรือคงที่กว่าบนโมเดลระดับแนวหน้าตัวเดิม
ข้อสรุปเชิงปฏิบัติสำหรับผู้นำฝ่ายวิศวกรรมคือ ให้วัด lead time ไม่ใช่แค่เวลาเขียนโค้ดหรือจำนวนบรรทัดที่สร้างได้ ก่อนตัดสินว่าเครื่องมือ AI คุ้มค่าหรือไม่ และสังเกตว่าวิศวกรกำลังจำกัดการใช้งานของตัวเองเพราะแรงกดดันด้านต้นทุนหรือโควต้าหรือไม่
หน้านี้มุ่งเน้นที่การตัดสินใจเรื่องต้นทุนทีมและการ rollout: จะโฮสต์เองหรือไม่ และจะ rollout อย่างไรเมื่อตัดสินใจแล้ว สำหรับคำถามที่กว้างกว่าและไม่ผูกกับโมเดลใดโมเดลหนึ่ง ว่า open weights, open source และ closed API หมายความว่าอย่างไรจริง ๆ และเหตุใดห้องแล็บและรัฐบาลจึงมองต่างกัน คู่มือของ Nightschool AI เรื่อง Open-Source vs Closed AI Models ครอบคลุมเรื่องนี้อย่างครบถ้วน
ปรับแต่งก่อนขยายสเกลการโฮสต์เองต้องใช้งานวิศวกรรม ไม่ใช่แค่เวท
ตัวเลขด้านโครงสร้างพื้นฐานของ Revolut เป็นข้อเตือนใจที่มีประโยชน์ว่าอย่าคิดว่าการโฮสต์เองจะง่ายทันทีที่มี GPU ตั้งแต่เดือนเมษายนถึงสิงหาคม 2026 โดยจำนวน GPU คงที่อยู่ที่ 56 ตัว โหลดเพิ่มขึ้นจากราว 3 เป็นมากกว่า 7 request ต่อวินาที ขณะที่ time-to-first-token ลดลงจากประมาณ 14 วินาทีเป็นต่ำกว่า 2 วินาที คิดเป็นการปรับปรุง latency ถึง 88% โดยไม่ต้องใช้ฮาร์ดแวร์ใหม่
Abitbol ให้เครดิตผลลัพธ์ประมาณ 80% ของที่ดีขึ้นนี้กับการตั้งค่า serving ไม่ใช่ตัว GPU เอง: การจำกัด context length ให้ต่ำกว่าค่าสูงสุดที่โมเดลโฆษณาไว้มาก การใช้ quantization แบบ precision ต่ำบนฮาร์ดแวร์ GPU รุ่นปัจจุบัน และการปรับวิธีแบ่ง attention cache ของโมเดลข้ามอุปกรณ์ สรุปสั้น ๆ ของเขาสำหรับทีมที่กำลังพิจารณาแนวทางนี้คือ: การโหลดเวทขึ้น GPU แล้วถือว่าจบงานจะได้ประสิทธิภาพที่แย่มาก
งานปรับแต่งนี้คือต้นทุนด้าน ops ที่เกิดขึ้นจริงและต่อเนื่อง ซึ่งทีมส่วนใหญ่มักประเมินต่ำเกินไปเมื่อเทียบราคาป้ายของโมเดลที่โฮสต์เองกับบิล API
เริ่ม Rolloutฝึกพฤติกรรมก่อนแตะโครงสร้างพื้นฐาน
ผลลัพธ์ที่ดีขึ้นของ Revolut สัมพันธ์กับการยกเลิกข้อจำกัด token ไม่ใช่การเปลี่ยนโมเดล นี่คือขั้นตอนที่ทำให้พฤติกรรมนี้ติดกับทีมไหนก็ได้ บนโมเดลไหนก็ได้
ตั้งค่า baseline ของ lead time ก่อน
ก่อนเปลี่ยนเครื่องมือหรือโควต้าใด ๆ ให้วัดว่าฟีเจอร์ทั่วไปใช้เวลาจริงเท่าไรตั้งแต่เริ่มหยิบมาทำจนพร้อม merge หากไม่มี baseline นี้ คุณจะบอกไม่ได้ว่าการเปลี่ยนแปลงในภายหลังช่วยได้จริงหรือไม่
กำจัดการจำกัดปริมาณแบบเงียบ ๆ
ตรวจสอบว่าวิศวกรกำลังเก็บการใช้งาน AI ไว้สำหรับตั๋วงานที่ยากที่สุดของเดือนเพราะโควต้าหรือไม่ ถ้าใช่ การจำกัดปริมาณนี้กำลังกดผลลัพธ์ของคุณอยู่ ไม่ว่าจะใช้โมเดลไหนอยู่เบื้องหลังก็ตาม
ฝึกใช้กับทุกตั๋วงาน ไม่ใช่แค่ตั๋วที่ยาก
พฤติกรรมที่ทำให้ตัวเลขของ Revolut ดีขึ้นคือการใช้ AI กับอีเมล ตั๋วงาน และเอกสาร ไม่ใช่แค่ปัญหาการเขียนโค้ดที่ยาก สอนพฤติกรรมนี้ให้ชัดเจน เพราะมันไม่เกิดขึ้นเองแค่เพราะยกเลิกข้อจำกัดไปแล้ว
วัด lead time ใหม่อีกครั้ง ไม่ใช่แค่เวลาเขียนโค้ด
ติดตามตัวชี้วัด lead time แบบเดียวกันอีกครั้งหลังจากเปลี่ยนแปลง ถ้าเวลาเขียนโค้ดดีขึ้นแต่ lead time ไม่ดีขึ้น แสดงว่าคอขวดยังอยู่ที่อื่นในกระบวนการ และ token เพิ่มขึ้นจะไม่ช่วยแก้ปัญหานี้
ข้อจำกัดที่ต้องยอมรับสิ่งที่กรณีของ Revolut ไม่ได้พิสูจน์
ตัวเลขของ Revolut อธิบายการใช้งานของธนาคารที่อยู่ภายใต้การกำกับดูแลแห่งหนึ่งที่สเกลของตัวเอง โปรดคำนึงถึงข้อจำกัดเหล่านี้ก่อนมองว่าเป็นผลลัพธ์ที่ใช้ได้ทั่วไป
ตัวเลขของบริษัทเดียว ไม่ใช่เกณฑ์มาตรฐาน
ตัวเลขด้านต้นทุนและ latency ในคู่มือนี้อธิบายการใช้งาน รูปแบบการใช้ และเงื่อนไขที่ Revolut เจรจาไว้โดยเฉพาะ ควรมองว่าเป็นหลักฐานว่าอะไรเป็นไปได้ ไม่ใช่การันตีราคาหรือประสิทธิภาพสำหรับงานของคุณเอง
เครื่องมือระดับแนวหน้ายังอยู่ในสมการ
Revolut ไม่ได้ตัด Claude Code ของ Anthropic, Codex ของ OpenAI หรือ Gemini ของ Google ออกไป แต่เก็บไว้เป็นข้อยกเว้นที่ตั้งใจไว้สำหรับปัญหาที่โมเดลที่โฮสต์เองจัดการได้ไม่ดีนัก ซึ่งเป็นต้นทุนที่การนำเสนอเรื่องโฮสต์เองส่วนใหญ่มักไม่พูดถึง
รายละเอียดด้านการปฏิบัติตามกฎระเบียบขึ้นอยู่กับแต่ละบริษัท
เหตุผลของ Revolut เรื่องที่ว่ารันโมเดลที่ไหนและสิ่งนั้นตอบโจทย์ผู้กำกับดูแลได้อย่างไร สะท้อนสถานการณ์เฉพาะของตัวเองในฐานะธนาคารที่อยู่ภายใต้การกำกับดูแลของ EU ไม่ใช่ข้อสรุปทั่วไปว่าโมเดล ภูมิภาค หรือการตั้งค่าใด ๆ จะผ่านข้อผูกพันขององค์กรอื่นได้
สอนพฤติกรรมนี้ก่อนแตะโครงสร้างพื้นฐาน
ผลลัพธ์ที่ดีขึ้นของ Revolut มาจากการยกเลิกข้อจำกัด token ทำให้วิศวกรใช้ AI กับทุกตั๋วงาน ไม่ใช่แค่ตั๋วที่ยาก การเปลี่ยนพฤติกรรมนี้มาก่อนการตัดสินใจเรื่องโฮสต์เองใด ๆ และหลักสูตรฝึกอบรมองค์กรของ Nightschool AI สร้างพฤติกรรมนี้ให้ทั้งทีมวิศวกรรม
คำถามที่พบบ่อย
โมเดลโค้ดดิ้งแบบ open-weight คืออะไร?
คือโมเดลที่เวทที่ผ่านการฝึกแล้วสามารถดาวน์โหลดและรันบนโครงสร้างพื้นฐานที่คุณควบคุมได้ ต่างจากโมเดลแบบปิดที่เข้าถึงได้ผ่าน API ของผู้ให้บริการเท่านั้น GLM ของ Z.ai ซึ่งเป็นโมเดลในกรณีของ Revolut คือตัวอย่างหนึ่ง การรันมันยังต้องใช้โครงสร้างพื้นฐาน GPU จริงและการปรับแต่ง serving stack
Revolut เลิกใช้ Claude Code, Codex และ Gemini ไปทั้งหมดเลยหรือไม่?
ไม่ Revolut ให้โมเดล open-weight ที่โฮสต์เองเป็นตัวเลือกหลักสำหรับงานเขียนโค้ดประจำวัน แต่ยังเก็บ Claude Code ของ Anthropic, Codex ของ OpenAI และ Gemini ของ Google ไว้ใช้เป็นข้อยกเว้นสำหรับปัญหาที่ยากที่สุด ซึ่งรายงานว่าเครื่องมือระดับแนวหน้าเหล่านี้ยังทำงานได้ดี
Revolut ประหยัดได้จริงเท่าไรจากการโฮสต์เอง?
ต้นทุนแบบผสมที่ Revolut รายงานเองอยู่ที่ประมาณ $0.30 ต่อล้าน token ซึ่งอยู่ที่ราวหนึ่งในสิบของค่าใช้จ่ายที่เคยจ่ายให้ Anthropic และ OpenAI รวมกัน โดย serve วิศวกรราว 2,000 คนบน GPU Nvidia B200 จำนวน 56 ตัว ตัวเลขนี้อธิบายการใช้งานของ Revolut เอง ไม่ใช่ราคาที่ทุกทีมควรคาดหวัง
การโฮสต์เองถูกกว่าจริงหรือไม่ ถ้านับรวมงานด้านวิศวกรรมด้วย?
ไม่เสมอไป Revolut รายงานว่าประมาณ 80% ของประสิทธิภาพที่ดีขึ้นมาจากการปรับแต่งการตั้งค่า serving ไม่ใช่จากการซื้อ GPU เพิ่ม ซึ่งเป็นงานโครงสร้างพื้นฐานที่ต้องทำต่อเนื่อง ทีมขนาดเล็กที่ไม่มีทักษะนี้ในองค์กรอาจต้องเสียมากกว่าเพื่อให้ได้ประสิทธิภาพใกล้เคียงกัน เมื่อเทียบกับการจ่ายบิล API ระดับแนวหน้า
โมเดล open-weight ที่โฮสต์เองอย่าง GLM เป็นความเสี่ยงด้านความปลอดภัยเพราะที่มาของมันหรือไม่?
ที่ซึ่งเวทของโมเดลถูกฝึกและที่ซึ่งคุณรันมันเป็นสองคำถามที่แยกจากกัน จุดยืนของ Revolut เองในฐานะธนาคารที่อยู่ภายใต้การกำกับดูแล คือการดาวน์โหลดเวทมารันบนโครงสร้างพื้นฐานที่ควบคุมได้ในเขตอำนาจที่ได้รับอนุมัติ เป็นเส้นทางข้อมูลที่ต่างจากการส่ง request ไปยัง endpoint ที่โฮสต์โดยบุคคลที่สาม องค์กรที่มีผู้กำกับดูแลต่างออกไปควรตรวจสอบเรื่องนี้กับข้อกำหนดการปฏิบัติตามกฎระเบียบของตัวเอง แทนที่จะสมมติว่าใช้ได้กับตนเอง
ทีมวิศวกรรมขนาดเล็กควรทำอะไรแทนการโฮสต์เอง?
มุ่งเน้นที่บทเรียนมากกว่าโครงสร้างพื้นฐาน: ตรวจสอบว่าวิศวกรกำลังจำกัดการใช้งาน AI เพราะข้อจำกัดด้านต้นทุนหรือโควต้าหรือไม่ ถ้าใช่ ให้มองหาแผนที่คงที่หรือถูกกว่าบนโมเดลระดับแนวหน้าที่ใช้อยู่แล้ว ก่อนพิจารณาลงทุนด้าน GPU และ ops ที่การโฮสต์เองต้องใช้
เราควรวัดอะไรเพื่อรู้ว่าเครื่องมือ AI สำหรับโค้ดดิ้งช่วยได้จริงหรือไม่?
วัด lead time คือจำนวนวันตั้งแต่เริ่มหยิบฟีเจอร์มาทำจนถูก merge และพร้อม deploy ควบคู่ไปกับเวลาเขียนโค้ด ข้อมูลของ Revolut แสดงว่า lead time ดีขึ้นมากกว่าเวลาเขียนโค้ด ซึ่งเป็นสัญญาณว่างานโดยรอบ ไม่ใช่การพิมพ์โค้ด คือคอขวดที่แท้จริง
Nightschool AI มีความเกี่ยวข้องกับ Anthropic, Z.ai หรือ Revolut หรือไม่?
ไม่ Nightschool AI เป็นแพลตฟอร์มการเรียนรู้ที่เป็นอิสระ และไม่มีความเกี่ยวข้อง ไม่ได้รับการรับรอง หรือได้รับการสนับสนุนจาก Anthropic, Z.ai, Revolut, OpenAI หรือ Google Claude, Codex, Gemini และ GLM เป็นผลิตภัณฑ์ของบริษัทที่เกี่ยวข้องตามลำดับ ซึ่งถูกกล่าวถึงในที่นี้เพียงเพื่ออธิบายว่าสิ่งเหล่านี้คืออะไรและถูกใช้งานอย่างไรในกรณีนี้
สร้างพฤติกรรมก่อน แล้วค่อยตัดสินใจเรื่องโครงสร้างพื้นฐาน
โมเดลและตัวเลือกการโฮสต์มีความสำคัญน้อยกว่าคำถามว่าทีมของคุณยังจำกัดปริมาณ token อยู่หรือไม่