Độ trễ và thông lượng AI là hai cách nhìn khác nhau về tốc độ của cùng một hệ thống. Hãy hình dung một quán phở: độ trễ là thời gian một khách chờ từ lúc gọi món đến lúc có tô phở; thông lượng là số tô quán phục vụ được mỗi giờ. Quán có thể bán rất nhiều tô mỗi giờ nhưng giờ cao điểm từng khách vẫn chờ lâu.
Với AI tạo sinh, câu trả lời được sinh dần từng token, nên độ trễ có nhiều lớp:
Thông lượng thì đo ở cấp hệ thống: tổng token mỗi giây cho tất cả người dùng, hoặc số yêu cầu hoàn thành mỗi phút. Một máy chủ có thể phục vụ 20 người cùng lúc với thông lượng cao, trong khi mỗi người thấy chữ chạy chậm hơn so với lúc chỉ có một mình.
"}, {"h2": "Các chỉ số tốc độ thường gặp và ý nghĩa", "html": "Khi đọc trang tài liệu API, bài đánh giá GPU hay báo cáo của công cụ chạy mô hình, bạn sẽ gặp các thuật ngữ sau. Cách gọi có thể khác nhau giữa nguồn, nên luôn xem họ đo trong điều kiện nào.
", "table": {"caption": "Thuật ngữ tốc độ AI và cách hiểu", "head": ["Chỉ số", "Đo cái gì", "Ai quan tâm", "Ảnh hưởng lớn nhất"], "rows": [["TTFT", "Thời gian chờ chữ đầu tiên", "Người dùng chat, voice bot", "Độ dài prompt, tải máy chủ"], ["Token/giây mỗi luồng", "Tốc độ chữ chạy cho một người", "Người dùng cuối", "Băng thông bộ nhớ GPU, kích thước mô hình"], ["Tổng token/giây", "Năng lực toàn hệ thống", "Người vận hành, IT", "Số yêu cầu đồng thời, phần mềm phục vụ"], ["Yêu cầu/phút", "Số tác vụ xong mỗi phút", "Quy trình xử lý hàng loạt", "Độ dài trung bình đầu vào, đầu ra"], ["Độ trễ p95", "Thời gian mà 95% yêu cầu nhanh hơn", "Người thiết kế dịch vụ", "Giờ cao điểm, yêu cầu dài bất thường"]]}}, {"h2": "Điều gì quyết định độ trễ và thông lượng", "html": "Nhiều yếu tố cộng lại, nhưng có thể gom thành bốn nhóm chính.
Mô hình càng nhiều tham số, mỗi token càng tốn tính toán và đọc bộ nhớ. Lượng tử hóa xuống 4-bit hoặc 8-bit giúp giảm dung lượng, thường tăng tốc độ trên cùng phần cứng nhưng có thể giảm nhẹ chất lượng.
Ở giai đoạn sinh token, tốc độ thường bị giới hạn bởi băng thông bộ nhớ GPU hơn là sức tính toán thuần. Đó là lý do GPU có VRAM nhanh cho tốc độ token/giây cao hơn rõ rệt so với chạy bằng CPU và RAM thường.
Prompt dài, nhiều tài liệu đính kèm làm TTFT tăng và chiếm thêm bộ nhớ cho KV cache, từ đó giảm số người phục vụ được cùng lúc.
Các công cụ như vLLM dùng kỹ thuật gom lô liên tục (continuous batching) để tăng thông lượng khi nhiều người dùng, còn Ollama ưu tiên dễ cài cho một người hoặc nhóm nhỏ. Cùng mô hình, cùng GPU, phần mềm khác nhau có thể cho thông lượng chênh nhau đáng kể.
"}, {"h2": "Đọc thông số quảng cáo sao cho không bị nhầm", "html": "Con số 'X token/giây' xuất hiện khắp nơi, nhưng thiếu ngữ cảnh thì gần như vô nghĩa. Trước khi so sánh, hãy hỏi đủ các câu sau:
Với API thương mại, tốc độ còn dao động theo giờ trong ngày và tải chung của nhà cung cấp. Nếu cần cam kết, hãy xem các gói có mức dịch vụ rõ ràng và tự đo trong khung giờ làm việc thật của công ty.
Nguyên tắc chung: chỉ tin con số bạn tự đo với dữ liệu của mình, còn số liệu công bố dùng để khoanh vùng lựa chọn.
"}, {"h2": "Bao nhiêu là đủ nhanh cho từng ứng dụng", "html": "Không phải ứng dụng nào cũng cần nhanh như nhau. Đặt yêu cầu đúng giúp tránh đầu tư thừa.
Công ty 40 người, giờ cao điểm khoảng 6–8 người hỏi cùng lúc, mỗi câu trả lời khoảng 300–500 token. Bạn cần hệ thống giữ tốc độ dễ chịu cho khoảng 8 luồng song song, không cần phục vụ 40 luồng. Ước lượng này giúp chọn đúng cỡ GPU thay vì mua quá lớn.
"}, {"h2": "Cách tự đo độ trễ và thông lượng", "html": "Bạn có thể tự đo mà không cần công cụ phức tạp.
Vẽ bảng đơn giản: số luồng đồng thời ở cột trái, TTFT và token/giây mỗi luồng ở các cột sau. Điểm mà TTFT bắt đầu tăng vọt chính là giới hạn thực tế của hệ thống. Hãy vận hành ở mức thấp hơn điểm đó để dự phòng giờ cao điểm.
"}, {"h2": "Cách cải thiện tốc độ và lỗi thường gặp", "html": "Khi hệ thống chậm, đừng vội nâng cấp phần cứng. Thử các cách sau trước:
Model card là một bản 'lý lịch' ngắn gọn của mô hình AI. Ý tưởng xuất phát từ bài báo 'Model Cards for Model Reporting' của nhóm nhà nghiên cứu tại Google, đề xuất rằng mỗi mô hình phát hành ra công chúng nên đi kèm một tài liệu chuẩn hóa về mục đích sử dụng, cách đánh giá và các giới hạn.
Lý do rất thực tế: mô hình AI không có 'nhãn dán' bên ngoài. Hai tệp trọng số trông giống hệt nhau có thể đến từ hai mô hình được huấn luyện cho hai mục đích khác nhau, với điểm mạnh, điểm yếu khác nhau. Không có model card, người dùng phải đoán.
Hiện nay model card xuất hiện ở nhiều dạng:
Mức độ chi tiết khác nhau rất nhiều. Một model card tốt giúp bạn quyết định nhanh; một model card sơ sài là tín hiệu cần thận trọng.
"}, {"h2": "Một model card thường gồm những phần nào", "html": "Không có mẫu bắt buộc duy nhất, nhưng phần lớn model card nghiêm túc có các mục dưới đây. Nếu thiếu nhiều mục, hãy coi đó là điểm trừ khi đánh giá.
", "table": {"caption": "Các mục thường có trong model card", "head": ["Mục", "Nội dung", "Câu hỏi doanh nghiệp cần trả lời"], "rows": [["Thông tin cơ bản", "Tên, phiên bản, nhà phát triển, giấy phép", "Có được dùng thương mại không?"], ["Mục đích sử dụng", "Việc nên dùng và không nên dùng", "Việc của mình có nằm trong phạm vi khuyến nghị?"], ["Dữ liệu huấn luyện", "Nguồn, ngôn ngữ, thời điểm cắt dữ liệu", "Mô hình có hiểu tiếng Việt, kiến thức đến khi nào?"], ["Đánh giá", "Bộ benchmark, kết quả, điều kiện đo", "Kết quả có đo trên việc giống mình không?"], ["Giới hạn và rủi ro", "Thiên lệch, ảo giác, lỗ hổng đã biết", "Rủi ro nào ảnh hưởng khách hàng của mình?"], ["Thông số kỹ thuật", "Số tham số, ngữ cảnh, định dạng, cách chạy", "Phần cứng hiện có chạy được không?"]]}}, {"h2": "Đọc model card trong 10 phút: thứ tự nên theo", "html": "Model card có thể dài hàng chục trang. Bạn không cần đọc hết, chỉ cần đi đúng thứ tự để loại sớm mô hình không phù hợp.
Sau 10 phút, bạn nên trả lời được: có hợp pháp để dùng không, có hợp việc không, có chạy được không. Nếu cả ba là 'có', chuyển sang bước thử nghiệm với dữ liệu thật.
"}, {"h2": "Dấu hiệu cảnh báo trong model card", "html": "Một số chi tiết cho thấy bạn nên dè chừng hoặc kiểm tra kỹ hơn:
Gặp một dấu hiệu chưa phải lý do loại bỏ ngay, nhưng gặp nhiều dấu hiệu cùng lúc thì nên chọn mô hình khác có tài liệu rõ ràng hơn.
"}, {"h2": "Ví dụ: chọn mô hình cho chatbot hỗ trợ khách hàng", "html": "Một cửa hàng bán linh kiện máy tính tại TP.HCM muốn chạy chatbot trả lời câu hỏi về bảo hành trên máy chủ nội bộ. Đội IT lọc được ba mô hình mở cỡ vừa. Đọc model card giúp họ quyết định như sau:
Sau đó đội IT thử mô hình B với 30 câu hỏi thật từ fanpage, chấm điểm từng câu và quyết định triển khai thử nghiệm. Model card không thay được bước thử nghiệm, nhưng giúp tiết kiệm nhiều ngày công thử những mô hình vốn không phù hợp.
"}, {"h2": "Doanh nghiệp tự viết model card cho ứng dụng AI nội bộ", "html": "Model card không chỉ để đọc. Khi công ty tự tinh chỉnh mô hình hoặc xây chatbot nội bộ, viết một model card ngắn là cách quản trị đơn giản và hiệu quả. Tài liệu này giúp người mới tiếp quản hiểu hệ thống, và là căn cứ khi có câu hỏi từ khách hàng, đối tác hay kiểm toán.
Cập nhật model card mỗi khi đổi mô hình nền, đổi dữ liệu hoặc thay đổi phạm vi sử dụng.
"} ], "tip": "Hãy biến việc đọc model card thành một bước bắt buộc trong quy trình duyệt công cụ AI của công ty: không có phiếu tóm tắt model card, không đưa mô hình vào dùng với dữ liệu thật.", "faq": [ {"q": "Model card và system card khác nhau thế nào?", "a": "Hai tên gọi thường dùng thay nhau. System card hay được dùng cho hệ thống hoàn chỉnh gồm mô hình cộng các lớp an toàn, và thường tập trung nhiều vào đánh giá rủi ro."}, {"q": "Tìm model card ở đâu?", "a": "Với mô hình mở, xem trang mô hình trên Hugging Face hoặc kho GitHub chính thức. Với mô hình thương mại, xem mục tài liệu, nghiên cứu hoặc an toàn trên website nhà phát triển."}, {"q": "Model card có đáng tin hoàn toàn không?", "a": "Model card do chính nhà phát triển viết nên phản ánh góc nhìn của họ. Hãy dùng nó để khoanh vùng, sau đó tự thử nghiệm với dữ liệu và câu hỏi thật của công ty."}, {"q": "Không biết tiếng Anh có đọc được model card không?", "a": "Phần lớn model card viết bằng tiếng Anh. Bạn có thể nhờ AI dịch và tóm tắt, nhưng nên tự đọc kỹ đoạn giấy phép gốc hoặc nhờ người có chuyên môn xác nhận."}, {"q": "Mô hình không có model card có nên dùng không?", "a": "Nên tránh cho công việc thật, đặc biệt khi xử lý dữ liệu khách hàng. Thiếu model card nghĩa là thiếu thông tin về giấy phép, giới hạn và rủi ro."}, {"q": "Model card có nói mô hình chạy cần bao nhiêu VRAM không?", "a": "Một số có, đa số chỉ ghi số tham số và định dạng. Bạn có thể ước lượng VRAM từ số tham số, mức lượng tử hóa và độ dài ngữ cảnh."} ], "sources": [ {"t": "Mitchell et al., Model Cards for Model Reporting – arXiv", "u": "https://arxiv.org/abs/1810.03993"}, {"t": "Hugging Face – Model Cards documentation", "u": "https://huggingface.co/docs/hub/model-cards"}, {"t": "NIST AI Risk Management Framework", "u": "https://www.nist.gov/itl/ai-risk-management-framework"} ], "related": ["open-weights-la-gi", "mo-hinh-ai-ma-nguon-mo-va-dong", "ai-benchmark-la-gi", "evals-la-gi", "ai-governance-la-gi", "foundation-model-la-gi", "mo-hinh-ai-la-gi", "vram-bao-nhieu-de-chay-llm"] }, { "id": 2183, "slug": "semantic-search-la-gi", "title": "Tìm kiếm ngữ nghĩa (semantic search) là gì? Ứng dụng cho doanh nghiệp", "meta_desc": "Tìm kiếm ngữ nghĩa (semantic search) là gì: tìm theo ý nghĩa thay vì đúng từ khóa. Cách hoạt động, ví dụ tra tài liệu nội bộ, khi nào nên dùng và cách triển khai.", "excerpt": "Nhân viên gõ 'nghỉ phép năm được mấy ngày' nhưng tài liệu ghi 'chế độ ngày phép hằng năm', ô tìm kiếm thông thường trả về không kết quả. Tìm kiếm ngữ nghĩa giải quyết đúng vấn đề này. Bài viết giải thích cách nó hoạt động và cách áp dụng cho kho tài liệu của công ty.", "answer": "Tìm kiếm ngữ nghĩa (semantic search) là cách tìm thông tin dựa trên ý nghĩa của câu hỏi chứ không chỉ dựa trên việc trùng từ khóa. Hệ thống dùng mô hình embedding để biến câu hỏi và tài liệu thành các vector số, rồi tìm những đoạn có vector gần nhau nhất về nghĩa. Nhờ vậy câu 'xin nghỉ ốm thế nào' vẫn tìm ra đoạn 'thủ tục nghỉ do bệnh'. Semantic search là nền tảng của RAG, chatbot đọc tài liệu nội bộ và gợi ý sản phẩm, nhưng thường nên kết hợp với tìm từ khóa cho mã sản phẩm, số hợp đồng.", "kws": ["tìm kiếm ngữ nghĩa", "semantic search là gì", "tìm kiếm theo ý nghĩa", "semantic search tiếng Việt", "tìm kiếm tài liệu nội bộ bằng AI"], "sections": [ {"h2": "Tìm kiếm ngữ nghĩa là gì", "html": "Tìm kiếm ngữ nghĩa là kỹ thuật cho máy tính hiểu ý định của người hỏi và tìm nội dung có cùng ý nghĩa, kể cả khi dùng từ khác hoàn toàn. Đây là bước tiến so với tìm kiếm từ khóa truyền thống vốn chỉ so khớp chữ.
Ví dụ trong một công ty phân phối 30 người, kho tài liệu có câu: 'Hàng lỗi do nhà sản xuất được đổi mới trong 7 ngày'. Nhân viên mới gõ các câu hỏi khác nhau:
Tìm kiếm từ khóa có thể bỏ sót cả ba vì không có chữ nào trùng hoàn toàn. Tìm kiếm ngữ nghĩa hiểu cả ba đều hỏi về đổi hàng lỗi và trả đúng đoạn tài liệu.
Khả năng này rất quan trọng với tiếng Việt vì cùng một ý có nhiều cách nói: 'hóa đơn' và 'HĐ', 'nghỉ phép' và 'xin off', 'khách sỉ' và 'đại lý'. Người dùng không cần nhớ chính xác thuật ngữ trong tài liệu.
"}, {"h2": "Semantic search hoạt động thế nào", "html": "Đằng sau là ba bước, có thể hình dung như sắp xếp sách trong thư viện theo chủ đề thay vì theo bảng chữ cái.
Hai đoạn văn có nghĩa gần nhau sẽ có vector nằm gần nhau trong không gian số, dù chữ viết khác nhau. Đó là lý do hệ thống tìm được 'hàng hư' khi tài liệu ghi 'hàng lỗi'.
Nhiều hệ thống thêm một mô hình reranker đọc kỹ 20–50 kết quả đầu và sắp xếp lại theo mức liên quan thực sự, giúp kết quả đầu tiên chính xác hơn.
"}, {"h2": "So sánh tìm kiếm ngữ nghĩa với tìm kiếm từ khóa", "html": "Tìm kiếm ngữ nghĩa không thay thế hoàn toàn tìm kiếm từ khóa. Mỗi cách mạnh ở một kiểu câu hỏi khác nhau.
Tìm kiếm từ khóa vượt trội khi người dùng biết chính xác điều mình tìm: mã sản phẩm 'RTX-4060-8G', số hợp đồng 'HD-2026-0315', tên riêng, số điện thoại. Tìm kiếm ngữ nghĩa có thể trả về sản phẩm 'na ná' thay vì đúng mã. Ngược lại, câu hỏi tự nhiên, mô tả vấn đề thì ngữ nghĩa thắng rõ.
Vì vậy các hệ thống thực tế thường dùng hybrid search: chạy cả hai cách rồi gộp kết quả.
", "table": {"caption": "Từ khóa, ngữ nghĩa và kết hợp", "head": ["Tiêu chí", "Tìm từ khóa", "Tìm ngữ nghĩa", "Kết hợp (hybrid)"], "rows": [["Câu hỏi tự nhiên", "Kém", "Tốt", "Tốt"], ["Mã, số hiệu, tên riêng", "Rất tốt", "Không ổn định", "Rất tốt"], ["Từ đồng nghĩa, viết tắt", "Kém nếu không có từ điển", "Tốt", "Tốt"], ["Giải thích vì sao ra kết quả", "Dễ", "Khó hơn", "Trung bình"], ["Độ phức tạp triển khai", "Thấp", "Trung bình", "Cao hơn"]]}}, {"h2": "Ứng dụng tìm kiếm ngữ nghĩa trong doanh nghiệp", "html": "Semantic search hữu ích ở mọi nơi có nhiều văn bản mà người dùng không biết chính xác từ khóa:
Kho dữ liệu nhỏ vài chục trang, hoặc dữ liệu có cấu trúc như bảng tồn kho, danh sách khách hàng. Với bảng dữ liệu, lọc theo cột hoặc truy vấn cơ sở dữ liệu vẫn chính xác và rẻ hơn.
"}, {"h2": "Triển khai semantic search cho kho tài liệu công ty", "html": "Soạn 30–50 câu hỏi thật kèm đáp án mong đợi. Đo tỷ lệ đoạn đúng nằm trong 3 kết quả đầu. Nếu thấp, kiểm tra lại cách chia đoạn và mô hình embedding trước khi đổi công cụ.
"}, {"h2": "Lỗi thường gặp và giới hạn cần biết", "html": "Tìm kiếm ngữ nghĩa mạnh nhưng không phải phép màu. Các vấn đề hay gặp:
Giới hạn cốt lõi: semantic search trả về đoạn giống nghĩa nhất, không đảm bảo đó là đoạn đúng nhất. Với thông tin quan trọng, giao diện nên hiển thị nguồn tài liệu để người dùng tự kiểm tra.
"} ], "tip": "Đầu tư thời gian dọn dẹp tài liệu trước khi chọn công cụ. Một kho tài liệu gọn, có ngày hiệu lực và phân quyền rõ thường cải thiện kết quả tìm kiếm ngữ nghĩa nhiều hơn việc đổi sang mô hình embedding đắt hơn.", "faq": [ {"q": "Semantic search khác Google Search thế nào?", "a": "Google Search hiện đã kết hợp nhiều kỹ thuật hiểu ngữ nghĩa. Semantic search trong doanh nghiệp là áp dụng cùng ý tưởng cho kho tài liệu riêng của công ty."}, {"q": "Semantic search có hiểu tiếng Việt không?", "a": "Có, nếu dùng mô hình embedding đa ngôn ngữ hoặc được huấn luyện thêm cho tiếng Việt. Hãy thử với câu hỏi thật, có dấu và không dấu, trước khi chọn."}, {"q": "Tìm kiếm ngữ nghĩa và RAG có phải là một?", "a": "Không. Semantic search là bước tìm đoạn tài liệu liên quan; RAG dùng các đoạn đó làm ngữ cảnh để mô hình ngôn ngữ soạn câu trả lời."}, {"q": "Cần vector database riêng không?", "a": "Với vài nghìn tài liệu, tiện ích vector của cơ sở dữ liệu quen thuộc hoặc công cụ tích hợp sẵn thường đủ. Vector database chuyên dụng phù hợp khi dữ liệu lớn hoặc cần tốc độ cao."}, {"q": "Có chạy semantic search hoàn toàn nội bộ được không?", "a": "Được. Mô hình embedding cỡ nhỏ chạy tốt trên máy chủ nội bộ, kể cả không có GPU mạnh, nên tài liệu không cần gửi ra ngoài."}, {"q": "Vì sao kết quả tìm kiếm ngữ nghĩa đôi khi sai?", "a": "Thường do cách chia đoạn chưa tốt, mô hình embedding yếu với tiếng Việt hoặc tài liệu cũ chưa được loại bỏ. Thêm tìm từ khóa và reranker giúp cải thiện đáng kể."} ], "sources": [ {"t": "Semantic search – Wikipedia", "u": "https://en.wikipedia.org/wiki/Semantic_search"}, {"t": "Sentence Transformers – tài liệu chính thức", "u": "https://www.sbert.net"}, {"t": "pgvector – GitHub chính thức", "u": "https://github.com/pgvector/pgvector"} ], "related": ["embedding-la-gi", "vector-database-la-gi", "rag-la-gi", "hybrid-search-la-gi", "graphrag-la-gi", "anythingllm-la-gi", "anythingllm-vs-open-webui", "context-engineering-la-gi"] } ]