API Ollama: cách hoạt động và các giải pháp thay thế

Hiểu về cửa sổ ngữ cảnh

Cửa sổ ngữ cảnh xác định tổng số token mà một LLM có thể xử lý trong một yêu cầu duy nhất, bao gồm cả prompt đầu vào và output được tạo ra. Trong các triển khai Ollama cục bộ, giới hạn này được quyết định bởi VRAM và RAM hệ thống khả dụng của bạn. Nếu mô hình vượt quá các ràng buộc vật lý này, quá trình suy luận sẽ thất bại hoặc suy giảm đáng kể. Các nhà cung cấp API lưu trữ, chẳng hạn như những dịch vụ cung cấp mô hình không kiểm duyệt, thường quảng cáo các cửa sổ ngữ cảnh cố định—thường là 100.000 token cho các kiến trúc hiện đại—cho phép bạn thiết kế các pipeline với các ranh giới có thể dự đoán được.

Khi di chuyển từ Ollama cục bộ sang API được lưu trữ, bạn phải tính đến sự phân chia giữa token đầu vào và token đầu ra. Một số dịch vụ áp dụng giới hạn đầu ra tối đa riêng biệt, ngay cả khi cửa sổ ngữ cảnh tổng thể lớn hơn. Sự khác biệt này rất quan trọng đối với các tác vụ tạo văn bản dài. Các thiết lập cục bộ cho phép bạn thử nghiệm với các ngữ cảnh lớn hơn bằng cách nâng cấp phần cứng, trong khi các dịch vụ được lưu trữ áp dụng các giới hạn nghiêm ngặt để duy trì hiệu suất đa người dùng. Luôn xác minh sự phân chia đầu vào/đầu ra cụ thể của endpoint đã chọn để tránh lỗi cắt ngắn trong thời gian chạy.

Lỗi đếm token

Sự khác biệt về token hóa là một nguồn lỗi API phổ biến, đặc biệt khi chuyển đổi giữa các phiên bản Ollama cục bộ và các dịch vụ được lưu trữ bên ngoài. Các mô hình khác nhau sử dụng các bộ token hóa khác nhau, có nghĩa là cùng một văn bản có thể tạo ra các số lượng token khác nhau. Các trình bao bọc Ollama cục bộ thường ước tính token dựa trên tệp mô hình cụ thể được tải, trong khi các API được lưu trữ đếm chính xác theo bộ token hóa của mô hình phục vụ. Điều này có thể dẫn đến việc chạm vào giới hạn tốc độ hoặc tràn ngữ cảnh không mong muốn nếu bạn dựa vào số lượng token cục bộ để quản lý các yêu cầu API bên ngoài.

Để giảm thiểu những lỗi này, hãy triển khai cơ chế đếm token mạnh mẽ trong mã khách hàng của bạn trước khi gửi yêu cầu. Sử dụng thư viện bộ token hóa chính thức tương ứng với mô hình của bạn (ví dụ: bộ token hóa Llama 3 hoặc Mistral) thay vì các xấp xỉ dựa trên ký tự. Khi sử dụng API không kiểm duyệt được lưu trữ, hãy xác minh rằng việc token hóa khớp với định dạng dự kiến của mô hình. Một số API cung cấp một endpoint chuyên dụng để đếm token, nhưng việc dựa vào tính toán phía máy khách đảm bảo bạn ở trong cửa sổ 100,000-token.

Xử lý phản hồi truyền phát

Các phản hồi truyền phát cho phép bạn nhận đầu ra của mô hình theo thời gian thực, cải thiện trải nghiệm người dùng cho các giao diện trò chuyện và các tác vụ tạo dài. Cả API Ollama cục bộ và các giải pháp thay thế được lưu trữ đều hỗ trợ Sự kiện được gửi qua máy chủ (SSE) để truyền phát. Tuy nhiên, cấu trúc của các khối truyền phát có thể khác nhau. Các phiên bản Ollama cục bộ có thể bao gồm siêu dữ liệu trong mọi khối, trong khi các API được lưu trữ thường nhóm các thống kê sử dụng hoặc lý do dừng vào khối cuối cùng.

