OpenAI GPT-OSS: Cách chạy cục bộ hoặc tự lưu trữ trên đám mây, Yêu cầu phần cứng

GPT-OSS được thiết kế đặc biệt tốt cho khả năng truy cập: gpt-oss-20B biến thể được thiết kế để chạy trên một GPU tiêu dùng duy nhất (~ 16 GB VRAM) hoặc máy tính xách tay cao cấp mới sử dụng bản dựng GGUF lượng tử hóa, trong khi gpt-oss-120B—mặc dù có tổng cộng 117B tham số—được cung cấp kèm theo các thủ thuật MoE/tham số chủ động và lượng tử hóa MXFP4 cho phép nó chạy trên một GPU H100-class (khoảng 80 GB) hoặc trên các thiết lập nhiều GPU. Việc triển khai một mô hình kiểu GPT nguồn mở (thường được gọi là "GPT OSS") — dù là mô hình nhỏ gọn 6–7B cho các ứng dụng cục bộ hay mô hình 70B+ cho các dịch vụ sản xuất — đều đặt ra cùng một câu hỏi cốt lõi: Làm thế nào để chạy GPT-OSS cục bộ hoặc tự lưu trữ trên đám mây, Yêu cầu phần cứng

Mô hình GPT-OSS là gì và yêu cầu về phần cứng của chúng là gì?

GPT-OSS là gì?

GPT-OSS là họ mô hình ngôn ngữ lớn, trọng lượng mở mới được OpenAI phát hành gần đây (hai biến thể tiêu biểu tại thời điểm phát hành: phiên bản tham số ~20B và ~120B). Chúng được cung cấp với các lựa chọn tối ưu (hỗn hợp chuyên gia, lượng tử hóa MXFP4 gốc trong bản phân phối của OpenAI, các cải tiến thưa thớt/dày đặc) cho phép các số lượng tham số tương đối lớn này chạy trên bộ nhớ ít hơn đáng kể so với các bản sao FP32/FP16 đơn giản. Bản phát hành này rõ ràng nhằm mục đích giúp các mô hình mạnh mẽ có thể chạy rộng rãi hơn và tùy chỉnh được bên ngoài các nhà phát triển siêu quy mô.

Thông tin sản phẩm chính (chịu tải):

gpt-oss-20B được thiết kế để chạy trên một GPU tiêu dùng duy nhất với ~16 GB VRAM (và có thể sử dụng trên máy tính để bàn/máy tính xách tay có lượng tử hóa GGUF).
gpt-oss-120B (≈117B tham số, ~5.1B hoạt động các tham số trong thiết kế MoE của OpenAI) được thiết kế sao cho mô hình có thể vừa với một H100/A100 80 GB khi sử dụng MXFP4 và hỗ trợ thời gian chạy cụ thể hoặc trên các thiết lập nhiều GPU.

Các yếu tố phần cứng quyết định các yêu cầu

Kích thước và kiến trúc mô hình – MoE và các lớp thưa/dày có thể thay đổi bộ nhớ kích hoạt và bộ nhớ làm việc. (GPT-OSS sử dụng các thành phần theo kiểu kết hợp chuyên gia.)
Độ chính xác và lượng tử hóa – FP32, FP16, BF16, 8-bit, 4-bit (GPTQ/AWQ/MXFP4). Độ chính xác thấp hơn làm giảm bộ nhớ nhưng có thể ảnh hưởng đến độ trễ và độ trung thực số. OpenAI cung cấp trọng số lượng tử MXFP4 cho GPT-OSS.
Độ dài ngữ cảnh (độ dài chuỗi) – ngữ cảnh dài hơn làm tăng tỷ lệ sử dụng bộ đệm kích hoạt; GPT-OSS hỗ trợ ngữ cảnh cực dài (lên đến cửa sổ mã thông báo rất lớn trong thiết kế của chúng), làm tăng nhu cầu bộ nhớ.
Kích thước lô và tính đồng thời – Việc phục vụ nhiều người dùng đồng thời sẽ tăng gấp đôi bộ nhớ cho các hoạt động kích hoạt và bộ nhớ đệm. Các nền tảng như vLLM, DeepSpeed và Triton cố gắng xử lý hàng loạt và chia sẻ các hoạt động kích hoạt trên nhiều yêu cầu một cách hiệu quả.
Chi phí khung phục vụ – các máy chủ suy luận khác nhau (vLLM, text-generation-inference, llama.cpp, ONNX Runtime) bổ sung thêm các chi phí và tối ưu hóa khác nhau.

