AI cho doanh nghiệp: Tự động hoá quy trình bằng tool calling trên model local

AI cho doanh nghiệp đang chuyển từ giai đoạn “hỏi đáp thử nghiệm” sang bài toán thực tế hơn: để AI đọc ngữ cảnh, gọi đúng công cụ, trả kết quả về hệ thống và hỗ trợ nhân sự xử lý quy trình lặp lại. Với nhóm doanh nghiệp muốn kiểm soát dữ liệu và chủ động hạ tầng, hướng chạy model local kết hợp tool calling là một lựa chọn đáng cân nhắc.

Điểm quan trọng là doanh nghiệp không nên nhìn AI local như một model đơn lẻ. Một hệ thống hữu ích thường gồm model ngôn ngữ, API cục bộ, lớp truy hồi dữ liệu, công cụ nội bộ và phương pháp đo hiệu năng. Khi các mảnh này được ghép đúng, AI có thể hỗ trợ các tác vụ như tra cứu quy định, tóm tắt hồ sơ, tạo phiếu xử lý, gọi API quản trị hoặc chuyển yêu cầu cho phần mềm nghiệp vụ.

Mục lục bài viết

1. Tool calling là gì và vì sao phù hợp với tự động hoá doanh nghiệp?

2. Một kiến trúc AI local cơ bản cho doanh nghiệp

3. Vì sao cần đo hiệu năng trước khi triển khai?

4. Lượng tử hoá: Đánh đổi dung lượng và độ chính xác

5. Cập nhật hệ sinh thái local AI đáng chú ý trong tháng 8/2026

6. Framework và công cụ hỗ trợ xây dựng agent

7. Gợi ý lộ trình triển khai cho chủ doanh nghiệp

1. Tool calling là gì và vì sao phù hợp với tự động hoá doanh nghiệp?

Tool calling là cơ chế cho phép model không chỉ trả lời bằng văn bản, mà còn tạo ra một lời gọi công cụ có cấu trúc. Trong tài liệu API của Ollama, endpoint POST /api/chat hỗ trợ tool calling thông qua tham số tools chứa định nghĩa hàm; model sinh tool call có cấu trúc và kết quả được đưa lại vào lịch sử hội thoại.

Với chủ doanh nghiệp, có thể hiểu đơn giản: Thay vì nhân viên hỏi “Đơn hàng này đang ở trạng thái nào?” rồi tự mở phần mềm để kiểm tra, AI có thể nhận câu hỏi, xác định cần gọi hàm tra cứu đơn hàng, nhận kết quả từ hệ thống và trả lời lại bằng ngôn ngữ tự nhiên. Nếu triển khai cẩn thận, cùng một logic có thể mở rộng sang kiểm kho, tạo ticket, phân loại yêu cầu khách hàng hoặc lấy thông tin chính sách nội bộ.

Minh họa cho Tool calling

Ollama cung cấp REST API cục bộ mặc định tại http://localhost:11434, với các endpoint chính như POST /api/generate, POST /api/chat và POST /api/embed. Điều này tạo bề mặt tích hợp tương đối rõ ràng cho đội kỹ thuật khi muốn dựng một lớp AI chạy trong mạng nội bộ.

2. Một kiến trúc AI local cơ bản cho doanh nghiệp

Một mô hình triển khai dễ hình dung có thể gồm bốn lớp:

• Lớp model local: Chạy model qua runtime như Ollama hoặc llama.cpp tuỳ môi trường phần cứng.
• Lớp truy hồi dữ liệu: Dùng embedding để tìm tài liệu, chính sách, hồ sơ hoặc tri thức nội bộ liên quan trước khi model trả lời.
• Lớp tool calling: Định nghĩa các hàm được phép gọi, ví dụ tra cứu đơn hàng, lấy trạng thái tồn kho, tạo phiếu hỗ trợ hoặc kiểm tra dữ liệu khách hàng.

