Phân Bổ Chi Phí AI Token Trong Outsourcing: Framework Theo Dõi LLM Spend Theo Từng CWO

Cái Dòng Chi Phí Không Ai Nghĩ Tới Khi Lập Budget

Hai năm trước, AI tooling còn là thứ "thử xem sao". Giờ thì nó đã là infrastructure rồi. Developer ở các công ty outsourcing đang dùng Cursor, GitHub Copilot, Claude, GPT-4 mỗi ngày — và cái "dùng mỗi ngày" đó có giá tiền thật.

Vấn đề là phần lớn công ty outsourcing vẫn đang xử lý chi phí token AI kiểu như license phần mềm hồi 2010: gom vào overhead, không hiện lên P&L dự án, không trace được về phía client hay hợp đồng cụ thể nào.

Khi AI cost của một project có thể chạy vài nghìn đô mỗi tháng, câu "cứ hấp thụ vào overhead đi" bắt đầu không còn hold được nữa — với client, với finance team, với bất kỳ ai đang cố tính xem project này thực sự lời hay lỗ.

Bài này đề xuất một framework để giải bài toán đó. Đây là proposed approach, không phải case study đã chạy production — mình chia sẻ như một starting point để cả ngành cùng thảo luận.

Tại Sao Bài Toán Này Khó Hơn Bình Thường Trong Outsourcing

Ở product company, việc gán chi phí AI khá đơn giản: AI phục vụ product, product sinh revenue, xong. Outsourcing thì khác — và khác theo những chiều quan trọng.

Đầu tiên, developer thường chạy song song nhiều hợp đồng. Một senior dev có thể đang 50% cho CWO fintech, 30% cho project e-commerce, 20% internal tooling — tất cả trong cùng một tuần. Nếu người đó dùng AI nhiều, client nào pay?

Thứ hai, đơn vị billing trong outsourcing là CWO (Contract Work Order), không phải project. Một project có thể kéo dài 3 năm qua 4 CWO khác nhau. Chi phí token phải land ở cấp CWO mới invoice được, không phải chỉ cấp project.

Thứ ba, AI tool usage không tự nhiên scope vào một project cụ thể. Không như compute cost có thể tag vào environment, một LLM prompt không biết — và không quan tâm — nó đang help code của client nào.

Core Insight: Timesheet Đã Giải Được Bài Này Rồi

Đây là observation quan trọng nhất: các công ty outsourcing đã có sẵn một hệ thống track chính xác thời gian của mỗi developer phân bổ vào CWO nào mỗi tuần. Đó là timesheet.

Nếu mình biết Developer A log 20 giờ vào CWO-Fintech và 10 giờ vào CWO-Ecommerce trong tuần 10, và biết Developer A đã dùng hết $45 AI token tuần đó — thì cách phân bổ defensible nhất, ít friction nhất là:

• CWO-Fintech: 20/30 × $45 = $30.00
• CWO-Ecommerce: 10/30 × $45 = $15.00

Đây là phân bổ theo tỷ lệ giờ thực tế đã log. Key ở chỗ dùng giờ đã submit và được approve — không phải giờ estimate hay plan — làm distribution key.

Lý do quan trọng: actual hours phản ánh thực tế. Planned allocation là aspirational; timesheet là những gì thực sự đã xảy ra.

Data Flow Đề Xuất

Đây là cách mình hình dung toàn bộ pipeline chạy:

Developer dùng AI tools (Cursor, Copilot, Claude API...)
        │
        ▼
AI Platform Team collect token usage logs
  { user_id, date, total_tokens, cost_usd }
        │
        ▼
Data Lake / Pipeline aggregate theo tuần
  { employee_id, week_start_date, total_tokens, total_cost_usd }
        │
        ▼
ETM (Timesheet System) query Data Lake mỗi tuần
        │
        ▼
Với mỗi employee, pull TimesheetEntry đã approve trong tuần đó
  → Traverse: TimesheetEntry → Task → Allocation → CWORole → CWO
  → Tính giờ theo từng CWO
  → Distribute token cost proportionally
        │
        ▼
Store: TokenCostAllocation { EmployeeId, CWOId, WeekDate, Tokens, CostUSD }
        │
        ▼
Aggregate lên Project level cho dashboard
Report ở CWO level cho invoicing

Tại Sao CWO, Không Phải Project?