Cái gì "phù hợp" ở đâu: quy tắc ghi nhớ sơ bộ

Hai khái niệm quan trọng đối với việc lập kế hoạch phần cứng:

Tổng số tham số — giới hạn trên của kích thước mô hình (117B so với 21B).
Bộ kích hoạt/hoạt động — trong MoE hoặc một số cài đặt độ chính xác nhất định, bộ nhớ hoạt động cần thiết khi suy luận có thể nhỏ hơn nhiều so với các byte tham số thô.

Nguyên tắc thực tế:

GPU/máy tính xách tay cạnh 16 GB → có thể cho gpt-oss-20b nếu bạn sử dụng cấu hình tiết kiệm bộ nhớ do mô hình cung cấp (hoặc lượng tử hóa mạnh mẽ thành 4-bit/NF4/AWQ).
80 GB H100 / A100 80GB → lưu trữ GPU đơn cho gpt-oss-120b trong thiết lập được đề xuất của họ. Đối với thông lượng sản xuất, bạn vẫn có thể cần nhiều GPU để xử lý hàng loạt, dự phòng hoặc giảm độ trễ khi xử lý đồng thời.
Thiết lập nhiều GPU lớn (cụm A100/H100) → bắt buộc nếu bạn muốn chạy nhiều người dùng đồng thời ở độ trễ thấp hoặc thực hiện tinh chỉnh/huấn luyện chuyên sâu. DeepSpeed/ZeRO và tính năng song song tenxơ tự động cho phép bạn chia nhỏ các mô hình lớn trên nhiều GPU.

Tóm tắt: Để thử nghiệm và sử dụng cục bộ nhẹ nhàng, hãy lên kế hoạch sử dụng GPU 16–24 GB (hoặc CPU + lượng tử hóa mạnh). Để suy luận GPU đơn lẻ cho mô hình gpt-oss lớn, bạn sẽ nhắm đến H100 80 GB, nếu không, hãy sử dụng phân vùng đa GPU.

Cần bao nhiêu sức mạnh tính toán để triển khai GPT-OSS trong thực tế?

Suy luận so với đào tạo: ngân sách khác nhau rất nhiều

Sự suy luận: chi phí chủ yếu là bộ nhớ GPU (VRAM) và kernel được tối ưu hóa. Với thời gian chạy được tối ưu hóa (vLLM, TensorRT, DeepSpeed-Inference) và lượng tử hóa, suy luận trên gpt-oss-20b có thể thực hiện được trên GPU tiêu dùng 16 GB; mô hình MoE 120 GB được thiết kế để phù hợp với H100 80 GB.
Tinh chỉnh / đào tạo toàn diện: lớn hơn gấp nhiều lần — bạn sẽ cần nhiều GPU hoặc các phiên bản đào tạo chuyên biệt (cụm H100/A100 đa nút, ngân sách DFLOP và I/O lưu trữ). Bài viết này chủ yếu tập trung vào các công thức suy luận/tự lưu trữ và tinh chỉnh nhẹ (QLoRA / LoRA), chứ không phải đào tạo trước nhiều tuần.

CPU so với GPU so với bộ tăng tốc chuyên dụng

