# Hệ thống Tiến hóa Thông minh EvoX và Thực hành Nghiên cứu AI Native - Bài giảng khóa học

Thời lượng: 1 · Số trang bài giảng: 16

## Điều hướng đọc

- [Bài 4｜Chủ đề: Nền tảng tính toán hiện đại và tiến hóa song song dạng tensor](#lecture-lesson-1)

---

<a id="lecture-lesson-1"></a>

## Bài 4｜Chủ đề: Nền tảng tính toán hiện đại và tiến hóa song song dạng tensor

<a id="lecture-page-1"></a>

### Nền tảng tính toán hiện đại và tiến hóa song song dạng tensor

*Trang 1*

> **Mục tiêu trang:** Tìm hiểu cách EvoX tổ chức quần thể, đánh giá và trạng thái thành tensor có thể tính toán toàn bộ, phá vỡ nút thắt tuần tự truyền thống để đạt tăng tốc quy mô lớn.

> **Mục tiêu trang**
>
> Trang này là phần mở đầu của bài 4, nêu ra vấn đề cốt lõi mà bài này cần giải quyết — khi quy mô quần thể, số lần đánh giá và số bước lặp của thuật toán tiến hóa ngày càng tăng, cách xử lý tuần tự từng cá thể, từng bước truyền thống sẽ trở thành nút thắt rõ rệt. Mạch chính của bài này là xem EvoX tổ chức lại quần thể, đánh giá và trạng thái thành tensor có thể tham gia tính toán toàn bộ như thế nào, từ đó đạt được tăng tốc thực chất trong các kịch bản quy mô lớn.

> **Trình tự giảng giải**
>
> Có thể bắt đầu bằng một câu hỏi trực quan — "Nếu quần thể có mười vạn cá thể, chúng ta vẫn phải xử lý từng cái một theo vòng lặp, điều gì sẽ xảy ra?" để dẫn dắt sinh viên nhận ra sự lãng phí kép của vòng lặp tuần tự về mặt thời gian và hiệu suất sử dụng phần cứng. Sau đó đưa ra hướng trả lời của bài này: coi toàn bộ quần thể như một lô dữ liệu, coi cập nhật một thế hệ như một phép toán lô, để tính toán có thể được triển khai tổng thể trên phần cứng song song. Cuối cùng dẫn ra vai trò của lớp Runtime, giải thích rằng nó chịu trách nhiệm điều phối năng lực tính toán không đồng nhất trong khi vẫn duy trì khả năng kết hợp của thuật toán.

**Điểm giảng dạy chính**

- 1. Biểu diễn dạng tensor — quần thể, đánh giá độ thích nghi và trạng thái nội bộ thuật toán không còn là các đối tượng rời rạc, mà được tổ chức thành tensor có hình dạng thống nhất, cho phép một thế hệ tiến hóa được biểu diễn bằng một số phép toán lô. Lợi ích là mô hình tính toán gọn gàng, thuận tiện vector hóa, và cùng một mô tả thuật toán có thể thích ứng với quần thể ở các quy mô khác nhau. 2. Phá vỡ nút thắt tuần tự — trong triển khai truyền thống, đánh giá và cập nhật trạng thái thường được thực hiện từng cá thể một, khi quy mô lớn, chi phí vòng lặp và chờ đồng bộ sẽ chi phối thời gian chạy
- sau khi chuyển sang lô hóa, các chi phí này được phân bổ mỏng, thông lượng tăng đáng kể. 3. Vai trò điều phối của Runtime — Runtime nằm giữa mô tả thuật toán và phần cứng bên dưới, chịu trách nhiệm phân phối phép toán lô đến CPU, GPU và các năng lực tính toán không đồng nhất khác, giúp tác giả thuật toán không phải viết lại logic cho từng thiết bị. Đồng thời, nó duy trì khả năng kết hợp của các thành phần thuật toán, cho phép các toán tử và chiến lược khác nhau được ghép nối tự do mà không phá vỡ khả năng song song.

**Từ khóa bao phủ**

- Tensor hóa, tính toán lô, nút thắt tuần tự, tăng tốc quy mô lớn, điều phối năng lực tính toán không đồng nhất, khả năng kết hợp thuật toán.

**Kiểm tra hiểu biết**

Yêu cầu sinh viên dùng lời của mình nói rõ "biến quần thể thành tensor" thực sự thay đổi điều gì — câu trả lời kỳ vọng nên nằm ở tầng "từ vòng lặp từng cá thể chuyển sang phép toán lô tổng thể, từ đó phần cứng song song thực sự được sử dụng"; nếu chỉ lặp lại thuật ngữ mà không nói được quan hệ nhân quả, có thể gợi ý họ tổ chức lại diễn đạt từ hai góc độ: số lần tính toán và hiệu suất sử dụng phần cứng.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên đã thiết lập được chuỗi nhân quả cơ bản "tensor hóa → tính toán lô → tăng tốc song song", mới chuyển sang các trang tiếp theo, xem cụ thể quần thể và trạng thái được tổ chức thành tensor như thế nào, và Runtime hoàn thành điều phối ra sao.

<a id="lecture-page-2"></a>

### Nền tảng tính toán hiện đại và tiến hóa song song dạng tensor

*Trang 2*

> **Mục tiêu trang:** Người học cần hiểu mâu thuẫn giữa nhu cầu năng lực tính toán quy mô lớn của tính toán tiến hóa hiện đại và kiến trúc tuần tự truyền thống.

> **Mục tiêu trang**
>
> Hiểu mâu thuẫn giữa nhu cầu năng lực tính toán quy mô lớn của tính toán tiến hóa hiện đại và kiến trúc tuần tự truyền thống; nắm được tư duy tổ chức quần thể, đánh giá và trạng thái thành tensor, thúc đẩy tiến hóa bằng song song lô; nhận biết sự mở rộng của mô hình lớn đối với việc sinh ứng viên, và các đánh đổi kiến trúc cấp hệ thống đi kèm.

> **Trình tự giảng giải**
>
> Trước tiên nêu rõ mâu thuẫn cốt lõi "đa dạng → số lần đánh giá → chi phí quản lý trạng thái và điều phối", sau đó giải thích tại sao vòng lặp tuần tự chạm trần trước; tiếp theo triển khai ba tầng tensor hóa — tensor quần thể, tensor đánh giá, tensor trạng thái, và tổng kết thuật ngữ cốt lõi "song song lô"; sau đó giải thích cách mô hình lớn đẩy việc sinh ứng viên đến biên giới mới; cuối cùng đi vào ví dụ kịch bản EvoX và đánh đổi cấp hệ thống, xử lý bài tập và tình huống.

**Điểm giảng dạy chính**

- Tiến hóa phụ thuộc vào đa dạng quần thể, và đa dạng trực tiếp chuyển hóa thành số lần đánh giá, chi phí quản lý trạng thái và điều phối. Trong vòng lặp tuần tự CPU truyền thống, mỗi cá thể phải gọi hàm mục tiêu riêng, cập nhật trạng thái riêng, ghi log riêng
- khi quần thể tăng từ vài chục lên hàng nghìn, số lần đánh giá và thời gian đồng hồ tường gần như tăng tuyến tính, một khi chi phí mô phỏng đơn lẻ cao, thông lượng tổng thể bị khóa chết ở "nhịp đơn nhân". Đa dạng càng cao, đánh giá càng đắt, nút thắt tuần tự càng rõ. Cách tensor hóa là tổ chức lại quần thể, đánh giá và trạng thái thành tensor có thể tính toán toàn bộ. Tensor quần thể xếp chồng tất cả tham số ứng viên thành tensor hai chiều "số cá thể × chiều", một lần gọi toán tử hoàn thành đột biến và cập nhật toàn bộ quần thể
- tensor đánh giá đóng gói yêu cầu đánh giá lô gửi xuống, được GPU hoặc dịch vụ xử lý lô thực thi song song rồi hợp nhất giá trị trả về
- tensor trạng thái duy trì độ thích nghi, mức vi phạm ràng buộc, xếp hạng và các trạng thái trung gian dưới dạng tensor, cho phép chọn lọc, sắp xếp và cập nhật đều tính toán toàn bộ. Ba thứ kết hợp lại chính là "song song lô", nó biến khối lượng tính toán do đa dạng mang lại từ gánh nặng thành quy mô có thể được thông lượng hấp thụ, do đó không phải là chi tiết tối ưu, mà là vấn đề hạ tầng của tính toán tiến hóa hiện đại. Khi quy mô tính toán được mở ra, câu hỏi then chốt chuyển từ "có tính được không" sang "ứng viên đến từ đâu". Mô hình lớn có thể hiểu ngôn ngữ tự nhiên, mã nguồn, kiến thức lĩnh vực và ngữ cảnh dự án, từ đó xây dựng ứng viên có cấu trúc phức tạp, khiến đối tượng tiến hóa mở rộng từ tham số số sang chương trình, thuật toán thậm chí trạng thái hệ thống hoàn chỉnh
- cách mã hóa và đột biến trước đây phụ thuộc vào thiết kế thủ công, bắt đầu có thể do mô hình tham gia sinh. Hai nguồn lực gặp nhau tại đây: GPU cho phép khám phá đồng thời lượng lớn khả năng, mô hình lớn cho phép hệ thống tạo ra khả năng phong phú hơn, và cơ chế tiến hóa chịu trách nhiệm đưa ứng viên vào nhiệm vụ thực, thông qua thực thi và đánh giá quyết định thay đổi nào đáng giữ lại. Đối với kỹ sư thuật toán và nhà phát triển hệ thống, đây không phải tối ưu cục bộ, mà là đánh đổi kiến trúc: cần cân nhắc cấp hệ thống giữa sự phong phú của sinh ứng viên, thông lượng tính toán lô và độ phức tạp kỹ thuật. Đa dạng là tiền đề cho hiệu quả tiến hóa, nhưng nó phải được thông lượng tiêu hóa. Trong kịch bản EvoX, nếu vẫn dùng vòng lặp CPU tuần tự đánh giá từng cá thể, quy mô quần thể sẽ bị giới hạn bởi thông lượng
- sau khi chuyển sang song song lô tensor hóa, cùng một vòng có thể đồng thời tổ chức tham số, trạng thái đánh giá và cập nhật của lượng lớn ứng viên, khiến "duy trì đa dạng" và "khám phá quy mô lớn" đồng thời khả thi về mặt kỹ thuật.

**Từ khóa bao phủ**

- Song song lô, tensor hóa, tensor quần thể, tensor đánh giá, tensor trạng thái, nút thắt tuần tự, sinh ứng viên, đánh đổi cấp hệ thống.

**Xử lý bài tập**

Trang này có 5 câu trắc nghiệm và 1 câu tình huống, tổng 2 câu hỏi. Câu trắc nghiệm lần lượt kiểm tra mâu thuẫn cốt lõi, cách thực hiện song song lô, vai trò mô hình lớn, đánh đổi cấp hệ thống sau khi chuyển đổi, thay đổi trực tiếp trong kịch bản EvoX. Khi trả lời nắm hai mạch chính: một là chuỗi nhân quả "đa dạng → khối lượng tính toán → nút thắt tuần tự → song song lô"; hai là phân công "mô hình lớn chịu trách nhiệm sinh ứng viên phong phú hơn, cơ chế đánh giá chịu trách nhiệm phán đoán ứng viên nào đáng giữ lại". Câu tình huống hỏi thứ nhất yêu cầu chẩn đoán nút thắt tuần tự và giải thích tensor hóa thay đổi cách tổ chức từ ba chỗ: quần thể, đánh giá, trạng thái; hỏi thứ hai yêu cầu đưa ra phán đoán đánh đổi từ các chiều: sự phong phú ứng viên vs thông lượng lô, lợi ích khám phá vs độ phức tạp kỹ thuật, thông lượng lô vs độ trung thực đánh giá.

Câu trả lời đúng nên liên hệ được với khái niệm trang này và giải thích căn cứ; nếu phán đoán sai, quay lại chuỗi nhân quả "đa dạng → số lần đánh giá → chi phí quản lý trạng thái và điều phối", và phân biệt "tăng tốc cùng một vòng lặp tuần tự" với "thay đổi cách tổ chức tính toán".

**Kiểm tra hiểu biết**

Ngẫu nhiên gọi một sinh viên dùng lời của mình tóm tắt trọng điểm trang này, đặc biệt nói rõ đa dạng chuyển hóa thành khối lượng tính toán như thế nào, tại sao tuần tự chạm trần, song song lô tensor hóa tổ chức quần thể, đánh giá và trạng thái ra sao. Nếu sinh viên chỉ lặp lại thuật ngữ mà không giải thích được nhân quả, có thể hướng dẫn họ quay lại so sánh độ dốc trong biểu đồ và chỗ đánh dấu "nút thắt tuần tự: thông lượng chạm trần".

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên nói được quan hệ cốt lõi của trang này — đa dạng mang lại khối lượng tính toán, thực thi tuần tự chạm trần, song song lô tensor hóa tiêu hóa quy mô bằng tính toán tổng thể — mới chuyển sang ví dụ, ứng dụng hoặc tổng kết của trang tiếp theo.

<a id="lecture-page-3"></a>

### Thách thức về đa dạng tiến hóa và quy mô tính toán

*Trang 3*

> **Mục tiêu trang:** Người học cần hiểu áp lực tính toán do đánh đổi đa mục tiêu và đa dạng ứng viên trong bài toán thực tế.

> **Mục tiêu trang**
>
> Hiểu áp lực tính toán do đánh đổi đa mục tiêu và đa dạng ứng viên mang lại, nắm được biên Pareto, quan hệ chi phối, và căng thẳng giữa duy trì đa dạng với chi phí đánh giá.

**Điểm giảng dạy chính**

- Khi bài toán chỉ có một mục tiêu, mới tồn tại nghiệm tối ưu duy nhất. Bài toán kỹ thuật thực tế thường có nhiều mục tiêu ràng buộc lẫn nhau (lực nâng và lực cản, độ chính xác và độ trễ, hiệu năng và chi phí), khi đó "câu trả lời tốt" là một tập nghiệm đánh đổi không chi phối lẫn nhau, tức biên Pareto. So sánh từng mục: A có phải không kém hơn B ở mọi mục tiêu → có phải A tốt hơn nghiêm ngặt ở ít nhất một mục tiêu → cả hai đều đúng thì A mới chi phối B. Chỉ cần một mục A kém hơn, hai bên không chi phối nhau, đều có thể nằm trên biên. Trục hoành f1, trục tung f2 đều càng nhỏ càng tốt
- cụm A thiên về f1 thấp, cụm B thỏa hiệp, cụm C thiên về f2 thấp
- điểm xám là nghiệm bị chi phối. Người ra quyết định cần không gian đánh đổi mà toàn bộ biên đại diện, chứ không phải điểm đơn lẻ do thuật toán chọn ra. Chỉ sự khác biệt có cấu trúc phân bố theo các hướng đánh đổi khác nhau dọc biên Pareto. Bao phủ hướng — lấp đầy đầu trên trái, đoạn giữa, đầu dưới phải của biên
- giữ lại khác biệt — các ứng viên gần như giống nhau tương đương với một cái
- giá trị quyết định — sở thích thường được làm rõ sau, giữ lại ứng viên khác biệt cho phép chọn lại với chi phí bằng không. Đa dạng càng mạnh, không gian tìm kiếm càng rộng, quy mô quần thể càng lớn, số lần đánh giá càng nhiều. Khi đánh giá phụ thuộc vào mô phỏng độ trung thực cao (như tính khí động học cánh siêu tới hạn mất hàng giờ), chi phí đánh giá đơn lẻ bị phóng đại thành nút thắt chính. Cách ứng phó phổ biến: mô hình thay thế thay thế phần lớn đánh giá độ trung thực cao
- ưu tiên phân bổ ngân sách độ trung thực cao có hạn cho ứng viên có khả năng mở rộng bao phủ biên nhất
- phân bổ lại ngân sách giữa quy mô quần thể và số thế hệ lặp. Đánh đồng đa dạng với nhiễu ngẫu nhiên hoặc chạy thêm vài lần. Đa dạng thực sự là khác biệt hướng có cấu trúc
- nhiễu ngẫu nhiên đơn thuần không mở rộng được bao phủ biên, cũng không giảm được độ khó quyết định. Gợi ý bài tập (5 câu trắc nghiệm + 1 câu phân tích tình huống): Biên Pareto là tập nghiệm đánh đổi không chi phối lẫn nhau, hai nghiệm bất kỳ đều có ưu nhược khác nhau ở các mục tiêu khác nhau. A tốt hơn ở f1, B tốt hơn ở f2, hai bên không chi phối nhau, đều có thể nằm trên biên. Đa dạng là khác biệt có cấu trúc phân bố theo các hướng đánh đổi khác nhau dọc biên Pareto, trực tiếp phục vụ quyết định. Bao phủ hướng đánh đổi rộng hơn cần phạm vi tìm kiếm lớn hơn, quy mô quần thể và số lần đánh giá mục tiêu nhiều hơn, do đó đa dạng càng mạnh, thách thức quy mô tính toán càng lớn. Dùng mô hình thay thế gánh phần lớn đánh giá, tập trung ngân sách độ trung thực cao có hạn vào mở rộng bao phủ biên, có thể giảm căng thẳng giữa quy mô và đa dạng. Thiết kế cánh siêu tới hạn. Sản phẩm bàn giao nên là một tập nghiệm ứng viên nằm trên biên Pareto, bao phủ các hướng đánh đổi khác nhau, chứ không phải phương án đơn lẻ
- biện pháp giảm căng thẳng bao gồm mô hình thay thế, ưu tiên phân bổ ngân sách, điều chỉnh tỷ lệ quần thể và số thế hệ, sàng lọc đa độ trung thực theo giai đoạn, v.v.

**Kiểm tra hiểu biết**

Yêu cầu sinh viên dùng lời của mình giải thích quan hệ chi phối và biên Pareto, và lấy ví dụ giải thích tại sao đa dạng mang lại áp lực tính toán. Nếu sinh viên nhầm lẫn đa dạng với nhiễu ngẫu nhiên, có thể quay lại "khẩu quyết tự kiểm" — ứng viên dù nhiều, nếu chen chúc ở cùng một góc của biên, vẫn không có đa dạng.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên phân biệt được tối ưu đơn điểm và tập nghiệm đánh đổi, và hiểu chi phí đa dạng, mới chuyển sang nội dung trang tiếp theo về tiến hóa song song tensor hóa.

<a id="lecture-page-4"></a>

### Nút thắt hiệu suất của vòng lặp CPU tuần tự truyền thống

*Trang 4*

> **Mục tiêu trang:** Người học cần nhận ra giới hạn hiệu suất của vòng lặp CPU tuần tự truyền thống khi xử lý hàng vạn lần đánh giá ứng viên.

**Điểm giảng dạy chính**

- Tổng số lần đánh giá ≈ quy mô quần thể × số thế hệ lặp; thời gian đánh giá tuần tự ≈ tổng số lần đánh giá × thời gian đánh giá đơn lẻ. Trước tiên tính hai đại lượng này, sau đó phán đoán nút thắt có đáng để cải tạo không.
- Vòng lặp tầng trình thông dịch, kiểm tra biên và phân phối kiểu từng cá thể, truy cập bộ nhớ không liên tục, đồng bộ và di chuyển dữ liệu thường xuyên, sẽ cộng dồn thành chi phí hằng số tuần tự. Chỉ tinh chỉnh bản thân toán tử, chỉ cắt được một phần nhỏ trong đó.
- Vẽ thời gian đồng hồ tường dưới các quy mô quần thể khác nhau: gần như đường thẳng cho thấy thực thi vẫn tuần tự, dạng bậc thang cho thấy đã tổ chức theo lô. Hình dạng đường cong nói rõ hơn về nguồn gốc nút thắt so với con số đơn điểm.

> **Mục tiêu trang**
>
> Trang này muốn sinh viên nhận ra rằng, khi đánh giá ứng viên đạt mức hàng vạn lần, vòng lặp CPU tuần tự truyền thống sẽ trở thành đoạn hẹp nhất trong toàn bộ pipeline tiến hóa; nút thắt này thuộc tầng mô hình thực thi, chứ không phải cách viết toán tử đơn lẻ hay lỗi mã nguồn. Xử lý lô, tensor hóa và điều phối song song tiếp theo chính là hướng cải tạo nhắm vào nút thắt cấu trúc này.
>
> Trình tự giảng giải và điểm giảng dạy chính:
>
> Tiến hóa phụ thuộc vào đa dạng, đa dạng mang lại sự gia tăng gấp bội về quy mô quần thể và số lần đánh giá. Tổng số lần đánh giá ≈ quy mô quần thể × số thế hệ lặp; thời gian đánh giá tuần tự ≈ tổng số lần đánh giá × thời gian đánh giá đơn lẻ. Khi số lần đánh giá đạt mức 10⁵, thời gian đồng hồ tường tuần tự tăng gần như tuyến tính.
>
> Hình so sánh xử lý tuần tự từng cá thể và xử lý song song lô. Trục hoành là số lần đánh giá ứng viên 10³, 10⁴, 10⁵, trục tung là thời gian đồng hồ tường chuẩn hóa. Đường cong tuần tự tăng gần như tuyến tính; đường cong song song tăng dạng bậc thang. Đoạn tối biểu thị chi phí điều phối và di chuyển dữ liệu. Kết luận then chốt là: với cùng khối lượng công việc, sự tăng thời gian song song chủ yếu do số lô quyết định chứ không phải số cá thể. Dùng hình dạng đường cong nói rõ nguồn gốc nút thắt tốt hơn chỉ nhìn con số đơn điểm.
>
> Cách triển khai ngây thơ nhất là coi toàn bộ quần thể như danh sách, vòng lặp lấy từng cá thể → giải mã thành tham số cụ thể → gọi hàm đánh giá → ghi độ thích nghi trở lại. Giữa các lần lặp liên tiếp gần như không thể chồng chéo: kết quả đánh giá không trở về, ghi lại không thể tiến triển; ghi lại không hoàn thành, cá thể tiếp theo không có chỗ đặt kết quả. Do đó các đơn vị song song như đa nhân, SIMD, GPU phần lớn thời gian nhàn rỗi.
>
> Số lần đánh giá phình to tuyến tính; thực thi từng cá thể ở tầng trình thông dịch, bao gồm vòng lặp từng cá thể, kiểm tra biên và phân phối kiểu, mang lại chi phí hằng số cố định nhưng cao; truy cập bộ nhớ không liên tục và di chuyển dữ liệu, cá thể lấy từng cái thường không liên tục trong bộ nhớ, tỷ lệ trúng cache thấp; đồng bộ và điều phối, để lấy cá thể tiếp theo, luồng thực thi dừng rồi khôi phục liên tục. Chỉ tinh chỉnh bên trong toán tử, chỉ cắt được một phần nhỏ trong đó.
>
> Lấy ví dụ quần thể 1000, lặp 100 thế hệ, tổng số lần đánh giá khoảng 1000 × 100 = 10⁵ lần. Nếu đánh giá đơn lẻ trung bình 1 ms, chỉ riêng khâu đánh giá tuần tự đã cần khoảng 100 giây, chưa tính chi phí tính toán toán tử và điều phối; nếu để duy trì đa dạng tăng số lần khởi động lại từ 1 lên 5 lần, chi phí tăng gần như tuyến tính lên khoảng 500 giây. Cùng khối lượng công việc nếu tổ chức theo lô và giao cho phần cứng song song xử lý, thời gian đồng hồ tường chủ yếu do số lô và thời gian mỗi lô quyết định.
>
> Khi đánh giá đơn lẻ cực rẻ (mức micro giây) hoặc quần thể cực nhỏ (dưới mức trăm), chi phí điều phối và bộ nhớ có thể vượt chi phí tính toán, khoảng cách giữa tuần tự và song song thu hẹp rõ rệt, lợi ích biên của tensor hóa giảm dần, nút thắt sẽ chuyển sang độ chi tiết điều phối và băng thông bộ nhớ. Do đó có đáng cải tạo mô hình thực thi hay không, cần đánh giá kết hợp chi phí đánh giá và quy mô.
>
> Nút thắt hiệu suất của vòng lặp CPU tuần tự là mang tính cấu trúc. Để thực sự giải quyết, cần tái cấu trúc từng cá thể thành từng lô, tức xử lý lô, tensor hóa và điều phối song song, đây là động lực trực tiếp cho thiết kế đồ thị tính toán tensor hóa tiếp theo.

**Từ khóa bao phủ**

- Vòng lặp CPU tuần tự, song song lô, thời gian đồng hồ tường, số lần đánh giá ứng viên, số lô, chi phí tầng trình thông dịch, truy cập bộ nhớ không liên tục, đồng bộ và điều phối, nút thắt cấu trúc, tensor hóa.

**Xử lý bài tập**

Trang này có 5 câu trắc nghiệm. Đề nghị mỗi câu trước tiên để sinh viên nói căn cứ phán đoán, sau đó đưa phản hồi.

Câu 1 hỏi giới hạn mô hình thực thi chính của vòng lặp tuần tự. Đáp án là "giữa các lần lặp liên tiếp khó chồng chéo, các đơn vị song song như đa nhân, SIMD, GPU phần lớn thời gian nhàn rỗi". Điểm phản hồi: quy trình lấy cá thể → giải mã → đánh giá → ghi lại từng cá thể khiến mỗi cá thể trở thành một bước tuần tự độc lập, phần cứng thiếu công việc độc lập có thể thực thi đồng thời; nút thắt không phải không tính được độ thích nghi, mà là tại mỗi thời điểm chỉ có một cá thể được xử lý.

Câu 2 hỏi với quần thể 1000, lặp 100 thế hệ, đánh giá đơn lẻ 1 ms, thời gian đồng hồ tường tuần tự chỉ riêng khâu đánh giá. Đáp án khoảng 100 giây. Hướng dẫn tính: tổng số lần đánh giá khoảng 1000 × 100 = 10⁵ lần, nhân với 1 ms.

Câu 3 hỏi mục nào không thuộc yếu tố phóng đại chi phí hằng số của vòng lặp tuần tự. Đáp án là "điều phối xử lý lô tensor hóa". Điểm phản hồi: xử lý lô tensor hóa là hướng cải tạo giảm nút thắt, không phải nguồn phóng đại chi phí của chính vòng lặp tuần tự; chi phí tuần tự đến từ truy cập bộ nhớ không liên tục, kiểm tra biên và phân phối kiểu từng cá thể, vòng lặp tầng trình thông dịch, v.v.

Câu 4 hỏi dưới song song lô, khi hoàn thành cùng tổng khối lượng công việc, thời gian đồng hồ tường chủ yếu do gì quyết định. Đáp án là "số lô và thời gian mỗi lô". Điểm phản hồi: xử lý lô biến từng cá thể thành từng lô, thời gian đồng hồ tường tăng dạng bậc thang theo số lô, không còn tăng gần như tuyến tính theo số cá thể.

Câu 5 hỏi trường hợp nào phán đoán vòng lặp tuần tự là nút thắt cấu trúc khó thành lập nhất. Đáp án là "đánh giá đơn lẻ giảm xuống mức micro giây, và quy mô quần thể chỉ mức trăm". Điểm phản hồi: khi đó chi phí điều phối và bộ nhớ có thể vượt chi phí tính toán, khoảng cách giữa tuần tự và song song thu hẹp; phán đoán nút thắt cần đánh giá kết hợp chi phí đánh giá và quy mô.

**Hoạt động trên lớp**

Có thể dùng tình huống trang này "lựa chọn mô hình thực thi dưới mười vạn lần đánh giá". Trước tiên để sinh viên ước tính, sau đó thảo luận ranh giới cải tạo.

Ước tính thời gian đồng hồ tường chỉ riêng khâu đánh giá của triển khai tuần tự hiện tại, và giải thích thay đổi sau khi tăng số lần khởi động lại từ 1 lên 5 lần, từ đó phán đoán trọng tâm tối ưu. Câu trả lời tham khảo: 1000 × 100 = 10⁵ lần đánh giá, nhân với 1 ms khoảng 100 giây; khởi động lại 5 lần thì khoảng 5 × 10⁵ lần đánh giá, tức khoảng 500 giây, thời gian đồng hồ tường phình to gần như tuyến tính. Điều này cho thấy tinh chỉnh hằng số bên trong toán tử thu được hạn chế, trọng tâm tối ưu nên đặt ở tầng mô hình thực thi, tức xử lý lô, tensor hóa và điều phối song song, để thời gian đồng hồ tường do số lô quyết định chứ không phải số cá thể.

Nếu chuyển sang mô hình thực thi song song lô, còn cần xem xét điều kiện biên nào để phán đoán cải tạo có đáng không. Câu trả lời tham khảo: một là chi phí đánh giá và quy mô, nếu đánh giá đơn lẻ giảm xuống mức micro giây, hoặc quần thể thu nhỏ dưới mức trăm, chi phí điều phối và di chuyển bộ nhớ có thể vượt chi phí tính toán, lợi ích song song giảm dần; hai là ràng buộc về số lô và kích thước lô, kích thước lô bị giới hạn bởi bộ nhớ hiển thị, băng thông bộ nhớ, thời gian tính toán mỗi lô, lô quá lớn sẽ nâng cao thời gian mỗi lô và chi phí đồng bộ; ba là bố cục dữ liệu và truy cập bộ nhớ, nếu cá thể ứng viên không thể tổ chức thành tensor liên tục, có thể vector hóa, xử lý lô vẫn sẽ bị chiết khấu do truy cập bộ nhớ không liên tục. Tổng hợp lại, chỉ khi số lần đánh giá và chi phí đánh giá đơn lẻ đều đủ lớn, lợi ích cải tạo mô hình thực thi mới rõ rệt.

**Kiểm tra hiểu biết**

Ngẫu nhiên gọi một sinh viên dùng lời của mình tóm tắt trọng điểm trang này, ví dụ "tại sao vòng lặp tuần tự là nút thắt cấu trúc" "sau song song thời gian đồng hồ tường do gì quyết định". Nếu sinh viên chỉ nói "chậm", hỏi thêm hai chiều: cấp độ lớn và số lô. Có thể bổ sung khẩu quyết tính nhanh: tổng số lần đánh giá ≈ quy mô quần thể × số thế hệ lặp; thời gian đánh giá tuần tự ≈ tổng số lần đánh giá × thời gian đánh giá đơn lẻ. Nhắc không chỉ nhìn bên trong toán tử, và có thể tự kiểm bằng hình dạng đường cong: gần như đường thẳng cho thấy thực thi vẫn tuần tự, dạng bậc thang cho thấy đã tổ chức theo lô.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên nói được "tuần tự là nút thắt mô hình thực thi, sau song song tổ chức theo lô thì đồng hồ tường do số lô quyết định", mới chuyển sang nội dung thiết kế đồ thị tính toán tensor hóa và điều phối song song tiếp theo.

**Căn cứ tài liệu**

Tiến hóa phụ thuộc vào đa dạng, và đa dạng có nghĩa là khối lượng tính toán khổng lồ. Vòng lặp CPU tuần tự truyền thống kém hiệu quả khi xử lý hàng vạn lần đánh giá ứng viên.

<a id="lecture-page-5"></a>

### Từ danh sách ứng viên đến đồ thị tính toán tensor hóa

*Trang 5*

> **Mục tiêu trang:** Người học cần nắm được chuyển đổi cốt lõi từ biểu diễn danh sách sang đồ thị tính toán tensor hóa cho quá trình tiến hóa.

> **Mục tiêu trang**
>
> Người học cần nắm được chuyển đổi cốt lõi từ biểu diễn danh sách sang đồ thị tính toán tensor hóa cho quá trình tiến hóa, và có thể giải thích tại sao tiến hóa cần tính toán tensor lô, và tensor hóa thay đổi cách biểu diễn quá trình tiến hóa như thế nào.

**Điểm giảng dạy chính**

- Tiến hóa phụ thuộc vào đa dạng, cần đánh giá hàng vạn thậm chí hàng triệu nghiệm ứng viên. Nếu viết ứng viên thành mảng đối tượng thông thường, dùng vòng lặp từng mục để đánh giá, phần lớn thời gian sẽ tiêu tốn vào điều phối từng mục và luồng điều khiển ngôn ngữ chủ, chứ không phải phép toán số thực sự. Nguyên nhân gốc rễ của vòng lặp CPU tuần tự truyền thống kém hiệu quả nằm ở đây. Tập ứng viên, kết quả đánh giá và trạng thái thuật toán được tổ chức thống nhất thành tensor. Toàn bộ thế hệ ứng viên được viết thành tensor ứng viên có hình dạng [quy mô quần thể, chiều nghiệm]
- một ứng viên không còn là đối tượng độc lập, mà là một lát cắt hoặc một hàng trong tensor. Hình minh họa trang cũng triển khai theo thứ tự này: bên trái danh sách ứng viên xử lý từng mục, giữa tensor ứng viên, bên phải đồ thị tính toán lần lượt là đột biến, đánh giá, chọn lọc, cập nhật trạng thái. Các thao tác như đột biến tác động trực tiếp lên toàn bộ quần thể, một lần gọi hoàn thành cập nhật toàn bộ ứng viên
- đánh giá được viết thành evaluate(tensor ứng viên), một lần thu được kết quả cả thế hệ, đơn vị đánh giá chuyển từ "cái" sang "lô". Chọn lọc và cập nhật trạng thái không còn chỉ là logic điều khiển tuần tự, mà là các nút trong đồ thị, do đó có cơ hội tối ưu biên dịch như hợp nhất toán tử, điều phối song song. Logic thuật toán, như phân phối đột biến và áp lực chọn lọc, không bị viết lại
- thứ bị viết lại là cách biểu diễn. Đây không phải đơn giản chuyển vòng lặp sang thiết bị nhanh hơn, mà là lấy tensor làm đơn vị xử lý nhỏ nhất để tổ chức dữ liệu và toán tử. Nếu vẫn khăng khăng "một ứng viên bằng một đối tượng độc lập", phần cứng song song rộng đến đâu cũng chỉ có thể bị nạp dữ liệu tuần tự. Bước nhảy then chốt trang này có thể ghi là "từ danh sách ứng viên đến đồ thị tính toán tensor hóa"
- thấy toán tử lô, nghĩ ngay "cả quần thể tính cùng nhau".

**Từ khóa bao phủ**

- Tính toán tensor hóa, tensor ứng viên, toán tử lô, đánh giá lô, đồ thị tính toán, tối ưu biên dịch, quy mô quần thể, chiều nghiệm.

**Xử lý bài tập**

Đáp án câu trắc nghiệm 1 nên chỉ vào chi phí hằng số của điều phối từng mục và luồng điều khiển ngôn ngữ chủ, chứ không phải thiếu năng lực tính toán hay thiếu đa dạng. Khi phản hồi nhấn mạnh ứng viên càng nhiều, tỷ lệ chi phí này càng cao.

Một nghiệm ứng viên tương ứng với một lát cắt trong tensor ứng viên, ví dụ một hàng; nó không còn ràng buộc như đối tượng ngôn ngữ chủ độc lập.

Chọn lọc và cập nhật trạng thái sau khi vào đồ thị tính toán có thể thu được cơ hội tối ưu biên dịch như hợp nhất toán tử, điều phối song song, giảm tensor trung gian và chi phí đồng bộ.

Đầu ra đánh giá có khả năng nhất là [quy mô quần thể] hoặc [quy mô quần thể, số mục tiêu]; đánh giá dọc chiều quần thể tạo ra một hoặc một nhóm chỉ số cho mỗi ứng viên.

EvoX ở tầng biểu diễn thay xử lý dạng danh sách từng ứng viên bằng đồ thị tính toán lô lấy tensor làm công dân hạng nhất.

Tìm kiếm 50000 cánh ứng viên. Nút thắt triển khai gốc chủ yếu ở tầng tổ chức dữ liệu và điều phối: truy cập đối tượng từng ứng viên, gọi hàm từng mục, so sánh từng lần và cập nhật trạng thái thủ công, và mỗi lần chỉ xử lý một ứng viên, không thể lấp đầy chiều rộng song song phần cứng. Cải tạo tensor hóa không thay đổi áp lực chọn lọc và phân phối đột biến, mà thống nhất ứng viên, kết quả đánh giá và trạng thái thuật toán thành tensor, cho đột biến và đánh giá tác động lên toàn bộ quần thể một lần. Nếu muốn chọn lọc và cập nhật trạng thái cũng thu được tối ưu biên dịch, nên đặt tensor ứng viên thành [50000, 48]; đầu ra đánh giá là [50000] hoặc [50000, số mục tiêu]; đột biến có hiệu lực với toàn bộ tensor ứng viên; chọn lọc dùng chỉ mục tensor hoặc mặt nạ;

cập nhật trạng thái viết thành nút rút gọn dọc chiều quần thể, như lấy giá trị nhỏ nhất hoặc tính trung bình.

**Kiểm tra hiểu biết**

Hình dạng tensor ứng viên là gì? Hình dạng đầu ra một lần đánh giá là gì? Hai khâu nào chuyển từ logic điều khiển tuần tự thành nút đồ thị tính toán? Trả lời được cả ba điểm, cho thấy đã nắm bước nhảy cốt lõi trang này.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên dùng lời của mình giải thích được thay đổi "từ danh sách ứng viên đến đồ thị tính toán tensor hóa", mới chuyển sang ứng dụng, ví dụ hoặc tổng kết của trang tiếp theo.

<a id="lecture-page-6"></a>

### Tổ chức tensor hóa quần thể, đánh giá và trạng thái

*Trang 6*

> **Mục tiêu trang:** Người học cần hiểu cách ánh xạ thống nhất dữ liệu quần thể, đánh giá độ thích nghi và biến trạng thái thành cấu trúc tensor.

> **Mục tiêu trang**
>
> Hiểu cách ánh xạ thống nhất dữ liệu quần thể, đánh giá độ thích nghi và trạng thái vận hành thuật toán thành cấu trúc tensor, hình thành khế ước dữ liệu thống nhất có thể tính toán lô, có thể cư trú trên thiết bị, có thể tái lập.

> **Trình tự giảng giải**
>
> Trước tiên dùng ba câu hỏi để tiếp cận — quần thể là gì, đánh giá thế nào, chạy đến bước nào; sau đó tương ứng ba loại container — tensor quần thể [N, D], ma trận đánh giá và ràng buộc [N, M] và [N, K], container trạng thái thống nhất; cuối cùng giải thích đánh giá lô và cư trú trạng thái biến vòng lặp từng cá thể thành phép toán cả lô như thế nào.

**Điểm giảng dạy chính**

- Tổ chức N nghiệm ứng viên thành tensor mã hóa [N, D]. N là chiều lô, D là chiều đặc trưng, thường đặt N ở ngoài cùng, để cùng một toán tử có thể tác động lên cả lô một lần. Nếu cá thể gồm nhiều đoạn tham số, có thể tách thành các khối trường [N, D1] + [N, D2] + …
- cá thể biến độ dài dùng đệm cộng mặt nạ hoặc chia nhóm, tránh cấu trúc không đồng nhất phá vỡ tính toán cả lô. Một lần đánh giá lô tạo ra ma trận độ thích nghi [N, M]
- đa mục tiêu, đa ràng buộc và chỉ số bổ sung có thể xếp song song thành [N, M+K] hoặc lưu bảng riêng, then chốt là tránh vòng lặp từng cá thể gọi hàm đánh giá. Số thế hệ, trạng thái số ngẫu nhiên, siêu tham số chiến lược, nghiệm tốt nhất, cache lịch sử, xếp hạng hoặc trạng thái lấy mẫu cũng vào tensor hoặc container trạng thái có cấu trúc, đảm bảo tái lập, theo dõi, cập nhật lô. Tensor thống nhất có thể giảm đi lại giữa máy chủ và thiết bị, giảm chi phí vòng lặp, và cung cấp nền tảng dữ liệu cho song song toán tử tiếp theo
- nhưng cần chú ý tính hiệu lực của mặt nạ, lãng phí đệm, số mục tiêu tăng làm ma trận đánh giá rộng ra, và chi phí đồng bộ trạng thái.

> **Gợi ý tư liệu**
>
> - Hình bố cục bộ nhớ đặt tensor quần thể, ma trận đánh giá, ma trận ràng buộc và container trạng thái thống nhất dưới cùng ngữ nghĩa bộ nhớ thiết bị. Có thể nhắc người học chú ý mũi tên "đánh giá lô" biểu thị một lần gọi xử lý cả lô, chứ không phải gọi từng cá thể. Khi N=1024, D=50, M=2, quần thể là [1024, 50], giá trị đánh giá là [1024, 2], ràng buộc là [1024, K]. generation có thể lưu dạng vô hướng, best_x có thể lưu dạng tensor một chiều [D], rng_state có thể biểu diễn bằng tensor số nguyên độ dài phù hợp. Mỗi cập nhật thế hệ đều có thể hoàn thành toàn bộ trên cùng chiều lô.

**Xử lý bài tập**

Hiểu biết cốt lõi là "quần thể, đánh giá và trạng thái ánh xạ thống nhất thành cấu trúc tensor". Nếu chọn đúng, cho thấy hiểu biết này nhất quán với mạch chính trang này; nếu chọn sai, quay lại đầu trang ôn khế ước dữ liệu thống nhất.

Diễn đạt hợp lý nên nhấn mạnh đánh giá lô tạo ra [N, M] và [N, K], chứ không phải vòng lặp từng cá thể. Khi phán đoán chỉ cần liên hệ hình dạng ma trận và căn cứ đánh giá lô.

Diễn đạt hợp lý nên giải thích số thế hệ, trạng thái số ngẫu nhiên, nghiệm tốt nhất cũng được đưa vào container trạng thái thống nhất, thuận tiện cho checkpoint và tái lập. Nếu câu trả lời chỉ dừng ở "đưa dữ liệu vào tensor", nhắc còn cần chú ý quản lý trạng thái và tái lập.

Với kịch bản N=2048, D=100, M=3, K=5, đề xuất quần thể [2048, 100], đánh giá [2048, 3], ràng buộc [2048, 5]; biến trạng thái như generation dùng tensor vô hướng, best_x dùng [100], rng_state dùng tensor số nguyên, cache lịch sử có thể dùng [T, 2048, 100] hoặc lưu nén. Khi đánh giá lô, vector hóa hàm đánh giá, để nó nhận [N, D] và trả về [N, M] và [N, K]; cá thể biến độ dài dùng đệm cộng mặt nạ hoặc chia nhóm, sau tính toán bỏ qua phần không hợp lệ theo mặt nạ.

**Kiểm tra hiểu biết**

Yêu cầu một người học dùng một câu giải thích tại sao N nên là chiều lô ngoài cùng, và nói ít nhất một biến trạng thái tại sao cần tensor hóa. Nếu câu trả lời dừng ở "đưa dữ liệu vào tensor", bổ sung: then chốt là khế ước dữ liệu thống nhất và thực thi toán tử cả lô.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận người học phân biệt được bốn loại container quần thể, đánh giá, ràng buộc và trạng thái, mới chuyển sang ví dụ, ứng dụng hoặc tổng kết của trang tiếp theo.

<a id="lecture-page-7"></a>

### Song song toán tử và tối ưu biên dịch

*Trang 7*

> **Mục tiêu trang:** Người học cần hiểu cơ chế tối ưu biên dịch tầng thấp khi các thao tác như đột biến, lai ghép tác động lên toàn bộ quần thể.

> **Mục tiêu trang**
>
> Hiểu rằng trong nền tảng tính toán hiện đại của EvoX, đơn vị thực thi nhỏ nhất của toán tử tiến hóa chuyển từ "cá thể" sang "tensor quần thể"; nắm được toán tử tensor hóa và biên dịch đồ thị tính toán nâng cao thông lượng tiến hóa lô như thế nào, đồng thời giữ nguyên ngữ nghĩa thuật toán.

> **Trình tự giảng giải**
>
> Trước tiên thiết lập phán đoán "toán tử tác động lên ai", sau đó so sánh khác biệt thực thi giữa vòng lặp từng cá thể và toán tử cấp tensor, tiếp theo giải thích cách biên dịch đồ thị tính toán tối ưu từ chuỗi toán tử sang kế hoạch thực thi, cuối cùng dùng tình huống và bài tập củng cố nguyên tắc "hiệu suất thay đổi, ngữ nghĩa không đổi".

**Điểm giảng dạy chính**

- 1. Tensor quần thể có hình dạng [N, D], N là quy mô quần thể, D là chiều biến quyết định. Các toán tử như đột biến, lai ghép, chọn lọc có thể tác động trực tiếp lên toàn bộ tensor quần thể, một lần gọi bao phủ toàn bộ N cá thể
- chiều cá thể đóng vai trò chiều lô, thiết bị có thể thực thi song song quy mô lớn, thông lượng tăng theo quy mô quần thể. 2. Cách viết từng cá thể như for ind in population: ind = mutate(ind) sẽ chia mỗi toán tử thành N lần gọi nhỏ, mang lại điều phối framework và khởi động kernel thường xuyên
- mỗi lô chỉ là 1, đơn vị song song thiết bị khó lấp đầy, kết quả trung gian tạo và giải phóng liên tục còn tăng chi phí cấp phát bộ nhớ hiển thị và di chuyển dữ liệu. Then chốt cải tạo là population = mutate(population_tensor), để toán tử thực thi với đơn vị là tensor quần thể. 3. Biên dịch đồ thị tính toán tổ chức "đột biến → lai ghép → chọn lọc" thành đồ thị tính toán, tối ưu toàn cục trên cả đồ thị: hợp nhất toán tử có thể gộp nhiều phép toán từng phần tử thành ít kernel hơn, giảm tensor trung gian và đọc ghi
- sinh kernel và điều phối dùng ít lần khởi động kernel hơn để hoàn thành cả thế hệ tiến hóa
- tái sử dụng bộ nhớ lập kế hoạch trước bộ đệm cho kết quả trung gian, giảm chi phí cấp phát và di chuyển. Tối ưu chỉ thay đổi "tính thế nào", không thay đổi "tính cái gì". Số kernel, quy mô tensor trung gian, chiến lược bộ nhớ và điều phối có thể thay đổi, nhưng ý nghĩa logic của đột biến, lai ghép, chọn lọc, thứ tự kết hợp toán tử và cách sử dụng số ngẫu nhiên nên giữ nhất quán
- dưới cùng hạt giống ngẫu nhiên, quỹ đạo từng thế hệ và kết quả trước và sau tối ưu nên nhất quán. Nhầm tensor hóa là đổi thuật toán tiến hóa, hoặc cho rằng tối ưu biên dịch sẽ khiến thuật toán "thông minh hơn". Tensor hóa chỉ là áp cùng một toán tử lên toàn bộ tensor quần thể
- tối ưu biên dịch cũng chỉ nằm ở tầng thực thi. Sau tối ưu nếu không kiểm tra hồi quy, dễ nhầm khác biệt triển khai thành cải tiến thuật toán.

> **Gợi ý tư liệu**
>
> - Trong hình, bên trái là tensor quần thể [N, D] và toàn bộ cá thể, giữa là đồ thị tính toán toán tử tiến hóa "đột biến → lai ghép → chọn lọc", bên phải so sánh trước biên dịch "vòng lặp từng cá thể, nhiều lần khởi động kernel, chiều lô là 1" và sau biên dịch "đồ thị tính toán hợp nhất, ít kernel GPU hiệu quả, một lần lan truyền lô hoàn thành cả thế hệ tiến hóa". Có thể dùng quy trình này giúp sinh viên liên hệ tensor hóa với tối ưu biên dịch.

**Xử lý bài tập**

Bài tập trang này xoay quanh độ chi tiết thực thi và giữ ngữ nghĩa.

Toán tử đột biến một lần gọi thường tác động lên toàn bộ tensor quần thể [N, D]; không phải vector giá trị hàm mục tiêu, cũng không phải vector quyết định của một cá thể đơn lẻ.

Vòng lặp Python/CPU từng cá thể chậm, vì lượng lớn lần gọi quy mô nhỏ mang lại chi phí điều phối và framework, và chiều lô là 1, hiệu suất thiết bị thấp.

Lợi ích chính của hợp nhất toán tử là gộp nhiều phép toán từng phần tử thành ít kernel hơn, giảm tensor trung gian và số lần khởi động kernel; nó không thay đổi phân phối xác suất hay ý nghĩa toán tử.

Chỉ thay đổi cách thực thi, không thay đổi ý nghĩa logic và thứ tự kết hợp của đột biến, lai ghép, chọn lọc.

Cải tạo population[i] = mutate(ind) nên đổi thành population = mutate(population_tensor), và giao chuỗi toán tử cho tối ưu biên dịch đồ thị tính toán; thu nhỏ N, đổi cú pháp vòng lặp hoặc chỉ dùng đa luồng CPU đều không giải quyết vấn đề độ chi tiết thực thi.

Lấy ví dụ chiến lược tiến hóa với quy mô quần thể N = 4096, chiều D = 128, triển khai ban đầu có hiệu suất thiết bị dưới 30%, thời gian mỗi thế hệ tăng gần như tuyến tính theo N, chiếm dụng bộ nhớ hiển thị cao. Chẩn đoán nên nằm ở độ chi tiết thực thi: vòng lặp từng cá thể phóng đại chi phí cố định lên N lần, chiều lô thoái hóa thành 1, đơn vị song song không lấp đầy, kết quả trung gian tạo giải phóng liên tục. Cải tạo chia ba bước: bước một tensor hóa toán tử, cho đột biến, lai ghép, chọn lọc tác động trực tiếp lên tensor [N, D]; bước hai bật biên dịch đồ thị tính toán, thực hiện hợp nhất toán tử, sinh kernel, tái sử dụng bộ nhớ và tối ưu điều phối; bước ba cố định hạt giống ngẫu nhiên làm kiểm tra hồi quy, so sánh đường cong độ thích nghi tốt nhất từng thế hệ và thống kê quần thể trước và sau tối ưu.

Nếu đường cong cơ bản trùng nhau, cho thấy chỉ thay đổi cách thực thi; nếu phân kỳ, trước tiên kiểm tra có thay đổi thứ tự toán tử, số lần sử dụng số ngẫu nhiên hay quy tắc chọn lọc không.

**Kiểm tra hiểu biết**

Một toán tử tiến hóa nên tác động lên một cá thể đơn lẻ hay toàn bộ tensor quần thể? Chuỗi tương đương từ hợp nhất toán tử đến hiệu suất thiết bị là gì? Làm thế nào xác minh tối ưu không thay đổi ngữ nghĩa thuật toán? Câu trả lời kỳ vọng: tác động lên tensor quần thể [N, D]; hợp nhất càng nhiều, khởi động kernel càng ít, đọc ghi tensor trung gian càng ít, hiệu suất thiết bị càng cao; dùng cùng hạt giống ngẫu nhiên so sánh đường cong độ thích nghi tốt nhất từng thế hệ và thống kê quần thể trước và sau tối ưu.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên phân biệt được tensor hóa và biên dịch đồ thị tính toán, và có thể dùng cùng hạt giống kiểm tra hồi quy ngữ nghĩa không đổi, mới chuyển sang ví dụ, ứng dụng hoặc tổng kết của trang tiếp theo.

<a id="lecture-page-8"></a>

### Thiết kế kiến trúc nền tảng mở và tách rời

*Trang 8*

> **Mục tiêu trang:** Người học cần hiểu nguyên tắc thiết kế tách rời và phân chia thành phần cốt lõi của kiến trúc nền tảng EvoX.

> **Mục tiêu trang**
>
> Hiểu nguyên tắc thiết kế của nền tảng mở tách rời EvoX và phân chia trách nhiệm của năm mô-đun cốt lõi, có thể dùng "ranh giới mô-đun" để phán đoán điểm rơi của yêu cầu.

> **Trình tự giảng giải**
>
> Trước tiên đưa ra phán đoán cốt lõi — nhà nghiên cứu không nên dành thời gian vào song song giao tiếp, phân bổ thiết bị và chịu lỗi phân tán; sau đó dẫn ra năm mô-đun cấp một, cuối cùng dùng sơ đồ kiến trúc giải thích quan hệ phân tầng giữa logic tiến hóa tầng trên và điều phối thống nhất tầng dưới.

**Điểm giảng dạy chính**

- Mô-đun thuật toán định nghĩa "tiến hóa như thế nào"
- mô-đun bài toán cung cấp giao diện đánh giá thống nhất
- workflow tổ chức tiến hóa theo giai đoạn
- mô-đun giám sát quan sát quá trình tiến hóa
- Runtime scheduler là tầng thực thi thống nhất, trả lời "tính ở đâu, làm sao tính được". Có thể ghi khẩu quyết: "logic tiến hóa ở trên, điều phối năng lực tính toán ở dưới", thứ tự là thuật toán → mô-đun bài toán → workflow → mô-đun giám sát → Runtime scheduler. Mô-đun thuật toán chỉ mô tả logic tìm kiếm như chọn lọc, lai ghép, đột biến, cập nhật, không ràng buộc bài toán cụ thể, cũng không nhận biết tensor nằm trên card nào
- mô-đun bài toán đóng gói mô phỏng, hàm mục tiêu hoặc môi trường thành giao diện đánh giá thống nhất
- workflow quyết định thứ tự giai đoạn khởi tạo, lặp tiến hóa, phán đoán hội tụ
- mô-đun giám sát thu thập chỉ số, ghi trạng thái quần thể và đường cong hội tụ
- Runtime scheduler che giấu khác biệt giữa GPU, thiết bị tăng tốc, cụm phân tán, đảm nhận chi tiết tính toán lô, song song và giao tiếp. Thuật toán và bài toán độc lập lẫn nhau, bài toán và năng lực tính toán độc lập lẫn nhau. Khi thêm toán tử đột biến mới, chỉ cần sửa mô-đun thuật toán
- mô-đun bài toán tiếp tục cung cấp giao diện đánh giá thống nhất, workflow và mô-đun giám sát giữ cách tổ chức ban đầu, Runtime scheduler tự động hoàn thành tính toán tensor lô và phân bổ thiết bị, mã thực thi tầng dưới không cần sửa. Do đó cùng một nền tảng có thể承载 các kịch bản như học tăng cường, lập trình di truyền và tối ưu tổ hợp, tránh xây dựng lại cơ sở hạ tầng kỹ thuật song song, điều phối và phân tán. Tách rời không có nghĩa hiệu suất chắc chắn chậm. Thứ thực sự ảnh hưởng hiệu suất là cách Runtime scheduler xử lý tính toán lô và sử dụng thiết bị, chứ không phải số lượng mô-đun. Phán đoán phân tầng có hiệu quả không, nên so sánh thời gian đầu cuối, hiệu suất sử dụng thiết bị và tỷ lệ giao tiếp
- nếu chi phí điều phối tăng, nên tối ưu chiến lược tính toán lô và sử dụng thiết bị của Runtime scheduler, chứ không phải viết mã song song trở lại mô-đun thuật toán. Dùng "có cần sửa không" để kiểm tra tách rời. Đổi phần cứng hoặc quy mô cụm chỉ nên sửa Runtime scheduler
- đổi bài toán chỉ nên sửa mô-đun bài toán
- đổi toán tử chỉ nên sửa mô-đun thuật toán. Nếu thay đổi nhỏ ảnh hưởng đến ba tầng trở lên, cho thấy triển khai đã bị ghép nối quá mức. Tách rời tiết kiệm kỹ thuật trùng lặp, không phải thời gian tính toán, vẫn cần thí nghiệm chuẩn để xác minh chi phí điều phối có chấp nhận được không.

**Xử lý bài tập**

Năm mô-đun cốt lõi loại trừ ("bộ tìm kiếm siêu tham số", nó thuộc cấu hình thí nghiệm hoặc chiến lược thuật toán, không phải mô-đun cấp một của nền tảng); thể hiện chính xác của gắn kết cao tách rời thấp (đáp án là logic bên trong mô-đun thuật toán tự nhất quán và không ràng buộc bài toán cụ thể, mô-đun bài toán cũng không nhận biết năng lực tính toán tầng dưới); trách nhiệm cốt lõi của Runtime scheduler (đáp án là che giấu khác biệt GPU, thiết bị tăng tốc và cụm phân tán và điều phối thực thi thống nhất); phạm vi thay đổi khi thêm toán tử đột biến mới (đáp án là chỉ cần triển khai logic mới trong mô-đun thuật toán, bài toán, workflow, giám sát và Runtime scheduler giữ nguyên); ý nghĩa trực tiếp nhất của truy cập mở thống nhất (đáp án là các lĩnh vực tái sử dụng cùng một bộ cơ sở hạ tầng kỹ thuật).

Khi phản hồi trước tiên để sinh viên quay lại "ranh giới trách nhiệm năm mô-đun" tìm bằng chứng, sau đó giải thích tại sao các lựa chọn khác sẽ phá vỡ ranh giới hoặc nhầm lẫn trách nhiệm.

Trong mở rộng cụm GPU đa nút, mô-đun thuật toán, mô-đun bài toán, workflow, mô-đun giám sát nên giữ nguyên, vì trách nhiệm của chúng không liên quan đến hình thái năng lực tính toán; thứ cần sửa hoặc cấu hình lại là Runtime scheduler. Nếu tranh luận "phân bổ thiết bị và giao tiếp viết tay trong toán tử" hay "hoàn toàn phụ thuộc Runtime scheduler", then chốt đánh giá là thay đổi rơi ở tầng nào: phân bổ thiết bị và giao tiếp thuộc tầng thực thi, viết vào toán tử sẽ ghép nối chi tiết năng lực tính toán vào mô-đun thuật toán. Phương án xác minh là trên cùng bài toán tối ưu tổ hợp so sánh thời gian đầu cuối, hiệu suất sử dụng thiết bị, tỷ lệ chi phí giao tiếp giữa điều phối Runtime thuần và điều phối viết tay, và ghi lại chi phí khi chuyển sang loại phần cứng khác hoặc nhiệm vụ học tăng cường;

chỉ khi lợi ích rõ rệt có thể tái lập bù được chi phí ghép nối và di chuyển, mới xem xét hạ tầng cục bộ.

**Kiểm tra hiểu biết**

Yêu cầu sinh viên dùng lời của mình thuật lại năm mô-đun và câu hỏi mỗi mô-đun trả lời, và chọn một yêu cầu bất kỳ phán đoán nên sửa tầng nào. Gợi ý chuyển tiếp: sau khi xác nhận sinh viên phân biệt được "logic tiến hóa" và "điều phối năng lực tính toán", mới chuyển sang chi tiết triển khai tiến hóa song song tensor hóa tiếp theo.

<a id="lecture-page-9"></a>

### Phân chia mô-đun thuật toán và bài toán

*Trang 9*

> **Mục tiêu trang:** Người học cần hiểu trách nhiệm và cách tương tác của mô-đun thuật toán và mô-đun bài toán trong kiến trúc nền tảng.

> **Mục tiêu trang**
>
> Hiểu ranh giới trách nhiệm, khế ước giao diện giữa mô-đun thuật toán và mô-đun bài toán trong nền tảng mở tách rời EvoX, và ý nghĩa của phân chia này đối với bài toán đa mục tiêu, có ràng buộc và phản hồi đắt đỏ.

> **Trình tự giảng giải**
>
> Trước tiên dùng một câu neo phân công — mô-đun thuật toán trả lời "tìm kiếm như thế nào", mô-đun bài toán trả lời "đánh giá cái gì, môi trường phản hồi ra sao". Sau đó triển khai đầu vào đầu ra của hai bên, cuối cùng rơi vào mở rộng độc lập, khả năng kết hợp và khả năng di chuyển do khế ước giao diện ổn định mang lại.

**Điểm giảng dạy chính**

- 1. Mô-đun thuật toán đóng gói chiến lược tìm kiếm và cơ chế tiến hóa. Nó chịu trách nhiệm sinh nghiệm ứng viên, khởi tạo quần thể, đột biến, lai ghép, chọn lọc, giữ精英, và điều khiển tìm kiếm như số vòng lặp, quy mô quần thể, khởi động lại và tiêu chí hội tụ, điều phối tham số toán tử. Điểm then chốt là nó chỉ phụ thuộc vào tiền đề trừu tượng "nghiệm ứng viên sẽ được đánh giá", không quan tâm ý nghĩa vật lý và hình thức cụ thể của hàm mục tiêu. 2. Mô-đun bài toán định nghĩa tiêu chuẩn đánh giá và phản hồi môi trường. Nó chuyển nghiệm ứng viên thành phản hồi có thể so sánh, như giá trị mục tiêu, độ thích nghi, mức vi phạm ràng buộc hoặc kết quả một lần tương tác môi trường
- đồng thời khai báo chiều biến, phạm vi giá trị và quy tắc miền khả thi, để thuật toán biết sinh nghiệm ứng viên ở đâu. Mô-đun bài toán đưa ra đánh giá nhất quán cho cùng một lô nghiệm ứng viên, cho phép so sánh ngang giữa các cá thể khác nhau, các thế hệ khác nhau thậm chí các thuật toán khác nhau. Mô-đun thuật toán nộp một lô nghiệm ứng viên, mô-đun bài toán trả về kết quả đánh giá có cấu trúc (vector mục tiêu, mức vi phạm ràng buộc và thông tin chẩn đoán tùy chọn), mô-đun thuật toán dựa vào đó cập nhật quần thể và đẩy thế hệ tiếp theo. Một lần "nộp — trả về" khứ hồi chính là một thế hệ tiến hóa. Hướng đúng rất quan trọng: phía thuật toán nộp nghiệm ứng viên chờ đánh giá, phía bài toán trả về kết quả đánh giá. Mở rộng độc lập — thêm hoặc thay thuật toán không ảnh hưởng định nghĩa bài toán, sửa hoặc thêm bài toán cũng không cần viết lại mô-đun thuật toán
- khả năng kết hợp — cùng một mô-đun bài toán có thể kết nối các thuật toán tiến hóa khác nhau, cùng một mô-đun thuật toán có thể chuyển sang các mô-đun bài toán khác nhau
- khả năng di chuyển — miễn khế ước ổn định, hai bên có thể tái sử dụng, thay thế và di chuyển xuyên nhiệm vụ. Bài toán kỹ thuật thực tế như thiết kế cánh siêu tới hạn thường đồng thời có nhiều mục tiêu ràng buộc lẫn nhau, ràng buộc lồng nhau và phản hồi đắt đỏ mà thưa thớt. Mô-đun bài toán quy đổi thống nhất đa mục tiêu và ràng buộc thành kết quả đánh giá có thể so sánh, khi cần dùng mô hình thay thế giảm chi phí
- mô-đun thuật toán duy trì một nhóm phương án ứng viên đa dạng, hỗ trợ chuyên gia đánh đổi sở thích giữa lực nâng, lực cản và biên an toàn. Do đó khế ước không chỉ cần承载 độ thích nghi vô hướng đơn lẻ, mà còn cần承载 vector mục tiêu và mức vi phạm ràng buộc, nếu không thông tin đa mục tiêu và ràng buộc sẽ mất vĩnh viễn tại giao diện.

**Từ khóa bao phủ**

- Mô-đun thuật toán, mô-đun bài toán, lô nghiệm ứng viên, kết quả đánh giá, vector mục tiêu, mức vi phạm ràng buộc, khế ước giao diện, mở rộng độc lập, khả năng kết hợp, khả năng di chuyển, mô hình thay thế. Viết hàm mục tiêu, xử lý ràng buộc hoặc quy tắc heuristic đặc thù bài toán vào mô-đun thuật toán, hoặc triển khai chọn lọc và cập nhật quần thể trong mô-đun bài toán, đều khiến hai bên ghép nối lại. Câu tự kiểm là: "Nếu chỉ đổi mô hình vật lý, tôi có chỉ cần thay mô-đun bài toán không?" Câu trả lời phải là khẳng định. Giao diện phải "hẹp mà đầy đủ": hẹp nghĩa là trường ít mà ổn định, chỉ truyền hai loại thông tin là lô nghiệm ứng viên và kết quả đánh giá
- đầy đủ nghĩa là thông tin then chốt không được khiếm khuyết, vector mục tiêu, mức vi phạm ràng buộc, chiều biến và biên đều phải giữ lại. Chỉ trả về độ thích nghi vô hướng đơn lẻ là khiếm khuyết thiết kế khó cứu vãn nhất sau này.

> **Gợi ý bài tập**
>
> - Năm câu trắc nghiệm lần lượt đối chiếu — ai chịu trách nhiệm tìm kiếm, trách nhiệm cốt lõi của mô-đun bài toán, hướng luồng dữ liệu khế ước, mở rộng độc lập sau tách rời, hậu quả của độ thích nghi vô hướng đơn lẻ. Đáp án đúng lần lượt chỉ vào: mô-đun thuật toán sinh nghiệm ứng viên và cập nhật quần thể
> - mô-đun bài toán chuyển nghiệm ứng viên thành giá trị mục tiêu, mức vi phạm ràng buộc hoặc kết quả tương tác môi trường
> - mô-đun thuật toán tạo ra lô nghiệm ứng viên, mô-đun bài toán trả về kết quả đánh giá
> - miễn khế ước không đổi, khi thay thế một bên thì bên kia không cần viết lại
> - bỏ thông tin ràng buộc sẽ khiến thuật toán không nhận được phản hồi ràng buộc, bài toán có ràng buộc khó được xử lý đúng. Khi phản hồi nếu sinh viên trả lời đúng, yêu cầu giải thích căn cứ
> - nếu trả lời sai, hướng dẫn quay lại hai điểm "ai đang tìm kiếm, ai đang đánh giá" và "khế ước có đầy đủ không" để phán đoán lại. Khi chuyển tối ưu khí động cánh sang giảm trọng lượng kết cấu cánh, thay thuật toán tiến hóa không cần viết lại mô-đun bài toán, vì mô-đun bài toán chỉ cam kết với bên ngoài "đầu vào lô nghiệm ứng viên, đầu ra kết quả đánh giá", không liên quan đến cơ chế chọn lọc, cập nhật hay sắp xếp bên trong thuật toán. Khi tái sử dụng cùng thuật toán cho tối thiểu hóa trọng lượng kết cấu, mô-đun bài toán ít nhất trả về ba loại thông tin: giá trị mục tiêu (trọng lượng kết cấu, nếu có chỉ số độ cứng thì là vector mục tiêu), mức vi phạm ràng buộc (mức vượt biên của ràng buộc độ cứng và khả thi hình học), chiều biến và phạm vi giá trị của không gian tìm kiếm. Thiếu một không được, vì thuật toán chỉ chịu trách nhiệm tìm kiếm, cần giá trị mục tiêu để phán đoán tốt xấu, cần mức vi phạm ràng buộc để phân biệt khả thi và không khả thi, cần biên nhất quán để sinh nghiệm ứng viên hợp lệ.

**Hoạt động trên lớp**

Để sinh viên dùng neo ghi nhớ thuật lại — mô-đun thuật toán = tìm kiếm như thế nào (sinh, đột biến, lai ghép, chọn lọc, điều khiển lặp); mô-đun bài toán = đánh giá cái gì (giá trị mục tiêu, mức vi phạm ràng buộc, phản hồi môi trường). Sau đó yêu cầu một sinh viên trả lời: "Nếu chỉ đổi mô hình vật lý, bên nào nên được thay thế?"

**Kiểm tra hiểu biết**

Ngẫu nhiên gọi một sinh viên dùng lời của mình nói ra luồng dữ liệu "lô nghiệm ứng viên ⇄ kết quả đánh giá", và giải thích tại sao chỉ trả về độ thích nghi vô hướng đơn lẻ sẽ phá vỡ xử lý bài toán có ràng buộc.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên phân biệt được tìm kiếm và đánh giá, và nói rõ được khế ước phải "hẹp mà đầy đủ", mới chuyển sang ví dụ, ứng dụng hoặc tổng kết của trang tiếp theo.

<a id="lecture-page-10"></a>

### Quản lý mô-đun workflow và giám sát

*Trang 10*

> **Mục tiêu trang:** Người học cần hiểu vai trò của kiểm soát workflow và mô-đun giám sát trong quản lý quá trình tiến hóa.

> **Mục tiêu trang**
>
> Sau khi học trang này, người học cần phân biệt được trách nhiệm của mô-đun workflow và mô-đun giám sát, và giải thích cách hai bên biến vòng lặp tiến hóa từ "hộp đen chưa biết" thành quá trình được kiểm soát có thể quan sát, có thể phán đoán, có thể can thiệp, có thể tái lập.

> **Trình tự giảng giải**
>
> Trước tiên dùng một câu thiết lập phân công — workflow trả lời "chạy theo thứ tự nào", giám sát trả lời "hiện chạy đến đâu, tốt không, có cần động không". Sau đó triển khai thứ tự, cạnh hồi quy và ranh giới giai đoạn của workflow, rồi giải thích cách giám sát thu thập trạng thái, phơi bày chỉ số và thúc đẩy quyết định. Cuối cùng thu gọn vào ba ranh giới trách nhiệm và chi phí khả quan sát, và dùng ví dụ tiến hóa tensor hóa GPU xâu chuỗi toàn bộ logic.

**Điểm giảng dạy chính**

- 1. Mô-đun workflow biên đạo các bước và phụ thuộc, chứ không phải logic thuật toán. Nó định nghĩa thứ tự "khởi tạo → đánh giá (lô) → chọn lọc → đột biến/lai ghép → cập nhật trạng thái → phán đoán kết thúc", cạnh hồi quy và ranh giới giai đoạn, và thông qua giao diện thống nhất nối mô-đun thuật toán với mô-đun bài toán. Then chốt của biên đạo nằm ở độ chi tiết và ranh giới: coi "một lần đánh giá lô" như một giai đoạn có thể điều phối toàn bộ, chứ không phải đẩy từng cá thể
- ranh giới giai đoạn đồng thời là điểm lấy mẫu giám sát và điểm chuyển đổi điều phối. 2. Mô-đun giám sát là tầng thu thập và phơi bày trạng thái vận hành, liên tục theo dõi các chỉ số như quy mô quần thể, số lần đánh giá, phân phối độ thích nghi, tính hội tụ và đa dạng, thời gian mỗi thế hệ, bộ nhớ hiển thị và thông lượng. Nhưng mục đích quan sát không phải ghi chép, mà là quyết định: chỉ số dùng để kích hoạt kết thúc, dừng sớm, khởi động lại, chuyển đổi tham số hoặc chiến lược, từ đó hình thành vòng kín "giám sát → phán đoán → can thiệp". 3. Khả năng kiểm soát còn yêu cầu trạng thái có thể tuần tự hóa. Lưu và khôi phục checkpoint cho phép tiến hóa dài hạn có thể ngắt và tiếp tục, thất bại có thể định vị, thí nghiệm có thể tái lập. Đồng thời, tách rời yêu cầu giám sát được gắn bằng callback hoặc hook, không xâm nhập mô-đun thuật toán và bài toán, do đó các backend giám sát khác nhau như console, log, bảng đường cong có thể hoán đổi, mà thuật toán cốt lõi không cần sửa. Workflow quản "thứ tự và giai đoạn", giám sát quản "trạng thái và chỉ số", runtime scheduler quản "tài nguyên và ánh xạ song song". Lỗi phổ biến là nhét ánh xạ tài nguyên hoặc logic thuật toán vào workflow, hoặc nhét điều khiển thứ tự vào giám sát, dẫn đến ghép nối và không thể tái lập. Khả quan sát cũng có chi phí: lấy mẫu tần suất cao và truyền đồng bộ trở về có thể làm gián đoạn pipeline song song, do đó tần suất lấy mẫu, cách tổng hợp chỉ số và chiến lược ghi đĩa bất đồng bộ cần cân nhắc theo mục đích thí nghiệm. Workflow coi "đánh giá lô" như một giai đoạn điều phối toàn bộ
- mô-đun giám sát trong cùng giai đoạn ghi độ thích nghi tốt nhất và trung bình theo thế hệ, đa dạng quần thể và thời gian mỗi thế hệ
- khi chỉ số ngừng cải thiện N thế hệ liên tiếp, kích hoạt phán đoán kết thúc hoặc chuyển sang chiến lược đột biến lớn hơn, và đồng bộ ghi checkpoint, để lần tiến hóa này vừa tái lập được, vừa tiếp tục được từ chỗ ngắt.

**Từ khóa bao phủ**

- Mô-đun workflow, mô-đun giám sát, bước và phụ thuộc, ranh giới giai đoạn, cạnh hồi quy, đánh giá lô, khả quan sát, giám sát→phán đoán→can thiệp, checkpoint, callback/hook, ranh giới trách nhiệm, chi phí lấy mẫu.

> **Gợi ý bài tập**
>
> - Bài tập trang này xoay quanh năm phán đoán. Đối tượng biên đạo trực tiếp của workflow là bước và phụ thuộc, chứ không phải công thức toán tử, ánh xạ bộ nhớ hiển thị hay mã hóa hàm mục tiêu
> - coi đánh giá lô toàn bộ như giai đoạn điều phối, vì độ chi tiết và ranh giới phù hợp hơn, ranh giới giai đoạn đồng thời đảm nhận lấy mẫu giám sát và chuyển đổi điều phối
> - mục đích căn bản của giám sát là quyết định, chứ không phải lưu trữ sau sự kiện
> - gắn callback hoặc hook là để tách rời, khiến backend giám sát có thể hoán đổi
> - khả quan sát cần cân nhắc tần suất lấy mẫu, tổng hợp chỉ số và chiến lược ghi đĩa, vì lấy mẫu tần suất cao có thể can nhiễu pipeline song song. Khi trả lời đúng, nhấn mạnh căn cứ đến từ hai mạch "thứ tự và giai đoạn" và "giám sát→phán đoán→can thiệp"
> - khi trả lời sai, quay lại ranh giới trách nhiệm, phân biệt bốn loại trách nhiệm: logic thuật toán, ánh xạ tài nguyên, điều khiển thứ tự và thu thập trạng thái.

**Kiểm tra hiểu biết**

Có thể dùng tình huống "dừng đáng ngờ trong tiến hóa tensor hóa dài hạn" để kiểm tra mức nắm. Trước tiên dùng ranh giới giai đoạn tách riêng thời gian của đánh giá lô, chọn lọc, đột biến, cập nhật trạng thái, phán đoán thời gian mỗi thế hệ tăng cao đến từ giai đoạn nào; sau đó chồng hai đường cong độ thích nghi trung bình ngừng cải thiện và đa dạng giảm, phán đoán là hội tụ dần ổn định, hay rơi vào tối ưu cục bộ. Phương án xử lý tổ chức theo "giám sát → phán đoán → can thiệp": tầng giám sát thu thập số thế hệ độ thích nghi ngừng cải thiện, đa dạng và thời gian mỗi thế hệ; tầng phán đoán đặt "N thế hệ liên tiếp cải thiện dưới ngưỡng và đa dạng rơi dưới biên dưới" là ngừng trệ, "thời gian mỗi thế hệ vượt ngưỡng" là bất thường tài nguyên; tầng can thiệp kích hoạt chuyển đổi chiến lược, dừng sớm hoặc khởi động lại, và điều chỉnh kích thước lô hoặc ánh xạ song song cho bất thường thời gian.

Trước khi xử lý ghi checkpoint, đảm bảo thí nghiệm tái lập, thất bại định vị được, tiến hóa dài hạn ngắt và tiếp tục được.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận người học nói được "workflow quản thứ tự và giai đoạn, giám sát quản trạng thái và chỉ số, scheduler quản tài nguyên và ánh xạ song song", mới chuyển sang trang tiếp theo.

<a id="lecture-page-11"></a>

### Runtime scheduler và quản lý năng lực tính toán không đồng nhất

*Trang 11*

> **Mục tiêu trang:** Người học cần nắm vai trò cốt lõi của Runtime scheduler trong phân bổ phần cứng không đồng nhất và khả năng kết hợp thuật toán.

> **Mục tiêu trang**
>
> Nắm vị trí của Runtime scheduler trong EvoX — nó là trung tâm thực thi kết nối logic thuật toán với phần cứng vật lý, chịu trách nhiệm ánh xạ thuật toán tiến hóa tầng trên, định nghĩa bài toán và workflow đến các tài nguyên năng lực tính toán không đồng nhất như GPU, thiết bị tăng tốc (TPU/NPU) và cụm phân tán, đồng thời duy trì khả năng kết hợp hiệu quả của mô-đun thuật toán trong khi che giấu khác biệt phần cứng.

> **Trình tự giảng giải**
>
> 1. Trước tiên phân biệt tầng thuật toán và tầng thực thi. Tầng thuật toán quan tâm "làm gì", Runtime quan tâm "làm ở đâu, làm thế nào". Sự tách biệt này là then chốt để hiểu kiến trúc EvoX.
>
> Điều phối năng lực tính toán không đồng nhất, quản lý thống nhất GPU, thiết bị tăng tốc và cụm phân tán, phân bổ nhiệm vụ, toán tử và đồ thị tính toán tensor đến backend phù hợp; phối hợp phụ thuộc và trạng thái, đảm bảo quan hệ phụ thuộc nhiệm vụ và trạng thái thực thi đồng bộ đúng; giao diện điều phối thống nhất, để tầng thuật toán khi nộp nhiệm vụ không cần ràng buộc thiết bị cụ thể hoặc hình thái cụm; khả năng kết hợp mô-đun, hỗ trợ thuật toán, bài toán, toán tử và backend thực thi kết hợp, thay thế và tái sử dụng theo mô-đun.
>
> Khi cùng một bộ thuật toán tiến hóa chuyển từ GPU đơn máy sang cụm đa máy, mã tầng thuật toán giữ nguyên, Runtime ánh xạ lại nhiệm vụ tính toán và backend thực thi. Nhà nghiên cứu do đó có thể tập trung vào đổi mới thuật toán, mà không phải viết lại mã cho từng loại phần cứng.
>
> Tầng trên là tầng thuật toán và workflow (mô-đun thuật toán, định nghĩa bài toán, workflow), giữa là Runtime scheduler và giao diện điều phối thống nhất, tầng dưới là tầng năng lực tính toán không đồng nhất (GPU, TPU/NPU, cụm phân tán); truyền nhiệm vụ, toán tử và đồ thị tính toán xuống, truyền trạng thái và kết quả lên.

**Điểm giảng dạy chính**

- Runtime không triển khai logic thuật toán tiến hóa, cũng không định nghĩa hàm mục tiêu bài toán
- trách nhiệm của nó là điều phối và ánh xạ. Tài nguyên thực thi nó quản lý là tài nguyên phần cứng, như GPU, thiết bị tăng tốc và cụm phân tán
- mã nguồn mô-đun thuật toán thuộc tầng thuật toán, không phải đối tượng Runtime điều phối. Tầng thuật toán chỉ cần mô tả làm gì, không cần quan tâm làm trên phần cứng nào, do đó cùng một bộ thuật toán có thể di chuyển sang môi trường đơn máy, đa card hoặc xuyên cụm. Khả năng kết hợp nghĩa là thuật toán, bài toán, toán tử và backend thực thi có thể kết hợp, thay thế và tái sử dụng tự do, chứ không bị khóa vào backend phần cứng đơn lẻ.

**Từ khóa bao phủ**

- Runtime scheduler, điều phối năng lực tính toán không đồng nhất, phối hợp phụ thuộc và trạng thái, giao diện điều phối thống nhất, khả năng kết hợp mô-đun, GPU, thiết bị tăng tốc, TPU/NPU, cụm phân tán, tầng thuật toán, tầng thực thi.

> **Gợi ý tư liệu**
>
> - Trang này có sơ đồ kiến trúc Runtime scheduler kết nối thiết bị phần cứng với thuật toán tầng trên. Trong hình, tầng trên là tầng thuật toán và workflow, giữa là Runtime scheduler và giao diện điều phối thống nhất, tầng dưới là tầng năng lực tính toán không đồng nhất
> - mũi tên biểu thị nhiệm vụ/toán tử/đồ thị tính toán phân phối xuống, trạng thái/kết quả truyền lên. Khi giảng hình có thể để sinh viên thuật lại theo mũi tên "tầng trên nộp gì, Runtime làm gì, tầng dưới trả về gì".

**Xử lý bài tập**

Đáp án đúng câu trắc nghiệm 1 là ánh xạ thuật toán và workflow đến tài nguyên năng lực tính toán không đồng nhất, và che giấu khác biệt phần cứng. Điểm phản hồi: Runtime là trung tâm thực thi, không triển khai logic thuật toán, cũng không định nghĩa bài toán.

Runtime quản lý tài nguyên thực thi phần cứng, mã nguồn thuộc nội dung tầng thuật toán.

Đáp án đúng câu trắc nghiệm 3 là thông qua giao diện điều phối thống nhất, tầng thuật toán không cần ràng buộc thiết bị cụ thể hoặc hình thái cụm. Điểm phản hồi: giảm ghép nối nghĩa là tầng thuật toán không cần viết mã khác nhau cho từng loại phần cứng.

Đáp án đúng câu trắc nghiệm 4 là thuật toán, bài toán, toán tử và backend thực thi kết hợp, thay thế và tái sử dụng theo mô-đun. Điểm phản hồi: khả năng kết hợp thể hiện ở việc thành phần có thể kết hợp và thay thế tự do.

Đáp án đúng câu trắc nghiệm 5 là ánh xạ lại nhiệm vụ tính toán và backend thực thi, mã tầng thuật toán giữ nguyên. Điểm phản hồi: Runtime điều chỉnh ánh xạ nhiệm vụ động, tầng thuật toán không cần sửa.

Trong kịch bản thiết kế cánh đa mục tiêu, nhóm đồng thời tối ưu hệ số lực nâng và tỷ lệ lực nâng lực cản hành trình, và di chuyển cùng một bộ mã thuật toán giữa GPU đơn máy và cụm phân tán. Khi trả lời nắm hai điểm: thứ nhất, Runtime thông qua giao diện điều phối thống nhất ánh xạ nhiệm vụ, toán tử và đồ thị tính toán đến backend phần cứng cụ thể; khi phần cứng thay đổi mã tầng thuật toán không đổi, Runtime ánh xạ lại và tách đồ thị tính toán, và phối hợp phụ thuộc nhiệm vụ và đồng bộ trạng thái. Thứ hai, khi điều phối cần xem xét đặc điểm tính toán nhiệm vụ và quan hệ phụ thuộc, khả năng phần cứng (như độ song song GPU, chi phí giao tiếp cụm), thực thi song song đánh giá đa mục tiêu và đồng bộ dưới phản hồi thưa thớt, và truyền trạng thái trở về, đảm bảo triển khai hiệu quả xuyên phần cứng mà không phá vỡ khả năng kết hợp.

**Kiểm tra hiểu biết**

Yêu cầu sinh viên dùng lời của mình giải thích "tầng thuật toán quan tâm làm gì, Runtime quan tâm làm ở đâu, làm thế nào", và lấy ví dụ giải thích khi chuyển từ GPU sang cụm thì tầng nào thay đổi, tầng nào giữ nguyên. Nếu sinh viên chỉ nhớ tên phần cứng mà không giải thích quan hệ điều phối và ánh xạ, có thể hướng dẫn họ quay lại quan hệ mũi tên trong sơ đồ kiến trúc.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên nói được vai trò điều phối và ánh xạ của Runtime, và có thể dùng giao diện thống nhất và khả năng kết hợp giải thích di chuyển xuyên phần cứng, mới chuyển sang ví dụ, ứng dụng hoặc tổng kết của trang tiếp theo.

<a id="lecture-page-12"></a>

### Ứng dụng đa lĩnh vực được hỗ trợ bởi nền tảng thống nhất

*Trang 12*

> **Mục tiêu trang:** Người học cần hiểu cách nền tảng thống nhất này hỗ trợ học tăng cường, lập trình di truyền và tối ưu tổ hợp cùng nhiều nhiệm vụ rộng khắp.

> **Trình tự giảng giải**
>
> Trước tiên dùng một câu nêu rõ "nền tảng thống nhất = truy cập mở + thực thi tensor hóa + điều phối Runtime. Khi thấy 'ứng dụng đa lĩnh vực', tự kiểm theo ba câu hỏi: nhiệm vụ truy cập bằng gì? Nghiệm ứng viên đánh giá lô thế nào? Năng lực tính toán và trạng thái do ai quản lý thống nhất?", sau đó kết hợp ví dụ, hình minh họa hoặc từ khóa trên trang giải thích tại sao nó quan trọng.

**Điểm giảng dạy chính**

- Nền tảng thống nhất = truy cập mở + thực thi tensor hóa + điều phối Runtime. Khi thấy "ứng dụng đa lĩnh vực", tự kiểm theo ba câu hỏi: nhiệm vụ truy cập bằng gì? Nghiệm ứng viên đánh giá lô thế nào? Năng lực tính toán và trạng thái do ai quản lý thống nhất?
- Song song bước môi trường, tiến hóa cấu trúc cây chương trình, ánh xạ tensor rời rạc thuộc tầng thích ứng
- quy trình đánh giá, quản lý trạng thái, tổ chức toán tử và điều phối thuộc tầng chia sẻ. Nếu viết trực tiếp cấu trúc đặc thù của một lĩnh vực vào logic điều phối chia sẻ, cho thấy đã chọn sai tầng trừu tượng.
- Trang này chỉ trả lời "nền tảng thống nhất có thể hỗ trợ gì". Gặp các vấn đề như thông lượng, chi phí điều phối, chi tiết triển khai tensor lô, trước tiên để vào phạm vi học tập về hiệu quả tính toán và phương pháp tensor lô tiếp theo, không mắc kẹt ở đây.

Ứng dụng đa lĩnh vực được hỗ trợ bởi nền tảng thống nhất

11

AI999

Nền tảng tính toán hiện đại và tiến hóa song song dạng tensor

Nhiệm vụ điều khiển và quyết định cần tương tác liên tục với môi trường thay đổi, nhiệm vụ thiết kế cấu trúc cần tìm kiếm trong không gian chương trình và biểu thức độ dài biến đổi, nhiệm vụ phân bổ tài nguyên và lập kế hoạch đường đi thì cần giải trong hoán vị và ràng buộc rời rạc. Nếu xây dựng riêng một bộ hệ thống cho mỗi loại bài toán, giao diện đánh giá, lưu trữ trạng thái, thư viện toán tử và điều phối năng lực tính toán đều phải triển khai lại, chi phí di chuyển kỹ thuật cực cao. Ý tưởng cốt lõi của nền tảng thống nhất là dùng cùng một bộ cơ sở hạ tầng tiến hóa để承载 các nhiệm vụ không đồng nhất này, cho ứng dụng đa lĩnh vực chia sẻ đánh giá, trạng thái, toán tử và quản lý năng lực tính toán.

Truy cập mở (dùng quy chuẩn đăng ký và giao diện thống nhất để truy cập nhiệm vụ), thực thi tensor hóa (tổ chức nghiệm ứng viên thành lô, đánh giá song song lô), điều phối runtime (phân bổ nhiệm vụ trên năng lực tính toán không đồng nhất và duy trì trạng thái). Ba thứ cùng đảm bảo tái sử dụng xuyên lĩnh vực, cũng giải thích tại sao khả năng "cung cấp nền tảng truy cập mở thống nhất cho học tăng cường, lập trình di truyền và tối ưu tổ hợp" đáng được thảo luận riêng.

Ứng dụng đa lĩnh vực được hỗ trợ bởi nền tảng thống nhất Cùng một nền tảng truy cập mở · Chia sẻ quy trình đánh giá, quản lý trạng thái, tổ chức toán tử và điều phối năng lực tính toán Khả năng nền tảng / Lĩnh vực nhiệm vụ Học tăng cường Lập trình di truyền Tối ưu tổ hợp Truy cập mở Giao diện truy cập môi trường Truy cập cấu trúc chương trình Truy cập nghiệm và ràng buộc Tương tác môi trường song song Lấy mẫu lô đa môi trường — — Tiến hóa cấu trúc cây chương trình — Đột biến / Lai ghép — Giải tensor hóa Đánh giá lô chiến lược Tensor hóa cấu trúc Lô ứng viên và ràng buộc Điều phối Runtime và quản lý trạng thái Điều phối và trạng thái chia sẻ Điều phối và trạng thái chia sẻ Điều phối và trạng thái chia sẻ Tầng thích ứng: hấp thụ khác biệt lĩnh vực —— Song song bước môi trường · Tiến hóa cấu trúc cây chương trình · Ánh xạ tensor rời rạc Nền tảng thống nhất: Truy cập mở · Thực thi tensor hóa · Điều phối Runtime và quản lý trạng thái Ba loại nhiệm vụ điển hình rơi vào cùng nền tảng như thế nào Học tăng cường: nền tảng cung cấp khả năng tương tác môi trường song song, hỗ trợ lấy mẫu lô nhiều instance môi trường, đánh giá song song một lô chiến lược ứng viên, và hình thành vòng kín với tối ưu tiến hóa.

Nền tảng hỗ trợ tiến hóa cấu trúc biến độ dài, phân tầng như cây chương trình, có thể xử lý biểu diễn cấu trúc và đột biến, lai ghép của nó trong quy trình quần thể và đánh giá thống nhất. Tối ưu tổ hợp: thích ứng quyết định rời rạc, chọn lọc, hoán vị và mục tiêu ràng buộc thành giải tensor hóa, nâng cao thông lượng tìm kiếm thông qua ứng viên lô và đánh giá song song. Chia sẻ gì, thích ứng gì Khác biệt lĩnh vực được tầng thích ứng hấp thụ: học tăng cường chú trọng song song bước môi trường, lập trình di truyền chú trọng tiến hóa cấu trúc cây chương trình, tối ưu tổ hợp chú trọng ánh xạ quyết định rời rạc sang tensor. Ba thứ chia sẻ điều phối Runtime và quản lý trạng thái tầng dưới —— chia sẻ quy trình đánh giá, vật mang trạng thái, cách tổ chức toán tử và quản lý năng lực tính toán, chứ không xây dựng lại hệ thống cho mỗi loại bài toán.

Nếu viết trực tiếp cấu trúc đặc thù của một lĩnh vực vào logic điều phối chia sẻ, cho thấy đã chọn sai tầng trừu tượng. Phạm vi trang này Trang này tập trung "nền tảng thống nhất có thể hỗ trợ gì", không triển khai so sánh hiệu suất cụ thể và chi tiết triển khai scheduler; phần sau để lại cho phần hiệu quả tính toán và phương pháp tensor lô tiếp tục thảo luận.

Giá trị đầu tiên của nền tảng truy cập mở thống nhất là gì?

Cho các lĩnh vực khác nhau tái sử dụng đánh giá, trạng thái, toán tử và quản lý năng lực tính toán, giảm đáng kể chi phí di chuyển kỹ thuật

Dùng một thuật toán thống nhất thay thế học tăng cường, lập trình di truyền và tối ưu tổ hợp

Nén tất cả nhiệm vụ thành cùng một loại biểu diễn vector độ dài cố định

Xây dựng lại hệ thống và chuỗi công cụ độc lập cho mỗi loại bài toán mới

Hình thái nhiệm vụ khác nhau, nhưng quy chuẩn truy cập, đánh giá lô, quản lý trạng thái và điều phối năng lực tính toán có thể dùng chung, bài toán mới chỉ cần mô tả khác biệt ở tầng thích ứng.

"Xây dựng lại hệ thống cho mỗi loại bài toán" chính là vấn đề nền tảng cần giải quyết; đồng thời nền tảng cũng không yêu cầu tất cả nhiệm vụ dùng chung một thuật toán hoặc cùng một biểu diễn, khác biệt được tầng thích ứng hấp thụ.

Đúng. Câu trả lời này liên hệ được với khái niệm trang này, và giải thích căn cứ.

Hãy quay lại phần giảng trang này, tìm bằng chứng hoặc ví dụ then chốt rồi phán đoán.

Trong kịch bản học tăng cường, nền tảng thống nhất chủ yếu cung cấp khả năng then chốt nào?

Toán tử đột biến và lai ghép cây chương trình

Chỉ hỗ trợ bước tuần tự của một instance môi trường đơn lẻ

Lấy mẫu lô nhiều instance môi trường và thu thập quỹ đạo, đánh giá song song một lô chiến lược ứng viên

Giao diện mô hình hóa hoán vị rời rạc và ràng buộc

Nhiều instance môi trường đẩy đồng thời, thu thập quỹ đạo theo lô, đánh giá song song chiến lược ứng viên, từ đó hình thành vòng kín với tối ưu tiến hóa.

Tiến hóa cấu trúc cây chương trình thuộc điểm thích ứng của lập trình di truyền, mô hình hóa ràng buộc rời rạc thuộc điểm thích ứng của tối ưu tổ hợp; then chốt của học tăng cường là song song lô tương tác môi trường, chứ không phải tuần tự đơn instance.

Khi nhiệm vụ lập trình di truyền truy cập nền tảng thống nhất, đặc tính then chốt nền tảng phải hỗ trợ là gì?

Chỉ xử lý vector số thực độ dài cố định

Biểu diễn và tiến hóa cấu trúc biến độ dài, phân tầng như cây chương trình, bao gồm đột biến cấu trúc và lai ghép

Phải mã hóa cưỡng bức cây chương trình thành chuỗi nhị phân độ dài cố định rồi mới tiến hóa

Chỉ xử lý hàm mục tiêu liên tục không ràng buộc

Nghiệm ứng viên của lập trình di truyền là cấu trúc chương trình biến độ dài, phân tầng, nền tảng cần chứa biểu diễn này trong quy trình quần thể và đánh giá thống nhất, và hỗ trợ đột biến và lai ghép tương ứng.

Vector độ dài cố định là biểu diễn điển hình của tối ưu liên tục; đặc trưng cốt lõi của lập trình di truyền chính là cấu trúc cây chương trình biến độ dài, phân tầng, và thao tác tiến hóa nhắm vào cấu trúc.

Khi nhiệm vụ tối ưu tổ hợp truy cập nền tảng thống nhất, công việc thích ứng then chốt nhất là gì?

Hủy bỏ toàn bộ ràng buộc, chỉ giữ một mục tiêu

Viết lại bài toán thành nhiệm vụ huấn luyện mạng nơ-ron liên tục khả vi

Biên dịch riêng một bộ giải chuyên dụng cho mỗi instance bài toán

Thích ứng quyết định rời rạc, chọn lọc, hoán vị và mục tiêu ràng buộc thành giải tensor hóa

Nghiệm ứng viên và ràng buộc được tổ chức thành lô, từ đó tái sử dụng khả năng ứng viên lô và đánh giá song song của nền tảng.

Biên dịch bộ giải chuyên dụng theo từng instance tương đương quay lại con đường cũ "xây dựng lại hệ thống"; từ bỏ ràng buộc cũng thay đổi chính bài toán, cả hai đều không phải thích ứng mà nền tảng yêu cầu.

Về phân công giữa tầng chia sẻ và tầng thích ứng, hiểu biết nào sau đây đúng?

Logic điều phối phải viết riêng một bản cho học tăng cường, lập trình di truyền và tối ưu tổ hợp

Tầng thích ứng chỉ làm hiển thị giao diện, không tham gia chuyển đổi ngữ nghĩa nhiệm vụ nào

Tầng chia sẻ chịu trách nhiệm tiến hóa cấu trúc cây chương trình, tầng thích ứng chịu trách nhiệm bước môi trường

Khác biệt lĩnh vực do tầng thích ứng hấp thụ, ba loại nhiệm vụ chia sẻ điều phối Runtime và quản lý trạng thái tầng dưới

Song song bước môi trường, tiến hóa cấu trúc cây chương trình, ánh xạ tensor rời rạc thuộc tầng thích ứng; quy trình đánh giá, quản lý trạng thái, tổ chức toán tử và điều phối thuộc tầng chia sẻ.

Viết cấu trúc đặc thù lĩnh vực vào logic điều phối chia sẻ, hoặc để tầng chia sẻ xử lý tiến hóa cấu trúc đặc thù của một lĩnh vực, đều là sai phân tầng.

Cùng một runtime承载 ba loại nhiệm vụ không đồng nhất

Đọc tình huống, trả lời câu hỏi.

Một nhóm thuật toán đang xây dựng nền tảng tính toán tiến hóa. Trước đây họ duy trì ba bộ hệ thống độc lập cho điều khiển học tăng cường, hồi quy ký hiệu (tìm kiếm cấu trúc chương trình) và lập kế hoạch đường đi logistics: mỗi bộ có giao diện đánh giá, lưu trữ trạng thái và điều phối năng lực tính toán riêng, mã trùng lặp nghiêm trọng, đổi một nhiệm vụ là phải viết lại quy trình. Phương án mới đổi thành dùng một nền tảng thống nhất承载 ba loại nhiệm vụ: nhiệm vụ học tăng cường đẩy song song nhiều instance môi trường và thu thập quỹ đạo; nhiệm vụ lập trình di truyền đánh giá song song quần thể cây chương trình; nhiệm vụ tối ưu tổ hợp tổ chức nghiệm ứng viên và ràng buộc thành lô tensor, do điều phối thống nhất phân bổ năng lực tính toán không đồng nhất.

1. Tại sao nhóm từ bỏ duy trì hệ thống riêng cho mỗi loại bài toán? Hãy giải thích từ góc độ tái sử dụng và chi phí di chuyển.

Truy cập nhiệm vụ, đánh giá lô nghiệm ứng viên, quản lý trạng thái ứng viên và quần thể, tổ chức toán tử và điều phối năng lực tính toán. Duy trì riêng nghĩa là các khả năng này bị triển khai lặp ba lần, bất kỳ nhiệm vụ mới nào cũng phải xây lại quy trình, chi phí di chuyển kỹ thuật rất cao. Nền tảng thống nhất cho ba loại nhiệm vụ tái sử dụng cùng một bộ quy trình đánh giá, vật mang trạng thái, cách tổ chức toán tử và quản lý năng lực tính toán, nhiệm vụ mới chỉ cần mô tả khác biệt của mình ở tầng thích ứng là có thể truy cập.

2. Hãy chỉ ra khác biệt ba loại nhiệm vụ hấp thụ ở tầng thích ứng, và giải thích chúng tái sử dụng gì ở tầng chia sẻ.

Học tăng cường chú trọng song song bước môi trường (lấy mẫu lô nhiều instance môi trường, thu thập quỹ đạo và đánh giá lô chiến lược); lập trình di truyền chú trọng biểu diễn và tiến hóa cấu trúc biến độ dài, phân tầng như cây chương trình (đột biến cấu trúc và lai ghép); tối ưu tổ hợp chú trọng ánh xạ quyết định rời rạc, chọn lọc, hoán vị và mục tiêu ràng buộc thành giải tensor hóa. Tầng chia sẻ tái sử dụng: quy chuẩn truy cập mở, thực thi lô tensor hóa, điều phối Runtime và quản lý trạng thái, và phân bổ năng lực tính toán không đồng nhất thống nhất. Chính vì khác biệt được thu gọn ở tầng thích ứng, điểm chung chìm ở tầng chia sẻ, mới không cần xây dựng lại hệ thống cho mỗi loại bài toán.

Trước tiên nhớ ba trụ cột

Nền tảng thống nhất = truy cập mở + thực thi tensor hóa + điều phối Runtime. Khi thấy "ứng dụng đa lĩnh vực", tự kiểm theo ba câu hỏi: nhiệm vụ truy cập bằng gì? Nghiệm ứng viên đánh giá lô thế nào? Năng lực tính toán và trạng thái do ai quản lý thống nhất?

Phân biệt tầng chia sẻ và tầng thích ứng

Song song bước môi trường, tiến hóa cấu trúc cây chương trình, ánh xạ tensor rời rạc thuộc tầng thích ứng; quy trình đánh giá, quản lý trạng thái, tổ chức toán tử và điều phối thuộc tầng chia sẻ. Nếu viết trực tiếp cấu trúc đặc thù của một lĩnh vực vào logic điều phối chia sẻ, cho thấy đã chọn sai tầng trừu tượng.

Ranh giới trang này

Trang này chỉ trả lời "nền tảng thống nhất có thể hỗ trợ gì". Gặp các vấn đề như thông lượng, chi phí điều phối, chi tiết triển khai tensor lô, trước tiên để vào phạm vi học tập về hiệu quả tính toán và phương pháp tensor lô tiếp theo, không mắc kẹt ở đây.

step-1

Người học cần hiểu cách nền tảng thống nhất này hỗ trợ học tăng cường, lập trình di truyền và tối ưu tổ hợp cùng nhiều nhiệm vụ rộng khắp.

lesson_4

lesson_4_slide_11

Từ bản nháp EvoClass

Cung cấp nền tảng truy cập mở thống nhất cho học tăng cường, lập trình di truyền và tối ưu tổ hợp

lesson_id_distribution

67ee25ab22558e4ae0e13f24b7c34c2da1218107cceb1cd331b38fc3521a9743

**Căn cứ tài liệu**

Từ bản nháp EvoClass (trang 4-4)

> **Gợi ý tư liệu**
>
> - Cung cấp nền tảng truy cập mở thống nhất cho học tăng cường, lập trình di truyền và tối ưu tổ hợp

**Hoạt động trên lớp**

Yêu cầu dùng một ví dụ gần gũi với kinh nghiệm sinh viên thuật lại nội dung trang này, và để sinh viên nói ra quan hệ giữa ví dụ này với "nền tảng thống nhất = truy cập mở + thực thi tensor hóa + điều phối Runtime. Khi thấy 'ứng dụng đa lĩnh vực', tự kiểm theo ba câu hỏi: nhiệm vụ truy cập bằng gì? Nghiệm ứng viên đánh giá lô thế nào? Năng lực tính toán và trạng thái do ai quản lý thống nhất?".

> **Mục tiêu tương ứng**
>
> - Nắm được phương pháp biểu diễn quá trình tiến hóa thành tính toán tensor lô
> - Hiểu vai trò của Runtime trong điều phối năng lực tính toán không đồng nhất và duy trì khả năng kết hợp thuật toán

**Kiểm tra hiểu biết**

Ngẫu nhiên gọi một sinh viên dùng lời của mình tóm tắt trọng điểm trang này, người giảng bổ sung từ khóa còn thiếu theo câu trả lời.

> **Gợi ý chuyển tiếp**
>
> Sau khi xác nhận sinh viên nói được quan hệ cốt lõi của trang này, mới chuyển sang ví dụ, ứng dụng hoặc tổng kết của trang tiếp theo.

<a id="lecture-page-13"></a>

### Thực hành phân tích so sánh hiệu quả tính toán

*Trang 13*

> **Mục tiêu trang:** Người học cần thông qua thực hành so sánh hiểu khác biệt hiệu suất giữa duyệt tuần tự CPU và xử lý lô tensor GPU.

> **Mục tiêu trang**
>
> Đưa so sánh hiệu quả tính toán vào một thực hành có thể tái lập, hiểu khác biệt hiệu suất đầu cuối giữa duyệt cá thể tuần tự CPU và xử lý lô tensor GPU, làm rõ tăng tốc đến từ đâu, chi phí là gì, ranh giới ở đâu.

> **Trình tự giảng giải**
>
> Trước tiên đưa ra hai đường cơ sở trên cùng nhiệm vụ tiến hóa, sau đó xem biểu đồ cột so sánh hiệu quả, tiếp theo giảng giao thức đo lường có thể tái lập, cuối cùng tổng kết nguồn lợi ích, điều kiện ràng buộc và kết luận thực hành.

**Điểm giảng dạy chính**

- Dùng vòng lặp gọi hàm đánh giá từng cá thể, mỗi thế hệ cần N lần điều phối độc lập, cập nhật trạng thái và tổng hợp kết quả. Điều khiển vòng lặp, chi phí trình thông dịch và truy cập bộ nhớ phân tán sẽ pha loãng năng lực tính toán hiệu dụng
- cá thể càng nhiều, tỷ lệ chi phí phi tính toán này càng cao. Tổ chức quần thể, đầu vào đánh giá và trạng thái vận hành thành tensor, thực thi lô đánh giá và toán tử trên GPU, một lần gọi bao phủ toàn bộ tập ứng viên, từ đó giảm đáng kể vòng lặp tuần tự và số lần điều phối. Dưới điều kiện cùng bài toán, cùng quần thể, cùng hạt giống ngẫu nhiên, và sau khi khởi động nóng và đồng bộ thiết bị mới tính thời gian, vòng lặp tuần tự CPU là chuẩn 1.0×, xử lý lô GPU b=64 khoảng 2.2×, b=256 khoảng 4.5×, b=1024 khoảng 7.1×. Hình hiển thị giá trị tương đối thời gian mỗi thế hệ, kích thước lô càng lớn, chi phí cố định càng dễ được phân bổ mỏng. Cố định bài toán, quy mô quần thể, số thế hệ lặp và hạt giống ngẫu nhiên
- ghi thời gian thực tế mỗi thế hệ, tổng thời gian, thông lượng (đánh giá/giây), tỷ lệ tăng tốc, hiệu suất GPU và chiếm dụng bộ nhớ hiển thị. Trước khi tính thời gian phải khởi động nóng, loại trừ