Mac Mini cho AI agent: cần bao nhiêu memory, và tận dụng máy đang có

1. Bạn không còn là người dùng duy nhất của máy tính

Nate mở đầu thẳng thắn: "Tôi nói luôn nhé. Bạn không còn là người dùng duy nhất của chiếc máy tính của mình nữa." Nếu bạn chạy agent cả ngày, nhiều khả năng chúng đang dùng máy nhiều hơn chính bạn.

Anh đoán trước điều người xem đang nghĩ: "Mac của mình cũ rồi, mình cần một cái to hơn." Có thể bạn đang xem video này vì đang so giá một chiếc Mac Mini hay Mac Studio, hoặc đang cân một máy NVIDIA. Vấn đề nằm ở đây: một con chip nhanh hơn và nhiều memory hơn sẽ không ngăn được phần tải agent mà bạn đang đẩy vào máy cứ lớn lên, lớn lên, lớn lên mãi.

Agent của bạn mở browser. Chúng khởi động service. Chúng ghi file. Và khi job đã xong, chúng để lại rất nhiều thứ trên máy. Nói gọn lại, theo Nate, bạn đang có một người bạn cùng phòng bừa bộn (a messy roommate) mà chưa ai đặt ra nội quy cho căn nhà. Nên trong video này, hai bên sẽ cùng nhau đặt nội quy đó.

Đến cuối video, anh hứa người xem sẽ biết ba điều: chiếc máy nào hợp với workload agent của mình; làm sao lấy thêm việc có ích từ chính chiếc máy đang nằm trên bàn; và làm sao để cách sắp xếp giữa agent và con người, tức "thoả thuận bạn cùng phòng", vẫn đáng tin cậy khi bạn thêm ngày càng nhiều agent job. Anh sẽ dùng bốn nguyên tắc để nối các quyết định này với nhau.

2. Khám máy: memory pressure trong Activity Monitor

Việc thứ nhất là một buổi "khám bác sĩ" cho chiếc Mac. Trên Mac, mở Activity Monitor và bấm vào tab Memory, bạn sẽ thấy, theo đúng nghĩa đen, biểu đồ memory pressure trong lúc những việc bạn quan tâm đang chạy cùng agent.

Biểu đồ này có màu. Xanh lá nghĩa là máy đang ổn. Vàng và đỏ nghĩa là máy đang vật lộn. Nate thú nhận thật lòng: máy của anh thường xuyên ở mức vàng và đỏ.

Tiếp theo, hãy xem ứng dụng nào đang dùng memory. Một con số cao trên thanh RAM đã dùng (RAM used) không tự nó nói rằng bạn cần mua máy khác. Nhưng chắc chắn nó nói rằng bạn cần nhìn kỹ lại hệ thống của mình.

Trên Windows, trên màn hình có ghi đường tắt tương ứng: Ctrl+Shift+Esc để mở Task Manager, rồi vào tab Performance.

3. Storage, swap và chuyện mọi thứ cộng dồn lại

Nếu vẫn đang trong buổi khám, bước kế tiếp là xem storage: vào System Settings → General → Storage. Nate tách bạch hai khái niệm. RAM là không gian làm việc (working space) cho những gì bạn đang làm. Storage giữ file của bạn, giữ phần mềm của bạn.

macOS có thể dùng storage làm swap memory, tức là tạm giữ nội dung của memory xuống ổ đĩa. Nate ví nó như một khoản "giữ tiền" trên thẻ tín dụng (a credit card hold), để hai thứ không giẫm chân lên nhau. Nhưng về căn bản, bạn cần nghĩ xem mình phân bổ memory thế nào, để không rơi vào cảnh xây mọi thứ chồng lên một đống "khoản giữ" của agent rải khắp nhiều harness.

Đó chính là điều anh hay thấy. Ví dụ: bạn có Claude chạy trong Chrome, lại có một đống working memory trong một browser khác (Nate dùng Zen); có một đống working memory trong Codex và một đống trong Claude; rồi thêm một tool AI nữa, có thể là một tool chép lời từ giọng nói. Tất cả cộng dồn lại. Đó chính là memory pressure.

Các lab cũng đã để ý chuyện này. Nate kể gần đây (tính tới video ngày 20/10/2026) phía OpenAI đã ship một cải tiến cho Codex giúp giảm lượng memory mà Codex dùng, vì đây rõ ràng từng là một vấn đề. Nhưng những bản sửa từng điểm (point fixes) như vậy từ phía các lab là không đủ, nhất là khi, như phần lớn chúng ta, bạn đang chạy nhiều harness cùng lúc.

Anh biết nhiều người trong cộng đồng của mình đang chạy local model như Qwen, đang chạy model như Claude, đang chạy Codex. Vì vậy cần một hệ thống làm việc được với tất cả chúng, và video này nói về đúng hệ thống đó.

4. Nguyên tắc 1: biết việc thật sự chạy ở đâu

