ใช้ GitHub Models ทดสอบโมเดลฟรีมาทั้งปี พอประกาศปิดบริการแล้วโค้ดที่ผูกไว้จะทำยังไงต่อ

เช้าวันหนึ่งทีมพัฒนาที่ผมช่วยดูแล pipeline อยู่พบว่า workflow ที่รัน AI code review อัตโนมัติใน GitHub Actions ล่มทั้งหมด ตามไปดู log ถึงรู้ว่า request ที่ยิงไปยัง endpoint ของ GitHub Models ถูกปฏิเสธ ตอนนั้นถึงจำได้ว่าไม่มีใครในทีมเคยจดไว้เลยว่าสคริปต์ตัวไหนบ้างที่ผูกกับบริการนี้ เพราะตอนเริ่มใช้มันฟรีและติดตั้งง่ายจนกลายเป็นส่วนหนึ่งของ workflow โดยไม่มีใครตั้งคำถาม

นี่คือสิ่งที่มักเกิดขึ้นกับบริการที่ให้ทดลองใช้ฟรีแบบสะดวก คนใช้กันเยอะเพราะไม่ต้องขอ API key จากผู้ให้บริการโมเดลเอง ไม่ต้องผูกบัตรเครดิตแยก แค่มี GitHub token ก็เรียกได้เลย พอบริการแบบนี้ประกาศปิดหรือปรับเงื่อนไขกะทันหัน ผลกระทบจึงไม่ได้จำกัดอยู่แค่โปรเจกต์ทดลองเล็ก ๆ แต่ลามไปถึง production workflow ที่ทีมพึ่งพาแบบไม่รู้ตัว

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

ทำไมทีมพัฒนาจำนวนมากถึงผูก Workflow ไว้กับ GitHub Models โดยไม่รู้ตัว

จุดขายของ GitHub Models คือความง่าย นักพัฒนาที่มี GitHub account อยู่แล้วสามารถเรียกโมเดลจากหลายค่ายผ่าน endpoint เดียว ใช้ token เดียวกับที่ใช้ authenticate กับ GitHub ทั่วไป ไม่ต้องไปสมัครบัญชีแยกกับผู้ให้บริการแต่ละเจ้า ไม่ต้องผูกบัตรเครดิตต่างหาก สำหรับทีมที่แค่อยากทดลองว่า prompt แบบไหนได้ผล หรืออยากเพิ่ม AI ช่วยรีวิวโค้ดแบบเบา ๆ ใน CI นี่คือทางที่เริ่มได้เร็วที่สุด

ปัญหาคือความง่ายนี้ทำให้หลายทีมข้ามขั้นตอนที่ควรทำตั้งแต่ต้น คือแยกชั้น abstraction ระหว่างโค้ดที่เรียกใช้โมเดลกับ provider จริง เมื่อไม่มีชั้นกลางนี้ endpoint ของ GitHub Models จึงถูกฝังตรง ๆ ในหลายจุด ทั้งใน workflow YAML ของ GitHub Actions, ในสคริปต์ทดสอบภายใน, และบางทีก็ในโค้ด production ที่ไม่มีใครคาดว่าจะยังอยู่ตรงนั้น

อีกเหตุผลคือทีมจำนวนมากมองบริการฟรีแบบนี้เป็น 'เครื่องมือพัฒนา' ไม่ใช่ 'dependency ของระบบ' จึงไม่ได้ใส่ไว้ใน dependency tracking หรือ documentation อย่างเป็นทางการ พอมันหายไปจริง คนที่ต้องมาแก้ปัญหาจึงต้องเริ่มจากศูนย์ในการตามหาว่ามันอยู่ตรงไหนบ้าง

ขั้นแรกที่ต้องทำก่อนอย่างอื่น ตรวจให้ครบว่าอะไรผูกกับบริการนี้บ้าง

ก่อนคิดเรื่องย้ายไปไหน ต้องรู้ก่อนว่ามีอะไรต้องย้ายบ้าง วิธีที่ทำได้เร็วที่สุดคือ grep หา pattern ของ endpoint และชื่อ model ที่เกี่ยวข้องกับ GitHub Models ทั่วทั้ง repository ทุกตัว ไม่ใช่แค่ repo หลัก เพราะบางทีม script ทดสอบหรือ internal tool ถูกแยกไว้คนละ repo แล้วไม่มีใครจำได้ว่ามันก็เรียกโมเดลเหมือนกัน

