Mọi thứ đều trên máy cục bộ – Hành trình xây dựng workspace AI offline

 (instavm.io)
6 điểm bởi GN⁺ 2025-08-09 | 2 bình luận | Chia sẻ qua WhatsApp
  • Chạy LLM cục bộ và môi trường sandbox mã để xây dựng workspace AI mà không cần phụ thuộc vào cloud.
  • Khởi chạy LLM cục bộ bằng Ollama, dùng Apple Container để chạy code trong VM cách ly, và cho phép tự động hóa cùng truy cập internet qua trình duyệt headless với Playwright.
  • UI dựa trên assistant-ui, ngoài ra triển khai dropdown chọn mô hình và tích hợp ai-sdk, cùng môi trường chạy code an toàn thông qua MCP(Model Context Protocol).
  • Trong VM Coderunner được kết nối bằng MCP, chạy máy chủ Jupyter và trình duyệt để xử lý tạo biểu đồ, chỉnh sửa ảnh/video, cài công cụ GitHub và tìm kiếm web trong trạng thái bảo vệ quyền riêng tư.
  • Hiện tại chỉ hoạt động trên Apple Silicon; các việc cần làm tiếp theo là cải thiện UI, tránh phát hiện trình duyệt, và tăng cường khả năng quản lý công cụ.

Yêu cầu và bối cảnh

  • Mục tiêu: Thực thi tất cả mọi thứ cục bộ, không cần chạy code trên cloud hoặc từ xa.
  • Các ứng dụng chat LLM hiện tại (ví dụ: ChatGPT, Claude) cung cấp chat LLM dựa trên cloud, chạy code cloud/cục bộ, và khả năng truy cập internet.
  • Khi việc dùng LLM mã nguồn mở tăng mạnh, tác giả tự hỏi có thể thực hiện toàn bộ các chức năng này hoàn toàn cục bộ hay không.
  • Chỉ với LLM cục bộ thì chưa đủ, nên code cần phải chạy trong môi trường cô lập và vẫn cần truy cập nội dung qua trình duyệt.

Ý tưởng ban đầu

  • Chạy LLM hoàn toàn trong môi trường cục bộ.
  • Xử lý việc thực thi code chỉ trong VM nhẹ để chặn rủi ro cho hệ thống host.
  • Bổ sung trình duyệt headless nhằm hỗ trợ tự động hóa, tiếp cận thông tin mới và khám phá công cụ.
  • Xây dựng workflow với trọng tâm bảo vệ quyền riêng tư, từ lập kế hoạch AI đến thực thi code, tất cả diễn ra cục bộ.
  • Có thể làm nhiều tác vụ như chỉnh sửa ảnh, video ngay tại local mà không gửi dữ liệu cho dịch vụ bên ngoài.

Ngăn xếp công nghệ

  • LLM: Ollama (hỗ trợ mô hình cục bộ và một số mô hình bên ngoài).
  • UI: assistant-ui + ai-sdk (thêm chức năng chọn mô hình).
  • Runtime VM: Apple container (cung cấp môi trường VM cách ly).
  • Orchestration: instavm/coderunner (kết nối máy chủ Jupyter qua MCP).
  • Tự động hóa trình duyệt: Playwright (mở dưới dạng công cụ MCP).

Thử nghiệm ứng dụng Mac và chuyển đổi

  • Đã thử phát triển ứng dụng Mac native bằng a0.dev, nhưng gặp khó khăn vì tập trung chủ yếu cho iOS.
  • Việc đóng gói Electron + NextJS cũng được thử nhưng đã bỏ vì vấn đề phức tạp.
  • Cuối cùng chuyển sang dùng assistant-ui web local.
Quảng cáo

Tùy biến Assistant-UI

  • Mong đợi sẽ hỗ trợ nhiều LLM như dropdown chọn model, nhưng thực tế bị giới hạn.
  • Sau khi tham khảo ví dụ, tự triển khai trực tiếp khả năng chọn nhiều mô hình thông qua ai-sdk.
  • Ban đầu cũng hỗ trợ mô hình cloud như OpenAI/Anthropic, với chiến lược dần dần chuyển sang cục bộ.