Nguyên tắc thứ nhất: bạn phải biết công việc diễn ra ở đâu (know where the work happens). Giả sử bạn nhờ Codex của OpenAI hay Claude Code của Anthropic dựng một website nhỏ. Một yêu cầu rất điển hình. Model có thể đang trả lời từ một data center, nhưng điều đó không có nghĩa là máy của bạn không chịu áp lực.

Máy của bạn vẫn đang chạy development server, chạy browser để kiểm tra website, chạy các build tool. Tất cả những thứ đó là local, và bạn cảm nhận được chúng. Nếu cùng lúc bạn giao cho một agent khác một project khác, agent đó lại khởi động từ một bộ tool khác, và tất cả đều dồn lên compute local của bạn.

Nate kể chính anh đã cảm nhận rõ điều này khi dùng Claude để dựng video bằng Blender, cùng lúc lại để Codex làm việc khác. Nó cứ thế "nhai" memory của máy. Vì vậy nếu bạn đang nhận cảnh báo về memory, hãy đưa các tool local vào phần chẩn đoán, và hãy dự tính rằng chính các tool local sẽ là con đường chính để giải quyết.

Điều đó không có nghĩa là bạn phải dừng làm việc với agent. Anh nói rõ là mình không nói vậy. Nhưng bạn phải nghĩ xem mình làm thế nào, và phải đi vào chi tiết. Bạn cần chắc rằng mình không chỉ đi mua một card đồ hoạ vì tưởng nó là lời giải một điểm cho vấn đề này.

Câu Nate nhắc đi nhắc lại: bạn có thể bỏ tiền ra để mua thêm capacity, nhưng bạn không thể bỏ tiền ra để thoát khỏi vấn đề, vì agent sẽ còn tiếp tục giỏi hơn. Kết luận: hãy coi vấn đề memory là chuyện local, một thứ bạn phải xử lý cùng agent của mình trước khi thêm agent mới.

Nếu đang chạy một model local, bạn phải tính kỹ yêu cầu compute của model đó. Và nếu bạn chạy kiểu hỗn hợp, mà theo Nate trong thực tế khá nhiều người làm vậy, thì bạn phải hiểu, bằng cách nhìn vào các mục settings vừa kể, thứ gì đang dồn lên memory từ từng ứng dụng cụ thể. Khi nào Qwen đang chiếm memory local, khi nào là Codex và Claude? Bạn cần nhìn thấy được điều đó.

Trên màn hình có một thẻ tóm tắt "Where It Runs": LOCAL là Qwen; CLOUD là Codex, Claude.

5. Job đã xong, tool vẫn ở lại

Quay lại câu chuyện website. Hãy tưởng tượng agent dựng xong website và bạn chuyển sang việc khác, nhưng development server và browser vẫn còn mở ở chế độ nền. Điều người ta không nhận ra, theo Nate, là sự chú ý của con người đã chuyển đi rồi, còn những tool đó thì vẫn đang dùng tài nguyên một cách thụ động.

Chúng vẫn giữ "khoản giữ tiền trên thẻ tín dụng" đó trên memory của bạn. Project có dependency, có build file chiếm storage. Bạn phải thật sự tắt hết mọi thứ khi muốn những file đó biến mất, hoặc khi muốn chấm dứt khoản giữ trên working memory.

Có thể bạn nghĩ phần lớn những gì Nate nói chỉ là chuyện agent. Nhưng thật lòng, theo anh, một phần trong đó đến từ bug đi kèm phần mềm agentic. Nate dẫn một báo cáo công khai về Codex: một người dùng mô tả một thư mục crash report phình lên hơn 50 GB, chỉ để mô tả các lần crash. Một người khác mô tả hơn 100 GB Git object gắn với các checkpoint của từng lượt (turn checkpoints). Đây là những số liệu Nate dẫn trong video ngày 20/10/2026, từ các báo cáo công khai của người dùng.

Anh nhấn mạnh đó là những setup cụ thể. Anh không nói đây chắc chắn là vấn đề của bạn. Anh nói: hãy để ý chi tiết trên máy của mình, để ý setup cụ thể của mình. Đó là lý do anh nhấn mạnh việc audit trước. Sau đó bạn mới cùng agent tìm ra chiến lược để sửa.

6. Audit trước: prompt chẩn đoán ngắn

Đây hoàn toàn là một việc có ích để giao cho agent. Bản ngắn của prompt chẩn đoán, thứ bạn đưa cho agent, như sau: bạn chỉ việc bảo nó kiểm tra máy của bạn, đừng thay đổi gì cả, tìm ra những thứ dùng nhiều memory nhất, những thứ "hút memory", cùng các thư mục liên quan, giải thích từng thứ thuộc về cái gì, rồi đề xuất các cách sửa cụ thể giúp bạn làm được việc thật của mình. Lời Nate nói, gần như nguyên văn:

Inspect my computer. Please don't change anything. Please identify the largest memory users and the relevant directories. Please explain what each belongs to and propose specific fixes that help me do my actual work.

Theo Nate, thật ra bạn cần cả một chương trình "vệ sinh" máy toàn diện (a comprehensive hygiene program). Nhưng về căn bản, hãy bắt đầu bằng một bản báo cáo như vậy, vì việc một thư mục đang được dùng không cho bạn biết nó có đang được dùng một cách có ích hay không. Bạn phải thật sự đào vào.

Ví dụ, giả sử bạn kiểm tra và thấy có cả đống development server đang chạy cùng lúc. Nate nói: "Này, tôi đã từng như thế đấy", với nhiều side project. Trước khi dừng một cái, hãy xem nó đang phục vụ gì. Project đã xong chưa? Server đó còn cần không? Nó có phải chỉ là một thử nghiệm? Nếu đúng vậy thì đóng nó lại, rồi xem memory pressure có dịu xuống không, xem áp lực lên storage có giảm không. Xác định cái gì có thể tạo lại được (regenerate), rồi mới chọn cách dọn.

Nếu tất cả nghe có vẻ nhàm chán, Nate có tin cho bạn: chúng ta đã phải sống chung với giới hạn của máy tính từ những năm 1980, và giờ chúng ta quay lại cảnh đó, vì có agent ở chung phòng với mình trên những chiếc máy này. Mình chỉ cần học cách làm những người bạn cùng phòng tử tế (be good roommates).

7. SSD bị ghi quá nhiều, log và worktree

Một chỗ khác nên nhìn vào là các vấn đề với SSD. Ổ cứng thể rắn ghi và ghi đè rất nhanh. Theo Nate, hồi đầu năm 2026 Codex từng có một lỗi ghi log quá mức. Một trong những người báo lỗi đo được khoảng 37 terabyte dữ liệu ghi lên SSD trong 21 ngày. "Nhiều lắm đấy", anh nói.

Codex đã ship các bản sửa phần logging vào tháng 6, và một bản phát hành sau đó thêm việc thu hồi lại phần dung lượng không dùng tới trong database log (reclamation of the unused log database space). Đó là tiến bộ.

Nhưng nếu đó từng là một vấn đề, nó nhắc Nate, và nên nhắc cả bạn, rằng đây là những phần mềm đang tiến hoá, và chúng ta nên theo dõi sát cách chúng dùng các linh kiện vật lý trong máy mình.

Và tất nhiên còn có phần tăng trưởng đến từ việc agent đơn giản là giỏi hơn: những tính năng hữu ích hơn, chạy đúng như thiết kế. Hãy nhìn sự tăng trưởng của coding agent từ tháng 1 tới giờ (tính đến video ngày 20/10/2026). Bạn có thể tạo worktree, có các thư mục làm việc riêng (separate working directories); mỗi thư mục có thể có dependency và build cache riêng; và Codex có settings để quản lý tất cả những môi trường đó.

Trên màn hình là thẻ "Worktrees Use Disk" với ảnh chụp tài liệu Worktrees của OpenAI, dòng chú thích "Separate working directories". Trước khi chọn một cách và quyết định settings, Nate khuyên hãy thật sự nghĩ xem bạn muốn làm build project này thế nào và ở đâu.

8. Cloud hay local, và nguyên tắc 2: cho mỗi agent một biển dừng

Ở đây Nate mở một ghi chú bên lề về chuyện dùng môi trường cloud hay local. "Tôi lật bài luôn": anh thích local, chừng nào còn được, vì local cho phép anh chuyển qua lại giữa các harness và giữa các tool AI rất dễ. Anh chỉ việc chỉ nó vào một thư mục và bảo: dùng cái đó đi. Slide "Nate's Pick: Local" ghi hai lý do: chuyển giữa các tool AI, và chỉ bất kỳ tool nào vào một thư mục.

Dù vậy, không có cách nào né được việc phải nghĩ kỹ chuyện này, dù bạn dùng cloud hay local. Quy tắc kinh nghiệm của anh là: cho mỗi agent một biển dừng (give every single agent a stop sign). Hãy cho nó một thứ khiến nó phải kết thúc, rồi đặt kết quả ở chỗ bạn tìm được.

Đó là điều cần nghĩ, vì theo Nate rất nhiều lần chúng ta bắt đầu một việc rồi bỏ dở. Dở dang theo nghĩa tab Chrome vẫn mở với project đang làm. Dở dang theo nghĩa cửa sổ chat vẫn mở, kèm một development server đang chạy. Nhưng rốt cuộc, nếu agent không có lý do để dừng, thì tất cả các AI agent đều đã được RLVR (reinforcement learning with verifiable rewards, như slide giải thích), tức là đã được train để cứ tiếp tục chạy.