Chỉ CPU: có thể thực hiện với GGUF/llama.cpp và các bản dựng lượng tử hóa nhỏ, đánh đổi độ trễ để giảm chi phí. Việc chạy 20B trên CPU mà không lượng tử hóa là không thực tế. Hãy sử dụng CPU khi quyền riêng tư hoặc hoạt động ngoại tuyến cục bộ là cần thiết và nhu cầu thông lượng của bạn thấp.
GPU: ưu tiên về độ trễ và thông lượng. Các GPU ML hiện đại (A100/H100/4090/4080) khác nhau đáng kể về HBM/VRAM và kết cấu liên GPU. Tài liệu gpt-oss khuyến nghị sử dụng H100 cho biến thể 120B.
TPU / AMD MI300X: được hỗ trợ bởi một số thời gian chạy (bản dựng vLLM/ROCm) và có thể tiết kiệm chi phí trên một số đám mây nhất định — hãy kiểm tra tài liệu của nhà cung cấp khi chọn phần cứng.

Làm thế nào để chạy GPT-OSS cục bộ với ngân sách hạn chế? (mã + hướng dẫn từng bước)

Dưới đây là hai cách tiếp cận thực tế: (A) Máy tính xách tay/máy tính để bàn GPU với VRAM ~16–24 GB sử dụng lượng tử hóa 4 bit và (B) CPU/GPU thấp (ngoại tuyến) sử dụng llama.cpp (GGUF) hoặc các bản dựng lượng tử hóa nhỏ. Cả hai đều được các chuyên gia sử dụng rộng rãi khi ngân sách và năng lực hạn hẹp.

Lưu ý: hướng dẫn này giả định bạn đang sử dụng môi trường Python (khuyến nghị Linux để hỗ trợ CUDA tốt nhất). Đối với Windows, hãy sử dụng WSL2 để tương thích tốt nhất với các chuỗi công cụ GPU.

A. Tuyến GPU (được khuyến nghị để có độ trễ tốt nhất với ngân sách hạn hẹp) — lượng tử hóa + tải bằng bitsandbytes (4 bit)

Con đường này nhằm mục đích chạy openai/gpt-oss-20b trên một GPU tiêu dùng duy nhất (ví dụ: 24 GB 4090 hoặc 16 GB 4080). Nó sử dụng lượng tử hóa 4 bit bitsandbytes và Hugging Face transformers bản đồ thiết bị/tăng tốc.

Bước 1 — Cài đặt cơ bản

# Linux + CUDA (example); pick the correct torch CUDA wheel for your driver

python -m pip install -U pip
pip install torch --index-url https://download.pytorch.org/whl/cu121  # pick your CUDA version

pip install -U transformers accelerate bitsandbytes safetensors

(Nếu bạn sử dụng conda, hãy tạo một env và cài đặt torch wheel tương thích với CUDA cho nền tảng của bạn.)

Bước 2 — (Tùy chọn) Đăng nhập vào Hugging Face để tải xuống các tệp lớn

huggingface-cli login

Bước 3 — Ví dụ về Python (tải mô hình lượng tử 4 bit)

# save as run_gptoss_4bit.py

import torch
from transformers import AutoTokenizer, AutoModelForCausalLM, BitsAndBytesConfig

model_id = "openai/gpt-oss-20b"

bnb_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16,
    bnb_4bit_use_double_quant=True,
    bnb_4bit_quant_type="nf4"   # or "fp4"/"nf4" depending on support

)

tokenizer = AutoTokenizer.from_pretrained(model_id, use_fast=True)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    device_map="auto",                 # let transformers pick GPU + CPU offload if needed

    quantization_config=bnb_config,
    torch_dtype=torch.float16,
    trust_remote_code=True
)

prompt = "Write a concise summary of quantization for LLMs."
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
out = model.generate(**inputs, max_new_tokens=200)
print(tokenizer.decode(out, skip_special_tokens=True))

Ghi chú & mẹo