Vấn đề tool-calling và hỗ trợ mô hình

  • Cần model hỗ trợ tool-calling, nhưng một số model như Ollama thực tế không hỗ trợ.
  • Mặc dù tài liệu chính thức có ghi nhận hỗ trợ tool, nhưng khi triển khai thực tế lại thiếu nhiều phần.
  • Tốc độ thay đổi nhanh của hệ sinh thái mã nguồn mở khiến tình trạng hỗ trợ tool và giá token biến động lớn.

Chạy code cô lập dựa trên container

  • Dùng công cụ Container của Apple vì thay vì Docker, mỗi container đều có môi trường VM cách ly hoàn toàn, nên có thể chạy code do AI sinh ra an toàn hơn.
  • Triển khai máy chủ Jupyter trong môi trường VM, phơi ra qua MCP để các công cụ như Claude Desktop, Gemini CLI... có thể tận dụng ngay.
  • Công khai mã MCP server của coderunner, cung cấp ví dụ tích hợp với công cụ bên ngoài.
  • Công cụ Apple Container vẫn chưa ổn định, nên khi gặp lỗi build/image cần khởi động lại nhiều lần.
  • Trong bài test chỉnh sửa video thực tế đã xác nhận hoạt động bình thường của combo UI + LLM + coderunner.

Tích hợp trình duyệt headless

  • Triển khai Playwright headless trong container và phơi ra như công cụ MCP.
  • Kỳ vọng ứng dụng cho việc khám phá công cụ/thông tin mới, tìm cách dùng GitHub, tự động hóa nghiên cứu...
  • Quy trình làm việc cơ bản đã hoàn tất: xây dựng combo LLM cục bộ + thực thi code sandbox + trình duyệt headless.

Ví dụ công việc có thể làm

  • Nghiên cứu và tóm tắt một chủ đề cụ thể.
  • Tạo và render biểu đồ CSV bằng lệnh ngôn ngữ tự nhiên.
  • Chỉnh sửa video bằng ffmpeg (cắt đoạn, ...).
  • Resize, cắt và chuyển đổi định dạng ảnh.
  • Cài đặt công cụ GitHub trong container.
  • Crawl web và tóm tắt bằng trình duyệt headless, v.v.
Quảng cáo

Gắn mount volume và cách ly file

  • Ánh xạ ~/.coderunner/assets của host sang container /app/uploads, file được lưu an toàn trong không gian chia sẻ.
  • Code đã chạy không thể truy cập trực tiếp hệ thống host, giúp tăng cường bảo mật.

Hạn chế và hướng phát triển tiếp

  • Apple Silicon là môi trường duy nhất, macOS 26 chỉ là tùy chọn.
  • Cần cải thiện UI cho quản lý công cụ, luồng output streaming...
  • Trình duyệt headless vẫn có tình trạng bị chặn do phát hiện bot trên một số trang.

Kết luận

  • Dự án này là một mô hình không chỉ là thử nghiệm, mà còn tập trung vào chủ quyền tính toán và bảo vệ quyền riêng tư.
  • Cung cấp trải nghiệm xử lý dữ liệu an toàn trên máy cục bộ cá nhân mà không phụ thuộc cloud hay máy chủ từ xa.
  • Mô hình LLM tốt nhất có thể vẫn nằm ở các cloud lớn, nhưng hướng tới phát triển công cụ AI cục bộ có thể bảo vệ quyền riêng tư cá nhân.
  • Mã nguồn mở coderunner-ui có thể dùng trên GitHub, xin chào đón phản hồi và cộng tác.

Tài nguyên liên quan

Bài viết liên quan

2 bình luận

 
wedding 2025-08-11

Tôi đồng ý với ý kiến rằng HN chỉ gần như là một sở thích vui vẻ.
Dù có thử trang trí, chỉnh sửa đủ kiểu, tôi vẫn không thể đạt được mức tiện lợi và tốc độ như bản thương mại.
 