Và thế là chúng cứ tiếp tục ăn máy local của bạn. Thêm capacity cho bạn thêm chỗ, nhưng không giải quyết vấn đề đó (slide ghi: "It does not solve that problem. More capacity gives you more room"). Bạn phải tự tìm ra lời giải. Đó là nguyên tắc số hai.

9. Nguyên tắc 3: quản lý nhu cầu đồng thời

Nguyên tắc thứ ba khi xử lý tất cả chuyện này là quản lý nhu cầu đồng thời (manage simultaneous demand). Giả sử bạn có một tá tài liệu cần xử lý và đưa 12 job vào hàng đợi. Nate nói đây là chuyện rất thực tế, chính anh vẫn làm vậy. Bạn chỉ chạy một hoặc hai bước nặng mỗi lúc.

Agent hoàn toàn có thể tự profile tải đó và lên kế hoạch cho toàn bộ nhiệm vụ mà không phải bật cùng lúc mọi browser, mọi tool chuyển đổi và mọi request tới local model. Nó làm được, và nó nên làm. Bạn chỉ cần yêu cầu.

Trong tình huống đó, theo Nate, bạn chỉ việc bảo agent: bạn có thể tăng dần để tối ưu theo tải của máy tôi không? Bắt đầu với một job đang chạy, rồi có thể lên hai. Xem các việc hoàn thành ra sao. Xem yêu cầu memory. Agent là một đối tác tốt ở đây, nó "compute native", nó tự kiểm được những thứ này. Slide lúc đó ghi "Start with one active job. Then try two."

Nếu thêm job làm mọi thứ chậm hẳn đi, bạn đã học được rằng mình đã đẩy compute hiện có tới giới hạn và cần lùi lại một chút.

Đó cũng là lý do số core CPU không quy đổi thẳng ra số agent. Không có câu trả lời đơn giản nào ở đây. Hai agent đang chờ phản hồi từ cloud có thể gần như chẳng làm gì ở local, nhưng hai agent đang chạy một bản build lớn hay render một video sẽ ăn hết mọi CPU bạn có.

Nên nhiều core hơn có ích khi phần mềm biết dùng chúng, và nhiều memory hơn có ích khi công việc đang chạy thật sự cần chỗ đó. Nhưng bạn không thể chỉ tối ưu theo con số đó mà không nghĩ về tải thật mà bạn đang dùng máy để làm.

Nếu bạn đầu tư phần cứng lớn, bạn vẫn có thể vắt thêm từ phần cứng đó bằng đúng quy trình này: tách các giai đoạn của job, để vài agent research và lên kế hoạch trong khi bản build local lớn chạy từng cái một trong hàng đợi. Cuối cùng bạn khớp lịch chạy với tài nguyên, thay vì bắt mọi task tranh nhau tài nguyên cùng một lúc. Slide "Separate the Stages" vẽ đúng chuỗi đó: Research + plan, rồi Queue, rồi One big local build. Và như Nate nói anh sẽ còn nhắc mãi: bạn có thể để chính agent làm việc sắp xếp này, vì nó là quá nhiều thứ để tự mình quản lý.

10. Cắt việc thừa và chỉnh setting cho local model

Bước kế tiếp là nhìn vào những việc không cần phải xảy ra. Hãy để agent kiểm tra một project đã có trước khi dựng thêm một môi trường mới. Dùng lại browser khi phù hợp. Giữ output trong một cấu trúc thư mục dễ đoán mà cả bạn lẫn agent đều hiểu. Bảo agent chỉ ra những process nào nên tiếp tục chạy sau khi xong việc. Và rốt cuộc, ghi những gì bạn học được vào phần hướng dẫn của project (project guidance) để dùng lại.

Nếu bạn dùng local model, settings của phần mềm sẽ rất quan trọng. Docker Desktop có giới hạn cho máy ảo của nó, và có chế độ tiết kiệm tài nguyên khi rảnh (Resource Saver). Các model server có những nút điều khiển cách xử lý context, xử lý request song song, và giữ model nạp trong bao lâu. Tất cả đều liên quan tới tải trên máy bạn. Nate tự nhận mình rất đam mê chuyện vắt kiệt hiệu năng của chiếc máy.

Với local model, bạn vẫn phải tính kích thước request và xử lý các việc chạy đồng thời. Context lớn hơn thì dùng nhiều memory hơn nếu đó là local model. Nhiều request cùng lúc cộng dồn lại. Giữ model nạp sẵn mọi lúc có thể giảm gánh nặng cho request kế tiếp, giảm latency, nhưng nó vẫn chiếm memory giữa các job. Bạn sẽ phải cùng agent chọn điểm cân bằng (tradeoff) tuỳ theo cách mình dùng.

Trên màn hình có thẻ "Loaded Between Jobs" kèm ảnh chụp tài liệu LM Studio, chú thích "Idle timeout + auto-evict": hết thời gian rảnh thì model tự được gỡ khỏi memory.

11. Nên mua bao nhiêu memory và storage

