Vì sao các công cụ truy vết LLM hiện đang xây dựng cổng AI

Năm 2026, LangSmith, Langfuse, Opik và Braintrust đều bổ sung một cổng trung gian trước các nhà cung cấp mô hình. Lý do chính là khả năng kiểm soát: công cụ truy vết chỉ có thể ghi lại một lệnh gọi mô hình, còn cổng trung gian có thể chặn lệnh gọi đó.

Hai công cụ đảm nhiệm hai công việc riêng biệt

Trong hai năm qua, nhiều nhóm đã vận hành các ứng dụng mô hình ngôn ngữ lớn (LLM) bằng hai công cụ riêng biệt. Một cổng trung gian nằm giữa ứng dụng và các nhà cung cấp mô hình. Cổng này lưu khóa API của nhà cung cấp, chuyển đổi giữa các API của nhà cung cấp và thử lại những lệnh gọi thất bại. LiteLLM, một proxy mã nguồn mở, trở thành lựa chọn phổ biến cho công việc này. Bên cạnh ứng dụng là một công cụ truy vết như LangSmith hoặc Langfuse, ghi lại từng lệnh gọi mô hình, lệnh gọi công cụ và bước truy xuất để kỹ sư có thể thấy tác tử đã làm gì.

Việc tách riêng hai công cụ là hợp lý, bởi cổng trung gian phải hoạt động nhanh và hỗ trợ API của mọi nhà cung cấp, trong khi công cụ truy vết cần có giao diện tốt, bộ lưu trữ cho các tải dữ liệu lớn và SDK bao bọc mã ứng dụng. Langfuse vẫn hướng dẫn cách thiết lập hai công cụ, với tích hợp LiteLLM Proxy chuyển mọi lệnh gọi qua proxy rồi đến Langfuse. Năm 2026, các nhà cung cấp công cụ truy vết bắt đầu tự xây dựng cổng trung gian.

Bốn lần ra mắt trong sáu tháng

LangChain công bố LangSmith LLM Gateway ở giai đoạn beta riêng tư vào tháng 5 năm 2026, rồi mở beta công khai vào ngày 30 tháng 7; kể từ đó, hãng cũng đưa sản phẩm này vào các gói triển khai LangSmith trên đám mây do khách hàng tự cung cấp. Braintrust ngừng cung cấp proxy AI trước đây và hướng người dùng đến một cổng trung gian mới, hiện đang ở giai đoạn xem trước và miễn phí cho đến khi phát hành rộng rãi. Comet ra mắt Opik LLM Gateway dưới dạng một điểm cuối beta chấp nhận các yêu cầu theo định dạng OpenAI. Ngày 4 tháng 11, Langfuse mở cổng AI của mình ở giai đoạn beta công khai, cả trên Langfuse Cloud lẫn cho các bản triển khai tự lưu trữ. Cổng này được cấp phép theo MIT và viết bằng Rust.

MLflow, vốn khởi đầu là một công cụ quản lý vòng đời học máy chứ không phải công cụ truy vết, đã có cổng AI từ lâu hơn, với cảnh báo và giới hạn ngân sách.

Cổng trung gian đã tồn tại nhiều năm, và những rủi ro khi vận hành một cổng như vậy đã được ghi nhận đầy đủ. Các cổng mới đến từ những công ty vốn hoạt động trong lĩnh vực ghi lại lệnh gọi mô hình, và giờ đây họ muốn mọi lệnh gọi phải đi qua mình trước tiên.

Vì sao ngân sách cần được kiểm soát ngay trên luồng yêu cầu

Công cụ truy vết ghi lại lệnh gọi mô hình sau khi nhà cung cấp đã phản hồi và chi phí token đã được thanh toán. Bản ghi đó đủ để lập biểu đồ chi tiêu, nhưng công cụ truy vết không thể ngăn khoản chi này phát sinh. Muốn thực thi ngân sách của một nhóm, chặn một mô hình hoặc xóa thông tin bí mật khỏi lời nhắc, cần kiểm tra yêu cầu trước khi nó đến nhà cung cấp. Chỉ thành phần nằm trên luồng yêu cầu mới làm được điều đó.