จุดที่ควรตรวจเป็นพิเศษคือไฟล์ workflow ใน `.github/workflows/` เพราะเป็นจุดที่มักฝัง environment variable หรือ secret ที่ตั้งชื่อเกี่ยวกับ GitHub Models ไว้ตรง ๆ ถ้าทีมเคยอ่านเรื่อง การใช้ AI ใน GitHub Actions มาก่อนจะรู้ว่าจุดเหล่านี้มักเป็นที่ฝัง endpoint ภายนอกไว้เยอะที่สุด รวมถึงสคริปต์ที่ใช้ใน pre-commit hook หรือ local development tool ที่นักพัฒนาบางคนติดตั้งเองโดยไม่ได้บันทึกไว้ในเอกสารทีม

ผลลัพธ์ของขั้นตอนนี้ควรเป็นรายการที่ระบุชัดว่า จุดไหนใช้ทำอะไร (เช่น code review อัตโนมัติ, สรุป PR description, ทดสอบ prompt) ความสำคัญของแต่ละจุดต่อ workflow ประจำวัน และมีใครเป็นคนดูแลจุดนั้น รายการนี้จะเป็นตัวช่วยตัดสินใจว่าจุดไหนต้องย้ายด่วน จุดไหนรอได้

ผลกระทบที่ชัดที่สุดมักอยู่ที่ CI/CD ไม่ใช่โค้ด Production โดยตรง

จากประสบการณ์ที่เจอ จุดที่พังก่อนใครมักเป็น workflow ใน GitHub Actions ที่เรียกโมเดลระหว่างขั้นตอน build เช่นให้ AI สรุปการเปลี่ยนแปลงใน Pull Request, ตรวจสอบว่า commit message ตรงตาม convention, หรือรัน static review เบื้องต้นก่อนส่งให้คนรีวิวจริง งานเหล่านี้ดูเหมือนเป็นแค่ของเสริม แต่ถ้าทีมตั้งให้ผลลัพธ์จาก step นี้เป็นเงื่อนไขที่ workflow อื่นต้องรอ (เช่นตั้งเป็น required check) การที่ endpoint หายไปจะทำให้ pipeline ทั้งสายค้างหรือ fail ไปด้วย

อีกจุดที่กระทบหนักคือ integration test ที่จำลองการเรียก AI เป็นส่วนหนึ่งของ test suite โดยไม่ได้ mock ไว้ ถ้าทีมเขียนเทสต์แบบเรียกจริงเพื่อความสมจริง พอ endpoint หาย เทสต์ทั้งชุดจะแดงหมดทันที ทำให้ทีมแยกไม่ออกว่าที่แดงเป็นเพราะโค้ดมีบั๊กจริงหรือเพราะบริการภายนอกหายไป

บทเรียนจากจุดนี้คือ workflow ที่พึ่งพา AI ควรมีทางออกสำรองเสมอ เช่นตั้งให้ step ที่เรียกโมเดลเป็น non-blocking หรือมี fallback ที่ปล่อยผ่านแบบมีเหตุผลชัดเจนเมื่อบริการภายนอกเรียกไม่ได้ ไม่ใช่ปล่อยให้ทั้ง pipeline ค้างเพราะ dependency เดียวที่ควบคุมไม่ได้

ทางเลือกที่ใกล้เคียงเดิมที่สุด ย้ายไป Azure AI Foundry หรือ GitHub Copilot API

สำหรับทีมที่อยากได้ประสบการณ์ใกล้เคียง GitHub Models เดิมที่สุด คือยังอยากเรียกหลายโมเดลผ่านช่องทางเดียวโดยไม่ต้องจัดการ credential แยกกับผู้ให้บริการแต่ละเจ้า Azure AI Foundry เป็นทางเลือกที่ควรพิจารณาก่อน เพราะมี catalog โมเดลจากหลายค่ายให้เลือกใช้ผ่าน endpoint ที่บริหารจัดการโดย Microsoft เหมือนกัน และผูกกับระบบ billing แบบ enterprise ที่คาดเดาได้ชัดกว่าบริการทดลองฟรี

