Bước vào thời đại 4.0, một ngôi nhà hay một hệ thống muốn vận hành trơn tru thì ngoài đời sống tâm linh, chúng ta luôn cần “điện nước tràn trề, nước nôi đầy đủ”. Điện không có thì máy tắt, nước không đầy đủ thì… người khô héo. Còn sang thời kì AI, còn một loại “nước nôi” tinh túy khác chạy qua các mạch máu của ứng dụng, thiếu nó một cái là AI “liệt dương” ngay lập tức: Token.
Câu chuyện đau thương: Thời kỳ “húp cạn nước” và cú quay xe chí mạng của GitHub
Tôi đang làm một dự án cho bên ngành Bảo Hiểm – cái ngành mà data với logic của nó loằng ngoằng như mê cung. Lúc đầu, khách hàng đại gia “chơi lớn”, cấp hẳn cho anh em tài khoản GitHub Copilot Enterprise. Ôi thôi, cái cảm giác lúc đó nó phê kéo dài các ông ạ!
Được cấp tài khoản xịn, anh em trong team dùng “thả phanh”, token đốt không phải nghĩ. Model dùng cho hệ thống cứ phải gọi là “max frontier”, đời cao nhất, mướt nhất như Claude 3 Opus, Claude 3.5 Sonnet… Cứ mỗi lần request là hệ thống húp token ừng ực như nắng hạn gặp mưa rào.
Cái thời kỳ hoàng kim đó, anh em dev chúng tôi tháng nào cũng húp cạn nước, liếm lấp đến từng giọt token cuối cùng. Cứ hễ con AI chuẩn bị “khô hạn”, hết budget một cái là khách hàng đại gia lại vung tiền bơm thêm nước nôi đầy đủ. Tiền bơm vào liên tục, anh em dev thì phê pha trong nhung lụa, code chạy mượt mà, cảm giác như mình đang làm chủ cả vũ trụ AI.
Nhưng thói đời “vui thôi đừng vui quá”. Thấy nước chảy dễ dàng, anh em bắt đầu chủ quan, xả láng không phanh. Đến một ngày đẹp trời, hệ thống lại báo hết nước, team tôi lại ton hót vác mặt đi xin tiền nạp card như mọi khi. Nhưng lần này, khách hàng thẳng thừng từ chối, lắc đầu nguây nguẩy!
Lý do? Bên khách hàng lôi data ra check thì phát hiện thằng F* (phương thức/hệ thống gọi AI) ở bên dưới đang đốt tiền kinh hoàng quá, húp nước như rồng cuốn nước. Họ nhận ra nuôi kiểu này thì có ngày phá sản, sập tiệm bảo hiểm luôn chứ chẳng chơi. Thế là họ xua tay: “Không nạp card, nạp kiếc gì nữa hết! Tự đi mà bóp mồm bóp miệng lại!”
Đã thế, họa vô đơn chí, bắt đầu từ tháng 6 này, GitHub lại chính thức quay xe: Nó bắt đầu tính tiền (charge) theo Token Usage thực tế!
Khách hàng thì cắt viện trợ không cho nạp card, GitHub thì bắt đầu đếm giọt tính tiền. Hóa đơn token đổ về làm các sếp nhìn mà “tím tái mặt mày”, suýt thì ngất lâm sàng. Đột nhiên, cả team bị đặt vào thế tiến thoái lưỡng nan: Hoặc là học cách “bóp ống”, quản lý sao cho dòng nước nôi này chảy đúng nơi đúng chỗ, hoặc là cả dự án “chết yểu” vì cạn kiệt ngân sách.
Cả năm trời quen code bằng tiếng Anh, giờ đúng một cái chuyển sang code Java, C#, lính tráng kêu trời, productivity metrics tụt dốc không phanh còn hơn cả giá vàng, từ 100% 70 , 50%, Sprint Health Index đỏ lòe, Delivery milestone trượt như patin
Chân lý ngộ ra, giờ mà không nghiên cứu thắt ống dẫn tinh, tiết kiệm token thì cả dự án ra đê hết
Là Lead Engineer dự án tôi đành vác sách đi tham gia hội thảo, cắp cặp đi nghe diễn đàn, chia sẻ các kinh nghiệm tối ưu token, các sử dụng AI cho hiệu quả, về vọc vạch cài cắm setup trên máy thử nghiệm
Đo token usage thế nào
Đi vác sách search Google hỏi ChatGPT thấy ra 1001 cách tiết kiệm token, nhưng vấn đề là đo token usage kiểu gì để biết nó có tiết kiệm thật hay bịp
Cái oái oăm tiếp theo là: Khách hàng bắt tối ưu token, nhưng lại đéo cho quyền access vào GitHub Organization Admin. Nghĩa là anh em mù tịt, không thể xem được Dashboard tổng, không biết chi phí thực tế tiêu hao bao nhiêu, con AI đang “bú” bao nhiêu token mỗi ngày để mà sửa. Đúng kiểu đi massage nhưng lại tắt đèn, không biết hàng họ thế nào, toàn dùng tay bóp để đánh giá
Nhưng “cái khó ló cái khôn”, dân chơi hệ hardcore thì sợ gì vết bẩn. Không cho quyền Admin thì ta tự “quay tay” bằng biện pháp nghiệp vụ:
Cào dữ liệu từ Agent Debug Log: Tôi phát hiện ra con GitHub Copilot Agent nó luôn nhè ra Log Debug cực kỳ chi tiết sau mỗi lần tương tác. Thế là tôi viết ngay một con Script Python chuyên đi “vét sạch” đống Debug Log, Prompt Tokens, Completion Tokens, Model ẩn bên dưới ra
Dựng Dashboard tự chế: Đống dữ liệu cào ra được đem lên một Dashboard “cây nhà lá vườn”, hiển thị trực quan sinh động xem đứa nào đang xài hao nước, con Bot nào đang ngốn token bậy bạ.
2 steps cũng không quá khó, prompt cho em Agent nó code 1 ngày là setup xong, dữ liệu đo được cũng khá ổn, track được cả tình hình xài prompt thế nào (prompt ngu hay prompt khôn)
Gọi là Prompt Analysis, cái dashboard tôi build nó trông thế này
Đại loại là collect và phân tích chất lượng prompt của mấy thằng đệ để nghiên cứu cách tối ưu prompt
Cài cắm Bộ đôi plugin “giáo dục”: Để anh em dev tỉnh ngộ và “kìm hãm sự sung sướng” lại trước khi bấm nút, tôi triển khai thêm hai con plugin thần thánh: Microsoft AI Coaching Engineer và AI Engineering Fluency.
Đây là 2 plugin tôi đánh giá rất chất lượng nó collect dữ liệu từ log local ra rồi vẽ lên Dashboard, không đẩy data ra ngoài ,keep privacy
Cách thắt ống dẫn tinh
Model Routing – “Đổi đào” liên tục
Mấy quán massage mà có em đào nào nổi, là toàn share lên diễn đàn, rồi cứ thế đâm đầu vào, đi đâu giờ nào cũng bảo có em Trinh số 19 không, rồi mới booking, dẫn đến em quá tải, giảm quality service, chủ quán lại được thể tăng giá, nâng phí dịch vụ, mà quên mất rằng ngoài em Trinh còn có em Nguyên, em Thảo chất lượng không kém. Tương tự như AI model cũng vậy, Dự án bảo hiểm có những câu hỏi rất “ngáo ngơ” từ user, nhưng cũng có những câu cần tính toán logic phức tạp. Đời không phải lúc nào cũng cần đến những “siêu phẩm” đắt đỏ như Claude 3.5 Sonnet hay Opus.
Cho nên việc đầu tiên là tôi xây dựng một em LiteLLM, em này setup các router đến các model giá rẻ, open source nằm ở AI foundry (giá rẻ hơn hosted Github) và 1 con Selfhost models , đảm bảo các thanh niên trước khi xài em Trinh (Claude Sonnet) thì cứ thử xài ChatGPT, Gemini, QWen etc… đảm bảo vẫn làm task ổn, vẫn phê
Bộ (Router). User vào chỉ chào hỏi “Hi”, “Hello”, hoặc hỏi mấy câu định nghĩa bảo hiểm đơn giản? Đẩy thẳng qua mấy em “vừa túi tiền” như GPT-4o-mini hoặc Llama-3-8B.
Khi nào user yêu cầu những task nặng đô, đòi hỏi logic hardcore như plan architect ? Lúc đó mới lôi các “vị đại sứ” đắt tiền ra tiếp khách.
Self-host Model
Khi Dev Tự “Quay Tay” Nạp Nước Bằng SGLang Trên AWS GPU.
Self-host thì không mất tiền token chỉ tốn tiền server quản lý được tiện lợi cho hệ thống nhiều user request lớn
Muốn tự “mây mưa” với mô hình lớn, anh em cần một cái “giường” thật chắc chắn và một bộ “động cơ” thật khỏe. Trên AWS, đó là các GPU Instance.
Tư thế chuẩn bị: Bác phải vác mặt đi xin sếp/khách hàng cấp budget để thuê Instance. Đợt này không phải xin nạp token, mà xin tiền thuê máy chủ.
Chọn "mẫu đào"
Muốn mướt mà, xả láng với Llama 3 70B hay Qwen 1.5 72B? Bác cần ít nhất 2 hoặc 4 con GPU A100 (instance loại p4d.24xlarge hoặc p4de.24xlarge). Nước nôi ở đây thì thôi rồi, tràn bờ đê luôn!
Muốn “tiết kiệm nước” hơn, xài mấy em “vừa túi tiền” như Llama 3 8B hay Qwen 1.5 7B? Một con GPU G5 (instance loại g5.xlarge hoặc g5.2xlarge) là đủ để anh em “làm vài hiệp” phê pha.
Anh em nào hay selfhost model thì hay xài Ollama nhỏ gọn tiện lợi. Nhưng em này phù hợp làm đồ án, practice chứ enterpise thì ko dc
Để dễ hình dung, hãy tưởng tượng token (thứ bạn cần tiết kiệm) chính là dòng nước mát. Hệ thống của bạn cần nước để vận hành, để “mây mưa” với dữ liệu.
Ollama: Giống như một cái Vòi Sen Gia Đình xịn sò. Nó cực kỳ dễ lắp đặt, chỉ cần cắm vào là nước chảy ngay. Dân chơi nghiệp dư hay kể cả dân chuyên nghiệp muốn nhanh gọn lẹ thì cứ vòi sen này mà xả.
SGLang: Giống như một Hệ Thống Bơm Tăng Áp Công Nghiệp. Nó không dành cho tay mơ. Lắp đặt loằng ngoằng, cần “bơm” (GPU) khủng, nhưng một khi đã chạy thì dòng nước (token) phun ra mạnh kinh khủng, mượt mà và cực kỳ tối ưu, chấp cả chục thằng cùng xả một lúc.
Rõ ràng với dự án bảo hiểm, mấy trăm chú dev, hàng chục team, hàng ngày số lượng LOC phải xxx nghìn, cả trăm PR, thì phải sử dùng SGLang
Vòi Sen Gia Đình (Ollama): Khi bác dùng mô hình nhỏ (Llama 3 8B, Qwen 7B) trên local device hoặc server nhỏ. Nó “dễ xài, chạy 1 lệnh!”, nước nôi phun ra “vừa túi tiền” cho 1 user mây mưa. Nhưng khi lên server chịu tải lớn, nước chảy ra nhỏ giọt, “thời gian chờ đợi dài” làm anh em “liệt dương”, không thể “thăng hoa” liên tục.
Hệ Thống Bơm Tăng Áp Công Nghiệp (SGLang): Khi bác thuê instance GPU khủng trên AWS (ví dụ p4d.24xlarge) để host mấy em mô hình hàng khủng (Llama 3 70B, Qwen 72B). SGLang Backend “cân được multi-GPU”, dùng “tensor parallelism” và “prompt caching” để dòng token xả ra “siêu tốc, mượt mà”. Nó “hỗ trợ 100+ user cùng lúc”, nước nôi luôn tràn nề đầy đủ, chấp cả chục thằng F* cùng xả một lúc không lo cạn kiệt.
Đây là 2 cách dạo đầu, đón đọc phần 2 về giai đoạn lâm trận thế nào
0 Nhận xét