• Lớp kiểm soát: Ghi log, phân quyền, giới hạn hành động, đo độ trễ và kiểm thử trước khi đưa vào vận hành.

Ollama có endpoint POST /api/embed để sinh embedding từ một hoặc nhiều đoạn văn bản, đảm nhiệm phần truy hồi của một stack RAG chạy cục bộ. Đây là mảnh quan trọng nếu doanh nghiệp muốn AI trả lời dựa trên tài liệu nội bộ thay vì chỉ dựa vào kiến thức có sẵn của model.

Ngoài các API sinh nội dung và embedding, Ollama còn cung cấp nhóm endpoint quản trị model như GET /api/tags để liệt kê model đã có, GET /api/ps để xem model đang nạp trong bộ nhớ, cùng các endpoint POST /api/show, POST /api/pull, POST /api/create và DELETE /api/delete. Với đội IT, nhóm endpoint này giúp kiểm soát vòng đời model trong môi trường thử nghiệm hoặc nội bộ.

3. Vì sao cần đo hiệu năng trước khi triển khai?

Trong môi trường doanh nghiệp, câu hỏi không chỉ là “Model có chạy được không?”, mà là “Model có phản hồi đủ nhanh cho quy trình thực tế không?”. Một trợ lý nội bộ có thể chấp nhận chờ lâu hơn chatbot chăm sóc khách hàng; một tác vụ phân tích hồ sơ hàng loạt lại cần thông lượng ổn định hơn phản hồi tức thì.

llama-bench là công cụ đo hiệu năng trong hệ sinh thái llama.cpp. Công cụ này báo kết quả theo tokens/giây, kèm trung bình và độ lệch chuẩn qua nhiều lần lặp, mặc định 5 lần. Tài liệu cũng nêu rõ phép đo không tính thời gian tokenization và sampling, vì vậy doanh nghiệp cần hiểu phạm vi số đo trước khi dùng để ra quyết định.

llama-bench tách hai chế độ đo khác bản chất: prompt processing, ký hiệu pp, mặc định 512 token; và text generation, ký hiệu tg, mặc định 128 token; ngoài ra còn có chế độ kết hợp pg. Với bài toán doanh nghiệp, prompt processing thường liên quan đến việc nạp ngữ cảnh dài, còn text generation phản ánh tốc độ sinh câu trả lời.

Ở cấp benchmark tiêu chuẩn hơn, MLPerf Client v1.6 phát hành ngày 06/04/2026 đo workload LLM chạy cục bộ trên PC qua nhiều backend như Windows ML, llama.cpp trên Windows và macOS, MLX với Metal, và llama.cpp với Metal. MLPerf Client báo cả tính đáp ứng lẫn thông lượng; trong đó time to first token, hay TTFT, là thời gian chờ trước token đầu tiên và giá trị thấp hơn là tốt hơn.

4. Lượng tử hoá: Đánh đổi dung lượng và độ chính xác

Khi chạy AI local, lượng tử hoá là khái niệm doanh nghiệp sẽ gặp rất sớm. Mục tiêu là giảm dung lượng và tài nguyên cần thiết để chạy model, đổi lại có thể ảnh hưởng đến độ chính xác hoặc chất lượng đầu ra tuỳ phương pháp và mức nén.

Đặc tả GGUF định nghĩa nhiều họ lượng tử hoá, gồm nhóm legacy như F32, F16, Q4_0, Q4_1, Q5_0, Q5_1, Q8_0, Q8_1; nhóm K-series như Q2_K, Q3_K, Q4_K, Q5_K, Q6_K, Q8_K; nhóm IQ như IQ2_XXS, IQ3_XXS, IQ4_NL; cùng các định dạng BF16, MXFP4, TQ1_0, TQ2_0. Điều này cho phép đội kỹ thuật đánh đổi dung lượng lấy độ chính xác theo nhu cầu.

