拓冰网站定制 
1. 8GB 显存跑 35B MoE到底卡在哪Ornith-1.5-35B-A3B 这个模型名字拆开看信息量很大总参数 35B每个 token 只激活约 3BA3B 就是 Active 3B 的意思MoE 架构MIT 协议原生 256K 上下文。它能在 8GB 显存的笔记本上跑起来靠的不是魔法而是三件事叠加MoE 稀疏激活把计算量压到 3B 级别、GGUF 量化把权重压到 4bit 左右、llama.cpp 的 CPUGPU 混合卸载把放不下的专家层丢给内存。但能跑和跑得舒服是两回事。我见过太多人卡在第一步直接-ngl 99全量卸载结果显存爆掉进程被杀或者量化档位选错Q8_0 文件 37GB 塞进 8GB 卡里根本加载不了再或者上下文开到 256KKV cache 直接把仅剩的显存吃干净。这篇就按选量化档位 → 写 llama.cpp 启动参数 → 验证显存与推理 → 排错的顺序把 8GB 显存这条路径走通。适合谁看手里有 8GB 显存显卡RTX 3070/4060 笔记本或桌面版都行、至少 32GB 内存、想本地跑一个能写代码的 Agent 模型的开发者。如果你只有 16GB 内存后面会讲怎么降级配置。先说结论Q4_K_M 是 8GB 显存 32GB 内存这个组合的甜点档文件约 20.2GB靠混合卸载能跑到 30 tok/s 上下128K 上下文可用。下面一步步来。2. 前置准备TaoToken 统一 Key 与 API 通道本地跑模型有个容易被忽略的环节配置校验和报错排查。llama.cpp 的报错经常很隐晦比如failed to load model背后可能是量化格式不匹配、也可能是 mmap 失败、还可能是 GGUF 版本太老。这时候如果有一个能直接对话、能贴报错、能问配置的通道排查效率会高很多。TaoToken 在这里的角色是统一 Key 和 API 通道你注册后拿到一个 Key就能通过它的 API 接入模型对话、coding plan、控制台和 API Keys 管理。对本地部署场景来说最实用的两个入口是模型对话贴报错问原因和接入文档查 OpenAI 兼容端点的调用格式。具体操作访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册账号然后在控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 里创建 API Key。Key 创建后到 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 可以随时查看和轮换。API 端点统一是 https://taotoken.net/api这个不加 UTM直接用于代码里。如果你要接 Claude Code 这类工具做配置校验参考文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里的接入说明长期做编码 Agent 的话Coding Plan 页面 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 有套餐说明。注意TaoToken 是合规的 API 聚合通道用于统一管理 Key 和调用入口不是任何形式的网络中转工具。本地 llama.cpp 服务和 TaoToken 是两条独立的链路——前者跑在你自己的硬件上后者用于配置校验和辅助排查。拿到 Key 后你可以用一行 curl 验证通道是否通curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4, messages: [{role: user, content: llama.cpp 报 failed to load model 常见原因有哪些}] }返回正常 JSON 就说明通道可用。这一步的意义在于后面 llama.cpp 出问题时你可以把报错原文贴给模型对话入口让它帮你定位是量化档位问题还是卸载层数问题。3. 可复制配置量化档位选择与 llama.cpp 启动参数3.1 量化档位怎么选GGUF 仓库里通常有多个量化文件8GB 显存这个场景下选择逻辑很明确量化档位文件大小8GB 显存可行性质量损失推荐场景Q8_0~37GB不可行几乎无损24GB 显存Q6_K~29GB勉强需大量卸载很小16GB 显存Q5_K_M~24GB可行卸载层数多小12GB 显存Q4_K_M~20.2GB甜点档可接受8GB 显存Q3_K_M~16GB轻松明显6GB 显存Q2_K~12GB很轻松较大应急Q4_K_M 是 llama.cpp 社区公认的质量/体积平衡点4bit 混合量化对 MoE 模型尤其友好——因为专家层本身稀疏量化误差被激活稀疏性稀释了一部分。8GB 显存下Q4_K_M 的 20.2GB 文件里注意力层和共享权重约 6-7GB可以塞进显存专家层留在内存由 CPU 计算。3.2 llama.cpp 启动参数骨架先确认 llama.cpp 版本够新MoE 架构支持在持续更新git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build --config Release -j编译时-DGGML_CUDAON开启 CUDA 加速AMD 卡换成-DGGML_HIPON纯 CPU 就不加。编译完build/bin/llama-server就是我们要用的。启动参数骨架8GB 显存 32GB 内存./build/bin/llama-server \ -m ./Ornith-1.5-35B-A3B-Q4_K_M.gguf \ --port 8000 \ --host 127.0.0.1 \ -c 131072 \ -ngl 12 \ -n 4096 \ --no-mmap \ -t 8 \ --flash-attn \ --cache-type-k q8_0 \ --cache-type-v q8_0逐个参数解释-ngl 12是关键。它表示卸载 12 层到 GPU。8GB 显存下这个数字需要试从 8 开始往上加加到显存占用接近 7.5GB 就停。不同量化档位、不同上下文长度下这个值不一样。Q4_K_M 128K 上下文12 层是个安全起点。-c 131072是 128K 上下文。官方支持 256K但 8GB 显存下 256K 的 KV cache 会吃掉太多空间。128K 对代码项目够用。--cache-type-k q8_0 --cache-type-v q8_0把 KV cache 量化到 8bit显存占用直接减半。这是 8GB 显存能开 128K 上下文的关键不设这个参数128K 的 KV cache 就要 8GB 以上。--no-mmap在内存不足时避免 mmap 导致的交换抖动32GB 内存下建议开。内存只有 16GB 的话去掉这个参数让系统用 mmap 按需加载。--flash-attn开启 Flash Attention减少注意力计算的显存峰值。-t 8是 CPU 线程数设成物理核心数。MoE 专家层在 CPU 上算线程数直接影响这部分速度。3.3 config.toml 骨架如果你用 OpenCode 或类似工具接本地端点配置文件骨架长这样[provider.ornith] npm ai-sdk/openai-compatible name Ornith Local options.baseURL http://127.0.0.1:8000/v1 options.apiKey EMPTY [provider.ornith.models.ornith-1.5-35b-a3b] name Ornith-1.5-35B-A3B contextWindow 131072 maxTokens 4096apiKey填EMPTY是因为本地 llama-server 默认不校验 Key。contextWindow要和启动参数-c一致否则工具会按错误的上下文长度发请求。采样参数按官方推荐通用任务temperature0.6, top_p0.95, top_k20要复现官方跑分用temperature1.0。注意这是推理模型默认输出think思考块服务端开 reasoning parser 后思考过程走单独的reasoning_content字段别当正文渲染。4. 验证请求与成功结果启动 llama-server 后终端会打印加载日志。重点看这几行llama_model_load: n_layer 48 llama_model_load: n_expert 128 llama_model_load: n_expert_used 8 llama_model_load: model size 20234.56 MB llama_model_load: CUDA0 model buffer size 6892.34 MB llama_model_load: CPU model buffer size 13342.22 MB llama_model_load: KV self size 1024.00 MBCUDA0 model buffer size就是显存占用6892MB 说明 12 层卸载后显存用了约 6.9GB8GB 卡还剩 1GB 余量给 KV cache 和计算缓冲。CPU model buffer size是留在内存的专家层13.3GB32GB 内存完全够。然后发一个验证请求curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: ornith-1.5-35b-a3b, messages: [{role: user, content: 写一个 Python 函数判断字符串是否为回文}], temperature: 0.6, max_tokens: 512 }成功返回的 JSON 里choices[0].message.content是正文choices[0].message.reasoning_content是思考过程。如果只看到思考块没有正文检查是否开了 reasoning parser。速度验证在返回的usage字段里看completion_tokens配合请求耗时算 tok/s。8GB 显存 32GB DDR5 内存下Q4_K_M 12 层卸载实测 28-35 tok/s 是正常区间。如果低于 15 tok/s检查-t线程数是否设对、内存是否跑在双通道、有没有开--flash-attn。显存占用验证另开终端跑nvidia-smi看 llama-server 进程的显存占用。稳定在 7-7.5GB 之间是健康的超过 7.8GB 就要降-ngl或降上下文。5. 本篇常见错排查5.1 failed to load model量化格式或 GGUF 版本不匹配最常见的原因是 llama.cpp 版本太老不认识新 GGUF 的 MoE 元数据。解决git pull更新到最新重新编译。如果还报错检查下载的 GGUF 文件是否完整sha256sum对比仓库里的校验值下载中断会导致文件损坏。5.2 CUDA out of memory卸载层数或上下文超了-ngl设太大或者-c设太大导致 KV cache 爆显存。排查顺序先把-ngl降到 8再把-c降到 65536确认能启动后再逐步往上加。KV cache 量化参数--cache-type-k q8_0 --cache-type-v q8_0一定要加不加的话 128K 上下文光 KV cache 就要 8GB。5.3 速度极慢10 tok/s内存或线程问题MoE 专家层在 CPU 上算内存带宽是瓶颈。检查内存是否双通道单通道带宽减半、-t是否设成物理核心数、有没有其他进程抢内存。16GB 内存的机器会频繁触发 swap速度会掉到个位数这种情况建议降到 Q3_K_M 量化档位。5.4 输出只有思考块没有正文这是推理模型的正常行为但需要服务端正确解析。llama-server 启动时加--reasoning-format deepseek或对应参数让think块走reasoning_content字段。如果客户端不认这个字段正文会显示为空。检查客户端是否支持 reasoning 字段或者临时用temperature0关掉思考。5.5 上下文超过 128K 后报错官方支持 256K但需要-c 262144且显存/内存足够。8GB 显存下 256K 的 KV cache 即使量化到 q8_0 也要 2GB 以上加上模型权重会爆。如果确实需要 256K建议降到 Q3_K_M 并减少-ngl或者用 16GB 显存的卡。排查时如果拿不准报错含义可以把完整报错贴到 TaoToken 的模型对话入口 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 让模型帮你分析。接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里有 OpenAI 兼容端点的完整调用格式配置校验时对照着看能省不少时间。6. 把本地链路接进编码 Agentllama-server 起来之后它就是一个 OpenAI 兼容端点。OpenCode、OpenClaw、Hermes 这些工具只要把OPENAI_BASE_URL指向http://127.0.0.1:8000/v1OPENAI_API_KEY填EMPTY就能用上本地这个 35B MoE 模型。如果你同时用 TaoToken 做云端模型的配置校验和报错排查两条链路可以并存本地 llama.cpp 跑主力编码任务TaoToken 通道用于查文档、问报错、验证配置。长期做编码 Agent 的话Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 里有针对持续编码场景的套餐和本地部署形成互补——本地跑量大管饱的日常任务云端通道处理需要更强推理的疑难问题。最后留一个实用技巧-ngl的最优值不是固定的换量化档位、改上下文长度、甚至换 llama.cpp 版本后都要重新试。写个脚本从 8 开始每次加 2跑一个固定 prompt 测 tok/s找到显存占用 7.5GB 附近的速度峰值那个就是你这台机器的甜点配置。 Ornith-1.5-35B-A3B 的 GGUF 量化实战：8GB 显存跑 35B MoE 的 llama.cpp 配置骨架
1. 8GB 显存跑 35B MoE到底卡在哪Ornith-1.5-35B-A3B 这个模型名字拆开看信息量很大总参数 35B每个 token 只激活约 3BA3B 就是 Active 3B 的意思MoE 架构MIT 协议原生 256K 上下文。它能在 8GB 显存的笔记本上跑起来靠的不是魔法而是三件事叠加MoE 稀疏激活把计算量压到 3B 级别、GGUF 量化把权重压到 4bit 左右、llama.cpp 的 CPUGPU 混合卸载把放不下的专家层丢给内存。但能跑和跑得舒服是两回事。我见过太多人卡在第一步直接-ngl 99全量卸载结果显存爆掉进程被杀或者量化档位选错Q8_0 文件 37GB 塞进 8GB 卡里根本加载不了再或者上下文开到 256KKV cache 直接把仅剩的显存吃干净。这篇就按选量化档位 → 写 llama.cpp 启动参数 → 验证显存与推理 → 排错的顺序把 8GB 显存这条路径走通。适合谁看手里有 8GB 显存显卡RTX 3070/4060 笔记本或桌面版都行、至少 32GB 内存、想本地跑一个能写代码的 Agent 模型的开发者。如果你只有 16GB 内存后面会讲怎么降级配置。先说结论Q4_K_M 是 8GB 显存 32GB 内存这个组合的甜点档文件约 20.2GB靠混合卸载能跑到 30 tok/s 上下128K 上下文可用。下面一步步来。2. 前置准备TaoToken 统一 Key 与 API 通道本地跑模型有个容易被忽略的环节配置校验和报错排查。llama.cpp 的报错经常很隐晦比如failed to load model背后可能是量化格式不匹配、也可能是 mmap 失败、还可能是 GGUF 版本太老。这时候如果有一个能直接对话、能贴报错、能问配置的通道排查效率会高很多。TaoToken 在这里的角色是统一 Key 和 API 通道你注册后拿到一个 Key就能通过它的 API 接入模型对话、coding plan、控制台和 API Keys 管理。对本地部署场景来说最实用的两个入口是模型对话贴报错问原因和接入文档查 OpenAI 兼容端点的调用格式。具体操作访问官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册账号然后在控制台 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 里创建 API Key。Key 创建后到 API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 可以随时查看和轮换。API 端点统一是 https://taotoken.net/api这个不加 UTM直接用于代码里。如果你要接 Claude Code 这类工具做配置校验参考文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里的接入说明长期做编码 Agent 的话Coding Plan 页面 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 有套餐说明。注意TaoToken 是合规的 API 聚合通道用于统一管理 Key 和调用入口不是任何形式的网络中转工具。本地 llama.cpp 服务和 TaoToken 是两条独立的链路——前者跑在你自己的硬件上后者用于配置校验和辅助排查。拿到 Key 后你可以用一行 curl 验证通道是否通curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_KEY \ -H Content-Type: application/json \ -d { model: claude-sonnet-4, messages: [{role: user, content: llama.cpp 报 failed to load model 常见原因有哪些}] }返回正常 JSON 就说明通道可用。这一步的意义在于后面 llama.cpp 出问题时你可以把报错原文贴给模型对话入口让它帮你定位是量化档位问题还是卸载层数问题。3. 可复制配置量化档位选择与 llama.cpp 启动参数3.1 量化档位怎么选GGUF 仓库里通常有多个量化文件8GB 显存这个场景下选择逻辑很明确量化档位文件大小8GB 显存可行性质量损失推荐场景Q8_0~37GB不可行几乎无损24GB 显存Q6_K~29GB勉强需大量卸载很小16GB 显存Q5_K_M~24GB可行卸载层数多小12GB 显存Q4_K_M~20.2GB甜点档可接受8GB 显存Q3_K_M~16GB轻松明显6GB 显存Q2_K~12GB很轻松较大应急Q4_K_M 是 llama.cpp 社区公认的质量/体积平衡点4bit 混合量化对 MoE 模型尤其友好——因为专家层本身稀疏量化误差被激活稀疏性稀释了一部分。8GB 显存下Q4_K_M 的 20.2GB 文件里注意力层和共享权重约 6-7GB可以塞进显存专家层留在内存由 CPU 计算。3.2 llama.cpp 启动参数骨架先确认 llama.cpp 版本够新MoE 架构支持在持续更新git clone https://github.com/ggerganov/llama.cpp cd llama.cpp cmake -B build -DGGML_CUDAON cmake --build build --config Release -j编译时-DGGML_CUDAON开启 CUDA 加速AMD 卡换成-DGGML_HIPON纯 CPU 就不加。编译完build/bin/llama-server就是我们要用的。启动参数骨架8GB 显存 32GB 内存./build/bin/llama-server \ -m ./Ornith-1.5-35B-A3B-Q4_K_M.gguf \ --port 8000 \ --host 127.0.0.1 \ -c 131072 \ -ngl 12 \ -n 4096 \ --no-mmap \ -t 8 \ --flash-attn \ --cache-type-k q8_0 \ --cache-type-v q8_0逐个参数解释-ngl 12是关键。它表示卸载 12 层到 GPU。8GB 显存下这个数字需要试从 8 开始往上加加到显存占用接近 7.5GB 就停。不同量化档位、不同上下文长度下这个值不一样。Q4_K_M 128K 上下文12 层是个安全起点。-c 131072是 128K 上下文。官方支持 256K但 8GB 显存下 256K 的 KV cache 会吃掉太多空间。128K 对代码项目够用。--cache-type-k q8_0 --cache-type-v q8_0把 KV cache 量化到 8bit显存占用直接减半。这是 8GB 显存能开 128K 上下文的关键不设这个参数128K 的 KV cache 就要 8GB 以上。--no-mmap在内存不足时避免 mmap 导致的交换抖动32GB 内存下建议开。内存只有 16GB 的话去掉这个参数让系统用 mmap 按需加载。--flash-attn开启 Flash Attention减少注意力计算的显存峰值。-t 8是 CPU 线程数设成物理核心数。MoE 专家层在 CPU 上算线程数直接影响这部分速度。3.3 config.toml 骨架如果你用 OpenCode 或类似工具接本地端点配置文件骨架长这样[provider.ornith] npm ai-sdk/openai-compatible name Ornith Local options.baseURL http://127.0.0.1:8000/v1 options.apiKey EMPTY [provider.ornith.models.ornith-1.5-35b-a3b] name Ornith-1.5-35B-A3B contextWindow 131072 maxTokens 4096apiKey填EMPTY是因为本地 llama-server 默认不校验 Key。contextWindow要和启动参数-c一致否则工具会按错误的上下文长度发请求。采样参数按官方推荐通用任务temperature0.6, top_p0.95, top_k20要复现官方跑分用temperature1.0。注意这是推理模型默认输出think思考块服务端开 reasoning parser 后思考过程走单独的reasoning_content字段别当正文渲染。4. 验证请求与成功结果启动 llama-server 后终端会打印加载日志。重点看这几行llama_model_load: n_layer 48 llama_model_load: n_expert 128 llama_model_load: n_expert_used 8 llama_model_load: model size 20234.56 MB llama_model_load: CUDA0 model buffer size 6892.34 MB llama_model_load: CPU model buffer size 13342.22 MB llama_model_load: KV self size 1024.00 MBCUDA0 model buffer size就是显存占用6892MB 说明 12 层卸载后显存用了约 6.9GB8GB 卡还剩 1GB 余量给 KV cache 和计算缓冲。CPU model buffer size是留在内存的专家层13.3GB32GB 内存完全够。然后发一个验证请求curl http://127.0.0.1:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: ornith-1.5-35b-a3b, messages: [{role: user, content: 写一个 Python 函数判断字符串是否为回文}], temperature: 0.6, max_tokens: 512 }成功返回的 JSON 里choices[0].message.content是正文choices[0].message.reasoning_content是思考过程。如果只看到思考块没有正文检查是否开了 reasoning parser。速度验证在返回的usage字段里看completion_tokens配合请求耗时算 tok/s。8GB 显存 32GB DDR5 内存下Q4_K_M 12 层卸载实测 28-35 tok/s 是正常区间。如果低于 15 tok/s检查-t线程数是否设对、内存是否跑在双通道、有没有开--flash-attn。显存占用验证另开终端跑nvidia-smi看 llama-server 进程的显存占用。稳定在 7-7.5GB 之间是健康的超过 7.8GB 就要降-ngl或降上下文。5. 本篇常见错排查5.1 failed to load model量化格式或 GGUF 版本不匹配最常见的原因是 llama.cpp 版本太老不认识新 GGUF 的 MoE 元数据。解决git pull更新到最新重新编译。如果还报错检查下载的 GGUF 文件是否完整sha256sum对比仓库里的校验值下载中断会导致文件损坏。5.2 CUDA out of memory卸载层数或上下文超了-ngl设太大或者-c设太大导致 KV cache 爆显存。排查顺序先把-ngl降到 8再把-c降到 65536确认能启动后再逐步往上加。KV cache 量化参数--cache-type-k q8_0 --cache-type-v q8_0一定要加不加的话 128K 上下文光 KV cache 就要 8GB。5.3 速度极慢10 tok/s内存或线程问题MoE 专家层在 CPU 上算内存带宽是瓶颈。检查内存是否双通道单通道带宽减半、-t是否设成物理核心数、有没有其他进程抢内存。16GB 内存的机器会频繁触发 swap速度会掉到个位数这种情况建议降到 Q3_K_M 量化档位。5.4 输出只有思考块没有正文这是推理模型的正常行为但需要服务端正确解析。llama-server 启动时加--reasoning-format deepseek或对应参数让think块走reasoning_content字段。如果客户端不认这个字段正文会显示为空。检查客户端是否支持 reasoning 字段或者临时用temperature0关掉思考。5.5 上下文超过 128K 后报错官方支持 256K但需要-c 262144且显存/内存足够。8GB 显存下 256K 的 KV cache 即使量化到 q8_0 也要 2GB 以上加上模型权重会爆。如果确实需要 256K建议降到 Q3_K_M 并减少-ngl或者用 16GB 显存的卡。排查时如果拿不准报错含义可以把完整报错贴到 TaoToken 的模型对话入口 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 让模型帮你分析。接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里有 OpenAI 兼容端点的完整调用格式配置校验时对照着看能省不少时间。6. 把本地链路接进编码 Agentllama-server 起来之后它就是一个 OpenAI 兼容端点。OpenCode、OpenClaw、Hermes 这些工具只要把OPENAI_BASE_URL指向http://127.0.0.1:8000/v1OPENAI_API_KEY填EMPTY就能用上本地这个 35B MoE 模型。如果你同时用 TaoToken 做云端模型的配置校验和报错排查两条链路可以并存本地 llama.cpp 跑主力编码任务TaoToken 通道用于查文档、问报错、验证配置。长期做编码 Agent 的话Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 里有针对持续编码场景的套餐和本地部署形成互补——本地跑量大管饱的日常任务云端通道处理需要更强推理的疑难问题。最后留一个实用技巧-ngl的最优值不是固定的换量化档位、改上下文长度、甚至换 llama.cpp 版本后都要重新试。写个脚本从 8 开始每次加 2跑一个固定 prompt 测 tok/s找到显存占用 7.5GB 附近的速度峰值那个就是你这台机器的甜点配置。