LangChain nêu lập luận này trong bài viết công bố ra mắt. Hãng mô tả các nhóm kết hợp một cổng trung gian riêng, một sản phẩm bảo vệ an toàn và một công cụ giám sát, đồng thời cho rằng muốn ngăn chặn vấn đề thì phải thực thi chính sách ở tầng yêu cầu. Cổng của hãng phản hồi mã trạng thái HTTP 402 cho một lệnh gọi vượt quá ngân sách, thay vì chuyển tiếp lệnh gọi đó đến nhà cung cấp.

Một điểm truy cập duy nhất ghi lại mọi lệnh gọi

Lý do thứ hai là độ bao phủ. SDK chỉ ghi lại những luồng mã đã được lập trình viên thêm công cụ đo lường. Ở những luồng nằm ngoài phạm vi đó, các lỗi của tác tử thường không được phát hiện. Một tập lệnh chạy trên máy tính xách tay, một sổ tay mã hoặc một tác tử lập trình sử dụng khóa API được sao chép sẽ không để lại dấu vết nào. Cổng trung gian lưu khóa của nhà cung cấp sẽ thấy mọi lệnh gọi, vì không có đường nào khác để kết nối với nhà cung cấp.

Langfuse xây dựng cổng trung gian dựa trên ý tưởng này. Theo tài liệu về cổng trung gian của hãng, mỗi khóa cổng thuộc về một người dùng hoặc tài khoản dịch vụ và có thể đi kèm siêu dữ liệu như nhóm hoặc trung tâm chi phí. Chỉ cổng trung gian mới lưu thông tin xác thực của nhà cung cấp, còn quản trị viên phê duyệt những mô hình mà mỗi thông tin xác thực được phép gọi. LangSmith đăng các trang hướng dẫn thiết lập để định tuyến Claude Code, Codex và Gemini CLI qua cổng của mình. Các tác tử này gọi mô hình từ máy của nhà phát triển, nằm ngoài mã truy vết của mọi ứng dụng.

Cổng trung gian tích hợp vào công cụ truy vết mang lại điều gì

Các nhà cung cấp công cụ truy vết cũng đưa ra lập luận ngược lại: chỉ riêng một cổng trung gian độc lập là chưa đủ. Bài viết công bố ra mắt của Langfuse cho biết một cổng trung gian độc lập chỉ có thể đếm token và chi phí, trong khi cổng của hãng biến mỗi lệnh gọi thành một phần của bản truy vết đầy đủ. Cổng của Langfuse chấp nhận tiêu đề traceparent của W3C, nhờ đó lệnh gọi đi qua cổng được đưa vào bản truy vết mà ứng dụng đã bắt đầu. Theo mặc định, cổng ghi lại mức sử dụng và chi phí, chứ không ghi nội dung lời nhắc và phản hồi.

Đây là lập luận kỹ thuật thuyết phục nhất cho việc tích hợp cổng trung gian vào công cụ truy vết. Một cổng trung gian độc lập chỉ thấy một danh sách phẳng các phản hồi hoàn tất. Công cụ truy vết đã có sẵn thông tin về các lệnh gọi công cụ và bước truy xuất của tác tử từ SDK, nên có thể đặt mỗi lệnh gọi qua cổng vào đúng cấu trúc đó.

Ngoài ra còn có một cách nhìn từ góc độ thương mại mà chính các nhà cung cấp không đề cập. Bên vận hành cổng nắm giữ khóa của nhà cung cấp và báo cáo chi tiêu; đây cũng là báo cáo mà các nhóm tài chính và nền tảng xem xét. Điều đó khiến việc thay thế một cổng khó hơn thay thế một công cụ xem dấu vết. LangSmith và Langfuse đã khai thác vị thế này theo những cách khác nhau: LangSmith bán Gateway Credits, cho phép khách hàng gọi các mô hình được lưu trữ, chẳng hạn như Kimi, mà không cần khóa riêng của nhà cung cấp; trong khi đó, mục Câu hỏi thường gặp của Langfuse cho biết dịch vụ này không bán lại token.