Tới đây mới có lý do cho câu chuyện mua phần cứng. Khi những việc bạn làm cần thêm capacity, sau khi bạn đã dùng hết máy, đã làm audit, đã kiểm tra profile tải, lúc đó bạn mới bàn tới chuyện mua thêm phần cứng và liệu có làm được việc đó hiệu quả không. Bạn tự nói chuyện ROI với chính mình, hoặc có thể bạn cứ hứng lên là mua. Nate thì có nói chuyện ROI với bản thân, vì mấy thứ này đắt.

Một điều anh muốn nói khi bạn nghĩ tới máy mới: nếu mua máy mới, hãy giữ máy cũ. Giữ cho nó chạy. Vì nếu nó còn chạy và được giao cho agent, bạn có thể làm nhiều job có thể chậm hơn, gánh bớt rất nhiều compute, và dùng các tool như Tailscale để điều khiển nó. Thẻ trên màn hình: "Keep the old one. If you buy a new computer"; ngay sau đó là thẻ "Tailscale: A private network linking your own machines".

Nếu bạn đang bắt đầu tìm phần cứng, trước khi nói tới hãng, Nate nói về mức dùng memory của agent ở thời điểm này. Giả định khởi điểm của anh, theo video ngày 20/10/2026, trừ khi bạn là người dùng siêu nặng, là làm việc với 24 đến 32 GB memory. 16 GB vẫn dùng được, nhưng bạn sẽ phải chủ động xử lý nhiều hơn. Khoảng cao hơn cho bạn thêm chỗ để mở cùng lúc các ứng dụng thường ngày, những thứ bạn vẫn dùng, và các tool agent bạn muốn mở.

Anh nói đây không phải con số được tối ưu siêu kỹ cho Codex hay Claude, và thật ra anh không mua phần cứng theo kiểu đó. Anh mua cho chính mình, và giả định rằng theo thời gian mình sẽ dùng những harness khác nhau.

Về storage, Nate lấy nửa terabyte làm điểm khởi đầu, và một terabyte khi anh làm việc với video lớn, project lớn, file lớn (thẻ trên màn hình: "512 GB → 1 TB · Start / big video and projects"). Nếu bạn làm website, nếu bạn tạo ra nhiều phim, hãy dùng chính thói quen làm việc thật của mình để quyết định mình cần bao nhiêu storage.

12. Vì sao nói về Mac, và giá Mac mini theo video

Có thể bạn thắc mắc vì sao Nate nói về Mac mà không nói Windows. Anh trả lời thật: như anh đã nhiều lần nói, theo anh cuộc cách mạng AI trên Mac đang đi trước Windows sáu đến tám tháng (nhận định của anh trong video ngày 20/10/2026). Máy Windows cũng đang có AI, nhưng không nhanh bằng. Một phần vì các lab đều chạy Mac, một phần vì chip Mac được tối ưu cho AI tốt hơn, xét tổng thể.

Nên khi nói về Mac, về cơ bản anh đang đưa những mẹo bạn có thể áp sang môi trường khác. Nhưng "mũi nhọn của cơn đau", thứ mà phần lớn mọi người đang vật lộn, những chiếc máy anh thấy đang khổ sở, lại đến từ những người dùng Mac, vì họ đang dồn sức vào agent và giao cho agent rất nhiều workload. Đó là lý do anh nói cụ thể về Mac ở đây.

Về phía Mac, nếu bạn đang đi mua, theo Nate trong video ngày 20/10/2026:

• Apple niêm yết M6 Mini giá 899 đô. Máy cơ bản đó có đúng 16 GB như anh nói ở trên, và một phần tư terabyte, tức 256 GB storage. Nó hơi mỏng so với cấu hình nên mua mà anh vừa mô tả, nhưng vẫn dùng được.
• Một lựa chọn khác với M6 Mini là cấu hình lên tới 32 GB memory.
• M5 Pro Mini khởi điểm từ 1.699 đô và lên tới 64 GB memory, còn nhiều hơn nữa.

Với bản Pro, bạn cần quyết định là mình thật sự muốn nó. Bạn đang cam kết với nhiều memory hoạt động hơn, cam kết với việc chạy local liên tục, nhiều khả năng là với local model. Anh muốn bạn nghĩ kỹ điều đó.

Nate kể trước đây anh đã làm một video về Mac, và nhận ra lúc đó anh nói về chúng như những món đồ để mua, những thứ bạn đi shopping, kèm một chút về workload AI. Lý do anh làm video này bây giờ là: càng dựa vào agent, mối quan hệ càng chằng chịt. Anh càng phải hiểu agent đang làm gì với máy mình thì mới quyết định mua đúng được. Vì vậy video này đảm bảo mọi người hiểu điều đó trước.

