บทนำ
หนึ่งในขั้นตอนการประหยัดต้นทุนที่ใหญ่ที่สุดที่ทีม AI workflow สามารถทำได้ในโปรเจกต์ใหม่ คือการใช้ประโยชน์จาก serverless inference เมื่อเหมาะสม แบบดั้งเดิม AI models ต้องการ dedicated GPU ที่รัน 24/7 จ่ายรายชั่วโมง ด้วย serverless inference endpoints ทีมมีตัวเลือกใช้ open source models หลายตัวแบบ pay-per-token แทนการจ่ายรายชั่วโมงและจัดการ setup/maintenance เอง นี่ลดต้นทุนการเริ่มผลิตภัณฑ์ใหม่ลงอย่างมาก เพราะช่วยให้ทีมจ่ายเฉพาะการใช้งานและ scale ตามความจำเป็น
ในขณะที่ serverless architecture มีอยู่มานานแล้ว ทีมที่มี custom หรือ fine-tuned models มักยังจ่ายอัตรารายชั่วโมงสำหรับ GPU usage แต่จริงๆ แล้วสามารถ host fine-tuned models และส่งมอบผ่าน serverless endpoint ด้วย pay-per-token billing ได้ เราจะเดินทางผ่านวิธีการ host fine-tuned models แบบ serverless และประโยชน์/ข้อเสียของการทำเช่นนั้น
สรุปสำคัญ (Key Takeaways)
- วิธี fine-tuning ที่มีประสิทธิภาพด้านพารามิเตอร์อย่าง LoRA ทำให้ serverless hosting ของ custom models เป็นเรื่องปฏิบัติได้ โดยผลิต adapter weights ขนาดเล็กที่สามารถวางซ้อนบน frozen shared base model ได้ หมายถึงแพลตฟอร์มสามารถ serve ได้หลายร้อย fine-tuned variants จาก GPU เดียว กำจัดความจำเป็นในการ deploy แบบ per-model dedicated
- ทีมที่มี bursty หรือ unpredictable traffic สามารถลดต้นทุน inference โดยเปลี่ยนไป serverless fine-tuned endpoints จ่ายเฉพาะ tokens ที่ใช้ แทนการรัน GPU ตลอด 24 ชม. Deployment เร็วกว่ามาก เพราะ upload trained adapter ไปที่ managed platform ให้ live API endpoint ในไม่กี่นาที ไม่ต้อง setup infrastructure
- Trade-off หลักของ serverless inference กับ fine-tuned models คือ cold starts ที่ idle adapter ต้องโหลดใหม่จาก storage ก่อน serve requests เพิ่ม latency ได้ถึงหลายร้อย milliseconds สามารถลดได้ด้วย periodic keep-alive requests และ delay นี้เล็กกว่า full model cold start มาก เพราะแค่ fetch lightweight adapter weights
Fine-Tuning Methods ที่รองรับ
สำคัญต้องชี้แจงว่า "fine-tuning" ในบริบทนี้ ไม่ได้หมายถึง traditional full fine-tuning ที่ retrain all weights ของโมเดลจากศูนย์บนข้อมูลใหม่ Full fine-tuning แพง ใช้เวลานาน และผลิตโมเดลใหม่ที่ใหญ่เท่าเดิม การ host โมเดลนั้นแบบ serverless ไม่ปฏิบัติได้ เพราะไม่สามารถ share ได้หลาย users ต้องการ dedicated GPU deployment ของตัวเอง
Parameter-efficient fine-tuning (PEFT) อัปเดตเพียง subset เล็กๆ ของ weights แทน retrain ทั้งหมด ทำให้ base model ค้าง frozen ไว้ นี่ผลิต additional weights ขนาดเล็กมากที่ represent customizations ในขณะที่ heavy base model คงเดิมและ shareable ได้หลาย users ที่ไม่เกี่ยวข้องกัน
PEFT method ที่ใช้กว้างที่สุดคือ Low-Rank Adaptation (LoRA) แทนที่จะ modify existing weights โดยตรง LoRA เพิ่ม trainable adapter matrices ขนาดเล็กบน frozen base model Adapters เหล่านี้ capture task-specific behavior ในเพียงไม่กี่ MB ของ weights เทียบกับสิบๆ ถึงร้อยๆ GB ของ base model LoRA ยังมี variants หลายแบบ เช่น QLoRA, DoRA, LoRA+ ซึ่งรองรับกันดีบน serverless inference platforms
เพราะ base model frozen และเหมือนกันทุก user แพลตฟอร์มจึงโหลดมันครั้งเดียวใน GPU memory และ share ได้ Adapter LoRA ของแต่ละ user โหลดซ้อนบน request time ทำให้ practical ที่จะ serve หลายร้อย fine-tuned variants จาก GPU เดียว สำคัญอีกอย่าง แพลตฟอร์มที่รองรับ serverless inference บน fine-tuned models โดยทั่วไปรองรับเฉพาะกับ base models เฉพาะเจาะจง คุณต้องมี LoRA adapter ที่ train บน supported base models ของพวกเขา
การจัดการ Multiple LoRA Adapters
LoRA adapter weights (โดยทั่วไป 10-100 MB แต่ละตัว) ถูกเก็บใน fast object storage หรือ in-memory cache ที่ inference server จัดการ เมื่อ request เข้ามาสำหรับ adapter เฉพาะ serving system fetch weights นั้นและ fuse เข้า forward pass on-the-fly
Fusion process นี้เบามาก ที่แต่ละ transformer layer ที่ LoRA ถูก apply adapter เพิ่ม two small matrices ที่ผลิต low-rank correction ให้ layer outputs ระหว่าง inference server คำนวณ base layer output แล้วเพิ่ม LoRA correction ใน extra CUDA operations 不กี่คำสั่ง Base weights ไม่ถูก modify จนเอง การ swap adapters ระหว่าง requests ต้องการแค่ replace small matrix pairs ใน GPU registers แทน reload base model หรือ restart CUDA kernel
Challenge ใหญ่ที่สุดคือ memory management กับหลายร้อย adapters บน single instance Inference server ต้อง maintain small resident cache ของ most recently/frequently used adapter weights ใน VRAM โดยตรง Adapters อื่นๆ ถูก evict จาก VRAM กลับ CPU RAM หรือ object storage ก่อให้เกิด reload time penalty ประมาณหลายร้อย milliseconds
Batching process อาจต่างกันตาม LoRA method ที่ใช้ Requests ที่ share adapter มักถูก grouped เป็น sub-batches ก่อน run correction แต่บางระบบอย่าง S-LoRA pack requests จาก adapters ต่างๆ เข้า forward pass เดียวกัน และ store active adapters ใน unified memory pool แล้ว address ด้วย custom CUDA kernels ที่ apply adapter corrections ต่างๆ ให้ตำแหน่ง sequence ต่างๆ พร้อมกัน วิธีนี้เรียกว่า LoRA multiplexing อนุญาตให้ GPU saturated แม้ trafficกระจายไปหลาย fine-tuned variants พร้อมกัน vLLM ก็รองรับ LoRA multiplexing native สำหรับผู้ที่สนใจ swap LoRA adapters บน GPUs ที่เช่ารายชั่วโมง
KV-cache entries ผูกมัดกับ adapter ที่ผลิตมัน Cache entry ที่ generate ด้วย adapter หนึ่ง ไม่สามารถ reuse สำหรับ request ที่ใช้ adapter อื่นได้ สุดท้ายนี้ทำให้ KV-cache hit rate ต่ำกว่าใน multi-adapter setting เทียบ single-model deployment Inference servers ต้อง key cache entries ด้วยทั้ง prompt tokens และ adapter identifier
ผลกระทบจริงของการใช้ Serverless Fine-Tuning
ข้อดีของ serverless fine-tuning ชัดเจนที่สุดสำหรับทีมที่สร้าง services ใหม่ที่มี inconsistent bursts of traffic จนไม่จำเป็นหรือไม่ cost-effective ที่จะมี reserved GPUs รัน 24/7 แทนที่จะจ่าย fixed GPU-hour rate สำหรับ idle hours ตอนกลางคืน คุณจ่ายเฉพาะ tokens จาก requests ของคุณ โดยเปลี่ยนไป serverless architecture คุณสามารถลด inference costs ลงทศนิยมหนึ่งระดับ (order of magnitude)
Deployment speed เร็วกว่ามาก ด้วย เมื่อ LoRA adapter ทrained แล้ว upload ไป managed inference platform ให้ live API endpoint ในไม่กี่นาที ไม่ต้อง cluster provisioning, container orchestration หรือ GPU driver management นี่ลดภาระ infrastructure ทำให้ทีม focus ที่ model และ product คุณยังควบคุมพฤติกรรมโมเดลได้ และคุณ own adapter weights แม้ base model จะ shared และรันอย่างมีประสิทธิภาพและราคาถูก
ข้อเสียใหญ่ที่สุดของการ host fine-tuned models แบบ serverless คือ cold start เมื่อ adapter ไม่ได้รับ traffic ช่วงหนึ่ง inference platforms โดยทั่วไป scale มันเป็นศูนย์ evict weights จาก GPU memory และ reclaim VRAM สำหรับ users อื่น user ถัดไปต้องรอระบบ fetch weights จาก object storage โหลด และเริ่ม forward pass นี้มักใช้เวลาประมาณหลายร้อย milliseconds แทนจะเป็นหลายวินาที เพราะ adapters เล็ก ข้อสังเกต: ถ้า base model เองไม่ได้ถูกใช้บ่อยและถูก evict (เป็นไปได้บนบาง architectures) cold starts อาจนานกว่า Cold starts spike Time-to-First-Token (TTFT) โดยเฉพาะ โดยไม่ affect Time-per-Output-Token (อัตรา generate tokens หลังตัวแรก) TTFT คือ metric ที่ต้องดูสำหรับทีมที่พยายาม minimize streaming latency
Cold starts สามารถลดได้ 2 วิธี: 1) Architecture ส่ง periodic keep-alive requests ใน low-traffic times 2) ขั้นตอนตอน train LoRA adapter ทำให้ loading มีประสิทธิภาพมากขึ้น ระหว่าง training adapter size และ expressiveness ควบคุมด้วย hyperparameter rank หรือ 'r' Rank-8 adapter ให้ trainable parameters ประมาณครึ่งของ rank-16 Rank-8 จะมี TTFT เร็วกว่าจาก cold start ถ้าอื่นๆ เท่ากัน Layer ที่ LoRA applied ก็เปลี่ยน file size และ inference overhead LoRA มัก apply ที่ query/value projection matrices ในแต่ละ attention block แต่ apply ที่ MLP layers สามารถปรับปรุง quality ได้เมื่อ adapt โมเดลสู่ specific domain
สรุป
Serverless fine-tuned inference น่าจะเป็น offering ที่ยิ่งนิยมขึ้นในอนาคต LLM landscape ปัจจุบัน focus หนักที่ scaling bigger, better-reasoning, monolithic models น้อยกว่าสนใจ architectures ที่มี many specialist models ทำงานร่วมกัน ในที่สุด community จะหาวิธีจัดการ many models และ use cases ที่ architecture นี้ perform ดี เมื่อนั้น LoRA multiplexing จะช่วยทีมที่จัดการ many custom agents ด้วยต้นทุนที่สมเหตุสมผล
ยังคงหาคำตอบอยู่?
งานนี้ได้รับอนุญาตภายใต้ Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.
