# FDE tốn khoảng 400.000 USD mỗi năm: mô hình chỉ scale được khi mỗi lần deployment làm lần sau rẻ hơn

> Các công ty AI đổ khoảng 10 tỷ USD trong 12 tháng để dựng đội FDE, nhưng thứ quyết định mô hình sống hay chết không nằm ở số người được tuyển.

Bản gốc: https://fdetimes.net/vi/phan-tich/mo-hinh-fde-co-scale-duoc-khong/

Các phòng lab AI hàng đầu đang trả từ 350.000 đến 550.000 USD cho một FDE senior, theo nhà đầu tư Tom Tunguz. Cùng lúc, ông ước tính các công ty AI đã cam kết khoảng 10 tỷ USD chỉ trong 12 tháng để dựng đội forward-deployed engineering.

Với chi phí xấp xỉ 400.000 USD mỗi FDE mỗi năm, Tunguz đặt câu hỏi rất thẳng: nhân mô hình này lên 10 lần có làm vỡ chính phép tính kinh tế từng khiến nó hiệu quả hay không. Câu trả lời không nằm ở việc tuyển thêm bao nhiêu người. Nó nằm ở chỗ mỗi lần deployment có làm lần sau rẻ hơn hay không.

Với bạn, một developer muốn bước vào nghề FDE, đây không phải chuyện tài chính của người khác. Nó quyết định loại FDE nào được trả lương cao và được giữ lại khi thị trường tỉnh táo: người giải xong bài toán cho một khách hàng, hay người biến lời giải đó thành thứ cả công ty dùng lại được.

## Đường thẳng là kẻ thù của phần mềm

Valletta Software mô tả vấn đề gọn gàng: số người làm deployment tăng tuyến tính theo số khách hàng, trừ khi mỗi lần triển khai làm lần sau rẻ hơn. Nói cách khác, bản thân mô hình FDE đắt về mặt cấu trúc. Đắt không phải vì lương cao, mà vì chi phí ấy lặp lại với từng khách mới.

Thử hình dung một công ty có 10 khách hàng doanh nghiệp, mỗi khách cần một nhóm FDE riêng. Lên 100 khách, nếu mọi thứ vẫn được làm tay từ đầu, công ty cần gấp mười lần số người. Lúc đó nó không còn là công ty phần mềm nữa, mà là một hãng tư vấn có sản phẩm đi kèm.

Đó là lý do bản tin Inside Software nhấn mạnh rằng FDE chỉ hợp lý khi nó bảo vệ biên lợi nhuận kiểu phần mềm thay vì trôi dần về biên lợi nhuận kiểu dịch vụ. Cùng nguồn này ghi nhận đội FDE có thể mở rộng lên khoảng 8 người cho các dự án lớn.

Con số đó cho thấy một giới hạn thực tế: bạn không thể dồn vô hạn người vào một khách hàng, nên tăng trưởng qua nhiều khách hàng phải đến từ chỗ khác.

## Bốn cách trả lời cùng một bài toán

Palantir chọn cách chấp nhận chi phí và gọi tên nó khác đi. Theo mô tả của Tunguz, ở Palantir FDE không phải lớp dịch vụ mà chính là sản phẩm lõi. Inside Software dẫn con số FDE chiếm khoảng 20% lực lượng lao động của công ty, dù các nguồn khác đưa ra tỷ lệ thấp hơn.

Valletta Software đưa ra một công thức khác: mô hình vận hành được như một con đường scale khi nửa công việc hiện trường có thể tái sử dụng được đưa ngược vào sản phẩm lõi. FDE ở đây giống người trinh sát của đội sản phẩm.

Mỗi connector, mỗi pipeline dữ liệu, mỗi bộ đánh giá viết cho khách A phải được hỏi: khách B có cần cái này không?

Constellation Research đẩy lập luận đó đến tận cùng. Hãng cho rằng các vendor doanh nghiệp chiến thắng sẽ lấy những gì FDE học được và nhúng vào sản phẩm, đến mức khách hàng không còn cần FDE nữa. Theo góc nhìn này, FDE tồn tại vì sản phẩm AI hiện tại còn non.

Trong khi đó, các công ty dịch vụ cũng lao vào cuộc chơi. CEO của Infosys nói công khai rằng công ty đang mở rộng đội forward deployed engineer. Với một hãng dịch vụ, tăng trưởng tuyến tính theo đầu người không phải lỗi mà là mô hình kinh doanh.

Nhưng chính điều đó cũng là ranh giới mà Inside Software cảnh báo các công ty phần mềm đừng trượt qua.