อีกทางที่หลายทีมมองข้ามคือ API ที่มากับสิทธิ์ GitHub Copilot ระดับองค์กร ซึ่งบางแผนเปิดให้เรียกโมเดลผ่าน endpoint แบบมีโควตาชัดเจนสำหรับ integration ภายในทีม ถ้าองค์กรมี seat ของ Copilot อยู่แล้ว (ดูมุมเปรียบเทียบเพิ่มเติมได้ใน GitHub Copilot vs Codex) ควรตรวจสอบสิทธิ์นี้ก่อนไปหาผู้ให้บริการรายใหม่ เพราะอาจไม่ต้องเพิ่มค่าใช้จ่ายรายเดือนใหม่เลย

ข้อดีของทางนี้คือการย้ายมักใช้แรงน้อยที่สุด เพราะโครงสร้าง request/response ใกล้เคียงของเดิม แต่ข้อเสียคือยังผูกอยู่กับ ecosystem เดียว ถ้าอนาคตมีการเปลี่ยนเงื่อนไขอีกครั้ง ทีมก็ยังเจอความเสี่ยงแบบเดิมซ้ำ

เรียกตรงจากผู้ให้บริการโมเดลแต่ละเจ้า คุมต้นทุนและความเสถียรได้เองมากขึ้น

อีกทางคือเลิกพึ่งพา endpoint กลางแล้วสมัครบัญชีตรงกับผู้ให้บริการโมเดลที่ทีมใช้จริง เช่น OpenAI, Anthropic หรือ Google ข้อดีของแนวทางนี้คือทีมควบคุม rate limit, การตั้งราคา และ SLA ได้ตรงกับผู้ให้บริการเอง ไม่ต้องพึ่งเงื่อนไขของตัวกลางที่เปลี่ยนได้ตลอดเวลาโดยที่ทีมไม่มีอำนาจต่อรอง

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

วิธีที่ช่วยลดความเสี่ยงตรงนี้ได้คือเขียนชั้น abstraction บาง ๆ คลุมการเรียกโมเดลไว้ในโค้ดตั้งแต่ตอนย้าย เพื่อให้ถ้าอนาคตต้องเปลี่ยนผู้ให้บริการอีกครั้ง ทีมแก้ที่จุดเดียวแทนที่จะต้องไล่แก้ทุกจุดที่เคยฝัง endpoint ไว้ตรง ๆ เหมือนที่เจอปัญหาซ้ำรอบนี้ แนวคิดนี้คล้ายกับที่พูดถึงใน การจัดวางความรู้ให้ Agent Skills คือแยกชั้นข้อมูลออกจาก logic หลักตั้งแต่ต้น

รันโมเดล Open-source เองบางส่วน ตัดความเสี่ยงเรื่องบริการภายนอกปิดตัว

สำหรับงานที่ไม่ต้องการความสามารถของโมเดลปิดขนาดใหญ่ที่สุด เช่นงานจัดหมวดหมู่ commit message, สรุปข้อความสั้น ๆ หรือตรวจสอบรูปแบบไฟล์เบื้องต้น การรันโมเดล open-source ขนาดเล็กเองผ่านเครื่องมืออย่าง Ollama บน runner ของทีมเป็นทางเลือกที่ตัดความเสี่ยงเรื่องบริการภายนอกปิดตัวไปได้เกือบทั้งหมด เพราะไม่มีใครมาปิดบริการที่ทีมรันเอง

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

อีกเงื่อนไขที่ต้องคิดคือทรัพยากรของ runner ใน CI ถ้ารันบน GitHub-hosted runner ทั่วไป อาจไม่มีกำลังประมวลผลพอสำหรับโมเดลขนาดใหญ่ ต้องพิจารณาใช้ self-hosted runner ที่มีทรัพยากรเพียงพอ ซึ่งเพิ่มภาระดูแล infrastructure ให้ทีมเองอีกชั้นหนึ่ง

ตารางเทียบทางเลือกสามแบบตามมุมที่ทีมมักใช้ตัดสินใจ

ตารางนี้สรุปมุมที่ควรถามตัวเองก่อนเลือกทางย้าย ไม่มีคำตอบเดียวที่ถูกสำหรับทุกทีม เพราะขึ้นกับลักษณะงาน งบประมาณ และความสามารถของทีมในการดูแล infrastructure เอง:

วางแผนย้ายแบบไม่ทำให้ Workflow ค้างระหว่างทาง

ขั้นตอนที่ปลอดภัยที่สุดคือเริ่มจากรายการที่ตรวจสอบไว้ในขั้นแรก แล้วเรียงลำดับตามผลกระทบ จุดที่กระทบ production หรือเป็น required check ควรย้ายก่อนจุดที่เป็นแค่เครื่องมือเสริมของนักพัฒนาแต่ละคน ระหว่างย้ายควรเปิดทั้งสองทางไว้พร้อมกันชั่วคราวถ้าเป็นไปได้ เพื่อเทียบผลลัพธ์ก่อนตัดทางเดิมทิ้งจริง

อีกจุดที่ช่วยได้มากคือแยก configuration ของ endpoint และ model name ออกจาก logic หลักตั้งแต่ตอนย้าย ให้อยู่ในไฟล์ตั้งค่ากลางไฟล์เดียวหรือ environment variable ที่จัดการรวมศูนย์ เพื่อให้ถ้าต้องเปลี่ยนอีกครั้งในอนาคต ทีมไม่ต้องไล่แก้ทุกจุดเหมือนรอบนี้ ถ้าทีมมีการเชื่อม GitHub MCP server อยู่ด้วย ควรตรวจให้ครบว่า config ของ MCP tool ตัวไหนอ้างถึง endpoint เดิมบ้าง

สุดท้ายควรทดสอบ workflow ที่ย้ายแล้วในสภาพแวดล้อมที่ใกล้เคียง production จริงก่อนปล่อยเข้า branch หลัก โดยเฉพาะ step ที่เป็น required check เพราะถ้าย้ายแล้วพังอีกรอบ ผลกระทบจะเหมือนตอนที่ GitHub Models หายไปครั้งแรกไม่ต่างกัน

ทำแบบนี้แล้วพัง เพราะรีบย้ายโดยไม่ตรวจให้ครบก่อน

เคสที่เจอบ่อยคือทีมรีบย้ายจุดที่เจ็บที่สุดจุดเดียวคือ workflow หลักที่พังชัดเจน แล้วคิดว่าจบแล้ว โดยไม่ได้ตรวจสอบต่อว่ายังมีสคริปต์เล็ก ๆ ที่นักพัฒนาบางคนใช้ส่วนตัวผูกอยู่กับบริการเดิมอีกหรือไม่ ผลคือหลังจากประกาศว่าย้ายเสร็จแล้ว ยังมีคนมารายงานว่า tool บางตัวใช้ไม่ได้อยู่ดีในอีกสองสามสัปดาห์ถัดมา

อีกเคสคือย้ายไปใช้ provider ใหม่โดยไม่ทดสอบเปรียบเทียบคุณภาพผลลัพธ์ก่อน เพราะรีบให้ workflow กลับมาทำงานได้เร็วที่สุด แล้วพบทีหลังว่าผลลัพธ์จาก step ที่เคยเชื่อถือได้ (เช่นสรุป PR หรือตรวจ commit message) เริ่มคลาดเคลื่อนบ่อยขึ้น เพราะโมเดลใหม่ตอบสนองต่อ prompt เดิมไม่เหมือนของเดิมทุกจุด

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

สรุป

การที่บริการฟรีอย่าง GitHub Models ปิดตัวไม่ใช่เรื่องผิดปกติของโลกที่เทคโนโลยี AI เปลี่ยนเร็ว สิ่งที่ทำได้จริงคือเปลี่ยนวิธีมองบริการแบบนี้จาก 'เครื่องมือทดลองที่ไม่ต้องดูแล' เป็น dependency ที่ต้องมีคนรับผิดชอบและมีแผนสำรองเหมือน dependency อื่นในระบบ

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

• ตรวจสอบให้ครบก่อนย้าย grep หา endpoint ทั่ว repository ไม่ใช่แก้แค่จุดที่พังชัดที่สุด
• เลือกทางย้ายตามลักษณะงาน Azure AI Foundry ง่ายสุด เรียกตรง provider คุมได้เองสุด รัน open-source ตัดความเสี่ยงสุด
• แยกชั้น abstraction ระหว่างโค้ดกับ provider ไว้เสมอ เพื่อลดแรงตอนต้องย้ายรอบถัดไป

คำถามที่พบบ่อย