Tóm tắt nhanh
- Needle 3 tập trung vào gọi công cụ, trích xuất dữ liệu có cấu trúc và embedding; không thay thế chatbot đa dụng.
- Cactus Compute công bố mô hình có binary 8–29 MB, với lựa chọn từ 2 đến 20 lớp.
- XDA đo bản 20 lớp trên Pi 5 8GB chạy DietPi: decode 280,2 token/giây và prefill 996,4 token/giây. Đây là một thiết lập cụ thể, không phải mức tốc độ đảm bảo.
- Mô hình chọn hàm và tham số; mã ứng dụng quyết định quyền thao tác. Chạy cục bộ không tự làm lệnh điều khiển thiết bị trở nên an toàn.
AI trên bo mạch Pi có ích nhất khi được giao một việc vừa sức. Với điều khiển nhà thông minh, yêu cầu cần giải quyết có thể chỉ là hiểu câu lệnh và chọn đúng thao tác, thay vì tạo ra một đoạn trả lời dài. Needle 3 đi theo hướng đó: đặt một lớp hiểu ngôn ngữ trước những hàm mà người phát triển đã viết.
Cactus Compute công bố dung lượng mô hình 8–29 MB, đủ nhỏ để khiến người dùng nghĩ ngay đến một trợ lý chạy trên bo mạch sẵn có. Nhưng điểm đáng bàn hơn dung lượng là phần công việc đã bị loại bỏ. Needle không cố biết mọi thứ. Nó dựa vào tập công cụ của ứng dụng để chuyển yêu cầu thành hành động có giới hạn. Nếu hiểu đúng sự đánh đổi này, việc dùng Pi cho AI sẽ bớt bị chi phối bởi câu hỏi phải mua thêm bộ tăng tốc nào.
Giá trị của Needle nằm ở việc chọn đúng hàm

Một mô hình chuyên gọi công cụ cần làm tốt đầu ra mà phần mềm đọc được, không cần trò chuyện dài. Function-calling là việc chọn một hàm trong danh sách được phép và điền tham số cho hàm đó. Chẳng hạn, trạng thái bật hay tắt của ổ cắm có thể được chuyển thành giá trị đúng hoặc sai, rồi giao cho mã điều khiển thực hiện.
Cactus mô tả đầu vào của Needle 3 gồm câu yêu cầu và định nghĩa công cụ hoặc khuôn dữ liệu cần trích xuất. Đầu ra là JSON có cấu trúc. Hãng cũng cung cấp khả năng tạo embedding, tức biểu diễn văn bản thành vector để tìm kiếm hoặc so khớp. Các công việc này vẫn liên quan đến ngôn ngữ, nhưng phạm vi hẹp hơn việc trả lời kiến thức mở trong một giao diện chat.
Sự khác biệt có ý nghĩa ngay ở cách đánh giá. Với chatbot, người dùng quan tâm câu trả lời có đầy đủ và dễ đọc hay không. Với bộ chọn công cụ, câu hỏi quan trọng là nó có chọn đúng hành động, đúng thiết bị và đúng tham số không. Một kết quả ngắn nhưng sai ổ cắm vẫn là lỗi nghiêm trọng; một danh sách lệnh rỗng khi yêu cầu nằm ngoài phạm vi lại có thể là hành vi đúng.
Trích xuất dữ liệu cũng cần phân biệt cú pháp và nội dung. Cactus cho biết ngữ pháp giải mã bảo đảm đầu ra có thể được phân tích cú pháp. Điều đó giúp ứng dụng nhận được JSON đúng dạng, nhưng không tự chứng minh mọi trường dữ liệu đều đúng nghĩa. Phần mềm vẫn cần kiểm tra giá trị trước khi lưu hoặc dùng nó để ra quyết định.
Không cần AI HAT, nhưng vẫn cần môi trường triển khai phù hợp

Với tác vụ hẹp, tận dụng CPU sẵn có đáng cân nhắc trước khi bổ sung phần cứng tăng tốc. Needle 3 dùng cách tổ chức mô hình cho phép chọn mạng con theo độ sâu. Cactus gọi đây là một thang năng lực: người triển khai lựa chọn kích thước phù hợp với thiết bị và tác vụ, thay vì luôn phải chạy toàn bộ mô hình.