Khi triển khai truyền phát (streaming), hãy đảm bảo máy khách của bạn có thể xử lý các đối tượng JSON từng phần và ghép chúng lại chính xác. Trong các API không kiểm duyệt được lưu trữ, chunk cuối cùng thường chứa đối tượng phản hồi hoàn chỉnh, bao gồm việc sử dụng token và lý do kết thúc. Nếu bạn đang xây dựng một ứng dụng trò chuyện, hãy đệm các token truyền phát và cập nhật giao diện người dùng theo từng bước. Luôn xử lý ngắt kết nối một cách thanh lịch, vì sự không ổn định của mạng có thể làm gián đoạn luồng dữ liệu khác với các lỗi phần cứng cục bộ. Hãy kiểm tra trình phân tích truyền phát của bạn trên cả các endpoint cục bộ và được lưu trữ để đảm bảo tính nhất quán về cấu trúc dữ liệu.

Cấu hình gọi hàm

Gọi hàm cho phép các mô hình xuất dữ liệu có cấu trúc mà ứng dụng của bạn có thể thực thi theo chương trình. Ollama cục bộ hỗ trợ sử dụng công cụ thông qua các kiến trúc mô hình cụ thể, nhưng chi tiết triển khai phụ thuộc vào dữ liệu huấn luyện của mô hình. Các API được lưu trữ chuẩn hóa điều này bằng cách tuân thủ lược đồ gọi hàm OpenAI, cho phép bạn sử dụng các SDK hiện có với ít thay đổi mã nhất. Điều này đặc biệt hữu ích cho các tác vụ như trích xuất dữ liệu, điền biểu mẫu hoặc kích hoạt các API bên ngoài.

Khi định cấu hình gọi hàm, hãy xác định rõ các công cụ của bạn với các tên, mô tả và lược đồ tham số riêng biệt. Cả dịch vụ cục bộ và dịch vụ lưu trữ đều yêu cầu tuân thủ nghiêm ngặt các lược đồ này; output JSON không hợp lệ sẽ gây ra lỗi phân tích cú pháp. Các mô hình không kiểm duyệt được lưu trữ thường xuất sắc trong việc gọi hàm vì chúng ít từ chối các định nghĩa công cụ phức tạp hoặc không theo quy ước hơn. Hãy kiểm tra kỹ các công cụ của bạn với các trường hợp biên, chẳng hạn như thiếu tham số hoặc kiểu dữ liệu không mong đợi, để đảm bảo mô hình xử lý chúng một cách mượt mà. Hãy nhớ rằng gọi hàm tiêu tốn token, vì vậy hãy theo dõi mức sử dụng của bạn để duy trì trong giới hạn tốc độ.

Xác thực chế độ JSON

Chế độ JSON buộc mô hình xuất ra JSON hợp lệ nghiêm ngặt, điều cần thiết cho việc tiêu thụ theo chương trình. Các phiên bản Ollama cục bộ hỗ trợ điều này thông qua tham số format, nhưng mức độ nghiêm ngặt khác nhau tùy theo mô hình. Các API được lưu trữ thường thực thi chế độ JSON nghiêm ngặt bằng cách từ chối bất kỳ đầu ra nào không khớp với lược đồ được chỉ định. Điều này giảm nhu cầu xử lý hậu kỳ và xử lý lỗi trong mã ứng dụng của bạn.

Để sử dụng chế độ JSON một cách hiệu quả, hãy cung cấp một lược đồ rõ ràng trong yêu cầu của bạn. Xác định các trường bắt buộc, các loại dữ liệu và các ràng buộc. Nếu mô hình xuất ra JSON không hợp lệ, API thường sẽ trả về lỗi, cho phép bạn thử lại với các prompt đã điều chỉnh. Trong các API không kiểm duyệt được lưu trữ, chế độ JSON đáng tin cậy vì các mô hình được tinh chỉnh để chính xác. Luôn xác thực đầu ra bằng trình phân tích JSON trước khi chuyển nó cho logic ứng dụng của bạn. Điều này ngăn ngừa các lỗi thời gian chạy do các chuỗi bị lỗi hoặc thiếu dấu ngoặc.

Giới hạn tốc độ (300 RPM)

Giới hạn tốc độ bảo vệ cơ sở hạ tầng API khỏi quá tải và đảm bảo sử dụng công bằng. Các phiên bản Ollama cục bộ không có giới hạn tốc độ vốn có, bị hạn chế chỉ bởi phần cứng của bạn. Tuy nhiên, các dịch vụ được lưu trữ thực thi các giới hạn nghiêm ngặt, chẳng hạn như 300 yêu cầu mỗi phút trên mỗi khóa API. Giới hạn này áp dụng cho cả các yêu cầu thành công và thất bại, vì vậy mã không hiệu quả có thể làm cạn kiệt hạn ngạch của bạn một cách nhanh chóng.

