Chi phí mỗi mẫu? Hãy thử tính chi phí mỗi lần chạy

Bài viết này dành cho các trưởng nền tảng tin sinh học, kỹ sư cơ sở hạ tầng ML và những người quản lý ngân sách genomics hiện đang chạy các quy trình làm việc tăng tốc GPU trên đám mây. Nó nói về một vấn đề chi phí ẩn mà hầu hết mọi đội ngũ cơ sở hạ tầng genomics đều phải trả tiền — nhưng rất ít người chủ động đo lường nó. Các quan sát ở đây cụ thể đối với các quy trình làm việc sắp xếp trình tự đọc ngắn (short-read sequencing), vẫn là kiểu dữ liệu thống trị trong các môi trường genomics sản xuất.

Các quy trình sắp xếp trình tự đọc ngắn, tiêu chuẩn trong các quy trình làm việc của thế hệ giải mã trình tự tiếp theo (NGS), từng nặng về CPU. Bạn sẽ chạy chúng trên một cụm máy chủ, chúng sẽ nghiền ngẫm qua việc căn chỉnh và gọi biến thể trong nhiều giờ, và điểm nghẽn là thông lượng CPU. Tăng tốc GPU chưa bao giờ là câu chuyện.

Điều đó đã thay đổi. Gọi biến thể dựa trên AI, các công cụ căn chỉnh tăng tốc GPU như Parabricks và các mô hình học sâu chạy trên dữ liệu giải mã trình tự đều đã chuyển hướng sang GPU. Điều này có nghĩa là các đội ngũ đang quản lý cơ sở hạ tầng GPU nghiêm túc lần đầu tiên.

Mô hình chi phí đi kèm với đám mây GPU khác biệt rõ rệt so với các cụm CPU, và mọi người đang mang những giả định của thời đại CPU về độ tin cậy của quy trình và kế toán chi phí vào môi trường GPU. Sự không phù hợp đó đang khiến họ tốn kém.

Chúng tôi làm việc với nhiều đội ngũ như vậy, và khi hỏi về chi phí cơ sở hạ tầng, họ hầu như luôn đưa ra một con số giống nhau: chi phí mỗi mẫu. Đó là con số được báo cáo lên trên, con số nằm trong ngân sách. Điều mà con số đó che giấu mới là nơi mọi thứ trở nên thú vị.

Khi pipeline thất bại

Một quy trình gọi biến thể dòng mầm (germline) điển hình có khoảng 10 đến 15 bước xử lý riêng biệt. Bạn bắt đầu với các tệp FASTQ thô từ máy giải mã trình tự, chạy kiểm soát chất lượng, căn chỉnh, đánh dấu trùng lặp, tính toán lại điểm chất lượng cơ sở, gọi biến thể, chú thích — mỗi bước chuyển giao cho bước tiếp theo.

Các quy trình này chủ yếu chạy trên các trình quản lý quy trình như Nextflow hoặc Snakemake, vốn có cơ chế tích hợp để tiếp tục các công việc thất bại. Nextflow có một cờ được thiết kế để cho phép bạn tiếp tục từ bước thứ tám trong số 11 thay vì khởi động lại từ đầu. Về nguyên tắc, đó chính xác là giải pháp đúng đắn.

Trên thực tế, vấn đề nằm ở cấu hình. Để cờ đó hoạt động, Nextflow cần tìm thư mục bộ nhớ đệm của mình — thư mục ghi lại các bước nào đã hoàn thành thành công. Nếu kiến trúc sư giải pháp thiết lập môi trường tính toán mà không cấu hình đúng dung lượng đĩa lưu trữ bền vững cho bộ nhớ đệm đó, tệp sẽ không có ở đó khi bạn cần, và quy trình sẽ khởi động lại từ bước một anyway. Đó là một lỗi thiết lập thay vì giới hạn của công cụ, nhưng kết quả thì giống nhau: bạn đã trả tiền cho tính toán mà không nhận được kết quả đầu ra.