Sử dụng device_map="auto" so transformers sử dụng chế độ giảm tải CPU/GPU tự động. Nếu bạn chỉ có một GPU, device_map="auto" thường sẽ đưa mọi thứ lên GPU và chuyển tải những gì cần thiết lên CPU.
Nếu bạn hết VRAM, hãy thêm --offload_folder ./offload (hoặc thiết lập offload_folder in from_pretrained) để chuyển tải tenxơ sang NVMe.
Phương pháp Hugging Face + bitsandbytes đã được ghi chép rộng rãi; xem hướng dẫn về máy biến áp 4 bit để biết chi tiết.

B. Tuyến CPU / ngân sách nhỏ (llama.cpp / GGUF)

Nếu bạn không có GPU hoặc GPU rất nhỏ, llama.cpp / Bản dựng GGUF (và các tệp lượng tử AWQ/GPTQ) cho phép bạn chạy các mô hình trên CPU với độ trễ chấp nhận được đối với người dùng đơn lẻ.

Bước 1 — Cài đặt llama.cpp / Python bindings

# Download and build (Linux)

git clone --recursive https://github.com/ggerganov/llama.cpp.git
cd llama.cpp
make
# Python bindings (optional)

pip install llama-cpp-python

Bước 2 — Chuyển đổi safetensor → GGUF (nếu có tập lệnh chuyển đổi cho gpt-oss)
OpenAI/Hugging Face cung cấp các bộ cảm biến an toàn; bộ chuyển đổi cộng đồng (hoặc tập lệnh trong llama.cpp) chuyển đổi sang GGUF. Lệnh chính xác phụ thuộc vào dòng điện hiện tại llama.cpp công cụ; kiểm tra kho lưu trữ README để biết convert.py/convert-safetensors-to-gguf. (Các chủ đề cộng đồng thảo luận về việc chuyển đổi sang các mô hình mới.)

Bước 3 — Chạy mô hình với llama.cpp

# basic inference (example)

./main -m ./gpt-oss-20b.gguf -p "Explain GGUF and quantization in one paragraph." -n 256

Ghi chú và sự đánh đổi

Tốc độ CPU chậm hơn nhiều. Hãy sử dụng tuyến đường này để thử nghiệm, bảo mật hoặc xử lý các tác nhân cục bộ có độ đồng thời rất thấp.
Việc tạo ra các đầu ra dài hoặc phục vụ nhiều người dùng đồng thời trên CPU là không thực tế; hãy chuyển sang GPU để sản xuất.

Bản dựng lượng tử trên đĩa (GPTQ/AWQ)

Nếu bạn cần nén một mô hình lớn vào một GPU nhỏ (ví dụ: 8–12 GB), kết quả từ cộng đồng cho thấy lượng tử hóa theo kiểu GPTQ/AWQ có thể khiến một số mô hình 20B chạy trên GPU VRAM thấp — nhưng việc chuyển đổi thường cần chi tiết CPU, RAM và một GPU trung gian trong quá trình chuyển đổi. Công cụ: GPTQ-for-LLaMa, AutoGPTQ (đã lưu trữ), AWQvà QLLM.

Mẹo thực tế cho ngân sách hạn hẹp

Ưu tiên các điểm kiểm tra lượng tử 4 bit (GPTQ/AWQ/MXFP4) — thường là sự khác biệt giữa “chạy trong 12 GB” và “yêu cầu 80 GB”.
Giới hạn độ dài ngữ cảnh Đối với suy luận ngân sách: ngữ cảnh dài sẽ làm quá tải bộ nhớ đệm kích hoạt. Nếu bạn phải lưu trữ ngữ cảnh dài, hãy cân nhắc các chiến lược giảm tải.
Sử dụng bộ nhớ hợp nhất / chuyển tải nvmem một cách cẩn thận — các khung có thể cung cấp khả năng chuyển tải CPU/NVMe (DeepSpeed ZeRO-Offload / ZeRO-Infinity), nhưng điều này làm tăng độ trễ.