Nếu bạn hay đi lại, một chiếc MacBook có thể hợp lý, vì rõ ràng bạn nhét nó vào túi và đi đâu cũng được. Theo anh, nếu mua MacBook thì hãy chọn cấu hình không làm bạn bị vướng khi đang đi đường. Và đây là chỗ Tailscale thật sự là một cách điều khiển và quản lý máy khác từ xa: bạn có thể dùng Tailscale để quản lý một chiếc Mac mini, quản lý một laptop cũ, trong khi mang theo laptop làm việc.

Nhưng ngay cả trong trường hợp đó, theo trải nghiệm của Nate, chiếc máy ngay trước mặt anh vẫn phải làm được việc ngay trước mặt anh (slide: "The computer in front of me needs to work"). Hãy nghĩ kỹ điều đó.

13. NPU không phải viên đạn bạc: tối ưu cả hệ thống

Các hãng chip, kể cả Apple, đang nói rất to về neural processing unit, tức NPU, và nói như thể đó là lời giải cho AI. Nate nói: bạn có thể dùng nó cho workload của mình, nhưng nó không phải viên đạn bạc thần kỳ. Bạn vẫn đang mua phần cứng để làm việc, và phải nghĩ xem nó có làm xong việc hay không.

Bạn đang tối ưu cả hệ thống: cách memory hoạt động, cách storage hoạt động, cách xử lý hoạt động. Bạn không chỉ tối ưu cho một con chip thần kỳ rồi coi như xong. Nên đừng bị "bán" cho những tính năng màu nhiệm. Bạn phải thật sự hiểu các phần này phối hợp với nhau thế nào.

Một buổi audit tốt, như anh vẫn nhắc, sẽ giúp bạn đến đó và đánh giá một cách thông minh xem mình đang thiếu core CPU, thiếu memory, hay thiếu storage.

Nếu chạy model local là một trong các mục tiêu của bạn, và Nate biết nhiều người xem rất đam mê chuyện này, thì lượng memory mà bộ tăng tốc (accelerator) dùng được, cùng phần mềm hỗ trợ nó, sẽ là chìa khoá để quyết định cấu hình hệ thống (thẻ "Local Models: Memory the accelerator can use").

Nếu bạn có một Mac Studio nhiều memory, một hệ NVIDIA, hay có thể một máy AMD dùng unified memory, hãy nghĩ xem các cách bố trí memory khác nhau đó cho phép chạy những loại tải khác nhau thế nào.

Nate gợi ý thật ra nên có hẳn một cuộc trò chuyện với chính hệ thống hiện tại, với chính các agent hiện tại của bạn: nói kỹ chi tiết kỹ thuật về việc workload hiện tại đang ăn memory ra sao, ăn core xử lý ra sao, rồi bắt đầu mô phỏng điều đó trên các cấu hình kỹ thuật khác nhau, để hiểu ở đâu bạn thật sự được nhiều nhất cho số tiền bỏ ra.

14. Local model trên Mac Studio, NVIDIA hay AMD

Slide "Three Memory Setups" chia ba hướng: Mac Studio, NVIDIA, AMD. Nate đi qua từng hướng.

Mac. Nếu đi theo Mac, một chiếc Mac Apple Silicon nhiều memory sẽ cho bạn chạy được local model, đồng thời vẫn chạy được các ứng dụng Mac native của bạn.

NVIDIA. Nếu bạn ở trong hệ sinh thái NVIDIA, hướng NVIDIA GeForce RTX rất mạnh. Về cơ bản nó được thiết kế để giúp bạn chạy local model, nhưng nó đòi CUDA, nền tảng tính toán của NVIDIA. Nếu công việc của bạn dựa vào tool GPU, bạn đang "leo đồi" (hill climbing) và fine-tune model, thì tất cả chạy rất tốt. Nếu bạn là kiểu "dân nghiện" đó, và Nate biết ngoài kia có nhiều người như vậy, thì tuyệt.

AMD. Rời NVIDIA, nếu bạn ở môi trường dựa trên AMD, mà theo quan sát của anh không nhiều người lắm, bạn sẽ muốn ghép được một setup memory rất lớn để một PC Windows hoặc Linux thông thường chạy tốt.

Cũng có người cài Omarchy lên những máy đó, và nó chạy được. Nate đã làm hẳn một video về Omarchy và việc nó "agent native" ra sao, và điều đó hoàn toàn áp dụng ở đây. NVIDIA Spark thì có yêu cầu phần mềm riêng. "Tôi có thể nói tiếp mãi", anh nói.

Mục tiêu của anh về cơ bản là khiến bạn nghĩ về mức độ bảo trì máy mà mình thấy thoải mái, và mức độ profile mà mình muốn làm. Bạn càng có nhiều chỗ, bạn càng có thể lỏng tay và lười hơn một chút trong việc profile, và càng thoải mái dùng máy trong khi một hay nhiều agent cũng đang dùng nó.