Khi một tác vụ lớn thất bại giữa chừng thay vì tại ranh giới bước sạch sẽ, ngay cả việc tạo điểm kiểm tra (checkpointing) đúng cách cũng không cứu bạn được, vì tác vụ phải được chạy lại hoàn toàn.

Một vấn đề khó đo lường

Các đội ngũ genomics làm việc với Nebius báo cáo nhất quán rằng 15 đến 40 phần trăm các lần chạy quy trình của họ gặp ít nhất một lần thất bại và khởi động lại trước khi hoàn thành. Việc xác định chính xác con số này rất khó, và chúng tôi không có con số xác định nào phản ánh thực tế ở đây.

Phạm vi rộng vì nó phụ thuộc nhiều vào mức độ trưởng thành của thiết lập cơ sở hạ tầng. Các đội ngũ có môi trường được cấu hình tốt nằm ở mức thấp; các đội ngũ mới làm quen với đám mây GPU hoặc chạy trên các spot instance có tỷ lệ gián đoạn cao hơn nằm ở mức cao.

Điều khiến điều này trở nên vô hình là nếu chỉ số của bạn là chi phí mỗi mẫu hoàn thành, một lần chạy thất bại cuối cùng hoàn thành vẫn trông giống như một mẫu với chi phí bình thường. Việc thử lại biến mất khỏi con số được báo cáo.

Ví dụ, một quy trình giải mã trình tự toàn bộ bộ gen tăng tốc GPU — gọi biến thể dòng mầm — mất khoảng hai giờ GPU trên H200. Với tỷ lệ theo yêu cầu hiện tại, đó là khoảng 9 đô la tính toán cho mỗi mẫu, và đó là chi phí nhìn thấy được.

Bây giờ hãy áp dụng tỷ lệ thất bại 25 phần trăm — hướng về mức thấp hơn của những gì các đội ngũ báo cáo. Với mỗi bốn mẫu bạn hoàn thành, một lần chạy thất bại, khởi động lại và chạy lại từ đầu. Chi phí thực tế của bạn cho mỗi mẫu hoàn thành không còn là 9 đô la nữa — mà là 11,25 đô la, một mức đánh dấu ẩn 25 phần trăm.

Mở rộng quy mô đó cho một đội ngũ xử lý 2.000 mẫu một tháng: hóa đơn tính toán nhìn thấy được là 18.000 đô la, nhưng chi phí thực là 22.500 đô la. Đó là 4.500 đô la một tháng — 54.000 đô la một năm — trong tính toán không tạo ra kết quả đầu ra nào. Đối với một đội ngũ genomics quy mô vừa, đó là một phần đáng kể của ngân sách đám mây, và nó không xuất hiện ở đâu dưới dạng lãng phí.

Và đó là chưa kể đến lưu trữ.

Các chi phí ẩn

Bức tranh lưu trữ tinh tế hơn nhiều so với mọi người mong đợi. Một bộ gen toàn bộ tiêu chuẩn tạo ra khoảng 200 gigabyte dữ liệu FASTQ thô, nhưng đó là con số chưa nén. Trong thực tế, hầu hết mọi thứ đi vào lưu trữ lạnh đều được nén, thường giảm xuống khoảng 30 gigabyte mỗi mẫu, vì vậy chi phí lưu trữ mỗi mẫu khá dễ quản lý.

Nơi nó trở nên phức tạp là việc truy xuất. Khi bạn muốn phân tích lại các mẫu được lưu trữ — ví dụ, chạy một nhóm đối tượng mới thông qua một quy trình cập nhật — bạn kéo các tệp nén đó trở lại, và cơ sở hạ tầng của bạn sau đó cần giải nén chúng. Tệp nén 30 gigabyte đó mở rộng thành 200 gigabyte, điều này có nghĩa là bạn cần không gian đĩa và dung lượng bộ nhớ để xử lý sự mở rộng đó. Nếu môi trường không được định kích thước cho nó, bạn sẽ gặp lỗi hoặc sự chậm trễ nghiêm trọng ở bước giải nén, điều này trở thành một danh mục chi phí ẩn khác hiếm khi được tính toán trước.

