- Tổng hợp câu hỏi và câu trả lời được đăng trên subreddit Reddit /r/ollama
- Với vai trò quản trị viên hệ thống của một hãng luật quy mô 300 người, người hỏi muốn cung cấp cho toàn bộ nhân viên một công cụ soạn thảo và hiệu đính tài liệu bằng AI tương tự ChatGPT
- Để bảo vệ thông tin nhạy cảm như PII, họ đang cân nhắc tự host trực tiếp LLM trên máy chủ nội bộ thay vì dùng dịch vụ bên ngoài, kèm kiểm soát truy cập như đăng nhập, 2FA, VPN
- Các câu hỏi chính
- Một máy chủ LLM tự triển khai có thực sự hỗ trợ được hơn 300 người dùng không?
- Ban đầu họ nghĩ chỉ cần vài PC + GPU là đủ, nhưng liệu như vậy có phải đang đánh giá quá thấp bài toán không?
- Tạo/quản lý người dùng có thể trở thành gánh nặng lớn không?
- Có yếu tố quan trọng nào bị bỏ sót không?
- Vì không phải chuyên gia trong lĩnh vực LLM, người hỏi muốn nhận được lời khuyên thực tế về khả năng mở rộng, gánh nặng vận hành và tính khả thi
Tóm tắt các câu trả lời chính
1. Giới hạn phần cứng, hiệu năng và chi phí
- Nếu kỳ vọng mức chất lượng như mô hình thương mại (ví dụ: ChatGPT), sẽ cần một cụm GPU đắt đỏ trị giá hàng trăm nghìn đến hơn một triệu USD (ước tính $200,000~$1,000,000+)
- Nếu hạ quy mô xuống mô hình mã nguồn mở (cỡ 30B~70B tham số) thì phải chấp nhận suy giảm hiệu năng (độ trễ, chất lượng kết quả). Ngay cả xử lý đồng thời cho 10~40 người cũng đã là giới hạn
- Khuyến nghị giả định mức sử dụng đồng thời dưới 10 người và mở rộng dần theo kiểu bổ sung thêm máy chủ
- So với môi trường cục bộ, thuê GPU trên đám mây có thể kinh tế và linh hoạt hơn
2. Khuyến nghị PoC (thử nghiệm/pilot) và tiếp cận từng bước
- Nên dựng PoC (pilot) với 1 máy chủ + 1 GPU trước, đo tải và các kịch bản công việc thực tế rồi mới mở rộng
- Khi có nhiều yêu cầu đồng thời, hệ thống hàng đợi là bắt buộc; trên thực tế, số người dùng đồng thời có thể không phải 300 mà chỉ ở mức 10~30
- Trong ngắn hạn, có thể thử nghiệm bằng mô hình nhỏ (3B~13B tham số) kết hợp với workstation
3. Tùy chọn đám mây / hybrid / thay thế
- Đề xuất cấu trúc hybrid kết hợp LLM trên nền tảng đám mây (API, VPS, Azure, AWS Bedrock, v.v.) với hạ tầng nội bộ để đáp ứng yêu cầu bảo mật
- Tự host mang gánh nặng lớn về bảo mật, hiệu năng và chi phí; trên thực tế, các giải pháp thương mại như ChatGPT Enterprise/Teams, Microsoft Copilot Studio có thể hiệu quả hơn
- Cần rà soát kỹ yêu cầu bảo mật khi xử lý dữ liệu pháp lý / PII
4. Các vấn đề khác về vận hành, quản trị và kỹ thuật
- Quản lý người dùng/xác thực: có thể đơn giản hóa bằng tích hợp AD, OAuth hoặc cơ chế xác thực riêng
- Chọn/tinh chỉnh mô hình: nên thử các mô hình mã nguồn mở cỡ vừa và nhỏ phù hợp nhu cầu thực tế (hiệu đính tài liệu, v.v.) như LLama, Deepseek, Gemma, Qwen
- Có thể cân nhắc bổ sung các giải pháp như RAG, caching, cân bằng tải
- Cần xác định kịch bản sử dụng thực tế và kiểm chứng ngân sách/ROI phù hợp thông qua PoC
Tổng hợp các câu trả lời tiêu biểu
ithkuil
- So với mô hình thương mại, mô hình mã nguồn mở có khoảng cách hiệu năng lớn; với quy mô 300 người, có thể cần phần cứng trị giá hàng trăm nghìn USD
- Có thể kỳ vọng phần cứng và mô hình mở sẽ tiến bộ trong vòng 2 năm tới
SlimeQ
- Nên bắt đầu nhỏ với một instance duy nhất + hàng đợi, rồi mở rộng dần khi lượng sử dụng tăng
- Không thể để cả 300 người dùng đồng thời; cần đo mức sử dụng thực tế rồi mới quyết định mở rộng
Ok-Internal9317
- Người dùng đồng thời thực tế có thể dưới 10 người, và 4~5 GPU có thể đã đủ
- Về dài hạn, chi phí API có thể kinh tế hơn phần cứng tự triển khai
dyoh777
- Có thể dựng demo đơn giản bằng Ollama+WebUI, nhưng chất lượng mô hình là yếu tố quan trọng
careful-monkey
- Có thể chạy mô hình nhỏ bằng Mac Studio + RAM dung lượng lớn, với tốc độ khoảng 20token/sec
tshawkins
- Khuyến nghị các giải pháp SaaS như Microsoft Copilot Studio, có thể tích hợp trong Power Platform
roman_fyseek, Cergorach, Space__Whiskey
- Giới hạn VRAM của mô hình: 1 phiên = 1 GPU, xử lý đồng thời 300 người sẽ cần 300 GPU
- Thực tế cần giới hạn kết nối đồng thời, caching và kiến trúc hybrid
Siderox, SandboChang, unrulywind
- Thử nghiệm bằng máy chủ nhỏ trước dưới dạng PoC (ví dụ: 1~2 người/mô hình, kiểm tra khả năng áp dụng vào công việc thực tế) → rồi mở rộng dần
- Cần xác định kịch bản thực tế/benchmark trước khi kiểm chứng ngân sách và ROI
Little_Marzipan_2087, morosis1982, Daemonero
- Thuê GPU đám mây rẻ hơn và dễ mở rộng hơn, là giải pháp được dùng khá phổ biến
- Xét đến gánh nặng vận hành và bảo trì, họ khuyến nghị dùng đám mây hơn là đầu tư phần cứng
CtiPath, alew3, faldore, Wheynelau
- Đề xuất các framework máy chủ LLM mã nguồn mở hiệu năng cao như vLLM, OpenWebUI, TGI, sglang
- Khuyến nghị kiến trúc queue + load balancer
Khác
- Về bảo mật/pháp lý: ngay cả khi dùng đám mây, vẫn cần rà soát kỹ vị trí dữ liệu, mã hóa, tuân thủ quy định
- Nhiều tùy chọn phần cứng được nhắc đến như Mac Studio, RTX 6000 Pro, 4090
- Có thể giảm tải bằng caching, RAG, giới hạn context, offload
Kết luận
- Với máy chủ LLM tự lưu trữ, cách tiếp cận thực tế là bắt đầu từ một pilot/PoC quy mô nhỏ, rồi kiểm chứng dần theo từng giai đoạn về quy mô người dùng thực tế / yêu cầu / hiệu năng / chi phí
- Xử lý đồng thời 300 người dùng đi kèm chi phí phần cứng và vận hành rất lớn; tùy nhu cầu thực tế và ngân sách, đám mây, hybrid hoặc giải pháp thương mại có thể phù hợp hơn
- Cuối cùng, cần cân nhắc tổng thể các yếu tố như bảo mật, chi phí, trải nghiệm người dùng và bảo trì
6 bình luận
Có vẻ bạn đã đặt tiêu chuẩn về năng lực suy luận cần dùng trong khối lượng công việc của 300 người dùng hơi quá rộng. Nếu thực sự muốn bao phủ từ kiến thức phổ thông rất cơ bản cho đến luận văn hay các chủ đề nâng cao thì cách này là đúng, nhưng nếu xét mặt bằng các công việc thực tế cần xử lý thì với khoảng 30b kèm RAG là có thể xử lý được phần lớn rồi. Có phải vì đang cố nâng toàn bộ trọng số của mô hình nền tảng mã nguồn mở lên và dựa vào các tính năng có năng lực suy luận cao, nên quy mô mới trở nên quá lớn như vậy không?? Và tôi nghĩ phần có thể xử lý ngay lập tức với phần tìm kiếm, khám phá tài liệu nên được tách thành các chức năng riêng biệt.
Đối với phạm vi token mục tiêu của KV cache để xử lý đồng thời 300 người, nếu mỗi bên ở mức khoảng 20.000 token đã lượng tử hóa thì cũng có thể dùng khá dư dả, nên phần này cũng có thể đã bị tính quá cao... ??
Nếu không phải thật sự là 300 tiến sĩ đang làm luận án, thì có lẽ chỉ cần đặt mức suy luận ở tầm học sinh trung học (14~30b), rồi thiết lập quy trình tìm kiếm các tài liệu nội bộ đa dạng theo logic RAG với CoT phù hợp, thì dự án có thể vận hành thử nghiệm ở mức chi phí khá hợp lý.
Bản thân tôi cũng vì nhu cầu mà đang làm một giải pháp RAG, dùng tới 4 GPU H100 vốn hiếm có, nhưng nếu tính không chỉ chi phí đầu tư phần cứng trực tiếp mà cả tiền điện, chi phí cho các giải pháp làm mát khác các kiểu thì tôi cứ thấy gọi API vẫn tốt hơn rất nhiều.
Lúc đầu tôi cũng bắt đầu thử với Ollama, rồi xác nhận là ngay cả 3 người dùng đồng thời cũng không gánh nổi nên chuyển ngay sang vLLM và xoay xở đủ kiểu để dựng cấu hình RAG. Nhưng riêng chỗ này thôi (giả định 10 người dùng đồng thời) đã gần như phải dùng gần hết 2 GPU H100. Các tác vụ embedding hay tìm kiếm tôi cũng mở bằng vLLM để dùng, nên 4 chiếc H100 thật sự vẫn rất chật vật. Dù VRAM mỗi card khoảng 90GB cũng vẫn là như vậy.
Tất nhiên là tôi cũng không rành AI lắm, chỉ là vừa làm theo nhu cầu của bộ phận vừa cố gắng đáp ứng qua lại các quy định bảo mật nội bộ nên cứ thế làm liều thôi... nhưng tôi cũng băn khoăn không biết như vậy có đúng không. Hình như là ChatGPT Enterprise ấy nhỉ? Tôi thật sự thấy mức giá của nó quá hời.
Chỉ cần một cỗ máy cực khủng với mức giá cực chát là có vẻ đủ? Hãng luật cực khủng thì chắc sẽ mua được thôi. Nhưng mà đúng kiểu chạy máy xưởng 24/7 ấy ha ha ha
Một người chỉ nghĩ đến giá mua Porsche mà hoàn toàn không tính đến chi phí bảo dưỡng, tiền xăng, bảo hiểm, v.v.
Với các dịch vụ như chatbot cần hỗ trợ tính năng streaming, khi xử lý đồng thời thì công đoạn prefill cũng bị ảnh hưởng bởi cả decode, nên dù VRAM có dư dả thì từ góc nhìn người dùng vẫn trông như hiệu năng bị giảm đi rất nhiều.
Tôi cũng đã thử áp dụng các tùy chọn liên quan đến chunk prefill và cả tính năng Disaggregated Prefilling mà vLLM cung cấp ở mức thử nghiệm, nhưng mỗi khi có yêu cầu mới đi vào thì vẫn xảy ra hiện tượng câu trả lời đang được sinh ra trước đó bị khựng và đứt quãng, nên ở góc nhìn của một lập trình viên mới vào nghề, tôi muốn hỏi liệu ngoài cách tăng thêm GPU hoặc node thì còn phương án nào hiệu quả nhất không.
Tùy trường hợp thôi!