Phục vụ Qwen3.8-Flash-Next-Uncensored-FP8: sổ tay vận hành vLLM cho bản dựng block-FP8

Qwen3.8-Flash-Next-Uncensored-FP8 — bản dựng block-FP8 của Flash-Next đã được abliterated — là tạo phẩm bạn thực sự tải xuống khi phục vụ mô hình này trên phần cứng trung tâm dữ liệu, và là bản cuối cùng trong bộ sưu tập nhận được một runbook riêng. Nó nằm tại orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 trên Hugging Face: hướng từ chối được loại bỏ khỏi Qwen3.8-Flash-Next của Qw​en, sau đó được tái lượng tử hóa ngoại tuyến theo đúng sơ đồ FP8 của Qwen3.8-Flash-Next-FP8 chính thức để vLLM phục vụ nó trên cùng một đường dẫn kernel. Đây là bản dựng mà bất kỳ ai chạy mô hình này trên GPU lớp Hopper trở lên sẽ tìm đến, và đường dẫn phục vụ có một cờ dễ cấu hình sai và khó chẩn đoán khi nó sai.

Trước tiên, ranh giới, vì độc giả cứ mãi làm mờ nó và nó thay đổi mọi thứ bên dưới. Qwen3.8-Flash-Next-Uncensored và Qwen3.8-27B-Uncensored là hai mô hình khác nhau, không phải hai bản build của cùng một mô hình. Trọng số gốc khác nhau — Qwen3.8-Flash-Next so với Qwen3.8-27B — kiến trúc khác nhau, các bản phát hành trọng số khác nhau, các bộ sưu tập Hugging Face khác nhau. Chúng chỉ dùng chung một kỹ thuật abliteration và cùng một tên họ; vậy thôi. Không con số nào trên trang 27B áp dụng cho mô hình này, và nếu bạn đến đây từ một kết quả tìm kiếm về 27B, thì sổ tay vận hành cục bộ riêng của bản 27B là một trang riêng với một bộ quyết định riêng.

Trang này là trang phục vụ Flash-Next FP8 và không gì khác. Sổ tay vận hành GGUF/MLX đề cập đến phần giải thích abliteration cho mô hình này và hai dòng build phần cứng tiêu dùng; kỹ thuật đằng sau toàn bộ dòng sản phẩm được giải thích trong tài liệu nhập môn về abliteration và bài giải thích mở rộng về uncensored-LLM; còn Qwen3.8-27B-Uncensored-FP8, bản anh em mà bạn có thể đã được trỏ đến, có sổ tay vận hành FP8 riêng. Ở đây chúng ta chỉ xoay quanh một câu hỏi: cách bạn phục vụ bản build block-FP8, điều gì sẽ hỏng nếu bạn làm sai, và những con số trên thẻ mô hình cho bạn biết điều gì và không cho bạn biết điều gì.

Trước khi bạn bắt đầu: cổng và thời gian chạy

Hai thứ kiểm soát repo này, và cả hai đều tạo ra các lỗi trông giống như do thứ khác gây ra.

Đầu tiên là quyền truy cập. Kho lưu trữ bị kiểm soát: bạn phải đăng nhập vào Hugging Face và đã chấp nhận các điều khoản của kho trước khi bất kỳ lượt tải nào hoạt động. Bản thân trang mô hình vẫn đọc được mà không cần tài khoản — toàn bộ phần mô tả trên thẻ là công khai — nhưng các trọng số thì không. Nói rõ ra, nếu không có phiên đăng nhập đã chấp nhận các điều khoản, cả `hf download` lẫn `vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8` đều thất bại với lỗi xác thực, chứ không phải thông báo thân thiện kiểu "bạn cần bấm Agree." Hãy làm bước bấm đồng ý một lần trước, sau đó tải ~186 GB bằng hf CLI hoặc để vLLM tự phân giải kho trong lần chạy đầu tiên.

Thứ hai là runtime. Checkpoint được đăng ký theo kiến trúc qwen4_exp (Qwen4ExpForConditionalGeneration), mà vLLM gốc và Transformers gốc không thể tải. Bạn cần image vLLM day-0 và transformers 5.16+. Đây là lỗi “không tải được” phổ biến nhất trong các runbook cộng đồng tuần này — không phải bản tải về bị hỏng, mà là runtime có trước kiến trúc. Image không phải tùy chọn; nó chính là con đường.