Nhìn chung, theo Nate, lựa chọn ít đòi hỏi kỹ thuật nhất là Mac. Từ đó trở đi chỉ càng kỹ thuật hơn. Khi tới NVIDIA, tới AMD, khi bạn tự cài một hệ điều hành như Omarchy, thì bạn là một builder, một người làm kỹ thuật, bạn thấy thoải mái với việc đó. Bạn nên hào hứng, vì bạn sẽ có nhiều quyền kiểm soát hơn hẳn. Nó giống như xe số sàn so với xe số tự động.

Điểm phân biệt quan trọng ở đây: memory cần để giữ một local model là một yêu cầu cộng thêm (thẻ "An additional requirement: Memory to hold a local model"). Nên hãy nghĩ về chiến lược local model của mình. Nếu bạn định mua một máy memory lớn, hãy chắc là mình mua vì một lý do chính đáng: hoặc bạn đang chạy rất nhiều model trên cloud và chúng dùng rất nhiều file và tool local, hoặc bạn đang chạy một local model lớn.

15. Ba lựa chọn: giữ, nâng cấp, hay mua mới

Rốt cuộc, theo Nate, bạn có ba lựa chọn, và phần lớn mọi người có hai trong số đó.

1. Giữ máy đang có. Đây chắc chắn là lựa chọn ai cũng có. Có thể bạn sẽ phải chủ động profile nó nhiều hơn, như anh đã nói ở phần trước.
2. Nâng cấp, trong một số trường hợp. Nhưng ở nhiều trường hợp, các hãng đang khoá chuyện đó lại và làm nó khó hơn. Mac chắc chắn làm nó khó hơn.
3. Mua máy mới, rồi dùng máy cũ cho việc của agent.

Tất cả đều là những lựa chọn hợp lệ. Anh chỉ muốn bạn chọn một cách có chủ đích, và tính trước được hướng mà agent đang đi tới.

16. Nguyên tắc 4: kế hoạch bảo trì liên tục, và Tailscale

"Nguyên tắc thứ tư đây, tôi biết các bạn đang thắc mắc nó ở đâu." Nguyên tắc thứ tư là đảm bảo bạn có một kế hoạch bảo trì liên tục (an ongoing maintenance plan).

Một chiếc máy bạn dùng trực tiếp (interactively) cần báo cho bạn biết khi nó đang chật vật. Một chiếc máy bạn để chạy nền qua Tailscale thì có thể cứ thế nhai việc, và nó có yêu cầu bảo trì và mức chú ý khác hẳn. Slide "Different Attention Needs" chia đúng hai loại: INTERACTIVE ("Get your attention when struggling") và BACKGROUND ("A different maintenance schedule").

Nên khi nói về AI và cách quản lý chuyện này theo thời gian, Nate rất ủng hộ việc giao cho agent một việc định kỳ là giữ cho máy tính khoẻ. Điều này, nhân tiện, cũng áp cho các agent chạy trên máy ảo. Anh có hẳn một agent Grok Bot chuyên lo giữ cho chiếc máy Linux chạy Grok Bot của anh khoẻ. Đó là một bản cài Linux, nó phải khoẻ, và con Grok Bot cứ thế ám ảnh với chuyện đó. Bạn có thể học theo cách đó cho máy local của mình.

Bạn có thể bảo agent theo dõi các thư mục, để nó hiểu khi nào có thay đổi đủ lớn để gọi bạn chú ý; giữ nguyên công việc đang chạy; ưu tiên việc của con người hơn việc của agent, và đẩy việc của agent xuống chạy nền. Hoặc bạn có thể đảo lại nếu muốn, nhưng Nate thì thích vẫn làm được việc trên máy của mình.

Tất cả những điều đó làm được với độ tin cậy cao, vì agent là "compute native". Và theo Nate, đó là một trong những thay đổi nền tảng lớn hơn trong năm qua (tính tới video ngày 20/10/2026). Từ thời ChatGPT, chúng ta lúc nào cũng có LLM trong kỷ nguyên AI. Nhưng không phải lúc nào chúng ta cũng tin rằng các agent này đủ thông minh để giúp mình quản lý tải compute một cách hiệu quả. Giờ thì có.

Nate đã nhắc Tailscale vài lần, nên anh giải thích nếu ai còn mơ hồ: đó là một cách quản lý máy qua một mạng riêng. Nói cách khác, Tailscale cho bạn một kết nối riêng ở bất cứ đâu trên thế giới, bạn làm việc với máy của mình từ xa, và làm một cách an toàn. Nhiều người dùng Tailscale với một máy local ở nhà, và dù đang ở đâu trên thế giới, họ vẫn giao cho chiếc máy đó chỉ dẫn của agent. Theo anh, nó rất dễ quản lý, và không quá khó để setup.

17. Máy cũ, Raspberry Pi và cái nhà kho sau vườn

