Hệ sinh thái LLM cục bộ không cần Ollama

 (sleepingrobots.com)
26 điểm bởi GN⁺ 5 ngày trước | 3 bình luận | Chia sẻ qua WhatsApp
  • Ollama từng là công cụ giai đoạn đầu giúp đơn giản hóa việc chạy LLM cục bộ, nhưng về sau đã đánh mất niềm tin vì che giấu nguồn gốc và chuyển hướng sang lấy đám mây làm trung tâm
  • Công lao của động cơ cốt lõi llama.cpp bị xem nhẹ, và khi chuyển sang backend ggml tự phát triển thì đã phát sinh suy giảm hiệu năng và tái xuất hiện lỗi cũ
  • Cộng đồng tiếp tục chỉ trích vì gây hiểu lầm về tên mô hình, phát hành ứng dụng GUI không công khai mã nguồn, và cấu trúc Modelfile kém hiệu quả
  • Nút thắt ở registry mô hình, lỗ hổng bảo mật, và cấu trúc khóa chặt theo nhà cung cấp mâu thuẫn với triết lý ưu tiên cục bộ
  • Các lựa chọn mã nguồn mở như llama.cpp, LM Studio, Jan đã cung cấp hiệu năng và độ minh bạch cao hơn, đồng thời trở thành trung tâm của hệ sinh thái LLM cục bộ