GGUF cũng được thiết kế để triển khai một file duy nhất, hỗ trợ nạp bằng mmap, và tự chứa đầy đủ thông tin cần thiết để load model gồm cả tokenizer. Với vận hành nội bộ, đặc tính “một file” giúp đơn giản hoá việc đóng gói, kiểm soát phiên bản và phân phối model trong môi trường thử nghiệm.

Một hướng lượng tử hoá khác là AWQ, phương pháp lượng tử hoá trọng số có nhận biết activation. Repo của MIT Han Lab cho biết AWQ hỗ trợ INT3/INT4 với activation 16-bit, tức W4A16; đồng thời công bố nhanh hơn FP16 khoảng 2,7 lần trên RTX 4090 và 2,9 lần trên Jetson Orin với LLaMA-3-8B. Công trình này đạt Best Paper Award tại MLSys 2024. Tuy nhiên, doanh nghiệp không nên xem các con số này là kết quả đảm bảo cho mọi model và mọi cấu hình, mà nên benchmark lại trên chính workload của mình.

5. Cập nhật hệ sinh thái local AI đáng chú ý trong tháng 8/2026

Hệ sinh thái AI local thay đổi rất nhanh, đặc biệt ở runtime, backend phần cứng và hỗ trợ model mới. Với doanh nghiệp, các mốc phát hành là tín hiệu để biết năng lực nào đang được bổ sung, nhưng vẫn cần kiểm thử trước khi nâng cấp môi trường vận hành.

Ollama v0.32.9 ngày 11/08/2026 bổ sung NVIDIA Nemotron 3.5 Lightning, một model mixture-of-experts 30B với 3B tham số active, kèm hỗ trợ kiến trúc Nemotron 3. Trước đó, Ollama v0.32.7 ngày 10/08/2026 hỗ trợ ban đầu Muse Glimmer, model đa phương thức 30B của Meta được định vị cho agent workload, qua MLX engine trên Apple Silicon; sau đó v0.32.8 cùng ngày mở rộng ra mọi nền tảng gồm NVIDIA và AMD.

Ollama v0.32.6 ngày 04/08/2026 cải thiện hiệu năng GPU Apple cho Qwen3.5 bằng speculative decoding qua MTP head tự động, đồng thời chuẩn hoá định dạng streaming /v1/chat/completions khớp OpenAI. Ở bản này, tính năng sinh ảnh thử nghiệm bị gỡ tạm thời. Ollama v0.32.10 ngày 12/08/2026, ở trạng thái pre-release, đổi giá trị mặc định repeat_penalty từ 1.1 xuống 1.0 cho các model không khai báo tham số này, và cải thiện prefill NVFP4 trên MLX khoảng 7–8% ở một số model.

Ở nhánh llama.cpp, bản b10369 ngày 12/08/2026 tích hợp Pocket-TTS cho sinh audio; thời gian sinh mỗi frame giảm khoảng 80% trên CUDA và khoảng 50% trên CPU. Bản b10356 ngày 11/08/2026 nâng hỗ trợ ROCm từ 7.2.1 lên 7.14 và là bản production đầu tiên dùng hệ thống build TheRock.

Các cập nhật này cho thấy local AI không chỉ xoay quanh chatbot văn bản. Hệ sinh thái đang mở rộng sang agent workload, đa phương thức, sinh audio, hỗ trợ GPU mới và tối ưu decoding. Với doanh nghiệp, đây là cơ sở để thiết kế lộ trình thử nghiệm theo từng use case thay vì triển khai đại trà ngay từ đầu.

6. Framework và công cụ hỗ trợ xây dựng agent

Nếu doanh nghiệp có đội kỹ thuật, việc xây dựng agent thường cần framework để chuẩn hoá cách gọi model, embedding, vector store, retriever và luồng xử lý. LangChain là framework xây dựng agent và ứng dụng LLM, cấp phép MIT, cung cấp giao diện chuẩn cho model, embedding, vector store và retriever, kèm LangGraph cho luồng agent có kiểm soát.