Một trong những cách bạn thật sự tiết kiệm được hàng trăm, hàng nghìn đô tiền compute, theo Nate, là nhớ rằng nhiều khả năng bạn đang có một chiếc máy cũ nằm đâu đó: một Mac mini cũ, một laptop Windows cũ, một MacBook cũ, gì cũng được. Bạn có thể nói: mình sẽ cắm nó lên, dùng Tailscale để quản lý, biến nó thành một máy cho agent, và agent có thể làm chủ, điều khiển và làm việc cho mình ở đó. Như vậy rẻ hơn nhiều so với mua máy mới.

Còn nếu bạn là dân mê phần cứng, Raspberry Pi đã có mặt khá lâu. Đó là những bo mạch nhỏ xíu, và trong thế giới này chúng đóng một vai trò tương tự nhưng nhỏ hơn (thẻ "Raspberry Pi: Tiny boards for small jobs"). Bạn có thể dùng Raspberry Pi để điều khiển màn hình e-ink, Nate làm vậy ở nhà. Và có thể dùng chúng để mở các service local nhỏ trong khi laptop của bạn đang ở chỗ khác. Một lần nữa, Tailscale có thể giúp ở đây.

Rốt cuộc, bạn tự quyết định muốn dành bao nhiêu compute. Một phần lý do Nate làm video này là anh muốn giúp bạn tiết kiệm tiền. Nếu bạn dùng máy tới mức tối đa, bạn ít có khả năng phải mua thêm. Và nếu có mua thêm, bạn sẽ mua khôn hơn.

Hãy nghĩ thế này. Chúng ta đang cố hiểu cách tận dụng tối đa "thoả thuận bạn cùng phòng" với agent hôm nay. Mình có căn nhà mình đang có, có những căn phòng mình đang có. Trước khi mua một căn nhà mới, nói theo nghĩa bóng, tức trước khi mua một chiếc máy mới, mình muốn chắc rằng mình đã tận dụng hết những gì đang có.

Và nếu sau vườn có một cái nhà kho cũ bỏ không, ẩn dụ yêu thích của Nate cho một chiếc máy cũ nằm đâu đó trên sàn nhà, thì mình sẽ dùng nó. Mình đảm bảo nó trở thành một phần không gian sống, một phần không gian compute cho agent, trước khi chạy đi mua thêm. Vì như anh nói, ai cũng thích bóc quà dưới gốc cây thông, nhưng anh cũng thích chắc rằng mình không phung phí tiền. Anh muốn bạn có đủ công cụ để ra một quyết định mua sắm khôn ngoan, và để giữ, dùng những gì mình đang có một cách thật tự tin.

18. Những điều mang về: bốn nguyên tắc và chuyện rửa bát

Nate chốt lại bằng vài điều để mang về. Nếu máy của bạn đang chật vật, như máy của anh từng bị, hãy chạy buổi chẩn đoán đó (thẻ "Run the diagnostic."). Kiểm tra và đảm bảo bạn hiểu mức dùng memory, mức dùng storage. Đảm bảo bạn hiểu áp lực lên các core CPU. Đảm bảo bạn hiểu cái gì đang gây ra áp lực đó. Và đảm bảo bạn biết cách profile công việc của mình.

Anh giải thích "profile" là một từ nghe sang chảnh, về cơ bản là sắp thứ tự công việc để bạn không dồn một đống tải cùng lúc, khiến tải dựng đứng thành đỉnh nhọn và máy tối sầm. Nate kể ngay tối hôm trước anh vừa bị một lần crash vì memory, chỉ vì anh, với tư cách con người, mở thêm đúng một chương trình mới trong khi trước đó máy vẫn ổn. Chuyện đó vẫn xảy ra, nhưng sẽ ít xảy ra hơn nếu chúng ta thật sự cẩn thận không làm máy quá tải.

Nói chung, chúng ta muốn quản lý nhu cầu một cách thông minh để giảm nhu cầu đồng thời. Nên lần tới khi ngồi trước máy tính, Nate muốn bạn nghĩ: mình có bạn cùng phòng, có nhiều agent là bạn cùng phòng, và mình phải thương lượng chuyện sống chung. Phải thương lượng xem ai chiếm bao nhiêu chỗ. Phải hiểu tất cả đang dùng căn nhà thế nào để nó hiệu quả. Về cơ bản, đó là chuyện "ai rửa bát" giữa AI và bạn trên chiếc máy tính.

Ai lo chuyện vệ sinh? Trong các cuộc nói chuyện giữa bạn cùng phòng, chẳng ai muốn bàn chuyện rửa bát. Đó là phần nhàm chán, nhưng cực kỳ quan trọng để căn nhà vận hành.

Mục tiêu của video này, theo Nate, là giúp bạn hiểu các primitive cốt lõi như memory, CPU, storage; hiểu agent đang dùng chúng thế nào, bạn đang dùng chúng thế nào; và cuối cùng có một kế hoạch dùng chúng tốt hơn, hoặc nếu bạn đang đi mua, thì mua thông minh cho chiếc máy kế tiếp. Anh chào: "Chúc may mắn, và go Hawks."