Khi thảo luận nội bộ, instinct đầu tiên là track ở cấp project — đơn giản hơn, và phù hợp với cách AI Platform Team nghĩ về codebase ownership.

Nhưng trong outsourcing, CWO mới là billing unit. Một project có thể có 3 CWO active trong cùng một quý. Khi contract với client sắp renew, bạn muốn show họ true cost of delivery — bao gồm AI tooling — scoped vào contract period đó, không phải toàn bộ project history.

Practical compromise: store ở CWO level, aggregate lên Project level để display. Finance có granularity cho invoicing, PM và CTO có project-level view cho cost management.

Xử Lý Developer Chạy Nhiều CWO Song Song

Edge case phức tạp nhất là developer làm việc trên nhiều CWO trong cùng một tuần. Proportional hours handle được khá clean, nhưng có vài nuances cần lưu ý:

Non-billable allocation: Thời gian trên CWO internal hay non-billable có tính token cost không? Đề xuất: có, đưa vào denominator khi tính tỷ lệ, nhưng flag riêng. Internal AI cost vẫn là real cost — chỉ là không pass sang client.

Tuần nghỉ phép: Developer nghỉ cả tuần thì token usage (nếu có) tính là overhead, không allocate vào CWO nào.

Timesheet nộp trễ: Nếu developer chưa submit timesheet khi weekly pipeline chạy, fall back về planned allocation hours làm provisional estimate. Recalculate sau khi timesheet được approve.

Zero-hours edge case: Developer có active allocation nhưng log 0 giờ cho tất cả CWO trong tuần — distribute đều token cost cho các CWO active thay vì để pipeline fail silently.

Phần Còn Thiếu: Ai Quyết Định Một CWO Được Cấp Bao Nhiêu Token?

Framework phân bổ ở trên trả lời câu hỏi "token đã đi đâu?" Nhưng có một câu hỏi quan trọng không kém mà ngành chưa address được: "một CWO nên được budget bao nhiêu token ngay từ đầu?"

Hầu hết công ty đang dùng một trong hai cách. Finance set một flat percentage của project budget cho AI tooling (top-down), hoặc Tech Lead estimate theo gut feel (bottom-up). Cả hai đều có vấn đề nghiêm trọng. Flat percentage bỏ qua thực tế là một CWO data engineering phức tạp ngốn token nhiều hơn gấp bội so với một CWO maintenance. Còn gut-feel estimate chỉ tốt bằng kinh nghiệm của người estimate — mà kinh nghiệm đó gần như bằng 0 với một cost category vừa xuất hiện hai năm trước.

Mình đề xuất model thứ ba: data-driven budget suggestion, PM confirm.

Khi hệ thống đã có vài tháng actual token usage data — data mà allocation pipeline ở trên tự generate — timesheet system có thể tính ra benchmark theo từng role:

Historical averages (computed từ TokenCostAllocation):
  Backend Developer:   ~8,000 tokens / tuần / người
  QA Engineer:         ~3,000 tokens / tuần / người
  Project Manager:     ~1,500 tokens / tuần / người

Khi PM tạo CWO mới, hệ thống đọc planned allocation và surface suggested budget tự động:

CWO mới: "Bosch Phase 3"   (12 tuần)

  Suggested weekly budget:
    3 × BE Dev  →  3 × 8,000  =  24,000 tokens
    1 × QA      →  1 × 3,000  =   3,000 tokens
    1 × PM      →  1 × 1,500  =   1,500 tokens
                              ─────────────────
    Weekly total              =  28,500 tokens
    + 5% buffer               =  30,000 tokens

  Suggested total budget:  30,000 × 12 tuần = 360,000 tokens

  [Confirm]  [Adjust]  [Skip]

PM không cần hiểu token pricing hay consumption pattern. Họ thấy một con số được build từ cách các role tương tự đã thực sự chạy ở các CWO trước, và confirm hoặc adjust trong một bước. Đó là toàn bộ interaction cần thiết.

Cách tiếp cận này có một property quan trọng: nó tự cải thiện theo thời gian. Mỗi CWO complete thêm một data point. Suggestion của hệ thống ở tuần đầu sẽ còn rough; đến tháng thứ sáu, nó đã được calibrate theo tooling habits và project type cụ thể của team.

Có một bootstrapping problem rõ ràng — không thể có historical benchmark trước khi có history. Trong 2-3 tháng đầu, team nên focus hoàn toàn vào tracking actual usage, không cần lo budget. Data thu được trong giai đoạn đó trở thành seed cho các suggestion có ý nghĩa về sau.

