OpenAI GPT-OSS: วิธีการรันในเครื่องหรือโฮสต์เองบนคลาวด์ ความต้องการด้านฮาร์ดแวร์

GPT-OSS ได้รับการออกแบบมาเป็นอย่างดีเพื่อการเข้าถึง: จีพีที-ออส-20บี ตัวแปรนี้ได้รับการออกแบบมาให้ทำงานบน GPU สำหรับผู้บริโภคตัวเดียว (~16 GB VRAM) หรือแล็ปท็อประดับไฮเอนด์รุ่นใหม่ๆ ที่ใช้การสร้าง GGUF แบบควอนไทซ์ ในขณะที่ จีพีที-ออส-120บี—แม้จะมีพารามิเตอร์รวม 117 พันล้าน — แต่มาพร้อมกับเทคนิค MoE/active-parameter และการวัดปริมาณ MXFP4 ที่ทำให้สามารถทำงานบน GPU ระดับ H100 ตัวเดียว (≈80 GB) หรือบนการตั้งค่า GPU หลายตัว การปรับใช้โมเดลโอเพนซอร์สสไตล์ GPT (มักเรียกว่า "GPT OSS") — ไม่ว่าจะเป็นโมเดลขนาดกะทัดรัด 6–7 พันล้านสำหรับแอปพลิเคชันภายใน หรือโมเดล 70 พันล้าน+ สำหรับบริการการผลิต — ก่อให้เกิดคำถามหลักเดียวกัน: วิธีการเรียกใช้ GPT-OSS ในเครื่องหรือโฮสต์ด้วยตนเองบนคลาวด์ ตามความต้องการด้านฮาร์ดแวร์

โมเดล GPT-OSS คืออะไร และมีข้อกำหนดด้านฮาร์ดแวร์อะไรบ้าง

GPT-OSS คืออะไร?

GPT-OSS คือตระกูลโมเดลภาษาขนาดใหญ่แบบ open-weight ที่เพิ่งเปิดตัวของ OpenAI (มีสองตัวแปรหลัก ณ เวลาที่เปิดตัว: เวอร์ชันพารามิเตอร์ ~20B และ ~120B) GPT-OSS มาพร้อมกับตัวเลือกที่ได้รับการปรับแต่งให้เหมาะสมที่สุด (การผสมผสานของผู้เชี่ยวชาญ, การวัดปริมาณแบบเนทีฟ MXFP4 ในการกระจายของ OpenAI, นวัตกรรมแบบเบาบาง/หนาแน่น) ซึ่งช่วยให้จำนวนพารามิเตอร์ที่ค่อนข้างใหญ่เหล่านี้ทำงานบนหน่วยความจำที่น้อยกว่าสำเนา FP32/FP16 แบบ naïve อย่างมาก เวอร์ชันนี้มีจุดประสงค์อย่างชัดเจนเพื่อให้โมเดลที่มีประสิทธิภาพสามารถรันและปรับแต่งได้อย่างกว้างขวางยิ่งขึ้น นอกเหนือจากไฮเปอร์สเกลเลอร์

ข้อมูลผลิตภัณฑ์หลัก (รับน้ำหนัก):