Phần cứng, để bạn có thể lên kế hoạch trước khi rút bất cứ thứ gì: lời gọi của card nhắm đến một nút 8 GPU, và hướng dẫn trong công thức chính thức của vLLM cho checkpoint FP8 được áp dụng tại đây vì các bản dựng khớp nhau từng tensor một — khoảng 265 GB VRAM GPU cho một triển khai toàn nút, với TP2 được coi là mức tối thiểu trên dòng GB300 và TEP4/TEP8 là các cấu hình toàn khay đã được xác thực.

Vì sao bản dựng FP8 tồn tại — và vì sao "đường thực thi kernel giống hệt" chính là điểm mấu chốt

Các trọng số BF16 đã abliterated là nguồn chuẩn; repo này chứa mô hình đó được định lượng lại ngoại tuyến, cố ý tái tạo đúng công thức Qwen3.8-Flash-Next-FP8 chính thức. Bộ định lượng chỉ tác động đến 512 phép chiếu chuyên gia định tuyến — experts.{e}.down/gate/up_proj — tách chúng khỏi bố cục 3D của bản dựng BF16 và lưu từng phép chiếu dưới dạng trọng số float8_e4m3fn cùng với tỷ lệ weight_scale_inv BF16 trong các khối 128×128. Kích hoạt sử dụng FP8 động theo từng token; không có tập hiệu chuẩn. Mọi thứ khác vẫn giữ BF16: attention và linear_attn, chuyên gia dùng chung, bộ định tuyến MoE (mlp.gate), các bộ trộn Hyper-Connection, embeddings, lm_head, đầu giải mã suy đoán MTP và toàn bộ tháp thị giác.

Dòng “đường dẫn kernel giống hệt” không chỉ là lời tiếp thị, và nó xứng đáng được nói rõ trong một câu. Bản build đã được xác minh so với điểm kiểm tra FP8 chính thức: tỷ lệ khối tái tạo chính xác (scale_relerr = 0) và các mã FP8 khớp đến mức làm tròn dưới ULP. Đó là lý do vLLM chạy nó với cùng các kernel FP8 có tỷ lệ khối và cùng cơ chế giải mã suy đoán MTP như bản phát hành chính thức — các tensor về bản chất là các tensor giống nhau, chỉ thiếu hướng từ chối.

{{1}}Cụ thể, điều đó mang lại cho bạn ~186 GB trên 131 phân đoạn (152.089 tensor, 75.264 trong số đó là FP8), 262.144 token ngữ cảnh gốc, tháp thị giác + video được giữ nguyên từng byte (333 tensor visual.*), và đầu MTP nguyên vẹn.{{/1}} {{2}}Các trọng số đã được abliterated trước — một hướng từ chối duy nhất được ước tính tại lớp 24 và được trực giao hóa khỏi 149 tensor ghi phần dư trong float32, theo Arditi et al. (2024) — và các bộ ghi phần dư của đầu MTP đã được chỉnh sửa nhất quán, vì vậy giải mã suy đoán tiếp tục hoạt động.{{/2}} {{3}}Chi tiết cuối cùng đó không hề hiển nhiên, và nó là sự khác biệt giữa một đầu tăng tốc giải mã và một đầu âm thầm làm suy giảm nó.{{/3}}

Flag duy nhất quyết định thành bại của việc tải

Phục vụ bản build này mà không bật `--enable-expert-parallel`, bạn sẽ gặp một lỗi trông giống lỗi shape chứ không phải lỗi cấu hình. Đây là lỗi serving được báo cáo nhiều nhất cho checkpoint này, và nó hoàn toàn tất định.

Đây là phép tính. Phép chiếu gate+up hợp nhất của các chuyên gia định tuyến có kích thước trung gian là 640. Block-FP8 lượng tử hóa theo các khối có độ rộng 128. Với song song tensor thông thường, 640 đó được chia cho các rank — 640 ÷ TP — và với các mức TP phổ biến (2, 4, 8), phần mỗi rank không chia hết cho 128: TP8 cho 80, TP4 cho 160, TP2 cho 320. vLLM sau đó từ chối tải trọng số với lỗi trông giống như sai lệch hình dạng: output_size của trọng số gate và up = 80 không chia hết cho block_n lượng tử hóa trọng số = 128.