Trong nghiên cứu ung thư, các con số lớn hơn nhiều. Gọi biến thể đột biến soma (somatic) chạy ở độ sâu giải mã trình tự 60x đến 100x, vì vậy các tệp FASTQ 600 gigabyte không phải là hiếm. Mọi thứ tôi đã mô tả đều mở rộng tương ứng.

Điểm chính: việc truy xuất từ lưu trữ lạnh luôn có chi phí, bất kể tính toán của bạn nằm ở đâu so với lưu trữ của bạn. Một số nền tảng tính phí cho dữ liệu egress giữa các vùng trên top của đó. Dù bằng cách nào, các đội ngũ chưa mô hình hóa tần suất phân tích lại của họ như một mục chi phí thực sự hầu như luôn bị bất ngờ khi họ làm điều đó.

Theo dõi, theo dõi và theo dõi...

Các kỹ sư tin sinh học biết tỷ lệ thất bại, vì họ là những người theo dõi các công việc thất bại lúc 2 giờ sáng. Nhưng đến khi các con số được tổng hợp cho bất kỳ ai kiểm soát ngân sách, nó chỉ là "chi phí đám mây". Không có mục chi phí nào cho "tính toán chúng tôi trả tiền nhưng không nhận được kết quả đầu ra".

Hóa đơn đám mây theo dịch vụ và loại instance không làm nổi bật điều này. Bạn thấy chi tiêu tính toán GPU của mình, chi tiêu lưu trữ, egress của mình. Bạn không thấy "20% chi tiêu GPU của bạn tháng này là cho các lần chạy không hoàn thành". Sự phân tích đó yêu cầu đo lường có chủ đích, và hầu hết các đội ngũ chưa xây dựng nó.

Những gì các đội ngũ nên đo lường thay vì chi phí mỗi mẫu

Các đội ngũ nên đo lường một vài thứ thay vào đó. Đầu tiên, tỷ lệ hoàn thành: phần trăm các lần chạy quy trình hoàn thành mà không có lỗi hoặc khởi động lại. Đó là điểm số độ tin cậy của quy trình của bạn, được liên kết trực tiếp với lãng phí tính toán.

Thứ hai, chi phí mỗi mẫu thử so với chi phí mỗi mẫu hoàn thành. Nếu những con số đó khác biệt một cách có ý nghĩa, bạn có một vấn đề đáng để sửa chữa.

Thứ ba, tần suất truy xuất lưu trữ và chi phí cơ sở hạ tầng của việc giải nén: bạn thường kéo dữ liệu lưu trữ trở lại bao nhiêu lần, và liệu bạn đã định kích thước đúng đĩa và bộ nhớ cho nó chưa. Đây là khoảng cách giữa những gì trông có vẻ rẻ trong hóa đơn lưu trữ và chi phí để sử dụng dữ liệu.

Một điều mà các đội ngũ cơ sở hạ tầng genomics nên làm khác nhau bắt đầu từ tuần này

Hãy đo lường tỷ lệ thất bại của quy trình của bạn, ngay bây giờ, trước bất cứ điều gì khác.

Con số bản thân nó không sửa chữa bất cứ điều gì, nhưng nó làm cho vấn đề trở nên nhìn thấy được. Một khi bạn có thể chỉ ra rằng 15 hoặc 25 phần trăm chi phí tính toán của bạn đang đi vào các lần chạy khởi động lại — với các con số đô la thực tế gắn liền — cuộc trò chuyện về việc sửa chữa cơ sở hạ tầng cơ bản trở nên dễ dàng. Mọi người di chuyển nhanh khi họ có thể thấy sự lãng phí.

Mọi thứ khác đều tuân theo điều đó — cấu hình điểm kiểm tra tốt hơn, kiến trúc lưu trữ thông minh hơn, tính toán ổn định hơn — nhưng bạn phải nhìn thấy vấn đề trước.

Khám phá những đột phá đang định hình tương lai của AI trong chăm sóc sức khỏe và khoa học đời sống. Truy cập https://nebius.com/solutions/life-sciences-and-healthcare để tìm hiểu thêm và đăng ký tham dự lễ trao giải AI Discovery Awards 2026: nebius.com/ai-discovery-award.