จีพีที-ออส-20บี มีวัตถุประสงค์เพื่อทำงานบน GPU สำหรับผู้บริโภคตัวเดียวที่มี VRAM ประมาณ 16 GB (และสามารถใช้บนเดสก์ท็อป/แล็ปท็อปที่มีการวัดเชิงปริมาณ GGUF)
จีพีที-ออส-120บี (≈117B พารามิเตอร์, ~5.1B คล่องแคล่ว พารามิเตอร์ในดีไซน์ MoE ของ OpenAI ได้รับการออกแบบมาเพื่อให้โมเดลพอดีกับ H100 / A100 ขนาด 80 GB ตัวเดียวเมื่อใช้ MXFP4 และการรองรับรันไทม์เฉพาะ หรือในการตั้งค่า GPU หลายตัว

ปัจจัยฮาร์ดแวร์ที่กำหนดความต้องการ

ขนาดโมเดลและสถาปัตยกรรม – MoE และเลเยอร์ที่เบาบาง/หนาแน่นสามารถเปลี่ยนหน่วยความจำการเปิดใช้งานและการทำงาน (GPT-OSS ใช้ส่วนประกอบสไตล์การผสมผสานของผู้เชี่ยวชาญ)
ความแม่นยำและการวัดปริมาณ – FP32, FP16, BF16, 8 บิต, 4 บิต (GPTQ/AWQ/MXFP4) ความแม่นยำที่ต่ำกว่าจะลดหน่วยความจำ แต่อาจส่งผลต่อความหน่วงและความเที่ยงตรงเชิงตัวเลข OpenAI มอบน้ำหนักเชิงปริมาณ MXFP4 สำหรับ GPT-OSS
ความยาวบริบท (ความยาวลำดับ) – บริบทที่ยาวขึ้นจะเพิ่มการใช้แคชการเปิดใช้งานตามสัดส่วน; GPT-OSS รองรับบริบทที่ยาวมาก (มากถึงหน้าต่างโทเค็นขนาดใหญ่ในการออกแบบ) ซึ่งทำให้ความต้องการหน่วยความจำเพิ่มขึ้นหลายเท่า
ขนาดชุดและการทำงานพร้อมกัน การให้บริการผู้ใช้พร้อมกันหลายคนจะช่วยเพิ่มหน่วยความจำสำหรับการเปิดใช้งานและแคช เฟรมเวิร์กอย่าง vLLM, DeepSpeed และ Triton พยายามแบ่งกลุ่มและแชร์การเปิดใช้งานระหว่างคำขอต่างๆ อย่างมีประสิทธิภาพ
โอเวอร์เฮดของกรอบการทำงานการให้บริการ – เซิร์ฟเวอร์อนุมานที่แตกต่างกัน (vLLM, text-generation-inference, llama.cpp, ONNX Runtime) เพิ่มค่าใช้จ่ายและการปรับแต่งที่แตกต่างกัน

อะไร “พอดี” ที่ไหน: กฎเกณฑ์ความจำคร่าวๆ

แนวคิดสองประการที่สำคัญสำหรับการวางแผนฮาร์ดแวร์:

จำนวนพารามิเตอร์ทั้งหมด — ขอบเขตบนของขนาดโมเดล (117B เทียบกับ 21B)
ชุดเปิดใช้งาน/ทำงาน — ใน MoE หรือการตั้งค่าความแม่นยำบางอย่าง หน่วยความจำที่ใช้งานซึ่งจำเป็นในการอนุมานอาจมีขนาดเล็กกว่าไบต์พารามิเตอร์ดิบมาก

กฎปฏิบัติเบื้องต้น:

GPU คลาส 16 GB/แล็ปท็อป Edge → เป็นไปได้สำหรับ จีพีที-ออส-20บี หากคุณใช้การกำหนดค่าประสิทธิภาพหน่วยความจำที่โมเดลให้มา (หรือควอนไทซ์อย่างเข้มงวดเป็น 4 บิต/NF4/AWQ)
80GB H100 / A100 80GB → การโฮสต์ GPU เดี่ยวสำหรับ จีพีที-ออส-120บี ในการตั้งค่าที่แนะนำ สำหรับปริมาณงานการผลิต คุณอาจยังต้องการ GPU หลายตัวสำหรับการประมวลผลแบบแบตช์ การสำรองข้อมูล หรือลดเวลาแฝงภายใต้การทำงานพร้อมกัน
การตั้งค่า GPU หลายตัวขนาดใหญ่ (คลัสเตอร์ A100/H100) → จำเป็นหากคุณต้องการให้ผู้ใช้หลายคนทำงานพร้อมกันโดยมีเวลาแฝงต่ำ หรือต้องการปรับแต่ง/ฝึกอบรมอย่างละเอียด DeepSpeed/ZeRO และการประมวลผลแบบขนานของเทนเซอร์อัตโนมัติ ช่วยให้คุณแบ่งโมเดลขนาดใหญ่บน GPU ได้

สรุปสั้นๆ: สำหรับการทดลองและการใช้งานแบบโลคัลที่มีน้ำหนักเบา ควรวางแผนใช้ GPU ขนาด 16–24 GB (หรือ CPU + การวัดปริมาณแบบหนัก) สำหรับการอนุมาน GPU เดี่ยวสำหรับการผลิตของแบบจำลอง gpt-oss ขนาดใหญ่ คุณจะต้องกำหนดเป้าหมายเป็น H100 ขนาด 80 GB มิฉะนั้น ให้ใช้การแบ่งพาร์ติชันแบบหลาย GPU

จำเป็นต้องใช้พลังการประมวลผลเท่าใดสำหรับการใช้งาน GPT-OSS ในทางปฏิบัติ?

การอนุมานกับการฝึกอบรม: งบประมาณที่แตกต่างกันอย่างมาก

การอนุมาน:ต้นทุนหลักคือหน่วยความจำ GPU (VRAM) และเคอร์เนลที่ปรับแต่งแล้ว ด้วยรันไทม์ที่ปรับแต่งแล้ว (vLLM, TensorRT, DeepSpeed-Inference) และการหาปริมาณ การอนุมานบน gpt-oss-20b จึงเป็นไปได้บน GPU ผู้บริโภคขนาด 16 GB ส่วนรุ่น 120B MoE ได้รับการออกแบบมาให้เหมาะกับ H100 ขนาด 80 GB
การปรับแต่ง / การฝึกอบรมเต็มรูปแบบ: มีขนาดใหญ่กว่ามาก — คุณจะต้องใช้ GPU จำนวนมาก หรืออินสแตนซ์การฝึกเฉพาะทาง (คลัสเตอร์ H100/A100 แบบหลายโหนด งบประมาณ DFLOP และ I/O ของพื้นที่เก็บข้อมูล) บทความนี้มุ่งเน้นไปที่การอนุมาน/การโฮสต์ด้วยตนเอง และสูตรการปรับแต่งเล็กน้อย (QLoRA/LoRA) ไม่ใช่การฝึกล่วงหน้าหลายสัปดาห์

CPU เทียบกับ GPU เทียบกับตัวเร่งความเร็วเฉพาะทาง

ซีพียูเท่านั้น: เป็นไปได้ด้วย GGUF/llama.cpp และการสร้างแบบควอนไทซ์ขนาดเล็ก แลกกับต้นทุนที่ต่ำลงจากความหน่วง การรัน 20B บน CPU โดยไม่ควอนไทซ์นั้นไม่สามารถทำได้จริง ควรใช้ CPU เมื่อความเป็นส่วนตัวหรือการทำงานแบบออฟไลน์ภายในเครื่องเป็นสิ่งจำเป็น และความต้องการทรูพุตของคุณต่ำ
GPU: แนะนำให้ใช้สำหรับความหน่วงเวลาและปริมาณงาน GPU ML รุ่นใหม่ (A100/H100/4090/4080) มีความแตกต่างอย่างมากในด้าน HBM/VRAM และโครงสร้างระหว่าง GPU เอกสาร gpt-oss แนะนำคลาส H100 สำหรับรุ่น 120B
ทีพียู / เอเอ็มดี MI300X: รองรับโดยรันไทม์บางตัว (รุ่น vLLM/ROCm) และสามารถประหยัดต้นทุนได้ในคลาวด์บางประเภท — ตรวจสอบเอกสารของผู้ให้บริการเมื่อเลือกฮาร์ดแวร์

วิธีการรัน GPT-OSS ในเครื่องด้วยงบประมาณจำกัด (โค้ด + ทีละขั้นตอน)

ด้านล่างนี้เป็นแนวทางปฏิบัติสองประการ: (A) แล็ปท็อป/เดสก์ท็อป GPU ที่มี VRAM ประมาณ 16–24 GB โดยใช้การวัดเชิงปริมาณแบบ 4 บิต และ (B) CPU/GPU ต่ำ (ออฟไลน์) โดยใช้ llama.cpp (GGUF) หรือไฟล์ขนาดเล็กที่ควอนไทซ์ ทั้งสองอย่างนี้ใช้กันอย่างแพร่หลายโดยผู้ปฏิบัติงานเมื่อเงินและอำนาจมีจำกัด

หมายเหตุ: คำแนะนำเหล่านี้ถือว่าคุณมีสภาพแวดล้อม Python ที่ใช้งานได้ (แนะนำให้ใช้ Linux เพื่อรองรับ CUDA ที่ดีที่สุด) สำหรับ Windows ให้ใช้ WSL2 เพื่อความเข้ากันได้ดีที่สุดกับชุดเครื่องมือ GPU

A. เส้นทาง GPU (แนะนำสำหรับเวลาแฝงที่ดีที่สุดในงบประมาณ) — quantize + โหลดด้วยบิตและไบต์ (4 บิต)

เส้นทางนี้มุ่งหมายที่จะวิ่ง โอเพนไอ/จีพีที-ออส-20บี บน GPU สำหรับผู้บริโภครายเดียว (เช่น 24 GB 4090 หรือ 16 GB 4080) โดยใช้การวัดปริมาณแบบ 4 บิตและ Hugging Face transformers อุปกรณ์แผนที่/เร่งความเร็ว

ขั้นตอนที่ 1 — ติดตั้งพื้นฐาน

# 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

(หากคุณใช้ conda ให้สร้าง env และติดตั้ง Torch Wheel ที่เข้ากันได้กับ CUDA สำหรับแพลตฟอร์มของคุณ)

ขั้นตอนที่ 2 — (ทางเลือก) การเข้าสู่ระบบ Hugging Face เพื่อดาวน์โหลดไฟล์ขนาดใหญ่

huggingface-cli login

ขั้นตอนที่ 3 — ตัวอย่าง Python (โหลดโมเดล 4 บิตแบบควอนไทซ์)

# 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))

หมายเหตุและเคล็ดลับ

ใช้ device_map="auto" so transformers ใช้ CPU/GPU offload โดยอัตโนมัติ หากคุณมี GPU ตัวเดียว device_map="auto" โดยปกติจะวางทุกอย่างไว้ใน GPU และถ่ายโอนสิ่งที่ต้องอยู่ใน CPU ออกไป
หากคุณใช้ VRAM หมด ให้เพิ่ม --offload_folder ./offload (หรือตั้งค่า offload_folder in from_pretrained) เพื่อถ่ายโอนเทนเซอร์ไปยัง NVMe
แนวทาง Hugging Face + bitsandbytes ได้รับการบันทึกไว้อย่างกว้างขวาง โปรดดูคู่มือ 4-bit transformers เพื่อดูรายละเอียด

B. CPU / เส้นทางงบประมาณน้อย (llama.cpp / GGUF)

หากคุณไม่มี GPU หรือ GPU ขนาดเล็กมาก llama.cpp / การสร้าง GGUF (และไฟล์ที่ถูกวัดปริมาณ AWQ/GPTQ) ช่วยให้คุณสามารถรันโมเดลบน CPU ด้วยความหน่วงที่ยอมรับได้สำหรับผู้ใช้รายเดียว

ขั้นตอนที่ 1 — ติดตั้ง llama.cpp / การผูก Python

# 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

ขั้นตอนที่ 2 — แปลงเซฟเทนเซอร์ → GGUF (หากมีสคริปต์การแปลงสำหรับ gpt-oss)
OpenAI/Hugging Face มอบตัวเซฟเทนเซอร์ ตัวแปลงชุมชน (หรือสคริปต์ใน llama.cpp) แปลงเป็น GGUF คำสั่งที่แน่นอนขึ้นอยู่กับกระแส llama.cpp เครื่องมือ ตรวจสอบ README สำหรับ repo convert.py/convert-safetensors-to-gguf(กระทู้ชุมชนพูดคุยถึงการแปลงเป็นโมเดลใหม่)

ขั้นตอนที่ 3 — รันโมเดลด้วย llama.cpp

# basic inference (example)

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

หมายเหตุและการแลกเปลี่ยน

การทำงานของ CPU ช้ากว่ามาก ใช้เส้นทางนี้สำหรับการทดสอบ ความเป็นส่วนตัว หรือตัวแทนภายในที่มีการทำงานพร้อมกันน้อยมาก
การสร้างเอาท์พุตที่ยาวนานหรือการให้บริการผู้ใช้พร้อมกันจำนวนมากบน CPU ไม่ใช่เรื่องที่ทำได้จริง จึงต้องเปลี่ยนไปใช้ GPU สำหรับการผลิต

การสร้างแบบควอนไทซ์บนดิสก์ (GPTQ/AWQ)

หากคุณจำเป็นต้องบีบอัดโมเดลขนาดใหญ่ลงใน GPU ขนาดเล็ก (เช่น 8–12 GB) ผลลัพธ์จากชุมชนแสดงให้เห็นว่าการวัดปริมาณแบบ GPTQ/AWQ สามารถทำให้โมเดล 20B บางรุ่นทำงานบน GPU ที่มี VRAM ต่ำได้ — แต่การแปลงมักจะต้องใช้ ข้อมูลเพิ่มเติม CPU RAM และ GPU ตัวกลางหนึ่งตัวในระหว่างการแปลง เครื่องมือ: GPTQ-for-LLaMa, AutoGPTQ (เก็บถาวรแล้ว) AWQและ QLLM.

เคล็ดลับปฏิบัติสำหรับงบประมาณจำกัด

ต้องการจุดตรวจสอบเชิงปริมาณ 4 บิต (GPTQ/AWQ/MXFP4) — มักจะเป็นความแตกต่างระหว่าง “รันใน 12 GB” และ “ต้องการ 80 GB”
จำกัดความยาวบริบท สำหรับการอนุมานงบประมาณ: บริบทยาวๆ จะทำให้แคชการเปิดใช้งานระเบิด หากคุณจำเป็นต้องจัดเก็บบริบทยาวๆ ให้พิจารณากลยุทธ์การออฟโหลด
ใช้หน่วยความจำรวม / การถ่ายโอน NVMeM อย่างระมัดระวัง — เฟรมเวิร์กอาจเสนอการลดภาระ CPU/NVMe (DeepSpeed ZeRO-Offload / ZeRO-Infinity) แต่จะเพิ่มเวลาแฝง

วิธีการโฮสต์ GPT-OSS บนผู้ให้บริการคลาวด์ด้วยตนเอง (คำแนะนำเชิงปฏิบัติและคำแนะนำด้านต้นทุน)

ควรเลือกฮาร์ดแวร์คลาวด์ตัวใด?

GPU เดี่ยว 80 GB H100: เหมาะสำหรับการโฮสต์ gpt-oss-120b สำหรับปริมาณการรับส่งข้อมูลขนาดเล็กถึงปานกลาง ในแง่ของ AWS อินสแตนซ์ P5 มีฮาร์ดแวร์ H100 ส่วนรุ่นที่ใช้ GPU เดี่ยว (ประกาศในปี 2025) ทำให้การปรับขนาดที่เหมาะสมสำหรับการอนุมานมีต้นทุนถูกกว่า ใช้ตระกูล P5/ND H100 ขึ้นอยู่กับผู้ให้บริการ
มัลติจีพียู (8× H100): สำหรับปริมาณงานสูงและความซ้ำซ้อน ให้ใช้ p5.48x, p5dn หรือคลัสเตอร์ที่เทียบเท่า NVidia NVLink/NVSwitch ในอินสแตนซ์เดียวกันช่วยลดโอเวอร์เฮดการสื่อสารระหว่าง GPU
เมฆทางเลือก:CoreWeave, Lambda Labs, Paperspace, Runpod — มักจะเช่า GPU แบบ Spot/Ondemand ในราคาที่ถูกกว่าสำหรับการอนุมานแบบ Bursty ควรใช้ GPU เหล่านี้สำหรับการพัฒนาก่อนที่จะตัดสินใจเลือกใช้โครงสร้างพื้นฐานระยะยาว
การผลิตที่ทันสมัย / หนัก: AWS p5 (H100) (8 × H100 80GB ต่ออินสแตนซ์) — สำหรับปริมาณงานสูงสุดต่อโหนดและความต้องการ GPU เดี่ยว 80+ GB หรือสำหรับ 120B+ พร้อมการแบ่งที่น้อยลง P5 มอบ H100 และพื้นที่จัดเก็บข้อมูลภายใน NVMe ขนาดใหญ่

rmers, text-generation-inference (TGI)/คอนเทนเนอร์ NVIDIA TGI หรือตั้งค่าการอนุมาน DeepSpeed

จัดเตรียม NVMe ในพื้นที่อย่างรวดเร็ว หากคุณวางแผนที่จะโอนสถานะการเปิดใช้งานขนาดใหญ่ (ZeRO-Infinity) โหนด P4/P5 มักจะมี NVMe ในเครื่องและแบนด์วิดท์เครือข่ายสูงมาก ()
ความปลอดภัยและเครือข่าย — วางจุดสิ้นสุดการอนุมานไว้ด้านหลังตัวปรับสมดุลการโหลด ใช้กลุ่มการปรับขนาดอัตโนมัติสำหรับส่วนหน้า และแยกความกังวล (การให้บริการโมเดลเทียบกับการกำหนดเส้นทางคำขอ)
การติดตามและ SLO — ติดตามการใช้งาน GPU, หน่วยความจำ, โทเค็น/วินาที, เวลาแฝง p95 และข้อผิดพลาด; ใช้ Prometheus + Grafana สำหรับตัวชี้วัด

ตัวอย่างเวิร์กโฟลว์การโฮสต์บนคลาวด์ด้วยตนเอง (AWS P4/P5)

เลือกอินสแตนซ์ (p4d/p5) ขึ้นอยู่กับความต้องการหน่วยความจำของโมเดล สำหรับ gpt-oss-20B อินสแตนซ์เดียวขนาด 16–32 GB ก็เพียงพอแล้ว สำหรับ gpt-oss-120B ให้เลือกอินสแตนซ์ HBM ขนาด 80 GB หรือหลาย GPU
เตรียม AMI / ภาพ — ใช้ AMI ของผู้จำหน่ายที่รวม CUDA, cuDNN และ PyTorch ที่ได้รับการเพิ่มประสิทธิภาพ (หรือรูปภาพของผู้จำหน่ายพร้อมไดรเวอร์ NVIDIA)
ติดตั้งสแต็กเสิร์ฟ: vLLM, หม้อแปลง, การอนุมานการสร้างข้อความ (TGI)/คอนเทนเนอร์ NVIDIA TGI หรือตั้งค่าการอนุมาน DeepSpeed
จัดเตรียม NVMe ในพื้นที่อย่างรวดเร็ว หากคุณวางแผนที่จะโอนสถานะการเปิดใช้งานขนาดใหญ่ (ZeRO-Infinity) โหนด P4/P5 มักจะมี NVMe ในเครื่องและแบนด์วิดท์เครือข่ายสูงมาก
ความปลอดภัยและเครือข่าย — วางจุดสิ้นสุดการอนุมานไว้ด้านหลังตัวปรับสมดุลการโหลด ใช้กลุ่มการปรับขนาดอัตโนมัติสำหรับส่วนหน้า และแยกความกังวล (การให้บริการโมเดลเทียบกับการกำหนดเส้นทางคำขอ)
การติดตามและ SLO — ติดตามการใช้งาน GPU, หน่วยความจำ, โทเค็น/วินาที, เวลาแฝง p95 และข้อผิดพลาด; ใช้ Prometheus + Grafana สำหรับตัวชี้วัด

ตัวอย่างแผนการโฮสต์ด้วยตนเอง (gpt-oss-20b, การผลิตขนาดเล็ก)

เป้าหมาย: รองรับผู้ใช้พร้อมกันประมาณ 20 ราย กำหนดเป้าหมายการตอบสนองภายใน 1–2 วินาที คำนึงถึงต้นทุน

ตัวอย่าง:1× A10G / 1× GPU 24 GB (เช่น G5 / A10G / RTX 6000) สำหรับรุ่น + 1× เซิร์ฟเวอร์บูตสแตรป CPU ขนาดเล็ก
Runtime: vLLM เป็นเซิร์ฟเวอร์จำลอง (การแบตช์ต่อเนื่อง) + เกตเวย์ CometAPI
สเกลอัตโนมัติ:ใช้กลุ่มการปรับขนาดอัตโนมัติกับ GPU AMI และ ALB + การปรับขนาดอัตโนมัติแนวนอนตามเมตริก CPU/GPU
พื้นที่จัดเก็บ:NVMe ในพื้นที่สำหรับการแคชโมเดล; ที่เก็บอ็อบเจ็กต์ (S3) สำหรับการจัดเก็บโมเดลแบบเย็น
การตรวจสอบ:Prometheus + Grafana ติดตามการใช้งาน GPU, ความหน่วง, ความยาวคิว
⁠ความปลอดภัย:VPC, ซับเน็ตส่วนตัว, บทบาท IAM สำหรับที่เก็บข้อมูลแบบจำลอง, ใบรับรอง TLS

ตัวอย่างแผนการโฮสต์ด้วยตนเอง (gpt-oss-120b, การผลิต)

เป้าหมาย: ความหน่วงต่ำสำหรับผู้ใช้พร้อมกันจำนวนมาก / องค์กร

ตัวอย่าง:1× H100 80 GB (GPU เดียว) สำหรับพื้นฐาน ปรับขนาดในแนวนอนหรือใช้อินสแตนซ์ p5 หลาย GPU สำหรับทรูพุต สำหรับทรูพุตสูง ให้ทำซ้ำบริการ GPU เดียว (ข้อมูลแบบขนาน) หรือแบ่งโมเดลระหว่าง GPU โดยใช้ DeepSpeed (เทนเซอร์/ไปป์ไลน์)
Runtime:การอนุมานแบบ DeepSpeed ด้วย TP อัตโนมัติหรือ NVIDIA TensorRT (ถ้ามี) การสนับสนุนของ vLLM สำหรับ MoE/Multi-GPU และเคอร์เนลที่ปรับแต่งแล้วอาจมีประโยชน์เช่นกัน
Kubernetes:ใช้ K8s กับปลั๊กอินอุปกรณ์และ NVMe ในเครื่อง ใช้การทดสอบความโกลาหลเพื่อความพร้อมใช้งาน
การเพิ่มประสิทธิภาพต้นทุน: อินสแตนซ์ที่สงวนไว้สำหรับโหลดที่คาดการณ์ได้ อินสแตนซ์จุดสำหรับเวิร์กโหลดแบบแบตช์

ตัวอย่าง: เริ่มคอนเทนเนอร์การให้บริการ vLLM สำหรับ gpt-oss-20b

# assume vllm is installed and CUDA is set up

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

จากนั้นชี้ส่วนหน้าของคุณไปที่ http://<host>:8000/v1/chat/completions (vLLM รองรับ API ที่เข้ากันได้กับ OpenAI)

เคล็ดลับการเพิ่มประสิทธิภาพต้นทุน

VM ที่สามารถตรวจจับ/ขัดจังหวะได้ ราคาถูกกว่า 50–80% แต่ต้องใช้จุดตรวจหรือกลยุทธ์การเกิดใหม่อย่างรวดเร็ว
การหาปริมาณแบบจำลอง ลดความต้องการประเภทอินสแตนซ์ (เช่น 120B ที่ถูกวัดปริมาณอาจให้บริการบน GPU น้อยลงหากเอ็นจิ้นรองรับการลดปริมาณแบบ on-the-fly)
ใช้กลุ่มอินสแตนซ์ที่ได้รับการเพิ่มประสิทธิภาพเฉพาะการอนุมานเท่านั้น (P5/P4/A2 Ultra) พร้อม NVLink/NVSwitch สูงเมื่อทำการประมวลผลแบบคู่ขนานของโมเดล GPU หลายตัว แบนด์วิดท์ของเครือข่ายมีความสำคัญต่อการแบ่งส่วน GPU ร่วมกัน

วิธีการสร้างสมดุลระหว่างต้นทุน ความหน่วง และคุณภาพของโมเดล

การหาปริมาณ: ความเร็วเทียบกับคุณภาพ

การวัดเชิงปริมาณเชิงรุก (2-4 บิต, AWQ/GPTQ) → ประหยัดหน่วยความจำได้มหาศาลและมักสูญเสียคุณภาพเพียงเล็กน้อยสำหรับงานจำนวนมาก ใช้ AWQ/GPTQ สำหรับการผลิตหากคุณวัดประสิทธิภาพเวิร์กโหลดเฉพาะ การแปลงอาจต้องใช้หน่วยความจำ CPU ขนาดใหญ่ในระหว่างการควอนไทซ์

ความแม่นยำแบบผสมผสานและการเพิ่มประสิทธิภาพเคอร์เนล

ใช้ fp16, bf16 หากรองรับ ให้รวมเข้ากับเคอร์เนล CUDA เฉพาะทาง (FasterTransformer, TensorRT) เพื่อประสิทธิภาพสูงสุด Nvidia/TensorRT นำเสนอการถอดรหัสเชิงคาดการณ์และเคอร์เนลที่ปรับแต่งให้เหมาะสมสำหรับทรานส์ฟอร์มเมอร์หลายตัว (NVIDIA มีอะแดปเตอร์ GPT-OSS ที่ปรับแต่งให้เหมาะสม)

ความปลอดภัยและการสังเกต

แบบจำลองแบบ Open-weight หมายความว่าคุณมีหน้าที่รับผิดชอบในการตรวจสอบการใช้งานในทางที่ผิด การรั่วไหลของข้อมูล และการเปลี่ยนแปลง ใช้งานการบันทึกคำขอ ตัวกรองเนื้อหา การจำกัดอัตรา และการควบคุมโดยมนุษย์ บันทึกประจำรุ่นและแบบจำลองของ OpenAI เน้นย้ำถึงการทดสอบภายในและการประเมินภายนอก แต่การโฮสต์ด้วยตนเองจะเปลี่ยนขอบเขตความปลอดภัยมาอยู่ที่ตัวคุณ

ความคิดสุดท้าย

GPT-OSS ขับเคลื่อนเข็ม: โมเดลที่ก่อนหน้านี้ต้องการโครงสร้างพื้นฐานขนาดใหญ่ที่ออกแบบเฉพาะ ตอนนี้เข้าถึงได้ง่ายขึ้นด้วยการเลือกสถาปัตยกรรมที่รอบคอบและการกระจายแบบควอนไทซ์ แต่ การปรับใช้ยังคงเป็นวินัย: การกำหนดขนาดฮาร์ดแวร์ต้องพิจารณาความแม่นยำของโมเดล ความยาวของบริบท และโปรไฟล์ความพร้อมกันของแอปของคุณ ใช้กลุ่มทดสอบขนาดเล็ก (ควอนไทซ์ 20B) เพื่อวัดค่าโทเค็น/วินาทีและเวลาแฝง p95 จากนั้นคูณเพื่อประเมินการประมวลผลบนคลาวด์และต้นทุนการผลิต

วิธีการเข้าถึง GPT-OSS API

CometAPI เป็นแพลตฟอร์ม API แบบรวมที่รวบรวมโมเดล AI มากกว่า 500 โมเดลจากผู้ให้บริการชั้นนำ เช่น ซีรีส์ GPT ของ OpenAI, Gemini ของ Google, Claude ของ Anthropic, Midjourney, Suno และอื่นๆ ไว้ในอินเทอร์เฟซเดียวที่เป็นมิตรกับนักพัฒนา ด้วยการนำเสนอการตรวจสอบสิทธิ์ การจัดรูปแบบคำขอ และการจัดการการตอบสนองที่สอดคล้องกัน CometAPI จึงทำให้การรวมความสามารถของ AI เข้ากับแอปพลิเคชันของคุณง่ายขึ้นอย่างมาก ไม่ว่าคุณจะกำลังสร้างแชทบ็อต เครื่องกำเนิดภาพ นักแต่งเพลง หรือไพพ์ไลน์การวิเคราะห์ที่ขับเคลื่อนด้วยข้อมูล CometAPI ช่วยให้คุณทำซ้ำได้เร็วขึ้น ควบคุมต้นทุน และไม่ขึ้นอยู่กับผู้จำหน่าย ทั้งหมดนี้ในขณะที่ใช้ประโยชน์จากความก้าวหน้าล่าสุดในระบบนิเวศ AI

นักพัฒนาสามารถเข้าถึงได้ จีพีที-โอเอสเอส-20บี และ จีพีที-โอเอสเอส-120บี ตลอด โคเมทเอพีไอรุ่นล่าสุดที่ระบุไว้เป็นข้อมูล ณ วันที่เผยแพร่บทความ เริ่มต้นด้วยการสำรวจความสามารถของโมเดลใน สนามเด็กเล่น และปรึกษา คู่มือ API สำหรับคำแนะนำโดยละเอียด ก่อนเข้าใช้งาน โปรดตรวจสอบให้แน่ใจว่าคุณได้เข้าสู่ระบบ CometAPI และได้รับรหัส API แล้ว โคเมทเอพีไอ เสนอราคาที่ต่ำกว่าราคาอย่างเป็นทางการมากเพื่อช่วยคุณบูรณาการ