Framework của LangChain

Ở mảng coding agent, Continue được phát hành dưới ba dạng: CLI @continuedev/cli trên npm, extension VS Code trên Marketplace và OpenVSX, cùng plugin JetBrains. Tuy nhiên, repository continuedev/continue hiện ở trạng thái read-only và không còn được bảo trì tích cực; dự án cấp phép Apache 2.0. Điều này nhắc doanh nghiệp cần kiểm tra trạng thái bảo trì của công cụ trước khi đưa vào quy trình dài hạn.

Ollama cũng định vị Muse Glimmer cho agent workload, cụ thể là coding agent và trợ lý cá nhân chạy dài. Đây là tín hiệu đáng chú ý cho các doanh nghiệp muốn thử nghiệm trợ lý nội bộ xử lý chuỗi công việc nhiều bước, nhưng vẫn cần đánh giá giấy phép, hiệu năng và độ ổn định theo nhu cầu riêng.

7. Gợi ý lộ trình triển khai cho chủ doanh nghiệp

7.1. Bắt đầu từ một quy trình hẹp

Đừng bắt đầu bằng mục tiêu “AI hoá toàn công ty”. Hãy chọn một quy trình có dữ liệu rõ ràng, thao tác lặp lại và rủi ro kiểm soát được, ví dụ tra cứu chính sách nội bộ, phân loại yêu cầu hỗ trợ, tóm tắt tài liệu hoặc tạo bản nháp phản hồi khách hàng.

7.2. Tách rõ quyền trả lời và quyền hành động

Ở giai đoạn đầu, AI có thể chỉ đề xuất hành động thay vì tự thực thi. Khi tool calling đã ổn định, doanh nghiệp mới mở dần quyền gọi công cụ thật, luôn kèm phân quyền, ghi log và cơ chế xác nhận với các thao tác nhạy cảm.

7.3. Đo trên workload thật

Hãy đo riêng thời gian nạp prompt, tốc độ sinh câu trả lời, TTFT và thông lượng trên chính dữ liệu nội bộ. Các công cụ như llama-bench hoặc chuẩn đo như MLPerf Client giúp doanh nghiệp có ngôn ngữ đo lường rõ hơn, nhưng quyết định cuối cùng nên dựa trên tác vụ thực tế.

7.4. Kiểm soát phiên bản model và runtime

Vì Ollama và llama.cpp có nhiều bản phát hành liên tục, doanh nghiệp nên ghi nhận phiên bản runtime, model, định dạng lượng tử hoá và cấu hình phần cứng trong mỗi lần kiểm thử. Việc này giúp tránh tình trạng kết quả thử nghiệm hôm nay không tái lập được sau một lần nâng cấp.

7.5. Xây lớp giám sát trước khi mở rộng

Tool calling tạo ra giá trị vì AI có thể tương tác với hệ thống thật, nhưng đây cũng là lý do cần giám sát chặt. Doanh nghiệp nên lưu lại câu hỏi, tool được gọi, tham số, kết quả trả về và phản hồi cuối cùng để kiểm tra lỗi, tối ưu prompt và đánh giá rủi ro vận hành.

Kết luận: AI local phù hợp khi doanh nghiệp cần kiểm soát và tự động hoá có giới hạn

AI cho doanh nghiệp không nhất thiết phải bắt đầu bằng một dự án lớn. Với model local, API cục bộ, embedding cho RAG và tool calling, doanh nghiệp có thể thử nghiệm tự động hoá từng quy trình nhỏ nhưng có giá trị rõ ràng. Điểm mấu chốt là chọn use case hẹp, đo hiệu năng đúng cách, kiểm soát quyền gọi công cụ và cập nhật hệ sinh thái một cách có kỷ luật.

Nếu làm đúng, AI local không chỉ là một chatbot nội bộ, mà có thể trở thành lớp điều phối thông minh giữa con người, dữ liệu và phần mềm doanh nghiệp.