Expert parallelism khắc phục lỗi này bằng cách phân mảnh trọng số expert trên các rank expert-parallel thay vì các rank tensor-parallel, nhờ đó bảo toàn ranh giới khối FP8. Đó là lý do flag này là bắt buộc đối với bản build này: với --enable-expert-parallel, TP8 trở thành TEP8 hoạt động được. (Điều này vô hại với bản build BF16, vì không có khối FP8 nào cần bảo toàn.) Hướng dẫn chính thức của vLLM nêu rõ TP8 thông thường không tương thích với các khối lượng tử hóa rộng 128 của checkpoint, và một issue trên vLLM được mở hai ngày sau khi các trọng số được đăng tải đã ghi nhận lỗi giống hệt trên một nút 8×L40s ở TP2, TP4 và TP8. Nếu quá trình load chết với một lỗi trông như lỗi shape, hãy kiểm tra flag trước khi kiểm tra bản tải xuống.

Câu lệnh chính xác

The source text to translate appears to be missing from your message. Please provide the card's docker invocation text (with the {{1}}...{{/1}} style markers) so I can translate it into Vietnamese.

docker run -d --name flashnext --gpus all --ipc host -p 8000:8000 -v /path/to/Qwen3.8-Flash-Next-Uncensored-FP8:/model vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 --model /model --served-model-name Qwen3.8-Flash-Next-Uncensored --tensor-parallel-size 8 --trust-remote-code --max-model-len 262144 --enable-expert-parallel --enable-auto-tool-choice --tool-call-parser qwen3_coder

Xử lý các cờ không hiển nhiên:

• vllm/vllm-openai:qwen38-flash-next-x86_64-cu130 — bản image day-0 của qwen4_exp. Đây không phải là vLLM thông thường; đây là image dành riêng cho kiến trúc cụ thể, và các image tiêu chuẩn có trước qwen4_exp sẽ hoàn toàn không tải được checkpoint.

• --trust-remote-code — nạp mã mô hình qwen4_exp đi kèm trong repo. Nếu không có cờ này, bộ nạp sẽ từ chối theo nguyên tắc.

• --max-model-len 262144 — khớp với cửa sổ ngữ cảnh gốc. Bạn muốn nó được khai báo tường minh ở đây thay vì để mặc định.

• --enable-expert-parallel — bắt buộc cho bản dựng FP8, vì những lý do trong phần trên. Thẻ ghi chú rằng nó vô hại đối với BF16.

• --enable-auto-tool-choice --tool-call-parser qwen3_coder — bật tính năng gọi công cụ và hàm bằng định dạng XML của Qwen3-Coder. Nếu tắt chúng, mô hình vẫn có thể trò chuyện, nhưng việc sử dụng công cụ tự động sẽ bị tắt.

• --tensor-parallel-size 8 — cách gọi của thẻ giả định một node 8 GPU (8× dòng Hopper). Với --enable-expert-parallel thì đó là một triển khai TEP8.

Khi container đã được khởi động, endpoint sẽ tương thích với OpenAI tại :8000/v1. Hãy đặt --served-model-name thành bất kỳ giá trị nào mà client của bạn mong đợi; thẻ sử dụng Qwen3.8-Flash-Next-Uncensored.

Các lựa chọn thay thế, tất cả đều có trong thẻ hoặc được xác nhận bởi các học viên trong tuần này: vllm serve orcarouter/Qwen3.8-Flash-Next-Uncensored-FP8 trực tiếp sau khi phiên HF của bạn được xác thực; SGLang qua hình ảnh lmsysorg/sglang:qwen38flashnext với --tp 8 --ep 8 — cùng yêu cầu song song chuyên gia, cùng lý do; và Transformers với pipeline("image-text-to-text", ...) trên transformers 5.16+ nếu bạn muốn viết script tương tác với mô hình thay vì phục vụ nó.

Điều gì thực sự hiệu quả khi bạn phục vụ nó

Các mẫu trong phần này là những phát hiện từ cộng đồng trong các runbook của người thực hành và các chủ đề diễn đàn trong tuần này, không phải hướng dẫn từ nhà cung cấp. Khi nhiều hơn một thiết lập báo cáo cùng một hành vi, thì đáng để coi đó là thực tế:

• MTP speculative decoding hoạt động. Thêm --speculative-config '{"method":"mtp","num_speculative_tokens":3}' và vLLM sẽ dùng MTP head đã được giữ lại. Nhiều runbook cho biết MTP chính là lý do khiến quá trình giải mã của mô hình này vẫn dùng được dù kích thước rất lớn.

• Bị OOM khi tải? Hãy offload bảng n-gram. Embedding PLE n-gram với 51B tham số chính là "bất ngờ" về bộ nhớ trong kiến trúc này. VLLM_PLE_CPU_OFFLOAD=1 sẽ chuyển nó sang RAM của máy chủ — hãy cấp ít nhất ~51 GB cho nó ở đó. Công thức chính thức và các runbook đa nút từ cộng đồng đều dùng đến cờ này.

• Thị giác là có thật, không phải tàn dư. Tháp thị giác + video được bảo toàn nguyên vẹn từng byte, nên đây vẫn là mô hình thị giác-ngôn ngữ đầy đủ. Truyền một phần nội dung image_url trong chat completion và cùng một endpoint đó phục vụ khả năng hiểu hình ảnh; các bài kiểm tra OCR từ cộng đồng trên bản build này cho kết quả vượt qua hoàn toàn.

• Suy luận được bật theo mặc định — và điều này thay đổi bức tranh an toàn. Mẫu trò chuyện cho phép suy nghĩ trừ khi bạn quy định khác. Chuyển đổi cho từng yêu cầu bằng chat_template_kwargs={"enable_thinking": true|false}, và thêm một trình phân tích suy luận nếu bạn muốn tách văn bản suy nghĩ khỏi câu trả lời. Vì mặc định này, bạn gần như luôn phục vụ mô hình có bật suy nghĩ trừ khi bạn tắt nó một cách tường minh.

• 262K gốc, 1M với rope override. Ngữ cảnh gốc là 262.144 token. Để đạt tới 1M, bạn cần một tùy chọn ghi đè YaRN rope-scaling tường minh cùng một biến môi trường để gỡ bỏ giới hạn max-model-len của vLLM — và trước tiên bạn nên kiểm thử hồi quy chất lượng ngữ cảnh ngắn, vì việc mở rộng mù 4× thường là nơi chất lượng ngữ cảnh dài bị suy giảm.

Những con số trên thẻ nói lên điều gì — và điều gì chúng không nói lên

Đây là các phép đo của chính nhà cung cấp trên bản chỉnh sửa của họ, được công bố trong model card và được đo trên chính các bộ trọng số này, chạy bằng vLLM so với bản gốc chính thức trong cùng tập lệnh và cài đặt. Hãy báo cáo chúng đúng bản chất: chỉ mang tính tham khảo, chứ không phải một cuộc kiểm toán độc lập.

Điểm mấu chốt là sự sụp đổ của khả năng từ chối khi tắt suy nghĩ. Trong bộ kiểm tra prompt độc hại của thẻ (n từ 50 đến 150 mỗi benchmark), tỷ lệ từ chối cơ bản là 64–100% và bản dựng này là 0–2.7%: AdvBench 100%→2.0%, JailbreakBench 94%→0.0%, StrongREJECT 99.3%→1.3%, HarmBench 100%→1.3%, MaliciousInstruct 98%→0.0%, SimpleSafetyTests 64%→2.0%, ForbiddenQuestions 75.3%→2.7%, và một bộ thử nghiệm tùy chỉnh tiếng Trung/tiếng Anh 63.6%→0.0%.

Giờ đến phần trung thực. Tỷ lệ từ chối của chính mô hình cơ sở sụt giảm mạnh khi bật chế độ suy luận — AdvBench giảm từ 100% ở mô hình cơ sở xuống 7,0% khi bật suy luận — nên phép so sánh khi bật suy luận ít kịch tính hơn nhiều: bản dựng này đạt 0,0% trên cùng bộ đánh giá, nhưng nó chỉ đang giảm thêm một phần nhỏ từ con số mà mô hình cơ sở vốn đã giảm. Chỉ trích dẫn số liệu khi tắt suy luận là bạn đang trình bày nửa phần có lợi của câu chuyện, và đó chính là nửa mà một đánh giá an toàn không được dựa vào.