| Đặc điểm | Needle 3 |
|---|---|
| Độ sâu có thể chọn | 2–20 lớp |
| Dung lượng binary được công bố | 8–29 MB |
| Quy mô tham số | 29–121 triệu |
| Lượng tử hóa | CQ2-bit |
| Engine triển khai | Dưới 1 MB |
| Dữ liệu huấn luyện được công bố | 360 tỷ token dữ liệu có cấu trúc |
Số liệu: Cactus Compute. Phần mô tả kiến trúc trên cùng trang nêu binary 9–29 MB, trong khi phần giới thiệu nêu 8–29 MB; cần kiểm tra artifact cụ thể khi triển khai.

Khả năng chọn mạng con tạo thêm lựa chọn, nhưng không có nghĩa bản nhỏ nhất phù hợp mọi bộ công cụ. Cần kiểm tra độ chính xác trên những câu lệnh thật sẽ sử dụng. Tiết kiệm thêm dung lượng không đáng đánh đổi nếu ứng dụng phải yêu cầu người dùng sửa lệnh thường xuyên hoặc chọn sai hành động.
Thiết lập XDA sử dụng Pi 5 8GB, DietPi và bản Needle 3 đầy đủ 20 lớp, build cho nền tảng linux-arm64. Quá trình chuẩn bị bao gồm môi trường Python riêng cùng các gói phụ thuộc. Vì vậy, mô hình nhỏ không đồng nghĩa người dùng chỉ tải một tệp rồi có ngay trợ lý nhà thông minh hoàn chỉnh.
Khả năng tương thích kiến trúc cũng là điều kiện cần kiểm tra trước khi tái sử dụng bo mạch cũ. XDA ghi nhận thử nghiệm trên Pi Zero đời đầu không build được do kiến trúc ARMv6 không được hỗ trợ. Đừng suy từ chữ “thiết bị nhỏ” sang việc mọi phiên bản Pi đều chạy được cùng một binary. Với Pi đang vận hành dịch vụ khác, thử trong môi trường Python tách biệt cũng giúp tránh thay đổi phụ thuộc của hệ thống hiện có.
Tốc độ token không phải thời gian ổ cắm phản hồi

Một con số token/giây không đủ để dự đoán cảm giác điều khiển thiết bị. Prefill là giai đoạn xử lý đầu vào; decode là giai đoạn sinh đầu ra. Sau đó, ứng dụng còn phải thực thi hàm, giao tiếp với dịch vụ và chờ thiết bị phản hồi. Dùng tốc độ sinh token làm thời gian hoàn tất hành động sẽ bỏ qua phần sau của chuỗi này.

