Bỏ qua tới nội dung chính
Quay lại tin tức

Làm thế nào để sử dụng hiệu quả OKF nhằm tạo điều kiện trao đổi tri thức giữa các mô hình ngôn ngữ lớn (LLM)

Towards Data Science· Anubhab Banerjee· 13/8/2026general

Định dạng Tri thức Mở (OKF) của Google là một cấu trúc Markdown+YAML dùng để chia sẻ tri thức giữa con người và các tác nhân AI. Bài viết này tái sử dụng cấu trúc đó cho một nhiệm vụ rất cụ thể — chuyển giao mảng số nguyên đã được mã hóa trước giữa ba mô hình Qwen2.5-Coder (7B, 3B, 1.5B) — và cho thấy mức giảm 28–37% thời gian tạo ra token đầu tiên (TTFT) cùng với một kiểm tra tương đương toàn bộ từ vựng giúp đảm bảo an toàn cho toàn bộ quá trình. Bài viết "Cách tận dụng OKF hiệu quả để cho phép trao đổi tri thức giữa các LLM" lần đầu xuất hiện trên Towards Data Science.

Các mô hình ngôn ngữ lớn Cách sử dụng OKF hiệu quả để tăng cường trao đổi tri thức giữa các LLM Sử dụng định dạng Open Knowledge Format (OKF) của Google (một bộ khung Markdown + YAML dành cho con người và tác nhân), thêm một trường chịu tải bổ sung vào phần frontmatter, và truyền các mảng số nguyên đã được mã hóa trước giữa ba tác nhân Qwen2.5-Coder (7B, 3B, 1.5B) thông qua `/dev/shm`. Thời gian xuất hiện token đầu tiên (TTFT) nhanh hơn 28–37% — và một kiểm tra thời gian chạy là yếu tố quyết định giữa "nhanh hơn" và "nội dung vô nghĩa trôi chảy một cách tự tin." Anubhab Banerjee Ngày 13/8/2026 21 phút đọc Ba tác nhân. Một bộ từ vựng chung. Bộ khung OKF của Google với một trường chịu tải bổ sung. Và một kiểm tra duy nhất là yếu tố quyết định giữa "nhanh hơn" và "sai." Những điểm chính Mô hình. Đây là bộ khung Open Knowledge Format của Google — một tệp Markdown với khối frontmatter YAML — được tái sử dụng cho việc chuyển giao giữa các tác nhân. Phần frontmatter của kho lưu trữ này mang một trường chịu tải bổ sung mà đặc tả OKF chung không định nghĩa: `token_pointer`, một đường dẫn tuyệt đối đến mảng `.npy` đã được tính toán trước trong bộ nhớ chia sẻ. Phần thân dễ đọc đối với con người, con trỏ dễ đọc đối với máy. Cơ chế. Ba mô hình Qwen2.5-Coder với các kích thước khác nhau (7B / 3B / 1.5B) không thể chia sẻ bộ nhớ đệm KV — chúng có kiến trúc khác nhau. Nhưng chúng có thể chia sẻ các ID token đã được tính toán trước, vì toàn bộ dòng Qwen2.5-Coder sử dụng một bộ từ vựng BPE giống hệt nhau. Kho lưu trữ này mã hóa token một lần, chuyển giao mảng số nguyên qua `/dev/shm/qwen_tokens/`, và cho phép mọi tác nhân hạ nguồn bỏ qua hoàn toàn bộ mã hóa token của riêng mình ở phía đầu vào. Các con số. Trung vị của 7 lần thử nghiệm trên mỗi lời nhắc, 3 khối, giải mã tham lam, 64 token mới: trên mô hình 3B, TTFT cơ sở trung bình giảm từ 69,3 ms xuống 49,9 ms — giảm 28,0%. Trên mô hình 1.5B, từ 49,6 ms xuống 30,9 ms — giảm 37,8%. Cả hai mô hình đều vượt qua kiểm tra tính mạch lạc trên mọi mẫu. Tổng thời gian thực hiện của toàn bộ quy trình là 41,3 giây từ đầu đến cuối (Tác nhân 1: 3,9 giây, Tác nhân 2: 18,7 giây, Tác nhân 3: 15,7 giây). Hàng rào bảo vệ. Việc cung cấp cho một mô hình hạ nguồn một mảng số nguyên mà có nghĩa là một từ con khác theo bộ từ vựng của chính nó không gây ra lỗi. Nó tạo ra một báo cáo trôi chảy, có vẻ mạch lạc, nhưng hoàn toàn sai. Vì vậy, trước khi bất kỳ tác nhân nào tin tưởng các số nguyên của tác nhân khác, quy trình này chạy một kiểm tra đầy đủ về sự bằng nhau của từ điển `get_vocab()` với khoảng 151.936 mục — không phải so sánh kích thước từ vựng, mà là kiểm tra thực sự. Những điều không được khẳng định. Chế độ khối ngắn (các khối vài trăm token). Không có CUDA tùy chỉnh — đây là sự điều phối trên API `model.generate(input_ids=...)` hiện có của thư viện transformers. Sự tương đương của bộ mã hóa token được xác minh cho chính xác ba điểm kiểm tra mà kho lưu trữ này sử dụng, không phải là một đảm bảo cố định trên toàn bộ dòng sản phẩm. Tóm tắt ngay từ đầu để bạn nắm được vấn đề chính: nếu bạn đã từng kết nối ba hoặc nhiều tác nhân (agent) dựa trên mô hình ngôn ngữ lớn (LLM) từ cùng một họ mô hình thành một quy trình (pipeline) xử lý một tài liệu chung, bộ xử lý trung tâm (CPU) của bạn đang thực hiện các phép hợp nhất mã hóa cặp byte (Byte-Pair Encoding - BPE) giống hệt nhau trên cùng một tập ký tự hai hoặc ba lần liên tiếp. Điều này xảy ra vì bộ mã hóa (tokenizer) của mỗi tác nhân là một thực thể mới không trạng thái, không biết rằng tác nhân trước đó đã tạo ra cùng một mảng số nguyên. Bài viết này trình bày về một quy trình nhỏ gồm ba mô hình Qwen2.5-Coder (7B, 3B, 1.5B), trong đó tác nhân đầu tiên mã hóa một lần, lưu một mảng NumPy chứa các ID token int64 vào /dev/shm/qwen_tokens/, và mọi tác nhân tiếp theo gọi trực tiếp model.generate(input_ids=...) trên mảng đó. Đồng thời, nó cũng — và đây là điểm kỹ thuật thú vị thực sự — từ chối cho phép bất kỳ tác nhân nào khác trong quy trình tin tưởng mảng đó cho đến khi nó xác nhận, từng byte một, rằng mọi mô hình trong chuỗi đều đồng ý về ý nghĩa của các số nguyên đó. Đây là một cơ chế điều phối, không phải một nhân CUDA. Nhưng nếu bạn đã từng gỡ lỗi một quy trình LLM tạo ra kết quả trôi chảy, đúng chủ đề, nhưng sai theo một cách khác nhau mỗi lần chạy, bạn đã biết hình dạng của vấn đề mà cơ sở hạ tầng này được thiết kế để ngăn chặn. Kho mã nguồn trên Github: https://github.com/AnubhabBanerjee/inter-llm-tokf 1. Một lời thú nhận: tác nhân thứ hai của bạn đang làm bài tập của tác nhân thứ nhất, hai lần Hãy kịch tính hóa khoảnh khắc mà toàn bộ kho mã nguồn này hướng tới. Hãy tưởng tượng bạn có ba tác nhân LLM được nối chuỗi với nhau. Tác nhân 1 là một mô hình lớn, nó đọc một tài liệu thiết kế. Tác nhân 2 là một mô hình cỡ trung, nó đánh giá một phần của tài liệu đó. Tác nhân 3 là một mô hình nhỏ, nó viết báo cáo cuối cùng. Cả ba đều thuộc cùng một họ mô hình — cùng bộ mã hóa, cùng từ vựng, mọi thứ giống nhau ngoại trừ các lớp ẩn — chỉ khác nhau về kích thước. Vì bạn không có nhiều bộ xử lý H100, và việc chạy một mô hình 7B ba lần trong khi một mô hình 1.5B là đủ cho bước cuối cùng sẽ là, thẳng thắn mà nói, lãng phí tài nguyên GPU của bạn. Bây giờ hãy xem điều gì xảy ra trên một thiết lập đơn giản: Bạn: "Tác nhân 1, vui lòng đọc tài liệu thiết kế này và chuyển các phần liên quan cho Tác nhân 2." Tác nhân 1 (7B): "Đã rõ. Đang tải bộ mã hóa. Đang chạy BPE trên toàn bộ tài liệu. Các phần đã được tách. Đang chuyển các phần thú vị cho Tác nhân 2 dưới dạng chuỗi. ✅" Bạn: "Tuyệt vời. Tác nhân 2?" Tác nhân 2 (3B): "Xin chào, tôi là một thực thể mới không trạng thái. Đang tải bộ mã hóa của riêng tôi. Đang chạy BPE trên cùng các ký tự mà Tác nhân 1 đã chạy BPE ba giây trước. Đang viết một bản đánh giá." Bạn: "Khoan đã, bạn có bộ mã hóa giống hệt Tác nhân 1." Tác nhân 2 (3B): "Tôi có sao?" Bạn: "Đúng vậy. Bạn thực sự thuộc cùng một họ mô hình. Cùng từ vựng, cùng ID từ con, mọi thứ đều giống nhau." Tác nhân 2 (3B): "Thật tốt. Dù sao, tôi đã mã hóa lại đầu vào từ đầu và tôi sẵn sàng tạo ra kết quả. Vui lòng chờ. 🫡" Bạn: "...còn Tác nhân 3?" Tác nhân 3 (1.5B): "Đang tải bộ mã hóa. Đang chạy BPE trên đầu ra của Tác nhân 2—" Bạn: "Thôi được rồi, quên đi tôi đã hỏi." Đó là câu chuyện đùa, và đó là bí mật bẩn thỉu của mọi quy trình LLM đa tác nhân xử lý một đoạn văn bản chung bằng cách sử dụng các mô hình từ cùng một họ. Bộ mã hóa không phải là nút thắt cổ chai — một bộ mã hóa BPE nhanh được hỗ trợ bởi Rust không hề chậm, và tôi sẽ không...

Nguồn tin: Towards Data Science — Tác giả: Anubhab Banerjee. Bản dịch tiếng Việt do AI thực hiện, có thể có sai sót.