Chạy Local LLMs ngoại tuyến trên chuyến bay 10 tiếng: Bài học từ MacBook M5 Max

Tôi vừa có chuyến bay từ London đến Las Vegas để tham dự Google Cloud Next 2026. Một chuyến bay kéo dài 10 tiếng hoàn toàn không có Wi-Fi. Thay vì ngủ hay xem phim, tôi đã tận dụng khoảng thời gian này để kiểm tra xem một chiếc MacBook hiện đại có thể "gánh" được các công việc kỹ thuật dựa trên Local LLMs (Mô hình ngôn ngữ lớn chạy cục bộ) tốt đến mức nào.

Thiết lập làm việc trên máy bay

Cấu hình và Chuẩn bị

Thiết bị tôi sử dụng là một chiếc MacBook Pro M5 Max mới mua chỉ một tuần trước, cấu hình 128GB bộ nhớ thống nhất (unified memory) và GPU 40 nhân.

Về phần mềm, tôi cài đặt các mô hình Gemma 4 31B và Qwen 4.6 36B thông qua LM Studio. Ngoài ra, tôi còn chuẩn bị sẵn 100 Docker image phổ biến nhất và các ngôn ngữ lập trình chính kèm theo các thư viện phụ thuộc cần thiết để xây dựng các chức năng website có trực quan hóa dữ liệu. Tôi cũng cài đặt vô số công cụ dòng lệnh (CLI), trong đó opencode, rtk, instantgrep và duckdb là những cái được sử dụng nhiều nhất.

Những gì tôi đã xây dựng

Mục tiêu lớn nhất của tôi là tạo ra một công cụ phân tích thanh toán (billing analytics) bao gồm chi phí đám mây trong hai năm của loveholidays. Hệ thống sử dụng DuckDB làm nền tảng, với giao diện người dùng tùy chỉnh để cắt lát dữ liệu theo các chiều mà các bảng điều khiển tiêu chuẩn không hiển thị được. Công cụ này đã giúp phát hiện ra các mẫu dữ liệu và mối tương quan giữa các dịch vụ mà trước đây rất khó để tìm ra.

Tôi đã quan tâm đến lĩnh vực này một thời gian nhưng chưa bao giờ có thể ưu tiên nó trước hàng tá trách nhiệm khác. Với 10 tiếng rảnh rỗi, phần cứng hàng đầu và các mô hình mã nguồn mở (OSS), tôi quyết định thử sức.

Bên cạnh đó, tôi đã xử lý khoảng 4 triệu token cho các nhiệm vụ nhỏ hơn: tái cấu trúc code (refactor), dựng khung CLI và viết tài liệu. Đối với các công việc có phạm vi hẹp (tight-scope), Gemma và Qwen tạo ra kết quả tương đương với các mô hình tiên phong (frontier models) mà tôi thường sử dụng trên đám mây.

Những khó khăn gặp phải

Tuy nhiên, tôi đã gặp phải ba giới hạn lớn.

Năng lượng: Dưới tải trọng liên tục, máy tiêu tốn khoảng 1% pin mỗi phút. Đáng lo ngại hơn là pin vẫn bị tụt ngay cả khi đang cắm sạc với nguồn cấp 60W.

Nhiệt độ: Với mức tiêu thụ điện duy trì ở mức 70–80W, vỏ máy nóng đến mức khó chịu. Chiếc chăn và gối của hãng hàng không cứu được đầu gối của tôi, nhưng lại làm vấn đề quá nhiệt trở nên tồi tệ hơn.

Ngữ cảnh (Context): Tốc độ xử lý và độ trễ (latency) giảm rõ rệt sau khi vượt quá 100k token.

Vòng lặp: Một số lệnh (prompt) đã khiến mô hình rơi vào vòng lặp vô hạn và cần can thiệp thủ công để dừng lại. Hiện vẫn chưa rõ lỗi nằm ở lớp điều phối opencode hay ở chính mô hình.

Những giải pháp hữu ích bao gồm: giải quyết một vấn đề cho mỗi phiên làm việc, viết kế hoạch dài vào file markdown để tái nhập dữ liệu, và giảm thiểu chi phí gọi công cụ với rtk. Tôi tránh việc nén dữ liệu (compaction) vì nó chạy rất chậm.