Làm thế nào để tự lưu trữ GPT-OSS trên các nhà cung cấp dịch vụ đám mây (hướng dẫn thực tế và gợi ý về chi phí)?

Nên chọn phần cứng đám mây nào?

GPU đơn 80 GB H100: phù hợp để lưu trữ gpt-oss-120b cho lưu lượng truy cập từ nhỏ đến trung bình. Theo thuật ngữ AWS, các phiên bản P5 cung cấp phần cứng H100; các biến thể GPU đơn (ra mắt năm 2025) giúp việc điều chỉnh kích thước phù hợp cho suy luận trở nên tiết kiệm hơn. Sử dụng họ P5/ND H100 tùy thuộc vào nhà cung cấp.
Đa GPU (8× H100): Để đạt thông lượng cao và dự phòng, hãy sử dụng p5.48x, p5dn hoặc cụm tương đương. NVidia NVLink/NVSwitch trong cùng một phiên bản giúp giảm chi phí giao tiếp giữa các GPU.
Những đám mây thay thế: CoreWeave, Lambda Labs, Paperspace, Runpod — thường có giá thuê GPU theo yêu cầu/tại chỗ rẻ hơn cho suy luận bùng nổ. Hãy sử dụng chúng cho phát triển trước khi đầu tư vào cơ sở hạ tầng dài hạn.
Sản xuất tiên tiến / nặng: AWS p5 (H100) (8 × H100 80GB mỗi phiên bản) — cho thông lượng cao nhất trên mỗi nút và nhu cầu GPU đơn 80GB trở lên, hoặc cho 120B trở lên với ít phân tách hơn. P5 cung cấp H100 và bộ nhớ cục bộ NVMe dung lượng lớn.

rmers, bộ chứa tạo văn bản-suy luận (TGI)/NVIDIA TGI hoặc thiết lập suy luận DeepSpeed.

Cung cấp NVMe cục bộ nhanh nếu bạn dự định chuyển tải các trạng thái kích hoạt lớn (ZeRO-Infinity). Các nút P4/P5 thường có NVMe cục bộ và băng thông mạng rất cao. ()
Bảo mật và mạng — đặt các điểm cuối suy luận phía sau bộ cân bằng tải, sử dụng các nhóm tự động mở rộng cho giao diện người dùng và phân tách các mối quan tâm (phục vụ mô hình so với định tuyến yêu cầu).
Giám sát & SLO — theo dõi mức sử dụng GPU, bộ nhớ, mã thông báo/giây, độ trễ p95 và lỗi; sử dụng Prometheus + Grafana để đo lường.

Ví dụ về quy trình tự lưu trữ đám mây (AWS P4/P5)

Chọn trường hợp (p4d/p5) dựa trên nhu cầu bộ nhớ của mô hình. Đối với gpt-oss-20B, một phiên bản 16–32 GB là đủ; đối với gpt-oss-120B, hãy chọn phiên bản HBM 80 GB hoặc đa GPU.
Chuẩn bị AMI / hình ảnh — sử dụng AMI của nhà cung cấp tích hợp CUDA, cuDNN và PyTorch được tối ưu hóa (hoặc hình ảnh của nhà cung cấp với trình điều khiển NVIDIA).
Cài đặt ngăn xếp phục vụ: vLLM, bộ chuyển đổi, bộ chứa tạo văn bản-suy luận (TGI)/NVIDIA TGI hoặc thiết lập suy luận DeepSpeed.
Cung cấp NVMe cục bộ nhanh nếu bạn dự định chuyển tải các trạng thái kích hoạt lớn (ZeRO-Infinity). Các nút P4/P5 thường có NVMe cục bộ và băng thông mạng rất cao.
Bảo mật và mạng — đặt các điểm cuối suy luận phía sau bộ cân bằng tải, sử dụng các nhóm tự động mở rộng cho giao diện người dùng và phân tách các mối quan tâm (phục vụ mô hình so với định tuyến yêu cầu).
Giám sát & SLO — theo dõi mức sử dụng GPU, bộ nhớ, mã thông báo/giây, độ trễ p95 và lỗi; sử dụng Prometheus + Grafana để đo lường.