Vấn đề của Ollama và các lựa chọn thay thế trong hệ sinh thái LLM cục bộ

  • Nguồn gốc và vai trò ban đầu của Ollama

    • Ollama được chú ý như trình wrapper cho llama.cpp đầu tiên giúp đơn giản hóa việc chạy LLM cục bộ
      • Người dùng có thể chạy mô hình mà không cần tự biên dịch C++ hay thiết lập máy chủ
    • Sau đó, dự án dần che giấu nguồn gốc, gây hiểu nhầm cho người dùng, và rời xa triết lý lấy cục bộ làm trung tâm để chuyển sang cấu trúc lấy đám mây làm trung tâm dựa trên vốn đầu tư mạo hiểm
    • Hai nhà sáng lập là Jeffrey Morgan và Michael Chiang, trước đó từng phát triển Kitematic, GUI cho Docker, rồi được Docker Inc. mua lại
    • Xuất thân từ Y Combinator (W21), ra mắt công khai vào năm 2023 và tự định vị là “Docker for LLMs”

  • Ghi nhận công lao không thỏa đáng đối với llama.cpp

    • Khả năng suy luận của Ollama phụ thuộc hoàn toàn vào llama.cpp của Georgi Gerganov
    • Trong hơn 1 năm, README, website và tài liệu marketing đều không hề nhắc đến llama.cpp, thậm chí cả thông báo giấy phép MIT cũng bị bỏ sót
    • Issue yêu cầu tuân thủ giấy phép của cộng đồng (#3185) không được phản hồi suốt hơn 400 ngày
    • Sau đó, đồng sáng lập chỉ thêm đúng một dòng ở cuối README: “llama.cpp project founded by Georgi Gerganov”
    • Phía Ollama nói rằng “chúng tôi đã thực hiện nhiều bản vá và sẽ dần chuyển sang động cơ riêng”, qua đó cố ý giảm nhẹ phần ghi nhận công lao

Chuyển sang backend riêng và suy giảm hiệu năng

  • Đưa vào backend tùy biến dựa trên ggml

    • Vào giữa năm 2025, Ollama chuyển từ llama.cpp sang bản triển khai riêng dựa trên ggml
    • Lý do được đưa ra là để tăng độ ổn định, nhưng kết quả lại là tái đưa vào các lỗi vốn đã được sửa từ trước
    • Xuất hiện hàng loạt vấn đề như lỗi structured output, mô hình thị giác thất bại, và xung đột assertion của GGML
    • Các mô hình mới như GPT-OSS 20B không hoạt động hoặc gặp lỗi không hỗ trợ kiểu tensor
    • Gerganov trực tiếp chỉ ra rằng Ollama đã fork ggml không đúng cách

  • Kết quả so sánh hiệu năng

    • Benchmark của cộng đồng cho thấy llama.cpp nhanh hơn Ollama 1,8 lần (161 so với 89 tokens/s)
    • Trên CPU cũng tồn tại chênh lệch hiệu năng 30~50%
    • Trong bài test Qwen-3 Coder 32B, llama.cpp cho throughput cao hơn 70%
    • Nguyên nhân được cho là do kiến trúc daemon của Ollama, cơ chế offload GPU kém hiệu quả, và backend lỗi thời

Gây hiểu lầm về tên mô hình

  • Trường hợp DeepSeek-R1

    • Ollama ghi các mô hình rút gọn như DeepSeek-R1-Distill-Qwen-32B đơn giản là “DeepSeek-R1”
    • Dù không phải mô hình 671B tham số thật sự, nó vẫn dùng cùng một tên
    • Người dùng hiểu lầm rằng mình đã “chạy DeepSeek-R1 trên máy cục bộ”, từ đó ảnh hưởng đến danh tiếng của DeepSeek
    • Các GitHub issue liên quan (#8557, #8698) đều bị xử lý là trùng lặp rồi để đó chưa giải quyết
    • Hiện tại, ollama run deepseek-r1 vẫn chạy mô hình rút gọn

Ra mắt ứng dụng đóng

  • Phát hành GUI app không công khai mã nguồn

    • Tháng 7/2025, Ollama GUI app cho macOS và Windows được công bố
    • Ứng dụng được phát triển trong repository riêng tư, phát hành không kèm giấy phép và không công khai mã nguồn
    • Với một dự án từng duy trì hình ảnh mã nguồn mở, đây là bước chuyển mạnh sang hướng đóng
    • Cộng đồng nêu ra khả năng phụ thuộc AGPL-3.0 và lo ngại vi phạm giấy phép
    • Website đặt nút tải xuống cạnh liên kết GitHub, tạo ấn tượng như thể đây là phần mềm mã nguồn mở
    • Sau nhiều tháng im lặng, đến tháng 11/2025 mã mới được gộp vào repository chính
    • XDA chỉ trích rằng “một dự án tự nhận là mã nguồn mở cần nói rõ việc có công khai hay không”

Sự kém hiệu quả của Modelfile

  • Trùng lặp với định dạng GGUF

    • Định dạng GGUF đã chứa toàn bộ thông tin cần thiết để chạy mô hình trong một tệp duy nhất
    • Ollama lại bổ sung thêm một tệp cấu hình riêng tên là Modelfile, có cấu trúc tương tự Dockerfile
    • Nó định nghĩa lặp lại những thông tin đã có trong GGUF, gây ra độ phức tạp không cần thiết
    • Ollama chỉ tự nhận diện danh sách template được hardcode, còn template mới thì bị bỏ qua
    • Kết quả là định dạng chỉ dẫn của mô hình bị hỏng, và người dùng phải tự chuyển đổi thủ công

  • Chỉnh sửa tham số kém hiệu quả

    • Khi thay đổi tham số, người dùng phải trích xuất bằng ollama show --modelfile, chỉnh sửa rồi tạo lại bằng ollama create
    • Trong quá trình này, toàn bộ mô hình 30~60GB bị sao chép lại
    • Cộng đồng chỉ trích đây là cách làm “kém hiệu quả và tạo bản sao không cần thiết”
    • Trong llama.cpp, tham số có thể điều chỉnh đơn giản bằng đối số dòng lệnh

  • Vấn đề tương thích template

    • Ollama dùng cú pháp template của Go, không khớp với template Jinja mà các nhà làm mô hình thường dùng
    • LM Studio và llama.cpp hỗ trợ Jinja trực tiếp, còn Ollama thì cần chuyển đổi
    • Nhiều báo cáo cho thấy việc chuyển đổi lỗi gây ra hỏng định dạng hội thoại

Nút thắt của registry mô hình

  • Chậm trễ trong đăng ký mô hình

    • Dù mô hình mới đã được đưa lên Hugging Face, với Ollama vẫn phải được đóng gói và đăng ký thủ công thì mới dùng được
    • Các định dạng lượng tử hóa được hỗ trợ cũng bị giới hạn như Q4_K_M, Q8_0
    • Vì vậy, luôn có độ trễ từ lúc mô hình phát hành đến khi có thể dùng trên Ollama
    • Trong cộng đồng đã lan truyền các bài PSA khuyên rằng “muốn test model mới thì hãy dùng llama.cpp hoặc vLLM”

  • Hạn chế về lượng tử hóa

    • Ollama không hỗ trợ các dòng Q5, Q6, IQ
    • Khi người dùng yêu cầu, câu trả lời nhận được là “hãy dùng công cụ khác”
    • Dù đã có thể gọi trực tiếp Hugging Face bằng lệnh ollama run hf.co/{repo}:{quant}, dữ liệu vẫn bị sao chép vào kho hash nội bộ và không thể chia sẻ, đồng thời vấn đề template vẫn tiếp diễn

Chuyển hướng sang đám mây và vấn đề bảo mật

  • Đưa mô hình đám mây vào

    • Cuối năm 2025, Ollama bổ sung các mô hình được host trên đám mây
    • Dù là công cụ vốn lấy cục bộ làm trung tâm, một số mô hình lại gửi prompt tới máy chủ bên ngoài
    • Khi dùng các mô hình bên thứ ba như MiniMax, dữ liệu có thể bị chuyển ra ngoài
    • Ollama ghi rõ rằng “không lưu log”, nhưng chính sách của bên thứ ba thì không rõ ràng
    • Với các mô hình dựa trên Alibaba Cloud, không có đảm bảo về việc lưu giữ dữ liệu

  • Lỗ hổng bảo mật

    • CVE-2025-51471: lỗ hổng cho phép máy chủ registry độc hại đánh cắp token xác thực
    • Đã có PR sửa lỗi nhưng không được hợp nhất suốt nhiều tháng
    • Với một công cụ lấy quyền riêng tư cục bộ làm giá trị cốt lõi, đây là vấn đề cấu trúc nghiêm trọng

Cấu trúc xoay quanh vốn đầu tư mạo hiểm

  • Mô hình lặp lại

    • Bọc một dự án mã nguồn mở để thu hút người dùng → gọi vốn → chuyển sang kiếm tiền
    • Các bước đi theo từng giai đoạn của Ollama
      • Khởi đầu là mã nguồn mở, xây trên nền llama.cpp
      • Giảm nhẹ nguồn gốc, đóng gói như một sản phẩm độc lập
      • Dùng registry và định dạng mô hình để tạo khóa chặt hệ sinh thái
      • Ra mắt GUI đóng
      • Đưa vào dịch vụ đám mây để kiếm tiền

  • Cấu trúc khóa chặt theo nhà cung cấp

    • Ollama lưu mô hình bằng tên tệp đã băm, khiến việc tương thích với công cụ khác trở nên khó khăn
    • Có thể nhập GGUF nhưng việc xuất ra lại được thiết kế bất tiện
    • Người dùng bị trói vào hệ sinh thái Ollama

Công cụ thay thế

  • llama.cpp

    • Cung cấp OpenAI-compatible API server (llama-server), web UI, khả năng điều khiển tham số chi tiết và throughput cao
    • Tháng 2/2026, ggml.ai gia nhập Hugging Face, giúp bảo đảm tính bền vững
    • Dựa trên giấy phép MIT, với hơn 450 người đóng góp

  • Các lựa chọn khác

    • llama-swap: hỗ trợ nạp nhiều mô hình và hot-swap
    • LiteLLM: cung cấp proxy tương thích OpenAI giữa nhiều backend
    • LM Studio: dựa trên GUI, dùng llama.cpp, tương thích đầy đủ với GGUF
    • Jan, Msty: ứng dụng desktop mã nguồn mở, thiết kế ưu tiên cục bộ
    • koboldcpp, Red Hat ramalama: chạy mô hình theo kiểu container, ghi rõ nguồn gốc minh bạch

Kết luận: hướng đi của hệ sinh thái LLM cục bộ

  • llama.cpp của Georgi Gerganov là nền tảng của làn sóng đổi mới AI cục bộ
    • Nhờ cộng đồng hợp tác, các mô hình mạnh có thể chạy được cả trên phần cứng phổ thông
  • Ollama đã phát triển trên nền tảng đó, nhưng đã đánh mất niềm tin vì che giấu nguồn gốc, suy giảm chất lượng, đóng lại và chuyển sang đám mây
  • Điều hệ sinh thái LLM cục bộ cần không phải là Ollama mà là llama.cpp
    • Tính mở thực sự và hiệu năng tốt hơn hiện đã được các công cụ do cộng đồng dẫn dắt cung cấp

Bài viết liên quan

3 bình luận

 
shblue21 4 ngày trước

Tôi khá đồng ý, và có vẻ như nếu muốn dùng cho ra hồn ở local thì LM Studio tốt hơn.
 
kirinonakar 4 ngày trước

Lúc đầu tôi cũng bắt đầu với Ollama, nhưng dạo gần đây tôi đã chuyển sang LM Studio từ lâu rồi.
 
GN⁺ 5 ngày trước
Ý kiến trên Hacker News

  • Hầu hết người dùng LLM cục bộ cho rằng Ollama đã giải quyết được vấn đề UX
    Có thể chạy mô hình chỉ với một dòng lệnh, và driver ROCm cũng được xử lý tự động
    Trong khi đó, llama.cpp ngay từ cái tên đã nghe như một thư viện C++, nên người dùng phổ thông khó tiếp cận
    Tôi chỉ không muốn phải tự build chương trình, mà chỉ muốn dùng thử cho vui thôi

    • Giờ đây llama.cpp về cơ bản đã có GUI. Trước đây thì không, nhưng thời thế đã khác rồi
    • Có nhiều lựa chọn thay thế như “LM Studio, Jan, Msty, koboldcpp…”, nhưng tôi muốn biết đâu mới là ứng viên kế nhiệm thực sự có thể thay thế Ollama
      Tôi dùng Mac Mini nhưng công cụ CLI cũng ổn. Điểm mạnh của Ollama là cài đặt dễ và tải mô hình thuận tiện, nên tôi kỳ vọng công cụ thay thế cũng phải tiện như vậy
    • Có người gợi ý kobold.cpp hoặc LM Studio. LM Studio không phải mã nguồn mở, nhưng có ghi công đầy đủ cho llama.cpp
      Tôi nghĩ kiểm soát chất lượng là rất quan trọng để tránh việc hỗ trợ mô hình bị tích hợp trong trạng thái hỏng hoặc GGUF sai bị tải lên
    • Đồng ý. Tình huống này khá giống Docker
      Tất nhiên bạn có thể dùng trực tiếp runc, nhưng đa số vẫn chọn docker run
      UX là yếu tố cốt lõi của việc tiếp nhận công nghệ, và nếu một dự án không làm tốt giao diện thì cũng chẳng có lý do gì để wrapper lại là điều xấu
    • Việc Ollama giải quyết được vấn đề UX không có nghĩa là được miễn trừ chuyện vi phạm giấy phép

  • Tôi đã mệt vì cứ phải lặp lại cùng một luận điểm, nên gom lại dòng thời gian và nguồn mà tôi biết trong một lần

    • Có người nói cảm ơn vì đã viết bài này. Tôi cũng có tham gia chút ít vào llama.cpp, và cách hành xử của những người sáng lập Ollama thực sự rất đáng thất vọng
      Về lựa chọn thay thế, tôi đề xuất llama-file. llamafile của Mozilla AI chạy trên mọi OS bằng một file thực thi duy nhất và hoàn toàn mã nguồn mở
      Nó dựa trên CosmopolitanC do Justine Tunney tạo ra, và sử dụng llama.cpp một cách chính thức
    • Có người nói đây là một bài viết rất có tính giáo dục đối với những ai coi trọng tinh thần FOSS
    • Có người nói đã biết thêm rất nhiều điều mà trước đây không biết
    • Có người đánh giá phần tóm tắt và dòng thời gian rất xuất sắc

  • Tôi nghĩ Ollama tốt hơn về mặt dễ dùng gấp 1000 lần
    llama.cpp rất tuyệt, nhưng không thân thiện với người dùng phổ thông
    Tôi bắt đầu với Ollama nhưng đã chuyển sang llama.cpp để có các bản sửa lỗi mới nhất
    Dù vậy tôi vẫn dùng Ollama để quản lý mô hình. Nó tiện đến mức tôi tự viết script để quản lý thư mục cache

    • Bài blog nói rằng các lựa chọn thay thế rất trực quan, nhưng thực tế không phải vậy
      Nếu chỉ là ứng dụng chat đơn giản thì còn được, nhưng khi cần API tương thích OpenAI và quản lý mô hình thì mức độ dễ tiếp cận giảm hẳn
    • Đã có nhiều phàn nàn rằng context size mặc định của Ollama quá nhỏ nên mô hình trở nên ngớ ngẩn
      Muốn thay đổi liên tục thì phải tạo file mô hình mới, mà như vậy còn phức tạp hơn
      Cách tiếp cận kiểu Docker lại bất tiện với người dùng phổ thông, còn người dùng nâng cao thì llama.cpp tốt hơn
    • Nhân tiện, giờ llama.cpp đã có chế độ router để thay đổi mô hình theo thời gian thực
    • Các phiên bản gần đây đã mạnh hơn nhiều. Có thể xem tại llama.cpp tools/serv
    • Tôi đã dùng LM Studio từ 3 năm trước, và ngay khi đó nó đã tốt hơn Ollama rất nhiều rồi

  • Có người tóm lược hai cách nhìn về giấy phép MIT

    1. “Chỉ cần ghi công một dòng thì muốn làm gì cũng được”
    2. “Về mặt pháp lý thì tự do, nhưng vẫn có trách nhiệm đạo đức với cộng đồng”
      Người tạo ra llama.cpp là Georgi Gerganov chỉ bày tỏ sự không hài lòng về việc thiếu ghi công. Tức là ông ấy hành động gần với cách hiểu thứ nhất hơn
    • Tôi nghĩ cách hiểu thứ hai không hợp lý. Nếu muốn có nghĩa vụ GPL thì cứ dùng GPL
      MIT là văn bản pháp lý chứ không phải hướng dẫn đạo đức
      Cá nhân tôi cho rằng phần mềm hướng tới người dùng thì nên dùng GPL
      Dùng MIT rồi sau đó lại than phiền việc công ty mang mã đi dùng là mâu thuẫn
      Tôi cho rằng công ty không có đạo đức, chỉ con người mới có
    • Nếu Georgi muốn, ông ấy hoàn toàn có thể chuyển sang GPL bất cứ lúc nào. Nhưng ông ấy đã không làm vậy
      Cuối cùng cả hai dự án đều tiếp tục phát triển, và người dùng có thêm nhiều lựa chọn hơn

  • Trước đây nó khá bất tiện vì không thể đổi thư mục mô hình mặc định
    Muốn đăng ký mô hình thì phải trải qua quy trình giống Dockerfile, và mô hình bị sao chép vào bộ nhớ hash nên không thể đổi vị trí
    Vì thế tôi đã chuyển sang LM Studio. Nó không hoàn toàn mã nguồn mở, nhưng cho phép lộ thư mục mô hình và tích hợp với Hugging Face

    • Giờ thì làm được rồi. Có thể chỉ định đường dẫn bằng biến môi trường OLLAMA_MODELS trong file cấu hình máy chủ
    • Tôi cũng từng khổ sở vì chuyện này. Tôi muốn so sánh với LM Studio trước và sau khi nâng cấp SSD, nhưng quá trình tìm vị trí mô hình và sắp xếp lại chúng phức tạp và đau đầu một cách không cần thiết

  • Vì Ollama sao chép file mô hình vào bộ nhớ blob băm, nên không thể chia sẻ với công cụ khác
    Có lẽ đây là thiết kế để khử trùng lặp, nhưng kết quả là khiến việc thử công cụ khác trở nên khó khăn hơn
    Vì file mô hình rất lớn nên dung lượng lưu trữ và tải xuống là gánh nặng đáng kể

  • Trên Arch Linux, pacman -Ss ollama cho ra 16 kết quả, nhưng llama.cpp hay lmstudio thì ra 0
    Mong một ngày nào đó điều này sẽ thay đổi

    • llama.cpp cập nhật quá nhanh nên khó trở thành gói ổn định, nhưng vẫn có thể cài từ AUR
      Đều hỗ trợ các bản Vulkan, ROCm và CUDA
    • Trong khi đó trên openSUSE, có thể tìm llamacpp bằng zypper
      Mỗi bản phân phối có phiên bản và mức hỗ trợ khác nhau, và rốt cuộc đó chính là lý do tồn tại của vô số bản phân phối Linux
    • Tôi đã cài bằng yay -S llama.cpp trên CachyOS, và nó nhanh hơn nhiều, tốt hơn Ollama

  • Cái tên “llama.cpp” giờ nghe không còn thân thiện nữa
    Trước đây nó gắn với mô hình Llama của Meta, nhưng giờ đã có nhiều mô hình mã nguồn mở mạnh hơn

  • Tôi đã tránh Ollama ngay từ đầu vì nó có mùi muốn kiểm soát toàn bộ workflow
    Kết quả là tôi nghĩ đó đúng là một lựa chọn sáng suốt

  • Cấu trúc lưu trữ blob băm của Ollama là cái bẫy lớn nhất
    Nếu đã tải mô hình trong vài tháng, thì khi chuyển sang công cụ khác sẽ phải tải lại toàn bộ
    Phần lớn người dùng chỉ nhận ra điều này sau khi đã đầu tư khá sâu, và lúc đó mới cảm thấy chi phí rời bỏ rất lớn