Những điều các cổng beta chưa thể làm

Các cổng này còn mới, và chính các nhà cung cấp cũng ghi rõ những hạn chế của sản phẩm. Hiện tại, cổng của Langfuse chỉ hỗ trợ OpenAI và Anthropic; Amazon Bedrock, Google Vertex AI và Google AI Studio nằm trong lộ trình phát triển. Tính năng chuyển dự phòng giữa các nhà cung cấp và đặt hạn mức chi tiêu cứng cho từng nhóm, người dùng hoặc khóa đã được lên kế hoạch nhưng chưa triển khai. Hiện tại, cổng này cung cấp bảng điều khiển chi tiêu và cảnh báo. Tài liệu của sản phẩm không đề cập đến giới hạn tốc độ hay lưu bộ nhớ đệm phản hồi.

Cổng Langfuse không chuyển đổi giữa các định dạng API, vì vậy ứng dụng khách OpenAI chỉ có thể gọi các mô hình OpenAI. Phiên bản tự lưu trữ chỉ gọi các URL chính thức của nhà cung cấp, nên hiện chưa thể sử dụng Azure OpenAI, Bedrock hoặc proxy nội bộ. Comet mô tả cổng Opik là được thiết kế cho mục đích phát triển và thử nghiệm. Braintrust chưa công bố giá cho cổng của mình.

Cổng của LangSmith hiện đã làm được nhiều việc hơn các cổng khác. Tài liệu của sản phẩm liệt kê tính năng chuyển dự phòng, giới hạn chi tiêu, giới hạn tốc độ và chính sách dữ liệu là những tính năng hiện có; đồng thời, cổng hỗ trợ các định dạng OpenAI Chat Completions, OpenAI Responses và Anthropic Messages. Tính năng chuyển dự phòng và giới hạn tốc độ được liệt kê là những hạng mục sẽ phát triển trong tương lai vào tháng 5, nên chúng đã được bổ sung trong giai đoạn beta. Toàn bộ sản phẩm vẫn được gắn nhãn beta.

Kiểm thử tải cho thấy một dạng hạn chế khác. Kết quả đánh giá tự lưu trữ cổng Langfuse, LiteLLM và AcruxCore cho thấy cổng Langfuse làm tăng độ trễ trên mỗi lệnh gọi ít hơn LiteLLM. Tuy nhiên, với các thiết lập Docker mặc định, cổng này gặp lỗi ở 739 trong số 1,000 luồng đồng thời, vì tiến trình vẫn giữ giới hạn mặc định 1,024 tệp đang mở của Docker. Chỉ cần sửa một dòng trong tệp Compose của Langfuse là khắc phục được vấn đề.

So với các sản phẩm beta này, LiteLLM — một cổng độc lập đã hoạt động trong nhiều năm — hỗ trợ hơn 100 nhà cung cấp và đã có sẵn khóa ảo, theo dõi chi tiêu, các biện pháp bảo vệ, cân bằng tải và bảng điều khiển quản trị. LiteLLM cũng đang chuyển đường xử lý yêu cầu từ Python sang Rust. Cổng AI bằng Rust của LiteLLM đang ở giai đoạn beta, và nhóm LiteLLM dự kiến các yêu cầu kiểu Anthropic /v1/messages sẽ được xử lý hoàn toàn bằng Rust trước ngày 1 tháng 12, với độ trễ thấp hơn khoảng 20 lần. Một số nền tảng mã nguồn mở, chẳng hạn như MLflow và AcruxCore, đã tích hợp cả cổng lẫn tính năng theo dõi dấu vết trong cùng một sản phẩm.

Lý do nên giữ chúng tách biệt