Triển khai cơ chế backoff theo cấp số nhân trong mã client của bạn để xử lý các lỗi giới hạn tốc độ một cách mượt mà. Theo dõi các chỉ số sử dụng của bạn để dự đoán các giới hạn trước khi chúng bị đạt tới. Một số API lưu trữ cũng áp đặt các giới hạn yêu cầu đồng thời, chẳng hạn như 8 yêu cầu đồng thời mỗi khóa. Điều này có nghĩa là bạn không thể làm ngập API bằng các yêu cầu đồng thời mà không gây ra lỗi. Đối với các ứng dụng có thông lượng cao, hãy cân nhắc sử dụng nhiều khóa API để phân phối tải. Luôn kiểm tra tài liệu API để biết chi tiết cụ thể về giới hạn tốc độ, vì chúng khác nhau tùy theo nhà cung cấp và gói dịch vụ.

Vấn đề thanh toán và tín dụng

Các API được lưu trữ thường hoạt động theo mô hình tín dụng trả trước, nơi bạn thanh toán cho việc sử dụng token thực tế. Chi phí được tính dựa trên token đầu vào và token đầu ra, với các mức giá khác nhau cho mỗi loại. Ví dụ: token đầu vào có thể tốn $0,15 mỗi triệu, trong khi token đầu ra tốn $0,50 mỗi triệu. Các lỗi và từ chối thường miễn phí, giúp giảm lãng phí. Tín dụng thường không hết hạn, cho phép bạn nạp tiền khi cần.

Các phương thức thanh toán khác nhau, với nhiều dịch vụ ưu tiên tiền mã hóa để ẩn danh và tốc độ. Số tiền nạp tối thiểu, chẳng hạn như $20, và cơ chế phần thưởng cho các khoản gửi lớn là phổ biến. Nếu bạn gặp phải các vấn đề về hóa đơn, chẳng hạn như tính phí kép, hãy liên hệ với bộ phận hỗ trợ để giải quyết. Khác với các mô hình đăng ký, tín dụng trả trước cho phép bạn kiểm soát hoàn toàn chi tiêu. Luôn theo dõi bảng điều khiển sử dụng của bạn để tránh các chi phí không mong muốn. Đối với các nhà phát triển đang kiểm tra tích hợp, nhiều nhà cung cấp cung cấp một khoản tín dụng dùng thử nhỏ, cho phép bạn xác minh thiết lập của mình mà không cần thanh toán ngay lập tức.

Logic từ chối nội dung

Từ chối nội dung xác định khi nào LLM chặn các chủ đề cụ thể, chẳng hạn như nội dung người lớn hoặc quan điểm chính trị gây tranh cãi. Các mô hình Ollama cục bộ khác nhau rất nhiều về hành vi từ chối tùy thuộc vào mô hình cơ sở và tinh chỉnh. Các API không kiểm duyệt được lưu trữ được thiết kế để giảm thiểu việc từ chối đối với nội dung người lớn hợp pháp, nghiên cứu bảo mật và các chủ đề gây tranh cãi. Điều này làm cho chúng lý tưởng cho các ứng dụng nơi tự do sáng tạo được ưu tiên hơn an toàn thương hiệu.

Tuy nhiên, không kiểm duyệt không có nghĩa là không hạn chế. Hầu hết các API được lưu trữ vẫn thực thi các giới hạn cứng, chẳng hạn như chặn nội dung tình dục liên quan đến trẻ vị thành niên. Việc từ chối thường được đánh dấu bằng một lý do kết thúc cụ thể trong phản hồi API. Khi tích hợp, hãy xử lý những từ chối này một cách duyên dáng bằng cách ghi lại chúng và điều chỉnh logic ứng dụng của bạn nếu cần. Ví dụ: nếu người dùng yêu cầu một loại nội dung cụ thể bị chặn, hãy thông báo rõ ràng cho họ mà không làm gián đoạn trải nghiệm người dùng. Hiểu những ranh giới này giúp bạn thiết kế các ứng dụng mạnh mẽ hơn.

Hướng dẫn khác

• Các giải pháp thay thế Ollama: API không kiểm duyệt dạng lưu trữ
• Cách dùng Ollama với GUI (và điểm cuối dự phòng được lưu trữ)
• Giá API Ollamansfw: Giải thích chi phí token