GN⁺ 2025-08-09
Ý kiến trên Hacker News

  • Tôi luôn bị thu hút bởi tinh thần lý tưởng này, nhưng khi cân nhắc mức hiệu năng của mô hình mà tôi có thể tiếp cận cùng chi phí chạy theo nhu cầu trên cloud, tôi thấy đó gần như chỉ là một sở thích thú vị hơn là một chiến lược thực tế. Vì phần cứng phát triển ngày càng nhanh nên khi mua thiết bị đã qua sử dụng giá trị cũng giảm nhanh như vậy, nên đầu tư vào phần cứng thật sự khó có thể biện minh được. Thêm nữa, hiệu năng của trọng số chạy trong môi trường local cũng thấp hơn nhiều, vì vậy hiện giờ chưa thấy đáng làm. Tôi vẫn hy vọng sẽ đến lúc đó và sẽ hào hứng đầu tư cho stack suy luận local khi có các trọng số tốt được công khai. Cho đến khi thay đổi, mình sẽ cứ ôm một tài sản đắt đỏ mất giá nhanh.

  • Gần đây tôi thấy hệ sinh thái local LLM rất thú vị, và tôi thích xem mọi người đang làm gì. Nhưng mỗi lần tôi chạy LLM local trên RAM khủng của MacBook Pro, tôi lại cảm nhận rất rõ khoảng cách với các frontier model (LLM SaaS mới nhất). Với mức mất khoảng 20 USD/tháng, chỉ trả phí theo token, có thể dùng nhiều mô hình hiệu năng cao; về tốc độ và chất lượng thì local model vẫn còn cách xa. Chỉ nhìn biểu đồ benchmark thì khoảng cách này không lộ rõ, nhưng khi dùng thực tế Frontiers model vẫn tốt hơn hẳn. Các mô hình của OpenAI, Anthropic đôi khi có vẻ chậm và hay lỗi; khi chuyển sang local thì tình trạng ấy trầm trọng hơn. Với các nhu cầu giải trí hay thí nghiệm mà privacy quan trọng thì có thể ổn, nhưng với tôi, tốt hơn hết là đợi đến khi có phần cứng thật sự mạnh như RAM 128GB cho MacBook thế hệ sau.

  • Tôi nghĩ rằng khi các mô hình sau API bắt đầu kiếm tiền từ kết quả đầu ra thì chất lượng output sẽ dần kém đi. Tôi nghĩ đây chỉ là vấn đề thời gian.

  • Tôi tò mò về lập luận rằng “phần cứng thay đổi nhanh nên dù mua mới hay cũ cũng nhanh mất giá”. Trong một số trường hợp, tôi nghĩ mô hình có thể tiếp tục chạy ngay cả khi không phải cấu hình nhanh nhất. Đây cuối cùng là tranh cãi kinh điển giữa opex (chi phí vận hành) và capex (vốn đầu tư). Nếu nhìn thuần tài chính thì cloud chỉ có lợi trong trường hợp cực kỳ hiếm (khi cần dựng hạ tầng nhanh mà không dự đoán được nhu cầu). Với LLM thì chuyện này không thực sự áp dụng. OP nói mình đầu tư khoảng 600 USD, nhưng đây tương đương giá 3 tháng EC2. Với lý do này, tôi tò mò liệu có số liệu nào chứng minh cho lập luận của OP không.

  • Tôi cũng là người tin rằng nó sẽ thay đổi. Tôi gần đây dùng Claude Code ngày càng nhiều trong công việc, và không muốn phải phụ thuộc vào công ty cho công việc coding hằng ngày. Tôi không thích lo lắng về giới hạn gói, chi phí API, chuyện phải trả 100–200 USD mỗi tháng, và rủi ro dữ liệu tôi dùng bị thu thập hoặc giám sát bởi công ty AI. Tôi chỉ dùng các sản phẩm smart home có kiểm soát local, còn khi cần truy cập từ bên ngoài thì tự thiết lập phần mềm chạy trên server riêng. Khi công ty đột ngột dừng dịch vụ, tăng giá, hoặc dùng dữ liệu của tôi, tôi không muốn bị khóa chặt vào thứ đó. Nhưng hiện tại tôi không có động lực, chi phí, kiến thức, hay công sức để cài LLM trên phần cứng riêng hoặc VPS. Tôi hài lòng khi trả 20 USD/tháng cho Anthropic, và các model mở hiện có vẫn không thể sánh bằng các SaaS tầm frontier. Tôi vẫn hy vọng một ngày nào đó mọi thứ sẽ thay đổi.

  • Tôi nghĩ tình huống này sẽ không thay đổi. Ngay cả nếu sau 2 năm có tùy chọn local mức GPT-5, lúc đó cloud cũng sẽ có lựa chọn tốt hơn, nên cuối cùng vẫn quay lại cùng một băn khoăn.

  • Tôi đánh giá việc tập trung vào lớp thực thi local, được sandbox hóa trong công việc này là một mảnh ghép lớn để hiện thực hóa private AI workspace. Công cụ coderunner trông có vẻ rất hữu dụng. Nhưng thêm một thử thách nữa là ‘knowledge layer’ giúp AI nhận biết email, notes, file cá nhân của tôi. Với RAG, xử lý email nhiều năm có thể dễ dàng đẩy dung lượng vector DB vượt 50GB. (Mình là thành viên một nhóm ở Berkeley đang giải bài toán này.) Chúng tôi tạo chỉ mục vector LEANN và thực sự đã giảm lưu trữ khoảng 97% bằng cách không lưu trực tiếp embedding. Vì vậy, việc index toàn bộ cuộc sống số local đã trở nên khả thi. Kết hợp knowledge index cực nhẹ như vậy với local execution engine là con đường đến một ‘local Jarvis’ thực thụ, theo tôi. Code: https://github.com/yichuan-w/LEANN Bài báo: https://arxiv.org/abs/2405.08051

    • Theo tiêu chuẩn năm 2025, vector DB 50GB cho vài năm email thì tôi nghĩ đây vẫn là mức khiêm tốn.

    • Cảm ơn đã cho mình biết về LEANN. Tôi đặc biệt quan tâm đến việc sử dụng RAG như knowledge layer cho LLM agent, pipeline hay execution engine. Tôi muốn xem liệu có thể kết hợp LLM với codebase quy mô lớn không, và việc RAG đã tích hợp sẵn với Claude Code đã làm giảm trở ngại thử nghiệm nên tôi rất mong chờ. Tôi muốn hỏi liệu có ai đã thực sự làm việc với RAG + LLM trên một codebase lớn chưa. Với front-end model (LM), tôi sẽ bắt đầu từ cloud rồi tự thử. Tham khảo liên quan: https://github.com/yichuan-w/LEANN/blob/main/packages/leann-mcp/README.md

    • Tôi gần như không biết gì về cấu trúc embedding hay lưu trữ vector. Có dự án nào áp dụng cách “pruned graph” (graph đã được tỉa bớt) cho cloud embedding không?

    • Cảm giác khó chịu khi index lớn hơn cả dữ liệu gốc. Thông thường tôi nghĩ index tồn tại với định dạng hiệu quả hơn để truy cập nhanh, nên khi nó phình to như vậy thì hơi lạ.

  • Một trong những lý do LLM “top world” chưa giúp mượt như kỳ vọng là chúng thường bỏ qua bớt bước, bỏ qua các đặc thù nền tảng, và thậm chí còn làm vấn đề tệ hơn bằng những lời bịa. Điều này cho thấy thiếu hụt dữ liệu huấn luyện về phát triển ứng dụng native. Gần như không có blog hay bài Medium dài về thiết kế ứng dụng native, và số dự án desktop app mã nguồn mở ít hơn nhiều so với mobile/web. Thập niên 1990, Microsoft từng thuê các biên tập viên chuyên nghiệp và xuất bản các cuốn sách hay về coding Windows (điển hình là Charles Petzold), nhưng ngành nghề chuyên nghiệp như vậy giờ gần như biến mất. Vì vậy, theo tôi, khoảng trống trong training data sẽ còn giãn ra. Cuối cùng cũng giống xu hướng toàn ngành phần mềm: ít người muốn tạo ứng dụng desktop native, và trong định hướng sự nghiệp đây là con đường ‘đầu hàng’. Ở thập niên 1990, developer app desktop Windows từng được đảm bảo đời sống trung lưu dù rào cản cao (C/C++ khó, học Win API khó), vì Microsoft đổ rất nhiều tiền vào giáo dục. Giờ thì khác hẳn. Bây giờ ngoài các nhà cung cấp OS (Microsoft, Apple) hoặc một số nhà cung cấp legacy phần mềm (Adobe, Autodesk...), nhu cầu phát triển desktop app là cực kỳ thấp.

    • Ngoài các bài toán HPC, không cần tạo riêng desktop app vì browser gần như đã giữ vai trò VM phổ quát nhất.

  • Tôi đã thử ứng dụng Ollama trên macOS và ngay khi mở ra đã phát hiện nó cố gắng truy cập một domain của Google. Điều này khiến claims về privacy hoàn toàn trở nên khó tin. https://imgur.com/a/7wVHnBA

    • Do kiểm tra cập nhật tự động. https://github.com/ollama/ollama/blob/main/docs/faq.md

    • Với việc có thể audit các cuộc gọi network như vậy, tôi thậm chí cảm thấy có sự đáng tin hơn. Chỉ cần theo dõi tự động các cuộc gọi mạng mỗi lần update là quản lý được.

    • Tôi đã thấy hiện tượng này tương tự ở plugin cline và copilot trong vscode. Khi chỉ định dùng local ollama và chặn outbound connection, nó sẽ không hoạt động. Dù tắt telemetry trong settings, cline vẫn tiếp tục cố gắng giao tiếp bên ngoài khiến tôi thất vọng.

  • Tôi hay nghĩ tới chuyện này hơn mình tưởng. Tôi thấy bảo vệ privacy đi kèm rất nhiều ma sát và khó khăn.

    • Tôi không nghĩ bài này thực sự giúp được cho việc giải quyết hoặc đưa ra giải pháp cho vấn đề đó.

  • Tôi vẫn thích local, vì phần lớn tốc độ suy luận AI đều chậm hoặc gần như không khác nhau. Gần đây tôi dùng cerebras (và nghe nói groq cũng vậy), trải nghiệm tốc độ 1000 token/giây khiến ngưỡng chịu đựng chờ đợi của tôi thay đổi hoàn toàn. Cerebras nói là không lưu dữ liệu và tôi muốn bạn tin rằng tôi không có quan hệ tài trợ với họ (thậm chí còn mong có). Tôi thực sự nghĩ đây là dịch vụ tuyệt vời. Nhưng tôi vẫn mong rằng sẽ có tiến bộ đáng kể về tốc độ. Kiến trúc diffusion dường như đặc biệt nhanh.

  • Ở giai đoạn này, tôi nghĩ giới hạn nằm ở phần cứng hơn là phần mềm. Để chạy LLM local được thì cần tối thiểu phần cứng khoảng 2000 USD (ví dụ Strix Halo, AI Max 395). Tôi hy vọng khi Strix Halo có thêm vài lần nâng cấp, mọi thứ sẽ dễ hơn.

    • Sự thay đổi đang diễn ra rất nhanh. https://simonwillison.net/2025/Jul/29/space-invaders/

    • Ngay cả khi có phần cứng đúng mức giá, tôi vẫn nghĩ tiêu chuẩn “dùng được” tự nó mơ hồ. Để công nghệ này thực sự hữu dụng thì trải nghiệm gần như instant là bắt buộc. Khi bạn cứ phải chỉnh sửa liên tục vì gặp kết quả chậm và mơ hồ, gần như mất hết giá trị. Local model đã cải thiện rất nhiều, nhưng về độ thành thạo coding thì vẫn chưa đạt Claude. Gần đây tôi tự chạy OpenRouter model mới nhất Qwen, GLM với cline, cảm giác giống mức của Claude 3.0. Tôi không nghĩ benchmark phản ánh đúng thực tế.

  • Thương hiệu và bài blog của sản phẩm có vẻ rối mù. Trên website thì thấy họ dựng VM trên cloud (như Firecracker), trong khi bài blog đọc như chạy VM local cho Mac. Từ góc độ từng làm cái đầu tiên, tôi mong muốn dùng dạng thứ hai với sản phẩm mới của gpt-oss.

  • Với OP, tôi thông báo link https://github.com/assistant-ui/assistant-ui không hoạt động.

  • Tôi thấy đây là một dự án rất đẹp và thiết kế rất tốt. Mình cũng đang làm thứ tương tự, và điều cốt lõi là dễ dàng chuyển qua lại giữa cloud và local chỉ bằng một khóa. Tất cả dữ liệu/cài đặt/prompt đều chỉ lưu local, còn API call cũng được route trực tiếp đến nhà cung cấp mà không đi qua server của chúng tôi. Hiện giờ tôi chạy infer local hoàn toàn trong browser bằng mlc-llm (Qwen3-1.7b chạy rất tốt). https://hypersonic.chat/