Qwen3.8-27B Vision-Language Model: Our Test Answers, 8GB+ VRAM

- 1. At a Glance
- 2. Overview
- 3. Specifications
- 4. Performance
- 5. Strengths and Use Cases
- 6. How It Differs from Similar Models
- 7. Hardware Requirements
- 8. Can You Run It Locally?
- 9. Our Own Measurements
- 10. How to Get It
- 11. Quantized and Converted Variants
- 12. Related Articles
- 13. What to Read Next
- 14. Sources
- 15. Update History
At a Glance
| Item | Value |
|---|---|
| Repository | Qwen/Qwen3.8-27B |
| Family guide | Qwen3.8 guide (8 articles) |
| Publisher guide | Alibaba (Qwen): models and licenses |
| Published | 2026-08-05 |
| License | apache-2.0 |
| Formats | safetensors |
| Source type | Primary source (the publisher itself) |
Values determined by this site’s code when the information was collected. Dates are JST.
What we checked ourselves
- Ran
Qwen3.8-27B-UD-IQ3_XXS.gguf(IQ3_XXS) on our CPU-only server (Neoverse-N1, 3 threads, llama.cpp b11223): generation at 0.6 tokens/s (a CPU figure, not a GPU speed). - Its answers to our fixed Japanese questions are shown verbatim below.
- It needs about 21% fewer tokens than the Qwen3 tokenizer for the same Japanese text, so about 1.26× as much Japanese fits in the same context length, and generation is faster per character.
Details and conditions are in “Our Own Measurements” below.
Overview
The Qwen team has released Qwen3.8-27B, a 27B dense model on Hugging Face, serving as the core of the new generation of Qwen open models, Qwen3.8. The model card positions Qwen3.8 as “the highest-performing generation of Qwen open models to date," building on the Qwen3.5 architecture with significant improvements in coding, business tasks, research, and long-horizon multi-step agent workflows. It is a vision-language model (VLM) capable of understanding images and videos, allowing users to toggle the presence and depth of thinking per request.
Quantized versions and fine-tunes based on this model are being published in rapid succession. While our site has previously covered 7 derivative versions, this is our first article on the original base model.
Specifications
- Parameter count: 27B (language model portion; has a separate visual encoder)
- Architecture: Dense. A hybrid configuration of 64 layers stacking 16 repetitions of a 4-layer block: three “Gated DeltaNet → FFN" layers followed by one “Gated Attention → FFN" layer. In total, 48 of the 64 layers are linear attention (Gated DeltaNet) and 16 are standard attention (Gated Attention)
- Gated DeltaNet: Linear attention heads have 48 V and 16 QK, with a head dimension of 128
- Gated Attention: Attention heads have 24 Q and 4 KV, with a head dimension of 256 and a RoPE dimension of 64
- Hidden layer dimension: 5,120. FFN intermediate dimension: 17,408
- Vocabulary (embedding/output): 248,320 (including padding)
- MTP (Multi-Token Prediction): Trained for multi-step prediction
- Context length: Native 262,144 tokens. Expandable up to 1,000,000 tokens using YaRN
- Inputs: Text, images, and videos (Causal Language Model with a visual encoder)
Performance
The model card provides two comparison tables for text and vision (VL) respectively. The comparison targets are four models from the previous or competing generations: Qwen3.6-27B, Qwen3.7-Plus, Muse Glimmer-30B, and Opus4.6 Max, with all figures published by their respective creators (“–" indicates no result or not applicable).
Text Performance (transcribed directly from the model card table)
→ Scroll horizontally to see all columns
| Qwen3.8-27B | Qwen3.6-27B | Qwen3.7-Plus | Muse Glimmer-30B | Opus4.6 Max | |
|---|---|---|---|---|---|
| Coding | |||||
| Agentic terminal coding Terminal Bench 2.1 (Terminus) | 73.0 | 63.4 | 64.0 | 51.7 | 78.2 |
| Agentic coding SWE-bench Pro | 61.7 | 53.5 | 57.6 | 51.2 | 53.4 |
| Repo-level code generation NL2Repo-Bench | 42.3 | 36.2 | 41.1 | — | 47.6 |
| Agentic coding DeepSWE 1.1 | 42.2 | 13.3 | 14.2 | — | — |
| Software engineering QwenSWEBench | 79.0 | 49.3 | 59.2 | — | 63.8 |
| Agent | |||||
| Long-horizon office work CoWorkBench | 70.7 | 61.0 | 65.1 | — | 68.2 |
| Professional job tasks JobBench | 33.4 | 21.8 | 27.6 | — | — |
| Frontier agentic tasks Agents’ Last Exam | Pass@1 20.4 Score 42.9 | Pass@1 10.6 Score 27.3 | Pass@1 13.2 Score 33.6 | — | — |
| General | |||||
| Instruction following IFBench | 79.5 | 69.1 | 79.1 | 77.0 | 62.5 |
| Scientific reasoning GPQA Diamond | 89.2 | 87.8 | 90.3 | 83.5 | 91.3 |
| Multidisciplinary reasoning HLE | 30.8 | 24.0 | 34.7 | 22.0 | 40.0 |
| Competitive coding LiveCodeBench v6 | 90.3 | 83.9 | 89.6 | — | 88.8 |
According to the model card, it outperforms the previous-generation Qwen3.6-27B across all rows. The largest gains are seen in agentic coding, where DeepSWE 1.1 surged more than threefold from 13.3 to 42.2, and the creator’s internal benchmark QwenSWEBench rose from 49.3 to 79.0. SWE-bench Pro (the percentage of real GitHub issues resolved by editing repositories) stands at 61.7, the highest among the comparison targets. On the other hand, Terminal Bench 2.1, which measures terminal task completion, scores 73.0, falling 5.2 points short of Opus4.6 Max (78.2). PhD-level scientific reasoning (GPQA Diamond: 89.2) and expert-crafted ultra-hard benchmark HLE (30.8) trail both Qwen3.7-Plus and Opus4.6 Max, with a 9.2-point gap against Opus4.6 Max in HLE. The trend gathered from the table is that it is strong in hands-on, execution-driven coding and business tasks, while falling short of top-tier models in difficult knowledge and reasoning benchmarks. LiveCodeBench v6, which compiles recent competitive programming problems, achieved a top score of 90.3 among the evaluated models.
However, comparison conditions require caution. According to the model card notes, SWE-bench Pro values were officially reported only for Opus4.6 Max, while other models were re-evaluated using the Claude Code harness. QwenSWEBench and CoWorkBench are internal benchmarks by the Qwen team and cannot be independently reproduced by third parties under identical conditions.
Visual (VL) Performance (transcribed from the model card table)
→ Scroll horizontally to see all columns
| Qwen3.8-27B | Qwen3.6-27B | Qwen3.7-Plus | Muse Glimmer-30B | Opus4.6 Max | |
|---|---|---|---|---|---|
| Agentic Multimodal Intelligence | |||||
| Computer use OSWorld-Verified | 84.3 | 63.9 | 73.3 | 65.9 | 72.7 |
| Browser use WebArena-Verified | 64.8 | 48.8 | 55.3 | — | — |
| Mobile use AndroidWorld | 81.9 | 70.3 | 81.0 | — | 62.0 |
| Application recreation RecreationBench | 47.1 | 29.8 | 30.2 | — | — |
| Multimodal tool use ClawEval-MM | Pass@3 57.4 Average 56.9 | Pass@3 42.6 Average 50.4 | Pass@3 57.4 Average 60.1 | — | Pass@3 52.5 Average 54.7 |
| Multimodal software engineering SWE-MM | 38.6 | 25.7 | 30.0 | — | 27.1 |
| Visual web development Vision2Web | 62.9 | 45.0 | 42.1 | — | — |
| General Multimodal Intelligence | |||||
| Visual math problem solving MathVision | Without CI 90.0 With CI 94.6 | Without CI 85.1 | Without CI 90.3 | — | Without CI 65.5 |
| General visual reasoning BabyVision | Without CI 65.7 With CI 85.6 | Without CI 28.9 | Without CI 64.7 With CI 70.4 | — | Without CI 12.6 |
| Scientific chart analysis CharXiv (RQ) | Without CI 83.7 With CI 90.2 | Without CI 78.4 | Without CI 85.8 With CI 85.9 | 78.8 | Without CI 66.0 |
| Document intelligence OmniDocBench 1.5 | 91.1 | 89.4 | 91.4 | 75.8 | 86.6 |
| Real-world perception RealWorldQA | 85.9 | 84.1 | 86.9 | — | 73.9 |
| Embodied intelligence ERQA | 65.5 | 62.5 | 69.8 | — | 40.8 |
The visual domain shows a similar trend, with significant gains in screen-interaction tasks. OSWorld-Verified, which measures task completion via real OS screen operation, scored 84.3, outperforming Qwen3.7-Plus (73.3) and Opus4.6 Max (72.7) by over 11 points. Browser operation WebArena-Verified (64.8), image-based software engineering SWE-MM (38.6), and web page generation from visual input Vision2Web (62.9) also achieved the highest scores among comparison targets. On the other hand, it trails Qwen3.7-Plus in document reading (OmniDocBench 1.5: 91.1 vs 91.4), real-world photo recognition (RealWorldQA: 85.9 vs 86.9), embodied reasoning (ERQA: 65.5 vs 69.8), and multimodal tool use average score (ClawEval-MM: 56.9 vs 60.1). While the first two are narrow margins within 1 point, ERQA shows a 4.3-point gap. Note that values labeled “With CI" for MathVision, BabyVision, and CharXiv include tools like code execution and differ in conditions from “Without CI"; comparisons must be made between values under identical conditions.
Strengths and Use Cases
The enhancements highlighted in the model card focus on four areas: coding, business tasks, research, and long-horizon multi-step agent workflows, emphasizing autonomous planning and improved capability to sustain tasks based on environmental feedback (execution results and errors). As shown in the tables, notable improvements are concentrated in “execution-to-completion" tasks such as repository editing to resolve issues, as well as operating terminals, browsers, and OS screens, making it best suited as the brain for coding and PC-operating agents. The model card also highlights expanded compatibility with popular harnesses and development tools.
On the visual side, inputs ranging from STEM diagrams and documents to hour-long videos are supported. For handling longer videos, the model card recommends increasing longest_edge in the distributed video_preprocessor_config.json to 469,762,048 (equivalent to 224k video tokens) for finer-grained frame sampling.
Thinking control is managed through the following three mechanisms:
- Thinking mode is enabled by default. It can be turned off per request via
enable_thinking: Falseinchat_template_kwargs. reasoning_effortselects thinking depth fromxhigh(default),medium, andlow. However, the model card warns that in multi-turn agent workflows, lowering the depth does not necessarily reduce total execution time (shallower analysis can increase failures and retries, consuming more tokens instead).preserve_thinkingis enabled by default, retaining thinking blocks across the entire conversation history. This maintains agent decision consistency and facilitates KV cache reuse. Set toFalseif you only want to preserve thinking from the most recent utterance.
Recommended sampling settings are temperature=1.0, top_p=0.95, top_k=20, and presence_penalty=0.0 in thinking mode, and temperature=0.7, top_p=0.80, top_k=20, and presence_penalty=1.5 in non-thinking mode. If repetitive text loops occur, presence_penalty can be increased within the 0–2 range, though raising it too high may cause language mixing or a slight performance drop. For agent workflows, allocating sufficient output length is recommended, with target guidelines of up to 262,144 tokens for the thinking portion and up to 131,072 tokens for the final response.
How It Differs from Similar Models
Our site has previously covered derivatives based on this model. For instance, Ternary-Bonsai-2-27B-gguf: Our Test Answers, 8GB+ VRAM reconstructs Qwen3.8-27B into a ternary representation at an effective 1.72 bits per weight, aiming to run on modest hardware while minimizing performance loss compared to FP16. Qwen3.8-27B-TWIN-TURBO-Fable-Cold-Fusion-709-L-Uncensored-NM-DAU-NEO-MTP-GGUF is a personal fine-tune adjusted to reduce thinking tokens. Both derivatives trade off size or thinking length based on the base model’s capabilities. The original Qwen3.8-27B serves as the reference point delivering the performance shown in the tables under the creator’s conditions.
Hardware Requirements
Estimated requirements (calculated by Local Model Watch) — 27.8B parameters
| Your VRAM | Quantization | File size | Est. memory needed |
|---|---|---|---|
| 8GB (RTX 4060 / 3060 Ti, etc.) | IQ1_M | 6.3GB | 7.5GB |
| 12GB (RTX 4070 / 3060 12GB, etc.) | Q2_K_XL | 9.2GB | 11.0GB |
| 16GB (RTX 5060 Ti 16GB / 4060 Ti 16GB, etc.) | IQ4_XS | 13.3GB | 15.9GB |
| 24GB (RTX 4090 / 3090, etc.) | Q5_K_XL | 19.4GB | 23.3GB |
| 32GB (RTX 5090, etc.) | Q8_K_L | 26.1GB | 31.3GB |
| 48GB (RTX 6000 Ada / A6000, etc.) | Q8_K_XL | 29.3GB | 35.2GB |
| 80GB class (A100 / H100) | BF16 | 50.9GB | 61.1GB |
Inference engine support (architecture name matched against each project’s own model registry in its source code, checked 2026-11-11): llama.cpp: registered, vLLM: registered, MLX (mlx-lm): registered.
Memory estimates add a 20% runtime overhead (KV cache, etc.) to the actual size of the distributed files. Actual usage varies with context length, batch size and inference engine. These figures are computed by this site from file sizes, not published by the model’s authors. File sizes are measured from the converted build unsloth/Qwen3.8-27B-GGUF. Compare with other models in our VRAM quick reference. What the quantization names mean: glossary.
Can You Run It Locally?
Runs in Ollama, LM Studio and llama.cpp via a converted build.
The publisher ships safetensors, but unsloth/Qwen3.8-27B-GGUF provides a GGUF build you can use.
License — apache-2.0 (Commercial use allowed): Permits commercial use, modification and redistribution. Redistribution requires including the license and stating changes; includes a patent grant.
Compression: the IQ4_XS build measures 4.11 bits per weight — about 26% the size of the original 16-bit weights, calculated by this site from the actual file sizes.
Compiled by this site’s code from the published formats, converted builds we have found, and each engine’s own model registry. “Not found" means we have not seen such a build, not that none exists. License summaries are not legal advice — check the publisher’s original terms before relying on them.
Our Own Measurements
Values we measured ourselves on our server (no GPU) by actually reading and running this model’s files — not figures copied from the model card. How we measure, and the results for every model: Our Measurements.
What We Found
The 4-bit files of Qwen3.8-27B do not fit our CPU measurement limit, so we measured the lower-bit IQ3_XXS file (10.18GB). On a CPU alone it generated only 0.64 tokens per second (about 1.2 Japanese characters per second) and read prompts at 0.72 tokens per second, with a peak memory of 14.5GB. That is far behind Qwen3-8B at Q4_K_M (4.57 tokens per second) under the same conditions.
The accuracy of its answers, on the other hand, stood out. On the images we drew ourselves, it read Saturday’s 260 visitors and the weekday total of 635 from the chart, and gave all 4 item amounts and the total of 1,354 yen from the table. It also answered the word problem correctly with 280 yen and kept the summary to the requested three sentences.
It has weak spots too. On the question about prefectures that do not border the sea it named 5 of the 8 but mixed in 4 that do, repeated the same line 9 times and was cut off at the 1,024-token limit. Its business email contained 5 English words and its word-problem answer 3. On a CPU-only machine, expect much longer waits in exchange for that accuracy.
Japanese Token Efficiency
| Tokenizer | Tokens per 1,000 Japanese characters | Ratio to the same text in English |
|---|---|---|
| This model | 546 | 0.99× |
| Qwen3 | 688 | 1.26× |
| Llama 3.2 | 744 | 1.36× |
| Gemma 3 | 564 | 1.03× |
| gpt-oss | 795 | 1.45× |
| LLM-jp-3 | 497 | 0.85× |
It needs about 21% fewer tokens than the Qwen3 tokenizer for the same Japanese text, so about 1.26× as much Japanese fits in the same context length, and generation is faster per character.
Counted with the tokenizer.json of Qwen/Qwen3.8-27B on a fixed text we wrote ourselves (876 Japanese characters across news, conversation, technical docs, a formal email, travel writing and a recipe) and its English translation. Fewer tokens mean more Japanese fits in the context window.
Inside the GGUF File
File: Qwen3.8-27B-UD-Q4_K_M.gguf (15.33GB, Q4_K_M). We read only the header (metadata) of the file, not the weights.
| Item | Value |
|---|---|
| Architecture (as named in the GGUF) | qwen35 |
| Maximum trained context length | 262,144 tokens |
| Layers | 65 |
| Vocabulary size | 248,320 |
| Chat template | Included (mentions tool calls, has a thinking switch) |
| imatrix | Used (1,251 chunks) |
| Weight types (share of parameters) | IQ4_XS 32.8% / Q4_K 27.4% / Q5_K 25.7% / Q6_K 8.1% / other 6.0% |
| Average bits per weight | 4.82 bits |
| Embedding / output layer type | Q4_K / Q6_K |
The quant name in the file name describes the file as a whole; in practice layers mix several types. The average bits per weight is the measured file data divided by the number of weights.
Running It on a CPU Only
| Item | Result |
|---|---|
| Prompt processing (512 tokens) | 0.7 tokens/s |
| Generation (128 tokens) | 0.6 tokens/s |
| Generation in Japanese characters | about 1.2 characters/s |
| Peak memory (context 4,096 tokens) | 14.5GB |
Conditions: Neoverse-N1, 3 threads, no GPU, llama.cpp b11223, IQ3_XXS (10.18GB) from unsloth/Qwen3.8-27B-GGUF, measured 2026-09-29 (JST). The 4-bit files did not fit our 13GB limit, so we measured the lower-bit IQ3_XXS file; quality is lower than at 4 bits. Other models measured under the same conditions (closest in file size):
→ Scroll horizontally to see all columns
| Model | Quant | File size | Generation | In Japanese |
|---|---|---|---|---|
| Xing4.0-29B-A4B | IQ2_M |
10.99GB | 4.5 tokens/s | — |
| Signal-3.8-27B | IQ3_XXS |
11.39GB | 0.6 tokens/s | 1.2 chars/s |
| MiMo-V2.6-Distill-Qwen-9B | Q8_0 |
8.87GB | 3.7 tokens/s | 6.8 chars/s |
| Gryphe_Pantheon-Reasoning-26B-A4B-1.1-V2 | Q3_K_S |
12.26GB | 6.2 tokens/s | 11.0 chars/s |
Peak memory includes the model file mapped into memory (mmap). A PC with a GPU will be much faster; these figures are a guide for CPU-only machines such as mini PCs and ARM boards.
Answers to Our Japanese Questions (Verbatim)
We ask every model the same five questions in Japanese under the conditions above (temperature 0, thinking turned off where the chat template allows it, up to 1024 tokens) and publish the answers unedited. We do not grade them; where a question has a single correct answer, we show it for comparison.
Summarization
次の記事を3文で要約してください。
みどり市は今年の春、市内に三つある公立図書館のうち最も古い中央図書館の改修を終え、十月一日に再開館した。改修は約一年半にわたり、総事業費は約十二億円。このうち約四億円は国の補助金でまかなわれた。
最大の変化は、閲覧席の配置である。以前は館内の座席の大半が学習用の机で、試験期間になると中高生で埋まり、高齢の利用者や小さな子ども連れが座れないという苦情が毎年寄せられていた。改修後は座席数を百二十席から二百席に増やしたうえで、学習用の机を三階にまとめ、一階は会話ができる「にぎわいフロア」、二階は静かに本を読む「閲覧フロア」に分けた。一階には予約制のグループ学習室が四室と、飲み物を持ち込めるカフェスペースも設けられた。
蔵書の面でも見直しが進んだ。貸出の少ない古い資料約三万冊を市内の他の館や保存書庫に移し、代わりに子ども向けの絵本と、介護・子育て・仕事探しといった暮らしに関わる実用書を約一万五千冊増やした。電子書籍の貸出サービスも始まり、利用登録をすれば自宅から一度に三冊まで、二週間借りられる。
建物そのものにも手が入った。築四十年を超えていた空調設備を入れ替え、屋上には太陽光パネルを設置して、館内で使う電力の約二割をまかなえるようにした。車いすの利用者から要望の多かったエレベーターは一基から二基に増え、書架の間の通路も以前より三十センチ広げられた。入口には段差のないスロープが新たに設けられ、授乳室と多目的トイレも各階に一つずつ置かれた。
一方で課題も残る。駐車場は改修前と同じ四十台のままで、週末には近くの道路に順番待ちの車が並んだ。市は隣接する市有地を臨時駐車場として開放したが、恒久的な対策は決まっていない。また、開館時間を平日の夜九時まで延ばしたことで職員の負担が増えており、職員団体は人員の追加を求めている。
利用者の受け止めはおおむね好意的だ。週に二度、孫を連れて来るという七十代の女性は「前は子どもが声を出すと周りの目が気になったが、一階なら気兼ねなく絵本を読んであげられる」と話す。一方、受験を控えた高校生の中には「学習席が三階だけになり、夕方はすぐに満席になる」と不満を漏らす人もいる。図書館は、学習席の空き状況をホームページで確認できる仕組みを年内に導入する予定だ。
再開館に合わせて、催しも増えた。毎週土曜の午前には読み聞かせ会、月に一度は地元の農家や商店主を講師に招く「まちの先生」講座が開かれる。十一月には、市内の中学生が選んだ本を紹介する展示も予定されている。
館長の山本和子さんは「本を借りる場所から、人が集まって過ごす場所へ変えたかった。再開館からの一か月で来館者は以前の一・八倍になった」と話す。市は来年度、残る二つの図書館についても利用者への聞き取りを行い、改修の必要性を検討する方針だ。
(Summarize the following article in three sentences. (The article, about 1,200 Japanese characters, describes the renovation and reopening of a city’s central library: the budget, the new floor layout and seating, changes to the collection and e-book lending, building and accessibility work, remaining issues such as parking and staff workload, users’ reactions, new events, and the city’s next steps.))
みどり市は約12億円の費用をかけて中央図書館を改修し、座席の機能別配置や蔵書の見直し、バリアフリー化などを通じて、静寂な学習空間から多様な利用者が集う「にぎわい」の場へと転換した。
一方で、駐車場不足や職員負担増といった課題が残るものの、来館者数は再開後一か月で1.8倍に増加し、利用者からは概ね好意的な反応が得られている。
市は今回の改修を踏まえ、来年度には残る2つの図書館についても利用者への聞き取りを行い、今後の改修必要性を検討する方針である。
Formal business email
取引先の担当者に、来週火曜日の打ち合わせを水曜日に変更してほしいとお願いするメールを、丁寧な敬語で書いてください。
(Write an email in polite Japanese (keigo) asking a client’s contact person to move next Tuesday’s meeting to Wednesday.)
件名:【ご相談】来週火曜日の打ち合わせ日程変更のお願い
○○株式会社
○○部 ○○様
お世話になっております。
株式会社△△の△△です。
いつも大変お世話になっております。
この度は、来週火曜日(○月○日)に予定しております打ち合わせの件でご連絡いたしました。
大変恐縮ではございますが、社内都合により、誠に不本意ながら、
**来週水曜日(○月○日)** に変更させていただくことは可能でしょうか。
つきましては、以下の日程にて改めてご調整いただけますと幸いです。
■ 変更希望日時
来週水曜日(○月○日) ○○時~○○時
※ご都合のよろしい時間帯をお知らせいただければ、そちらに合わせて調整いたします。
ご多忙のところ、ご迷惑をおかけし誠に申し訳ございません。
何卒、ご検討のほど、よろしくお願い申し上げます。
――――――――――――――――
株式会社△△
△△部
△△(氏名)
TEL:03-XXXX-XXXX
Mail:xxxxx@xxxxx.com
――――――――――――――――
Word problem
りんごが1個120円、みかんが1個45円です。りんごを3個とみかんを8個買って、1,000円札で払いました。おつりはいくらですか。考え方も示してください。
(Apples cost 120 yen each and mandarins cost 45 yen each. You buy 3 apples and 8 mandarins and pay with a 1,000-yen bill. How much change do you get? Show your reasoning.)
おつりの計算と、その考え方の手順を以下に示します。
### 1. 考え方の手順
1. **りんごの合計金額を計算する**
* 1個の価格 × 個数
2. **みかんの合計金額を計算する**
* 1個の価格 × 個数
3. **買ったものの合計金額を計算する**
* りんごの合計 + みかんの合計
4. **おつりを計算する**
* 支払った金額(1,000円) - 合計金額
---
### 2. 具体的な計算
**① りんごの合計金額**
$$120 \text{円} \times 3 = 360 \text{円}$$
**② みかんの合計金額**
$$45 \text{円} \times 8 = 360 \text{円}$$
(※ $45 \times 8$ は、$45 \times 2 = 90$、$90 \times 4 = 360$ と計算すると楽です)
**③ 合計金額**
$$360 \text{円} + 360 \text{円} = 720 \text{円}$$
**④ おつり**
$$1,000 \text{円} - 720 \text{円} = 280 \text{円}$$
---
### 答え
おつりは **280円** です。
Reference: The correct answer is 280 yen (120×3 = 360, 45×8 = 360, 1,000 − 720 = 280).
Knowledge
日本の都道府県のうち、海に面していない県をすべて挙げてください。
(List all of Japan’s prefectures that do not border the sea.)
日本の都道府県の中で、海に面していない(内陸県)のは以下の**10県**です。
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **三重県** ※※※ **誤り訂正**:三重県は太平洋に面しています。
→ 正しくは:**滋賀県**
5. **奈良県**
6. **和歌山県** ※※※ **誤り訂正**:和歌山県は太平洋・紀伊水道に面しています。
→ 正しくは:**鳥取県**?いや、鳥取県は日本海に面しています。
→ 正しくは:**島根県**?いや、島根県も日本海に面しています。
---
**再確認と正しいリストの作成:**
日本の都道府県は全47県です。
海に面している県(沿岸県)と、海に面していない県(内陸県)に分けます。
**内陸県(海に面していない県)は以下の10県です:**
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **滋賀県**
5. **奈良県**
6. **和歌山県**? → 和歌山県は太平洋に面しています。
7. **鳥取県**? → 鳥取県は日本海に面しています。
8. **島根県**? → 島根県は日本海に面しています。
---
**正しい内陸県リスト(10県):**
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **滋賀県**
5. **奈良県**
6. **和歌山県** → **誤り**。和歌山県は海に面しています。
7. **鳥取県** → **誤り**。鳥取県は海に面しています。
8. **島根県** → **誤り**。島根県は海に面しています。
---
**正しい内陸県は以下の10県です:**
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **滋賀県**
5. **奈良県**
6. **和歌山県** → **誤り**
7. **鳥取県** → **誤り**
8. **島根県** → **誤り**
---
**最終確認:**
日本の内陸県(海に面していない県)は以下の**10県**です。
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **滋賀県**
5. **奈良県**
6. **和歌山県** → **誤り**(和歌山県は太平洋に面している)
7. **鳥取県** → **誤り**(鳥取県は日本海に面している)
8. **島根県** → **誤り**(島根県は日本海に面している)
---
**正しい内陸県リスト:**
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **滋賀県**
5. **奈良県**
6. **和歌山県** → **誤り**
7. **鳥取県** → **誤り**
8. **島根県** → **誤り**
---
**正しい内陸県は以下の10県です:**
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **滋賀県**
5. **奈良県**
6. **和歌山県** → **誤り**
7. **鳥取県** → **誤り**
8. **島根県** → **誤り**
---
**正しい内陸県リスト(最終版):**
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **滋賀県**
5. **奈良県**
6. **和歌山県** → **誤り**
7. **鳥取県** → **誤り**
8. **島根県** → **誤り**
---
**正しい内陸県は以下の10県です:**
1. **山梨県**
2. **長野県**
3. **岐阜県**
4. **滋賀県**
5. **奈良県**
6. **和歌山県** → **誤り
(Cut off at the 1024-token limit.)
Reference: The correct answer is eight prefectures: Tochigi, Gunma, Saitama, Yamanashi, Nagano, Gifu, Shiga and Nara.
Constrained writing
「春」をテーマにした俳句を3つ、五・七・五の音数を守って作ってください。それぞれに一言の説明を付けてください。
(Write three haiku on the theme of spring, keeping the 5-7-5 syllable pattern, each with a one-line explanation.)
ご指定の「春」をテーマにした俳句を3つ作成しました。それぞれ五・七・五の音数(モーラ数)を厳守しています。
1. **句:**
桜吹雪 舞い散る空 春の風
(さくら ふぶき まい ちる そら はる の かぜ)
* **説明:** 満開の桜が花びらを散らし、春の柔らかな風が吹く情景を詠みました。
2. **句:**
新緑の 木漏れ日揺れる 春の朝
(しんりょくの きもれび ゆれる はる の あさ)
* **説明:** 若葉が茂り始めた木々から差し込む光が揺れ動く、春の朝の静けさを表現しました。
3. **句:**
桃の花 咲き乱れし 春の庭
(もも の はな さき みだれし はる の にわ)
* **説明:** 桃の花が次々と咲き乱れ、庭全体が春の気配で賑わっている様子を詠みました。
Answers About Images (Verbatim)
Under the same conditions, we gave the model images we drew ourselves with code (a chart and a table in Japanese) and asked about them. Answers are unedited; the correct answers were computed by the code that drew the images.
Reading a chart

このグラフで来客数が最も多い曜日と、その人数を答えてください。また、平日(月曜日〜金曜日)の来客数の合計も求めてください。
(Which day has the most visitors in this chart, and how many? Also give the weekday (Mon-Fri) total.)
グラフから読み取れる情報に基づいて回答します。
---
**1. 来客数が最も多い曜日と人数**
グラフの各バーの高さと数値を確認すると:
- 月曜日:120人
- 火曜日:95人
- 水曜日:110人
- 木曜日:130人
- 金曜日:180人
- **土曜日:260人** ← 最大
- 日曜日:240人
→ **最も多いのは「土曜日」で、260人**です。
---
**2. 平日(月曜日〜金曜日)の来客数の合計**
月~金の人数を足し合わせます:
> 120(月) + 95(火) + 110(水) + 130(木) + 180(金)
計算:
120 + 95 = 215
215 + 110 = 325
325 + 130 = 455
455 + 180 = **635**
→ **平日の合計は 635人**
---
✅ **最終回答:**
- 来客数が最も多い曜日:**土曜日**、人数:**260人**
- 平日(月~金)の来客数合計:**635人**
Reference: Correct answer: Sat with 260 visitors; the weekday total is 635.
Reading a table and calculating

この表の品目ごとの金額(数量×単価)と、合計金額を答えてください。
(Give the amount for each item (quantity × unit price) in this table, and the total.)
### 手順
1. 各品目について、数量と単価を掛け算して金額を計算します。
2. 計算した各品目の金額をすべて足し算して、合計金額を求めます。
### 解答
**りんご:**
3 × 120円 = 360円
**みかん:**
8 × 45円 = 360円
**牛乳:**
2 × 198円 = 396円
**食パン:**
1 × 238円 = 238円
**合計金額:**
360円 + 360円 + 396円 + 238円 = 1354円
Reference: Correct answer: 360 yen, 360 yen, 396 yen, 238 yen; total 1,354 yen.
How to Get It
- Distribution format: Hugging Face’s
Qwen/Qwen3.8-27Bhosts the post-trained model weights and configuration files in Transformers format (safetensors). Agreement to terms of use is not required for download. - Example download command:
huggingface-cli download Qwen/Qwen3.8-27B - Supported engines: The model card lists usage with Transformers, vLLM, SGLang, and TokenSpeed. For production deployment or scenarios requiring high throughput, dedicated servers like SGLang, vLLM, and TokenSpeed are recommended. Note that inference efficiency varies significantly across frameworks, so using the latest versions is advised.
- API usage: Text, images (
image_url), and videos (video_url) can be passed via OpenAI-compatible Chat Completions APIs to servers set up with the above engines. Currently, vLLM is reportedly the only framework allowing per-request adjustment of video frame extraction (fps, etc.). - Long-context handling: YaRN must be used for contexts exceeding 262,144 tokens. vLLM, SGLang, and TokenSpeed support rewriting
rope_parametersintext_configwithinconfig.jsonor overriding via startup arguments. However, because all frameworks implement static YaRN (constant scaling factor regardless of input length), performance may degrade on short texts. The model card recommends enabling it only when long context is required and adjusting the scaling factor (factor) to match the intended length (e.g., 2.0 for 524,288 tokens). - llama.cpp, Ollama, and LM Studio are not mentioned in the model card. GGUF versions for these platforms are primarily converted and adjusted by third parties as seen in derivative articles, so verifying the source and quantization method prior to use is recommended.
Quantized and Converted Variants
→ Scroll horizontally to see all columns
| Added | Publisher | Format | Repository | Smallest VRAM tier (build, est. memory) |
|---|---|---|---|---|
| 2026-09-26 | unsloth | GGUF (imatrix) | unsloth/Qwen3.8-27B-GGUF | IQ1_M 7.5GB (fits in 8GB VRAM) |
| 2026-09-26 | Qwen | FP8 | Qwen/Qwen3.8-27B-FP8 | – |
| 2026-09-26 | lmstudio-community | MLX | lmstudio-community/Qwen3.8-27B-MLX-4bit | MLX 4bit 17.9GB (fits in 24GB VRAM) |
| 2026-09-26 | lmstudio-community | MLX | lmstudio-community/Qwen3.8-27B-MLX-8bit | MLX 8bit 33.0GB (fits in 48GB VRAM) |
| 2026-09-26 | unsloth | NVFP4 | unsloth/Qwen3.8-27B-NVFP4 | NVFP4 25.2GB (fits in 32GB VRAM) |
| 2026-09-26 | lmstudio-community | GGUF | lmstudio-community/Qwen3.8-27B-GGUF | Q4_K_M 18.8GB (fits in 24GB VRAM) |
| 2026-10-15 (19 days after publication) | autotrust | NVFP4 | autotrust/Qwen3.8-27B-NVFP4-DGX-SPARK | NVFP4 24.5GB (fits in 32GB VRAM) |
| 2026-11-10 (45 days after publication) | MiniMaxAI | INT8 | MiniMaxAI/MiniMax-H3-Image-PE | U8 20.0GB (fits in 24GB VRAM) |
File sizes of each build:
- Available builds in unsloth/Qwen3.8-27B-GGUF: IQ1_S 5.8GB / IQ1_M 6.3GB / IQ2_XXS 6.8GB / IQ2_S 7.8GB / Q2_K_XL 9.2GB / IQ3_XXS 10.2GB / IQ3_S 11.2GB / Q3_K_XL 12.2GB / IQ4_XS 13.3GB / Q4_K_S 14.3GB / Q4_0 15.0GB / Q4_K_M 15.3GB / Q4_1 16.3GB / Q4_K_XL 16.4GB / Q5_K_S 17.4GB / Q5_K_M 18.4GB / Q5_K_XL 19.4GB / Q6_K 20.5GB / Q6_K_M 21.5GB / Q6_K_L 22.5GB / Q6_K_XL 23.6GB / Q8_K_L 26.1GB / Q8_0 27.1GB / Q8_K_XL 29.3GB / BF16 50.9GB
- Available builds in lmstudio-community/Qwen3.8-27B-MLX-4bit: MLX 4bit 15.0GB
- Available builds in lmstudio-community/Qwen3.8-27B-MLX-8bit: MLX 8bit 27.5GB
- Available builds in unsloth/Qwen3.8-27B-NVFP4: NVFP4 21.0GB
- Available builds in lmstudio-community/Qwen3.8-27B-GGUF: Q4_K_M 15.7GB / Q6_K 20.9GB / Q8_0 27.1GB
- Available builds in autotrust/Qwen3.8-27B-NVFP4-DGX-SPARK: NVFP4 20.4GB
- Available builds in MiniMaxAI/MiniMax-H3-Image-PE: U8 16.7GB
In addition, 30 converted build(s) from other uploaders exist on Hugging Face; this site lists only builds from the model’s publisher or established quantization maintainers.
This section is appended automatically by Local Model Watch when a converted build of this model appears after publication. Memory figures are estimated from the size of the distributed files. What the quantization names mean: glossary.
Related Articles
- Ternary-Bonsai-2-27B-gguf: Our Test Answers, 8GB+ VRAM
- clef Structured Decision-Making Model: 12GB+ VRAM, GGUF Builds
- OrcaSAQ-2-27B Text Generation Model: Our Test Answers, 16GB+ VRAM
- Hemmingway-1 Text Generation Model: 12GB+ VRAM, GGUF Builds
What to Read Next
- Find models by VRAM (This model runs from the 8GB tier) → Other models that run on a 8GB GPU
- Explore the same model family → Qwen3.8 family overview (8 articles, 17 converted builds)
- Engines that run this model → llama.cpp / Ollama / vLLM
- What IQ1_M, IQ4_XS, Q8_K_L mean and where to get this model → GGUF format guide and models / MLX format guide and models / FP8 format guide and models / NVFP4 / MXFP4 format guide and models / Quantization and model-format glossary
- Learn about the publisher → Alibaba (Qwen): models, licenses and articles
Sources
Update History
- 2026-09-26: Added converted builds to “Quantized and Converted Variants”: unsloth/Qwen3.8-27B-GGUF, Qwen/Qwen3.8-27B-FP8, lmstudio-community/Qwen3.8-27B-MLX-4bit, lmstudio-community/Qwen3.8-27B-MLX-8bit, unsloth/Qwen3.8-27B-NVFP4, lmstudio-community/Qwen3.8-27B-GGUF
- 2026-09-26: Updated the hardware requirements table with the actual file sizes of unsloth/Qwen3.8-27B-GGUF.
- 2026-09-26: Changed the title to show what the article covers (VRAM requirements, file list, etc.).
- 2026-09-28: Added our own measurements: Japanese token efficiency, what is inside the GGUF file.
- 2026-09-29: Added our own measurements: CPU speed and answers to Japanese questions.
- 2026-09-30: Changed the title to show what the article covers (VRAM requirements, file list, etc.).
- 2026-10-16: Added converted builds to “Quantized and Converted Variants”: autotrust/Qwen3.8-27B-NVFP4-DGX-SPARK
- 2026-11-11: Added converted builds to “Quantized and Converted Variants”: MiniMaxAI/MiniMax-H3-Image-PE