Việc tích hợp cổng vào công cụ theo dõi dấu vết cũng có cái giá của nó, trong đó lớn nhất là sự gắn kết chặt chẽ giữa hai thành phần. Khi dùng cổng riêng, một nhóm có thể đổi nhà cung cấp công cụ theo dõi bằng cách thay đổi callback ghi nhật ký. Nhưng nếu công cụ theo dõi đồng thời là cổng, URL cơ sở, khóa và mã định danh mô hình của mọi dịch vụ cũng phải thay đổi. Chẳng hạn, Langfuse ghi mã định danh mô hình theo định dạng credential:model.

Công cụ theo dõi dấu vết cũng trở thành một phần phụ thuộc trong thời gian chạy. Nếu hệ thống phụ trợ theo dõi dấu vết ngừng hoạt động, nhóm sẽ mất các dấu vết. Nếu cổng ngừng hoạt động, các lệnh gọi mô hình sẽ thất bại. Nhà cung cấp công cụ theo dõi dấu vết vận hành cổng giờ đây phải bảo đảm thời gian hoạt động ở mức cần thiết cho hạ tầng trọng yếu.

Các nhà cung cấp bảo mật cũng muốn chiếm vị trí tương tự trong luồng xử lý yêu cầu. Palo Alto Networks đã hoàn tất thương vụ mua lại Portkey, một cổng độc lập, vào tháng 5 năm 2026 và biến sản phẩm này thành cổng AI của nền tảng Prisma AIRS. Nhóm bảo mật có thể muốn tự kiểm soát cổng thay vì đặt nó bên trong một công cụ giám sát khả năng quan sát. Các cổng cũng trở thành mục tiêu của tin tặc, như vụ xâm phạm chuỗi cung ứng LiteLLM hồi tháng 3 cho thấy.

Cách các nhóm lựa chọn

Các nhóm có thể bắt đầu bằng cách liệt kê những việc cần thực hiện trước khi gọi mô hình. Nếu chỉ cần khả năng quan sát, một công cụ theo dõi dấu vết đặt cạnh luồng xử lý yêu cầu là đủ và không tạo thêm phần phụ thuộc trong thời gian chạy. Nếu còn cần ngân sách, chính sách khóa hoặc phê duyệt mô hình, họ sẽ cần một dạng cổng nào đó.

Tiếp theo là phạm vi hỗ trợ nhà cung cấp. Nhóm nên ghi lại mọi nhà cung cấp và định dạng API được gọi trong môi trường sản xuất, bao gồm Azure OpenAI và Bedrock, rồi đối chiếu danh sách đó với những gì mỗi cổng hiện hỗ trợ, thay vì chỉ xem lộ trình phát triển.

Các nhóm đã vận hành LiteLLM không có nhiều lý do để chuyển đổi cho đến khi một cổng beta cung cấp được tính năng mà họ còn thiếu. Giá trị chính mà cổng của công cụ theo dõi dấu vết mang lại là đặt lệnh gọi cổng vào bên trong dấu vết của tác tử; lợi ích đó phải đủ lớn để xứng đáng với việc chuyển đổi. Các nhóm bắt đầu từ đầu vẫn có thể giữ cổng thành một lớp riêng, ngay cả khi một nhà cung cấp cung cấp cả hai thành phần. Đặt URL cơ sở và khóa trong cùng một mô-đun cấu hình sẽ giúp việc chuyển đổi sau này chỉ cần thay đổi cấu hình, thay vì sửa mã.

Hầu hết các cổng này được gắn nhãn beta hoặc bản xem trước, vì vậy danh sách hạn chế sẽ nhanh chóng thu hẹp. Câu hỏi còn bỏ ngỏ là ai sẽ chịu trách nhiệm về luồng xử lý yêu cầu trong một công ty điển hình: nhóm giám sát khả năng quan sát, nhóm nền tảng vận hành cổng độc lập hay nhóm bảo mật. Năm nay, LangSmith và Langfuse đã xây dựng cổng riêng, còn Palo Alto Networks đã mua lại một cổng; tuy vậy, trong nhiều hệ thống, luồng xử lý yêu cầu vẫn đi qua LiteLLM.