Tôi suýt tối ưu chi phí con bot — trước khi nó kịp tốn của tôi một đồng nào

Có một thứ nghe rất "dân pro" mà tôi suýt làm: ngồi tối ưu chi phí token cho con bot, trước khi nó kịp tốn của tôi một đồng đáng kể nào.

May là tôi dừng lại đúng lúc. Và bài học đó — đừng sửa cái chưa hỏng — đáng giá hơn mọi mẹo tiết kiệm tôi định làm.

Cái bẫy đầu tiên: tối ưu cho cảm giác giỏi

Mỗi câu trả lời của con bot là một lần gọi tới Claude. Mỗi lần gọi tốn token — tức là tiền thật. Nên phản xạ rất tự nhiên của một người viết code là: "phải làm cho nó rẻ."

Tôi đã đọc đủ thứ về cách hạ chi phí LLM. Phân tầng model rẻ–đắt. Cắt bớt lịch sử hội thoại. Tóm tắt các lượt cũ. Bật cache thông minh hơn. Mỗi cái nghe đều thông minh, đều cho tôi cái cảm giác mình đang làm "kỹ thuật xịn".

Rồi tôi tự hỏi một câu rất phũ: con bot này hiện đang tốn của tôi bao nhiêu một tháng?

Câu trả lời thật: gần như không đáng kể. Nó đang phục vụ một spa thật. Lưu lượng một ngày của một spa cỡ vừa không phải là cái núi token. Tôi định bỏ vài buổi tối đi đẽo gọt một con số mà ở quy mô hiện tại còn chưa đủ lớn để nhìn thấy.

Đó là cái bẫy kinh điển của người ship một mình: tối ưu vì nó cho cảm giác mình giỏi, chứ không phải vì bài toán đang thật sự đau.

Cú phản đòn tôi không ngờ: cái mẹo tiết kiệm lại làm tốn tiền

Đây mới là phần khiến tôi lạnh gáy.

Tôi đã bật sẵn một thứ gọi là prompt-cache từ trước. Hiểu nôm na: phần dữ liệu lớn lặp đi lặp lại trong mỗi câu hỏi — bộ kiến thức về spa, bảng giá, giọng thương hiệu — được "giữ tạm" lại, để lần sau khỏi gửi và tính tiền lại từ đầu. Lần đầu gửi thì hơi đắt (phải ghi cache), nhưng các lần sau đọc lại thì rẻ giật mình. Nghe là một chiến thắng hiển nhiên.

Vấn đề nằm ở một chi tiết tôi suýt bỏ qua: cái cache đó chỉ sống khoảng năm phút.

Giờ ghép hai sự thật lại. Một: cache lần đầu đắt hơn gửi thường (khoảng 1,25 lần). Đọc lại thì rẻ hơn nhiều (cỡ một phần mười). Hai: spa là nơi khách nhắn rải rác — một tin lúc 9 giờ, tin tiếp lúc 9 giờ 20.

Thấy vấn đề chưa? Nếu hai tin của khách cách nhau hơn năm phút, cache đã chết giữa chừng. Tin sau không được đọc lại cache rẻ — nó lại phải ghi cache mới, lại trả cái giá đắt 1,25 lần. Lặp đi lặp lại.

Tức là: ở một con bot lưu lượng thưa, cái mẹo "tiết kiệm token" có thể âm thầm khiến tôi trả nhiều hơn là cứ gửi bình thường. Tôi tưởng mình đang tối ưu. Thực ra tôi đang trả phí cho một sự tiết kiệm chưa từng xảy ra.

Lối thoát không phải code thêm — mà là một con số

Câu hỏi đúng lúc này không phải "tối ưu thế nào". Nó là: tôi có đang thật sự tiết kiệm, hay chỉ tưởng?

Và câu đó chỉ trả lời được bằng một thứ: đo.

Nên thay vì lao vào đẽo gọt, tôi làm một việc nhỏ xíu trước. Mỗi lần con bot trả lời xong, nó tự ghi lại: lần này nó đọc lại được cache (rẻ — gọi là hit) hay phải ghi cache mới (đắt — gọi là miss). Đếm theo từng khách. Cộng dồn theo ngày.

Việc này nhỏ. Nhưng nó biến "tiết kiệm token" từ một niềm tin mơ hồ thành một con số tôi soi được. Trước khi có con số đó, mọi quyết định tối ưu của tôi đều là đoán mò — và đoán mò thì rất dễ đoán sai theo hướng làm mọi thứ tệ hơn, như cái bẫy cache ở trên.

Khi đã có số rồi, tôi mới được quyền nói: à, ở lưu lượng này, cache đang lời hay lỗ? Có nên giữ cache lâu hơn năm phút không? Có đáng cắt bớt lịch sử không? Mỗi câu giờ có dữ liệu đỡ lưng, không còn là "tôi cảm thấy nên làm".

Vì sao chuyện này đặc biệt nguy với người làm một mình

Trong một công ty, có người chuyên lo chi phí hạ tầng, có dashboard, có ai đó cản bạn lại khi bạn định tối ưu một thứ chưa đáng. Ship một mình thì không. Người duy nhất quyết định bỏ buổi tối vào đâu là bạn — và bạn không có sếp nào ngăn bạn đốt thời gian vào một bài toán chưa tồn tại.

Đó là lý do cái kỷ luật này quan trọng gấp đôi với người làm một mình: mỗi giờ tôi tiêu vào việc sai là một giờ con bot không có thêm khách, không thêm tính năng người ta cần.

Cái "đắt" thật của con bot này không phải vài đồng token hôm nay. Nó là rủi ro khi nhân lên — khi một ngày tôi chạy nhiều bot cho nhiều spa. Lúc đó tối ưu chi phí mới là bài toán thật. Còn bây giờ, đo để biết khi nào nó trở thành bài toán mới là việc đúng. Đo trước. Tối ưu sau. Đừng đẽo gọt sớm.

Bài học mang đi

Người mới hay nghĩ "ship một mình" nghĩa là làm thật nhiều, thật nhanh, tối ưu mọi ngóc ngách. Tôi thì học được điều ngược lại: một phần lớn nghề là biết những việc nào KHÔNG làm lúc này.

Cái cảm giác "đang tối ưu" rất gây nghiện, vì nó giống như đang giỏi lên. Nhưng tối ưu một con số chưa đau, dựa trên một niềm tin chưa đo, là cách nhanh nhất để vừa mất thời gian vừa làm hệ thống tệ đi mà không hay.

Một người ship một mình giỏi không phải người tối ưu sớm nhất. Là người biết đặt một cái cân vào đúng chỗ, rồi đủ kỷ luật để chờ con số bảo mình khi nào nên ra tay.

👉 Muốn tự tay build con bot đầu tiên tới chỗ hiểu vì sao "đo trước, tối ưu sau" mới là tư duy của người làm thật — chứ không phải đẽo gọt cho oách? Bắt đầu với mini-course miễn phí: Bot AI đầu tiên của bạn — làm xong trong một buổi tối, và bạn sẽ có một sản phẩm thật để bắt đầu nghĩ như một người ship một mình.