Mẫu kế hoạch tự lưu trữ (gpt-oss-20b, sản xuất quy mô nhỏ)

Mục tiêu: phục vụ ~20 người dùng đồng thời, mục tiêu phản hồi 1–2 giây, nhạy cảm với chi phí.

Sơ thẩm: 1× A10G / 1× GPU 24 GB (ví dụ: G5 / A10G / RTX 6000) cho model + 1× máy chủ khởi động CPU nhỏ.
Runtime: vLLM là máy chủ mô hình (xử lý liên tục) + cổng CometAPI.
Quy mô tự động: sử dụng nhóm tự động điều chỉnh tỷ lệ với GPU AMI và ALB + tự động điều chỉnh tỷ lệ theo chiều ngang theo số liệu CPU/GPU.
Bảo quản: NVMe cục bộ để lưu trữ mô hình; kho lưu trữ đối tượng (S3) để lưu trữ mô hình lạnh.
Giám sát: Prometheus + Grafana, theo dõi mức sử dụng GPU, độ trễ, độ dài hàng đợi.
Bảo mật : VPC, mạng con riêng, vai trò IAM để lưu trữ mô hình, chứng chỉ TLS.

Mẫu kế hoạch tự lưu trữ (gpt-oss-120b, sản xuất)

Mục tiêu: độ trễ thấp cho nhiều người dùng/doanh nghiệp cùng lúc.

Sơ thẩm: 1× H100 80 GB (một GPU) cho đường cơ sở; mở rộng theo chiều ngang hoặc sử dụng các phiên bản p5 đa GPU để tăng thông lượng. Để tăng thông lượng, hãy sao chép dịch vụ một GPU (dữ liệu song song) hoặc phân mảnh mô hình trên nhiều GPU bằng DeepSpeed (tensor/pipeline).
Runtime: DeepSpeed-Inference với TP tự động hoặc NVIDIA TensorRT (nếu có). Việc vLLM hỗ trợ MoE/Multi-GPU và kernel được điều chỉnh cũng có thể hữu ích.
Kubernetes: sử dụng K8s với các plugin thiết bị và NVMe cục bộ; sử dụng thử nghiệm hỗn loạn để đảm bảo tính khả dụng.
Tối ưu hóa chi phí: các phiên bản dành riêng cho tải có thể dự đoán được; các phiên bản tại chỗ cho khối lượng công việc hàng loạt.

Ví dụ: khởi động một container phục vụ vLLM cho gpt-oss-20b

# assume vllm is installed and CUDA is set up

vllm serve --model openai/gpt-oss-20b --port 8000 --num-gpus 1

Sau đó hướng front-end của bạn tới http://<host>:8000/v1/chat/completions (vLLM hỗ trợ API tương thích với OpenAI).

Mẹo tối ưu hóa chi phí

Máy ảo Spot/Preemptive rẻ hơn 50–80% nhưng yêu cầu phải kiểm tra điểm hoặc chiến lược hồi sinh nhanh.
Lượng tử hóa mô hình giảm nhu cầu về loại phiên bản (ví dụ: 120B lượng tử có thể được phục vụ trên ít GPU hơn nếu công cụ hỗ trợ khử lượng tử hóa tức thời).
Sử dụng các họ thể hiện được tối ưu hóa chỉ suy luận (P5/P4/A2 Ultra) với NVLink/NVSwitch cao khi thực hiện song song mô hình đa GPU; băng thông mạng quan trọng đối với phân mảnh giữa các GPU.

Làm thế nào để cân bằng chi phí, độ trễ và chất lượng mô hình

Lượng tử hóa: tốc độ so với chất lượng