| Phép đo (cao hơn tốt hơn) | Needle 3 — Pi 5, Cactus công bố | Needle 3 20 lớp — Pi 5 8GB, XDA đo |
|---|---|---|
| Decode (token/giây) | 400–4.000 | 280,2 |
| Prefill (token/giây) | 1.000–10.000 | 996,4 |
Số liệu: Cactus Compute và XDA Developers, với phép đo XDA đạt decode 280,2 và prefill 996,4 token/giây. Đây không phải phép thử đối chứng; không đánh dấu bên thắng do điều kiện và cấu hình chưa đồng nhất.
Cactus công bố một dải tốc độ cho Pi 5, còn XDA đo một lần triển khai bản 20 lớp trên DietPi với lệnh điều khiển smart plug. Không thể lấy đầu trên của dải công bố để hứa hẹn tốc độ cho cấu hình đó. Cũng chưa đủ cơ sở kết luận nguyên nhân chênh lệch nằm ở hệ điều hành, độ sâu mô hình hay cách đếm token khi các điều kiện đo chưa được chuẩn hóa.
Điều có thể rút ra là tác vụ gọi công cụ không cần sinh một bài văn dài. Đầu ra ngắn giúp một mô hình nhỏ trở nên hữu dụng, nhưng tốc độ chỉ là một phần của tiêu chí. Một hệ thống điều khiển đáng tin phải phản hồi đúng và từ chối đúng, chứ không chỉ sinh JSON nhanh.
Phép trình diễn Needle 2 cho thấy rõ giới hạn của chỉ số độ trễ. Các số dưới đây thuộc Needle 2, gói cactus-needle 2.0.7, chạy CPU trên Pi 5 8GB với Pi OS. Chúng được giữ riêng để giải thích phương pháp đo, không dùng làm benchmark Needle 3.
Thời gian chọn hàm (ms, thấp hơn tốt hơn)
| Phép thử — Thời gian chọn hàm (ms, thấp hơn tốt hơn) | Needle 2 — Pi 5 8GB |
|---|---|
| Bật LED | 78 |
| Đọc nhiệt độ | 149 |
| Nhấp nháy LED | 83 |
| Chụp ảnh | 76 |
| Lưu ghi chú | 107 |
| Hỏi thủ đô nước Pháp (không chọn hàm) | 92 |
Prefill (token/giây, cao hơn tốt hơn)
| Phép thử — Prefill (token/giây, cao hơn tốt hơn) | Needle 2 — Pi 5 8GB |
|---|---|
| Bật LED | 488 |
| Đọc nhiệt độ | 487 |
| Nhấp nháy LED | 475 |
| Chụp ảnh | 461 |
| Lưu ghi chú | 475 |
| Hỏi thủ đô nước Pháp (không chọn hàm) | 470 |
Decode (token/giây, cao hơn tốt hơn)
| Phép thử — Decode (token/giây, cao hơn tốt hơn) | Needle 2 — Pi 5 8GB |
|---|---|
| Bật LED | 296 |
| Đọc nhiệt độ | 303 |
| Nhấp nháy LED | 314 |
| Chụp ảnh | 248 |
| Lưu ghi chú | 305 |
| Hỏi thủ đô nước Pháp (không chọn hàm) | 297 |
Số liệu: Raspberry Pi, trình diễn Needle 2 trên Pi 5 8GB cùng Cactus Compute. Token/giây là bộ đếm phiên; thời gian tính cho một lần complete(), trước khi hàm Python chạy.
Lệnh chụp ảnh mất 76 ms ở bước chọn hàm không có nghĩa ảnh đã chụp và lưu xong sau 76 ms. Đây là khác biệt cần giữ khi so sánh trợ lý điều khiển với nút bấm hoặc tự động hóa thông thường. Trong thử nghiệm của chính mình, nên đo cả thời gian từ lúc gửi câu lệnh đến khi hành động hoàn tất, đồng thời ghi nhận số lần chọn sai hoặc từ chối.
29 MB không phải ngân sách RAM của cả ứng dụng

Dung lượng tệp mô hình chỉ mô tả một phần hệ thống. Khi triển khai còn có engine, bộ nhớ phục vụ suy luận, trình thông dịch và các thư viện ứng dụng. Home Assistant hoặc dịch vụ mà công cụ gọi đến cũng có nhu cầu tài nguyên riêng. Vì thế, không nên lấy 29 MB làm cam kết tổng RAM.
Ví dụ Needle 2 do Raspberry Pi công bố có phiên native khoảng 28 MB, nhưng cả tiến trình Python đạt đỉnh 43–46,4 MB. Hai con số này thuộc phiên bản và môi trường khác với thử nghiệm Needle 3. Chúng không cho biết mức RAM của Needle 3, nhưng cho thấy việc cộng thêm lớp ứng dụng làm thay đổi cách đọc con số “mô hình nhỏ”.
Cần phân biệt cả dung lượng tải về khi cài đặt và dung lượng cần ở lúc chạy. Môi trường chuẩn bị mô hình có thể chứa các gói phục vụ công việc khác nhau; không nên coi toàn bộ chúng là kích thước binary triển khai. Ngược lại, kích thước binary gọn cũng không xóa nhu cầu quản lý phụ thuộc và cập nhật phần mềm.
Với người đã có Pi 5 làm máy chủ tại nhà, lựa chọn thực dụng là đo tài nguyên của toàn tiến trình trong lúc sử dụng, thay vì mua bo mạch theo dung lượng mô hình. Không cần AI HAT cho thử nghiệm gọi công cụ này là một lợi thế về phần cứng; mức tài nguyên còn dư khi chạy chung dịch vụ mới quyết định hệ thống có phù hợp vận hành lâu dài không.
Quyền của hàm Python mới quyết định mức độ an toàn