Công cụ đo lường (Instrumentation)

Trong chuyến bay, tôi đã xây dựng hai công cụ:

1. powermonitor: Một công cụ CLI đọc dữ liệu đo lường điện năng của Mac (CPU, GPU, ANE, bộ chuyển đổi, pin) theo thời gian thực. Tôi đã gửi một bản sửa lỗi để phát hiện nhanh hơn các thay đổi nguồn điện của bộ chuyển đổi.
2. lmstats: Đọc dữ liệu đo lường từ LM Studio và báo cáo tốc độ xử lý token, phân phối độ trễ và hành vi của cửa sổ ngữ cảnh trong suốt một phiên làm việc.

Cả hai công cụ đều tuân theo cùng một mô hình mà chúng tôi áp dụng tại loveholidays ở quy mô lớn hơn: đo lường hệ thống trước khi hành động.

Không gian làm việc và các công cụ đo lường

Phản hồi từ cộng đồng

Bài đăng trên LinkedIn đã thu hút nhiều cuộc thảo luận thú vị.

Steve Turner nhận thấy rằng việc chạy cục bộ, nơi chi phí được thể hiện rõ ràng về mặt vật lý, khiến ông trở nên phê phán hơn với những gì ông yêu cầu từ các mô hình đám mây. Đây là nguyên lý "sự thấu cảm cơ học" (mechanical sympathy) được áp dụng vào AI - tiếp xúc trực tiếp với nhiệt, điện năng và tác động của ngữ cảnh giúp xây dựng trực giác về nơi nào suy luận rẻ và nơi nào đắt. Trực giác đó chuyển ngược lại việc sử dụng đám mây.

Jackson Oaks đã lập luận về hiệu suất trên mỗi watt (perf-per-watt) của Apple Silicon vượt trội so với NVIDIA cho các khối lượng công việc bị giới hạn bởi pin.

Vấn đề về cáp sạc

British Airways quảng cáo là cung cấp 70W cho mỗi ghế. Tuy nhiên, powermonitor cho thấy chỉ có 60W được cung cấp trong chuyến bay đi. Tôi quyết định làm rõ sự chênh lệch này khi đến nơi.

Tại khách sạn, tôi đã kiểm tra M5 Max dưới tải tương đương với hai loại cáp khác nhau. Cùng một bộ sạc, cùng một ổ cắm, cùng khối lượng công việc:

• Cáp iPhone: Cung cấp 60W.
• Cáp MacBook: Cung cấp 94W.

Một khoảng cách 34W (36%) chỉ từ việc chọn cáp. Trong chuyến bay đi, tôi đã tự giới hạn mình ở mức 60W trong khi trần là 70W.

Chuyến bay về sẽ kiểm tra điều này với cáp đúng. Tôi kỳ vọng sự cải thiện ít nhất 16% so với mức trần 70W, và nhiều dư địa hơn nữa khi cáp không còn là giới hạn. Nếu không có các công cụ đo lường, tôi sẽ không bao giờ phát hiện ra sai lầm của mình khi dùng cáp iPhone.

Bài học rút ra

Suy luận cục bộ (local inference) khả thi cho một tập hợp con ý nghĩa của công việc kỹ thuật: lập trình phạm vi hẹp, công cụ khám phá và các nhiệm vụ không đạt được ngưỡng chi phí - lợi ích khi dùng suy luận đám mây. Các tác vụ suy luận ngữ cảnh lớn, quy trình tác nhân (agentic workflows) cần trí thông minh tiên phong và các công việc giá trị cao vẫn thuộc về đám mây.

Tác động phụ: Việc tiếp xúc trực tiếp với chi phí suy luận cục bộ buộc phải có kỷ luật về kích thước lệnh (prompt), chi phí gọi công cụ và quản lý ngữ cảnh. Kỷ luật đó sẽ được mang theo khi sử dụng đám mây.

Tiếp theo là gì?

Chuyến bay trở về với cáp sạc đúng và công bố các con số. Khám phá các mô hình LLM nhỏ chạy bằng Neural Engine vì tính hữu ích, tốc độ và mức tiêu thụ điện năng của chúng, vì nó được cho là rất hiệu quả để chạy.