Sự từ chối quá mức trên các prompt vô hại (XSTest-safe, n=250) giảm từ 9,6% trên mô hình cơ sở xuống 1,2% trên bản dựng này khi tắt chế độ suy luận — một cải thiện thực sự, vì một mô hình từ chối các prompt vô hại là kiểu lỗi âm thầm hơn. Mức duy trì năng lực trên MMLU / MMLU-Pro / GSM8K / CMMLU cho thấy chênh lệch lần lượt là −2,0, −1,2, −1,3 và −0,6 điểm, phù hợp với tuyên bố rằng việc trực giao hóa một hướng gần như không làm mất năng lực tổng quát. Gọi công cụ, thị giác/OCR và suy luận đều được báo cáo là hoạt động trên bản dựng này.

Hai lưu ý quan trọng bao trùm toàn bộ những điều nêu trên. Chỉ số từ chối đến từ một bộ phân loại cụm từ mở đầu dựa trên quy tắc, thứ mà bản thân thẻ gọi là chỉ có tính tham khảo, chứ không phải là con số đến từ một LLM-judge hay đạt chuẩn công bố — một hội đồng người hoặc một mô hình giám khảo sẽ không thể tái tạo chính xác các con số này. Và cột lưu ý cũng rất quan trọng: trong bộ thử nghiệm tắt suy nghĩ, khoảng một nửa đến ba phần tư số đầu ra của bản build này vẫn mở đầu bằng một tuyên bố miễn trừ ngắn trước khi thực hiện yêu cầu. Mô hình hiếm khi từ chối; nó chỉ né tránh. “Không kiểm duyệt” ở đây nghĩa là nó trả lời, chứ không phải là nó trả lời mà không có lời mở đầu.

Phần an toàn không phải là hình thức

Hãy đọc nội dung này trước khi kéo tạ, không phải sau đó.

Mô hình này đã bị loại bỏ phần lớn cơ chế căn chỉnh an toàn, và cơ chế này là cụ thể: một hướng từ chối duy nhất đã được ước tính trong luồng phần dư và được trực giao hóa ra khỏi mọi ma trận ghi phần dư — 149 ma trận — được tính toán bằng float32. Hậu quả được công bố rõ ràng, không phải là điều ngẫu nhiên. Thẻ mô hình nói thẳng rằng mô hình sẽ tuân thủ các yêu cầu có hại, phi đạo đức, xúc phạm hoặc bất hợp pháp mà mô hình gốc Qwen3.8-Flash-Next sẽ từ chối, và rằng mô hình không có biện pháp bảo vệ tích hợp đáng kể nào. Mô hình được phát hành hoàn toàn cho nghiên cứu hợp pháp — khả năng diễn giải, nghiên cứu an toàn AI và cơ chế từ chối, red-teaming, đánh giá độ bền vững và các thí nghiệm có kiểm soát — và người dùng chịu toàn bộ trách nhiệm và nghĩa vụ pháp lý đối với những gì mô hình tạo ra. Apache 2.0 quy định những gì bạn có thể làm với các trọng số.

Có hai điều cần làm cho thật chính xác, vì bản dựng này khiến chúng rất dễ bị làm sai.

Đầu tiên, một phép thử jailbreak “thành công” đối với mô hình này không phải là một đánh giá an toàn đạt yêu cầu. Đó chính là hành vi được quảng cáo. Nếu đánh giá của bạn khẳng định rằng “tính an toàn của mô hình này đã bị vượt qua,” thì bạn đã đo lường thiết kế, chứ không phải một lỗ hổng. Điều thực sự được coi là phát hiện sẽ là một sự từ chối vẫn sống sót sau quá trình abliteration, hoặc một sự suy giảm năng lực — và các con số trên thẻ cho thấy cả hai đều hiếm.

Thứ hai, bề mặt tấn công được bảo toàn rộng hơn văn bản. Tháp thị giác còn nguyên vẹn từng byte và chức năng gọi công cụ hoạt động, nên cả đầu vào hình ảnh lẫn sử dụng tác nhân đều đang hoạt động. Một kế hoạch đội đỏ chỉ thăm dò các lời nhắc văn bản sẽ bỏ sót các phương thức mà mô hình này thực sự phơi bày. Và các con số từ chối ở trên là một bộ phân loại dựa trên quy tắc trên bản chỉnh sửa của chính nhà cung cấp — chúng không phải là một cuộc kiểm toán độc lập về bất cứ điều gì, kể cả an toàn.