| Cách scale | Ai đề xuất hoặc đi theo | FDE được đo bằng gì | Rủi ro chính |
|---|---|---|---|
| FDE là sản phẩm | Palantir | Giá trị tạo ra tại từng khách hàng | Tỷ lệ FDE trong công ty cao, chi phí lớn |
| Đưa nửa dùng lại được vào sản phẩm | Công thức do Valletta Software mô tả | Mỗi deployment làm lần sau rẻ hơn bao nhiêu | Đội sản phẩm không tiếp nhận được phản hồi hiện trường |
| Productize đến khi không cần FDE | Kịch bản của Constellation | Bao nhiêu việc tay biến thành tính năng | Vai trò FDE thu hẹp khi sản phẩm chín |
| Tăng đầu người | Công ty dịch vụ như Infosys | Số giờ, số dự án giao được | Biên lợi nhuận kiểu dịch vụ |

Trừ mô hình dịch vụ thuần, cả ba hướng còn lại đều đặt cược vào một cơ chế: công việc ở hiện trường phải chảy ngược về sản phẩm. Khác biệt chỉ là tốc độ chảy và việc FDE còn lại bao nhiêu khi dòng chảy hoàn tất.

## Mỗi lối tắt ở hiện trường đều có giá

Cả công thức của Valletta lẫn kịch bản của Constellation đều ngầm đòi hỏi cùng một kỹ năng. Đó là khả năng nhìn vào một deployment lộn xộn và tách ra đâu là thứ chỉ khách này cần, đâu là mẫu hình sẽ lặp lại ở khách sau.

Kỹ năng này khó hơn vẻ ngoài. Ở hiện trường, áp lực là giao việc cho khách hàng trước hạn, nên cách nhanh nhất luôn là viết code riêng, hard-code cấu hình, sửa tay dữ liệu. Mỗi lối tắt như vậy đều hợp lý trong tuần đó, và cộng lại chúng chính là thứ kéo công ty về đường thẳng tuyến tính.

Vì thế, nếu một công ty trả 400.000 USD cho một FDE, khoản tiền đó chỉ đáng khi người ấy để lại thứ gì đó lớn hơn một khách hàng hài lòng. Ngay cả trong kịch bản của Constellation, khi sản phẩm chín và cần ít FDE hơn, những người đã làm công việc productize lại là người hiểu sản phẩm và khách hàng sâu nhất.

**Điểm mấu chốt:** FDE đáng giá nhất không phải người giải được bài toán của một khách hàng, mà là người khiến khách hàng kế tiếp tốn ít công hơn.

## Developer Việt Nam nên đặt cược vào đâu?

Nhiều developer Việt Nam đang làm ở các công ty outsourcing, tức là sống trong mô hình dịch vụ tính theo đầu người. Đó không phải điểm yếu: bạn đã quen ngồi cạnh khách hàng, đọc hệ thống lạ, giao việc dưới áp lực. Thứ còn thiếu thường là thói quen hỏi phần nào của dự án này nên trở thành sản phẩm.

Hãy thể hiện thói quen đó trong CV. Thay vì "triển khai hệ thống cho khách hàng ngân hàng", hãy viết bạn đã rút ra thành phần dùng lại nào, như một connector, một bộ test đánh giá hay một template triển khai, và nó giúp những dự án sau rút ngắn bao lâu.

Viết như vậy là cách bạn chủ động cho người tuyển dụng thấy mình hiểu bài toán biên lợi nhuận, thay vì chờ họ tự suy ra từ danh sách dự án.

Khi đọc job description hoặc đi phỏng vấn, hãy để ý FDE nằm ở đâu trong sơ đồ tổ chức. Nếu vai trò gắn với đội sản phẩm và có quy trình rõ để đưa phản hồi hiện trường vào roadmap, đó là mô hình đang cố bẻ cong đường thẳng.

Nếu vai trò chỉ được đo bằng số dự án giao xong, bạn đang ứng tuyển vào một công việc dịch vụ mang tên mới.

Câu hỏi đáng theo dõi không phải là ngành còn cần FDE hay không, mà là mỗi FDE để lại bao nhiêu trong sản phẩm sau khi rời khách hàng. Hãy là người trả lời được câu hỏi đó bằng con số.

**Thử ngay tuần này:**

- Mở lại dự án gần nhất bạn làm cho khách hàng, chia mọi việc đã làm thành hai cột: 'chỉ riêng khách này' và 'khách sau dùng lại được'.
- Viết lại một dòng CV theo công thức: triển khai cho ai, rút ra thành phần dùng lại nào, giúp lần triển khai sau nhanh hơn ra sao (dùng số liệu thật của bạn).
- Chuẩn bị một câu hỏi phỏng vấn: 'Những gì FDE học được ở khách hàng đi vào sản phẩm lõi qua quy trình nào?'

## Nguồn

- [FDE arms race (Tom Tunguz)](https://tomtunguz.com/fde-arms-race/)

- [The Forward Deployed AI Engineer Model, and What It Costs](https://vallettasoftware.com/blog/post/forward-deployed-engineer-model)

- [Forward deployed engineers: The promise, peril in AI deployments](https://www.constellationr.com/insights/news/forward-deployed-engineers-promise-peril-ai-deployments)

- [Inside Software 01.18.26 - The Rise (and Real Variations) of the Forward Deployed Engineer](https://insidesoftware.substack.com/p/inside-software-011826-the-rise-and)