Lượng tử hóa mạnh mẽ (2-4 bit, AWQ/GPTQ) → tiết kiệm bộ nhớ đáng kể và thường giảm chất lượng ở mức vừa phải cho nhiều tác vụ. Sử dụng AWQ/GPTQ cho sản xuất nếu bạn đánh giá chuẩn khối lượng công việc cụ thể. Việc chuyển đổi có thể yêu cầu bộ nhớ CPU lớn trong quá trình lượng tử hóa.

Độ chính xác hỗn hợp và tối ưu hóa hạt nhân

Sử dụng fp16, bf16 Nếu được hỗ trợ; hãy kết hợp với các kernel CUDA chuyên dụng (FasterTransformer, TensorRT) để đạt thông lượng tối đa. Nvidia/TensorRT cung cấp giải mã suy đoán và các kernel được tối ưu hóa cho nhiều bộ biến áp (NVIDIA cung cấp bộ điều hợp GPT-OSS được tối ưu hóa).

An toàn và khả năng quan sát

Mô hình trọng số mở đồng nghĩa với việc bạn chịu trách nhiệm giám sát việc sử dụng sai mục đích, rò rỉ và trôi dạt dữ liệu. Triển khai ghi nhật ký yêu cầu, bộ lọc nội dung, giới hạn tốc độ và kiểm duyệt vòng lặp. Ghi chú phát hành và thẻ mô hình của OpenAI nhấn mạnh vào quá trình thử nghiệm nội bộ và đánh giá bên ngoài — nhưng việc tự lưu trữ sẽ chuyển giao ranh giới an toàn cho bạn.

Lời cuối

GPT-OSS tạo ra bước đột phá: các mô hình trước đây đòi hỏi cơ sở hạ tầng riêng biệt khổng lồ giờ đây dễ tiếp cận hơn nhờ các lựa chọn kiến trúc cẩn thận và phân phối lượng tử. Nhưng triển khai vẫn là một kỷ luật: việc định cỡ phần cứng phải xem xét độ chính xác của mô hình, độ dài ngữ cảnh và cấu hình đồng thời của ứng dụng. Sử dụng các nền tảng thử nghiệm nhỏ (lượng tử hóa 20B) để đo token/giây và độ trễ p95, sau đó nhân lên để ước tính chi phí điện toán đám mây và sản xuất.

Cách truy cập API GPT-OSS

CometAPI là một nền tảng API hợp nhất tổng hợp hơn 500 mô hình AI từ các nhà cung cấp hàng đầu—chẳng hạn như dòng GPT của OpenAI, Gemini của Google, Claude của Anthropic, Midjourney, Suno, v.v.—thành một giao diện duy nhất thân thiện với nhà phát triển. Bằng cách cung cấp xác thực nhất quán, định dạng yêu cầu và xử lý phản hồi, CometAPI đơn giản hóa đáng kể việc tích hợp các khả năng AI vào ứng dụng của bạn. Cho dù bạn đang xây dựng chatbot, trình tạo hình ảnh, nhà soạn nhạc hay đường ống phân tích dựa trên dữ liệu, CometAPI cho phép bạn lặp lại nhanh hơn, kiểm soát chi phí và không phụ thuộc vào nhà cung cấp—tất cả trong khi khai thác những đột phá mới nhất trên toàn bộ hệ sinh thái AI.

Các nhà phát triển có thể truy cập GPT-OSS-20B và GPT-OSS-120B thông qua Sao chổiAPI, các phiên bản mẫu mới nhất được liệt kê là tính đến ngày xuất bản bài viết. Để bắt đầu, hãy khám phá các khả năng của mẫu trong Sân chơi và tham khảo ý kiến Hướng dẫn API để biết hướng dẫn chi tiết. Trước khi truy cập, vui lòng đảm bảo bạn đã đăng nhập vào CometAPI và lấy được khóa API. Sao chổiAPI cung cấp mức giá thấp hơn nhiều so với giá chính thức để giúp bạn tích hợp.