Không triển khai bản này cho người dùng cuối hoặc đưa vào môi trường sản xuất nếu bạn chưa tự bổ sung các lớp an toàn, kiểm duyệt và ngăn chặn lạm dụng của riêng mình. Điều khoản của repo nêu rõ điều này và không phải là văn bản sáo rỗng: đầu ra không phản ánh quan điểm của người tải lên hoặc của Qw​en / Ali​baba.

Cách lấy đường cơ sở bị kiểm duyệt để so sánh

Nếu công việc của bạn là nghiên cứu cơ chế từ chối hoặc red-teaming, gần như chắc chắn bạn sẽ muốn có phiên bản đã kiểm duyệt của mô hình này đặt cạnh nhau — cùng một kiến trúc nhưng không có chỉnh sửa — để đo lường mức khác biệt. Bản dựng không kiểm duyệt này được thiết kế chỉ hoạt động cục bộ: kho lưu trữ bị giới hạn truy cập và không có triển khai suy luận được lưu trữ trực tuyến, điều này là có chủ đích để các payload nhạy cảm không bao giờ đi qua API của bên thứ ba.

Đối với baseline được lưu trữ, OrcaRouter định tuyến dòng Qw​en theo đúng giá niêm yết của nhà cung cấp mà không cộng thêm phí — Qwen3.8-Flash ở mức $0,15 cho mỗi triệu token đầu vào và $0,47 cho mỗi triệu token đầu ra, được truyền qua nguyên trạng, kèm khả năng tự động chuyển đổi dự phòng và một khóa duy nhất cho hơn 200 mô hình. Thay đổi giá từ nhà cung cấp sẽ hiện ra ngay trong ngày. Nếu bạn đang cân nhắc có nên chạy bản build này hay không, hoặc nó có thể gánh được bao nhiêu phần trong stack của bạn, thì đó chính là cách rẻ để đối chiếu phiên bản kiểm duyệt với nó mà không cần hợp đồng thứ hai hay codebase thứ hai.

Bắt đầu tại đây

Tóm tắt quyết định. Bạn cần: một tài khoản Hugging Face đã chấp nhận các điều khoản của repo; một nút thuộc lớp Hopper hoặc mới hơn — lệnh của card nhắm tới 8 GPU và khoảng 265 GB VRAM GPU theo hướng dẫn của recipe chính thức cho checkpoint FP8 tương ứng; image vLLM day-0 và transformers 5.16+; và khoảng 186 GB dung lượng đĩa cho các trọng số.

Trình tự thực hiện: {{1}}chấp nhận điều khoản của repo{{/1}} → {{2}}tải xuống các trọng số{{/2}} → {{3}}kéo image ngày 0{{/3}} → {{4}}phục vụ với cờ --enable-expert-parallel{{/4}} → {{5}}xác minh bằng một yêu cầu tới :8000/v1/chat/completions{{/5}} → {{6}}sau đó bắt đầu chạy các bản eval của bạn{{/6}}. Nếu một lần tải thất bại với lỗi trông giống lỗi về shape, hãy kiểm tra cờ trước khi kiểm tra bản tải xuống.

Và hãy giữ khung. Đây là một công cụ nghiên cứu, được phát hành với điều kiện đó. Các con số của nó là những phép đo tham khảo của chính nhà cung cấp trên bản chỉnh sửa của họ. Hành vi an toàn của nó chính là mục đích của bài tập, không phải là lỗi để vòng qua. Hãy phục vụ nó, đo lường nó, và đặt sự kiểm duyệt của riêng bạn giữa nó và bất kỳ thứ gì thuộc về con người.

Tất cả năm bản dựng Flash-Next — BF16, GGUF, MLX, FP8 và NVFP4 — được tập hợp trong bộ sưu tập Qwen3.8-Flash-Next-Uncensored trên Hugging Face.

Một mô hình khác, không phải một bản dựng khác của mô hình này: Qwen3.8-27B-Uncensored được abliterated từ một base model khác và có collection cũng như runbook riêng của nó.

Các trọng số này chỉ dùng cục bộ theo thiết kế. Để có một đường cơ sở được lưu trữ nhằm so sánh với bản build đã abliterated, Qwen3.8-Flash được phục vụ trên OrcaRouter với giá niêm yết của nhà cung cấp và không cộng thêm phí — mô hình gốc, nguyên vẹn phần an toàn.