Mỗi Team Cần Làm Gì

AI Platform Team: Token usage phải trackable ở cấp individual user, không phải chỉ team level. Nếu AI tooling chỉ expose aggregate usage theo department, toàn bộ approach này sẽ không work. User-level attribution là hard prerequisite.

Data Pipeline team: Weekly aggregate export ở format queryable được: { employee_id, week_start_date, total_tokens, cost_usd }. Timesheet system không cần raw logs — weekly summary theo từng người là đủ.

Timesheet / ETM team: Một bảng mới để store allocated token cost, một scheduled job chạy weekly để pull từ Data Lake và run allocation logic, một recalculation trigger khi timesheet được approve hoặc amend, và hai field mới trên bảng CWO (TokenBudgetPerWeek, TokenBudgetTotal) để lưu confirmed budget.

Schema Đề Xuất

Đây là minimal schema addition để support toàn bộ framework — cả allocation tracking lẫn budget management:

-- Extend CWO table (PM set một lần khi tạo CWO)
CWO
  TokenBudgetPerWeek   BIGINT NULL
  TokenBudgetTotal     BIGINT NULL

-- Weekly allocation result (fully automated)
TokenCostAllocation
─────────────────────────────────────────────
Id                UNIQUEIDENTIFIER  PK
EmployeeId        UNIQUEIDENTIFIER  FK → Employee
CWOId             UNIQUEIDENTIFIER  FK → CWO
MondayDate        DATE              Week identifier
AllocatedTokens   BIGINT
AllocatedCostUSD  DECIMAL(18, 4)
AllocationBasis   NVARCHAR(20)      'ACTUAL' | 'ESTIMATED'
IsRecalculated    BIT

-- Budget vs actual tracking (fully automated)
TokenBudgetTracking
─────────────────────────────────────────────
Id              UNIQUEIDENTIFIER  PK
CWOId           UNIQUEIDENTIFIER  FK → CWO
MondayDate      DATE
BudgetTokens    BIGINT
ActualTokens    BIGINT
UtilizationPct  DECIMAL(5, 2)
CreatedAt       DATETIME2

Field AllocationBasis flag xem allocation dùng approved timesheet hours (ACTUAL) hay planned allocation hours (ESTIMATED). Bảng TokenBudgetTracking enable utilization dashboard và automated alert — notify PM khi đạt 70%, escalate khi đạt 90% — không cần manual intervention nào trong pipeline.

Các Câu Hỏi Còn Mở

• Token cost có nên bill cho client không? Đây là commercial decision, không phải technical. Nhưng có data thì mới có thể bắt đầu conversation đó.
• Xử lý shared AI infrastructure cost như thế nào (ví dụ: một RAG system central phục vụ nhiều project)? Proportional hours không work ở đây — cần usage-level attribution.
• Refresh cadence phù hợp là gì? Weekly align với timesheet cycle, nhưng một số công ty có thể muốn monthly để match invoicing cycle.
• Audit allocation như thế nào? Developer nên có thể xem token usage của mình được distribute như thế nào, đặc biệt nếu nó affect project cost reporting.
• Bao lâu thì benchmark trở nên reliable? Hypothesis của mình là 2-3 tháng data per role type, nhưng con số này sẽ vary nhiều tùy team size và tooling mix.

Tại Sao Bây Giờ Là Lúc Cần Làm Điều Này

Ngành outsourcing đã dành nhiều thập kỷ build các framework phức tạp để track thời gian con người — timesheet, allocation, billing rate, CWO structure. Tất cả infrastructure đó tồn tại vì time là primary input cost.

AI đang trở thành primary input cost thứ hai. Nó xứng đáng được đối xử với cùng mức độ nghiêm túc đó.

Tin tốt là hard infrastructure — timesheet, CWO hierarchy, weekly billing cycle — đã có sẵn rồi. Framework này không yêu cầu rebuild từ đầu. Nó chỉ yêu cầu connect hai data system chưa bao giờ được designed để nói chuyện với nhau, dùng timesheet như cái bridge. Và khi connection đó tồn tại, chính data track "token đã đi đâu" cũng sẽ cho biết "nên budget bao nhiêu token cho lần sau".

Nếu bạn đang build gì đó tương tự, hoặc có approach khác — mình thực sự muốn nghe.