Chạy AI cục bộ giảm nhu cầu gửi câu yêu cầu lên dịch vụ ngoài, nhưng không giới hạn quyền của đoạn mã thực thi. Nếu ứng dụng cho phép một hàm thao tác rộng, mô hình chọn nhầm vẫn có thể tạo ra hậu quả rộng. Ranh giới bảo vệ phải nằm ở công cụ và lớp kiểm tra phía sau nó.
Trong ví dụ smart plug, phần mềm gọi Home Assistant qua URL nội bộ và token truy cập dài hạn. Hàm điều khiển cố định thực thể switch.smart_plug, rồi chuyển trạng thái bật hoặc tắt thành lời gọi dịch vụ. Cấu trúc này dễ kiểm soát hơn việc để mô hình tự điền bất kỳ địa chỉ thiết bị hoặc tên dịch vụ nào: phạm vi hành động đã được thu hẹp trước khi xử lý ngôn ngữ.
Hướng mở rộng sang quản lý Docker càng cần giữ cách giới hạn đó. Nên cung cấp từng hành động có mục đích rõ và kiểm tra tham số, thay vì mở một hàm chạy lệnh tùy ý. Đây là khuyến nghị thiết kế, không phải tính năng an toàn mặc định của Needle. Với thao tác khó hoàn tác, lớp ứng dụng cần yêu cầu xác nhận trước khi thực thi.
Cactus mô tả mỗi phản hồi có điểm tin cậy và ngưỡng mặc định 0,1: lời gọi dưới ngưỡng bị giữ lại. Hãng cũng hỗ trợ trigger theo biểu thức chính quy để buộc yêu cầu khớp đi đến công cụ. Trường hợp trigger đáng chú ý vì lời gọi vẫn có thể được tạo ra dưới ngưỡng tin cậy. Người triển khai phải quyết định dùng điểm số để hỏi lại hay thực thi; không nên coi việc đã có function_calls là bằng chứng đủ để hành động.
Token truy cập cần được bảo vệ như thông tin xác thực của phần mềm điều khiển, không đưa vào câu yêu cầu gửi cho mô hình hay chia sẻ trong script công khai. Suy luận diễn ra trên máy cũng không bảo đảm toàn bộ chuỗi hoạt động không dùng mạng: lời gọi Home Assistant vẫn đi qua kết nối giữa các thiết bị. Nếu công cụ được viết để gọi dịch vụ đám mây, phần hành động đó vẫn phụ thuộc dịch vụ đám mây.
Người dùng Việt nên thử khả năng hiểu lệnh trước khi mở rộng

Giá trị thực dụng với người dùng Việt nằm ở khả năng điều khiển bằng cách nói tự nhiên, nhưng không nên suy từ ví dụ tiếng Anh sang độ chính xác tiếng Việt. Các phép thử đang được công bố ở đây chưa cho một bộ kết quả đủ để đánh giá việc hiểu câu lệnh tiếng Việt. Trước khi dùng hằng ngày, cần thử đúng cách đặt tên phòng và thiết bị trong ngôi nhà của mình.
Đây cũng là lý do không nên thay mọi tự động hóa cố định bằng AI. Tác vụ có lịch rõ hoặc điều kiện cảm biến rõ vẫn phù hợp với quy tắc thông thường. Needle đáng thử khi người dùng muốn diễn đạt một yêu cầu theo nhiều cách, còn ứng dụng đã có sẵn một số hành động được định nghĩa hẹp. Phần hiểu ngôn ngữ bổ sung sự linh hoạt; nó không thay thế logic điều khiển.
Với người đang chạy Home Assistant trên Pi, nên bắt đầu bằng công cụ ít rủi ro, kiểm tra kết quả và giữ phương thức điều khiển trực tiếp. Cần thử cả câu thiếu thông tin, tên thiết bị dễ nhầm và yêu cầu nằm ngoài phạm vi. Một trợ lý chỉ hoạt động đúng khi câu lệnh giống mẫu trình diễn chưa đủ để dùng làm giao diện chính.
Needle 3 đáng chú ý vì cho thấy AI cục bộ có thể hữu ích bằng cách thu hẹp nhiệm vụ. Lý do để thử nó là có một công việc gọi công cụ cụ thể cần lớp hiểu ngôn ngữ, không phải chỉ vì tệp mô hình nhỏ. Khi mở rộng ứng dụng, nên mở rộng từng quyền đã kiểm tra được; đừng để tốc độ phản hồi biến thành lý do bỏ qua xác nhận hành động.
Nguồn tham khảo: Cactus Compute, XDA Developers, Raspberry Pi







