{"id":"5e42ff28-57cc-43b5-8502-c6b8b1792e7b","entityType":"agent","slug":"clawhub-hoperealize-llama-params-optimizer","name":"llama-params-optimizer","canonicalUrl":"https://www.xpersona.co/agent/clawhub-hoperealize-llama-params-optimizer","canonicalPath":"/agent/clawhub-hoperealize-llama-params-optimizer","generatedAt":"2026-10-11T14:14:52.887Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T11:35:50.761Z","emptyReason":null},"description":"Complete methodology for local LLM performance optimization. Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU... Skill: llama-params-optimizer Owner: hoperealize Summary: Complete methodology for local LLM performance optimization. Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU... Tags: latest:3.1.0, llama.cpp:2.0.0, local-llm:2.0.0, optimization:2.0.0, performance:2.0.0 Version history: v3.1.0 | 2026-04-28T11:07:43.048Z | user 新增 Qwen3.6-27B 实战案例；修正甜点公式为起点参考；batch-size 因模型而异；推理","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17ad6sxtk65d4y20pyavaxmys83mb6w:llama-params-optimizer","sourceUrl":"https://clawhub.ai/hoperealize/llama-params-optimizer","homepage":"https://clawhub.ai/hoperealize/skills/llama-params-optimizer","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/hoperealize/llama-params-optimizer","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/hoperealize/skills/llama-params-optimizer","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Complete methodology for local LLM performance optimization. Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T11:35:50.761Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T11:35:50.761Z","emptyReason":null},"stars":null,"forks":null,"downloads":1075,"packageName":null,"latestVersion":"3.1.0","tractionLabel":"1.1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T11:35:50.753Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T11:35:50.761Z","lastCrawledAt":"2026-10-11T11:35:50.753Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T11:35:50.753Z","lastVerifiedAt":null,"highlights":[{"version":"3.1.0","createdAt":"2026-04-28T11:07:43.048Z","changelog":"新增 Qwen3.6-27B 实战案例；修正甜点公式为起点参考；batch-size 因模型而异；推理模型 TTFT 开销说明；OpenClaw 配置对齐指南","fileCount":5,"zipByteSize":15482},{"version":"3.0.0","createdAt":"2026-04-26T12:22:48.654Z","changelog":"Fixed 0.0.0.0 references in all example files to use 127.0.0.1","fileCount":4,"zipByteSize":12285},{"version":"2.3.0","createdAt":"2026-04-26T12:18:01.227Z","changelog":"Security hardening: removed all 0.0.0.0 references, explicit localhost binding, clarified binary source safety, added cloud model debugging guidance","fileCount":4,"zipByteSize":12277},{"version":"2.2.0","createdAt":"2026-04-26T12:16:27.519Z","changelog":"Clarified binary source safety, removed 0.0.0.0 references, added explicit localhost binding recommendation","fileCount":4,"zipByteSize":12277},{"version":"2.1.0","createdAt":"2026-04-26T12:13:36.940Z","changelog":"Added safety guidelines, fixed host binding (0.0.0.0→127.0.0.1), added cloud model debugging suggestion","fileCount":4,"zipByteSize":12152},{"version":"2.0.0","createdAt":"2026-04-26T11:06:39.334Z","changelog":"llama-params-optimizer 2.0.0 introduces a revised \"GPU memory sweet spot\" principle and updated guidance for context settings. - Core optimization principle changed: prioritize maximizing context while fully utilizing dedicated GPU memory for optimal speed. - Methodology renamed and rewritten to focus on \"GPU 内存覆盖原则\" (GPU memory coverage principle), replacing references to \"context sweet spot.\" - All test tables and typical results revised: new speedup values and examples aligned with updated optimization strategy. - Documentation improved with clearer step-by-step guidance and updated case studies for 35B + 4060Ti (now showing 2–3x speedup). - Outdated claims and numbers removed or replaced for accuracy. - General language, layout, and process clarifications for both Chinese and English readers.","fileCount":4,"zipByteSize":10836},{"version":"1.2.0","createdAt":"2026-04-26T05:01:28.622Z","changelog":"llama-params-optimizer v1.2.0 - Added full bilingual (Chinese/English) documentation for global accessibility. - Improved description and keywords, emphasizing speedup (context \"sweet spot\") and universal applicability. - Clarified and streamlined step-by-step optimization methodology for easier adoption. - Highlighted real case results (e.g., 6% less context gives 75% faster speed, zero quality loss). - Updated counterintuitive findings and mitigation tips, making the guide more robust for diverse hardware and models.","fileCount":4,"zipByteSize":10567},{"version":"1.1.2","createdAt":"2026-04-26T04:54:32.970Z","changelog":"llama-params-optimizer 1.1.2 - 新增 “实战案例合集” 部分，详细区分 MoE 模型与 Dense 模型优化结果与最佳参数 - 增加 Qwen3.6-35B Dense 最新实测数据与参数推荐 - 补充不同模型类型在 `--parallel` 参数、上下文阈值等的最佳选择与警告 - 文档结构更清晰，方便快速查找针对性实战配置与经验","fileCount":4,"zipByteSize":8457}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17ad6sxtk65d4y20pyavaxmys83mb6w:llama-params-optimizer","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T14:14:52.883Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-hoperealize-llama-params-optimizer/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T11:35:50.761Z","emptyReason":null},"readme":"Skill: llama-params-optimizer\n\nOwner: hoperealize\n\nSummary: Complete methodology for local LLM performance optimization. Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU...\n\nTags: latest:3.1.0, llama.cpp:2.0.0, local-llm:2.0.0, optimization:2.0.0, performance:2.0.0\n\nVersion history:\n\nv3.1.0 | 2026-04-28T11:07:43.048Z | user\n\n新增 Qwen3.6-27B 实战案例；修正甜点公式为起点参考；batch-size 因模型而异；推理模型 TTFT 开销说明；OpenClaw 配置对齐指南\n\nv3.0.0 | 2026-04-26T12:22:48.654Z | user\n\nFixed 0.0.0.0 references in all example files to use 127.0.0.1\n\nv2.3.0 | 2026-04-26T12:18:01.227Z | user\n\nSecurity hardening: removed all 0.0.0.0 references, explicit localhost binding, clarified binary source safety, added cloud model debugging guidance\n\nv2.2.0 | 2026-04-26T12:16:27.519Z | user\n\nClarified binary source safety, removed 0.0.0.0 references, added explicit localhost binding recommendation\n\nv2.1.0 | 2026-04-26T12:13:36.940Z | user\n\nAdded safety guidelines, fixed host binding (0.0.0.0→127.0.0.1), added cloud model debugging suggestion\n\nv2.0.0 | 2026-04-26T11:06:39.334Z | auto\n\nllama-params-optimizer 2.0.0 introduces a revised \"GPU memory sweet spot\" principle and updated guidance for context settings.\n\n- Core optimization principle changed: prioritize maximizing context while fully utilizing dedicated GPU memory for optimal speed.\n- Methodology renamed and rewritten to focus on \"GPU 内存覆盖原则\" (GPU memory coverage principle), replacing references to \"context sweet spot.\"\n- All test tables and typical results revised: new speedup values and examples aligned with updated optimization strategy.\n- Documentation improved with clearer step-by-step guidance and updated case studies for 35B + 4060Ti (now showing 2–3x speedup).\n- Outdated claims and numbers removed or replaced for accuracy.\n- General language, layout, and process clarifications for both Chinese and English readers.\n\nv1.2.0 | 2026-04-26T05:01:28.622Z | auto\n\nllama-params-optimizer v1.2.0\n\n- Added full bilingual (Chinese/English) documentation for global accessibility.\n- Improved description and keywords, emphasizing speedup (context \"sweet spot\") and universal applicability.\n- Clarified and streamlined step-by-step optimization methodology for easier adoption.\n- Highlighted real case results (e.g., 6% less context gives 75% faster speed, zero quality loss).\n- Updated counterintuitive findings and mitigation tips, making the guide more robust for diverse hardware and models.\n\nv1.1.2 | 2026-04-26T04:54:32.970Z | auto\n\nllama-params-optimizer 1.1.2\n\n- 新增 “实战案例合集” 部分，详细区分 MoE 模型与 Dense 模型优化结果与最佳参数\n- 增加 Qwen3.6-35B Dense 最新实测数据与参数推荐\n- 补充不同模型类型在 `--parallel` 参数、上下文阈值等的最佳选择与警告\n- 文档结构更清晰，方便快速查找针对性实战配置与经验\n\nv1.1.1 | 2026-04-26T04:52:35.034Z | auto\n\n- 更新最佳启动参数推荐，现在对并行参数 `--parallel` 给出更精准的适用建议（4060Ti + 35B Dense 推荐 parallel=1，MoE 可测试 parallel=2）\n- 补充并细化实战案例部分，增加 Qwen3.6-35B Dense+4060Ti 120K 甜点阈值的完整启动命令，以及 Linux 启动命令含 CPU 亲和性绑定示例\n- 对比并强调不同模型（Dense/MoE）在 parallel 参数下的性能差异，避免经验主义误区\n- 文档内容修正和格式优化，提升易读性及操作性\n\nv1.1.0 | 2026-04-26T04:46:22.014Z | auto\n\nllama-params-optimizer 1.1.0\n\n- 全面升级优化方法论，新增四阶段十步法的标准化测试流程\n- 独创「上下文甜点阈值」参数发现方法，实现零质量损失、速度提升50-100%\n- 覆盖所有llama.cpp/llama-server模型和硬件，经验实战和反常识结论大幅扩充\n- 提供实战案例指导，详细的参数矩阵与可复现的性能/质量评估工具\n- 增加优化流程清单和最终一键启动命令输出\n\nArchive index:\n\nArchive v3.1.0: 5 files, 15482 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (2654b), example-qwen3.5-moe-4060ti.md (4538b), skill-card.md (2271b), SKILL.md (23150b)\n\nFile v3.1.0:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 3.1.0\ndescription: >\n  Complete methodology for local LLM performance optimization.\n  Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU runs at full speed.\n  Step-by-step 4-phase 10-step control variable testing process.\n  Works for ALL llama.cpp / llama-server models on ANY hardware.\n  Cases: Qwen3.5-MoE, Qwen3.6-35B, Qwen3.6-27B (2026-04-28).\nauthor: fenglai\nkeywords: [llama.cpp, performance optimization, local llm, llama-server, quantization, long context, control variable testing, speed optimization, reasoning models, OpenClaw config]\ntags: [llm, performance, optimization, local-first, chinese-support]\n---\n\n# llama.cpp 启动参数优化技能 / llama.cpp Parameter Optimization Guide\n\n**中文** | **English**  \n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。  \n_A standardized methodology for optimizing local LLM deployment parameters, using rigorous control variable testing to find the optimal performance/quality balance._\n\n**⚠️ 安全声明 / Safety Notice**\n- 本技能仅用于 **本地部署** 参数优化，所有测试应在隔离环境中进行。\n- **llama-server 和 llama.cpp 二进制文件**应仅从官方 GitHub 仓库 (https://github.com/ggerganov/llama.cpp) 获取，避免使用第三方来源。\n- **网络绑定安全**：本地开发/测试时建议绑定 `127.0.0.1`（localhost），生产环境必须通过反向代理 + HTTPS 暴露服务。\n- 参数调优可能触发 OOM 崩溃，**不确定最优参数时，建议使用云端模型（如 OpenAI/Gemini）进行推理验证**，本地只用于性能调优。\n- **不要在生产环境中使用本技能提供的示例命令直接暴露服务**，需根据实际安全需求调整。\n\n## 🎯 核心卖点 / Key Features\n- ✅ **GPU 内存覆盖原则** / _GPU Memory Coverage Principle_：在完全使用专用 GPU 内存的前提下，找到最大上下文值 | _Find max context while fully covering GPU memory_\n- ✅ **四阶段十步法控制变量测试** / _4-phase 10-step process_：完整的性能/质量评估 | _Comprehensive performance and quality evaluation_\n- ✅ **大量反常识踩坑经验** / _Battle-tested counterintuitive findings_：避免踩同样的坑 | _Avoid common pitfalls_\n- ✅ **通用方法论** / _Universal methodology_：提供系统化测试框架，具体参数需结合实际硬件验证 | _Provides a systematic testing framework; specific parameters must be validated against actual hardware._\n- ✅ **实战验证** / _Real-world proven_：35B+4060Ti 案例：~30 → ~90 token/s，提升 2-3 倍；27B 案例：~23.6 tok/s，验证理论公式不可靠 | _Multiple cases: MoE 262% boost, Dense 2-3x, 27B theoretical formula fails_\n\n## 适用场景 / When to Use\n\n**中文** | **English**  \n新模型首次部署，需要找到最佳启动参数  \n_First-time deployment of a new model, finding optimal launch parameters_  \n新硬件环境下的性能调优  \n_Performance tuning on new hardware_  \nllama.cpp / llama-server 启动参数优化  \n_llama.cpp / llama-server launch parameter optimization_  \n验证量化损失、长上下文能力等核心特性  \n_Verify quantization loss, long context capabilities, and other core features_\n\n---\n\n## 完整评估流程 / Complete Methodology\n_**4 phases, 10 steps**_\n\n---\n\n### 📊 第一阶段：基准建立 / Phase 1: Establish Baseline\n\n#### 步骤 1：建立初始基准 / Step 1: Run at default parameters\n**中文** | **English**  \n在默认参数下运行，记录基础性能数据：  \n_Run with default parameters and record baseline performance:_  \n```\n✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数 / Step 2: List all parameters to test\n**中文** | **English**  \n列出所有可能影响性能的参数：  \n_List all parameters that may affect performance:_  \n| 参数 / Parameter | 典型测试值 / Typical values |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试 / Phase 2: Control Variable Testing\n\n#### 步骤 3：逐个参数控制变量测试 / Step 3: Test one parameter at a time\n**中文** | **English**  \n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**  \n_**Core principle: Change only ONE parameter each time, keep ALL others at baseline!**_  \n\n❌ 错误做法 / Wrong way：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因  \n_Chain modification - change threads, then context, then FA - results can't be attributed_  \n✅ 正确做法 / Correct way：每次测试都回到基准配置，只改一个参数  \n_Return to baseline config for each test, change only one parameter_  \n\n#### 步骤 4：建立性能对比矩阵 / Step 4: Build comparison matrix\n\n**⚠️ 重要反常识发现 / Critical Counterintuitive Findings**\n- ❌ `--parallel 2` 不一定好 / Not always good：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益  \n  _On 4060Ti + 35B Dense, parallel=2 slows single request by 40% - scheduling overhead exceeds concurrency benefit_  \n- ✅ `--flash-attn on` 对长 Prompt 影响巨大 / Huge impact on long prompts：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍  \n  _300-500 → 1858 token/s, 3-5x faster, but only ±5% effect on regular generation_  \n- ❌ KV 缓存激进量化不一定好 / Aggressive KV quantization not always good：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，优先用 q8_0  \n  _q4_K can cause extremely slow loading on some llama.cpp versions - prefer q8_0_  \n\n**中文** | **English**  \n每个参数测试完成后，记录完整的对比表：  \n_After each parameter test, record complete comparison table:_  \n\n**示例：线程数对比 / Example: Thread count comparison**\n| 线程数 / Threads | 生成速度 / Gen Speed | Prompt 速度 / Prompt Speed | 变化 / Change | 推荐 / Recommend |\n|------------------|----------------------|-----------------------------|---------------|------------------|\n| 8 | 84.8 | 80.0 | 基准 / Baseline | 🏆 最佳 / Best |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：GPU 内存甜点阈值 / Priority: GPU Memory Sweet Spot\n**MUST DO first - highest ROI optimization!**\n\n**中文** | **English**  \n这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！  \n_This is the highest ROI optimization you can do - typically 50-100% speed boost with ZERO quality loss!_\n\n#### 背景 / Background\n**中文** | **English**  \n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：  \n_Almost every model + GPU combination has a cliff-like performance threshold:_  \n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值  \n  _Below threshold: GPU fully utilized, maximum theoretical speed_  \n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB  \n  _Above threshold: Speed drops by 40-60% (half speed), but VRAM only increases 30-50MB_  \n\n这不是线性下降，是跳崖式下降！原因通常是：  \n_This is NOT a linear degradation, but a cliff! Common causes:_  \n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍  \n   _GDDR memory bank alignment - cross-bank access latency increases 3-5x_  \n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页  \n   _FlashAttention tile size threshold - exceeding triggers cache swapping_  \n3. 大页内存分配失败，TLB 命中率骤降  \n   _Large page memory allocation failure - TLB hit rate plummets_  \n\n#### 标准测试方法 / Standard Testing Method\n**中文** | **English**  \n1. **从厂商标称的最大上下文开始** / _Start from manufacturer's advertised maximum_（比如 128K）  \n2. **每次降 4K** / _Reduce by 4K each time_（必须是 2 的幂次相关步长 / Must be power-of-2 aligned）  \n3. 每次都跑一次完整测速（生成 600 token 左右） / _Run full speed test each time (~600 tokens)_  \n4. 找到 **速度突然跳涨的那个点** / _Find the point where speed suddenly jumps_，就是你的黄金甜点阈值 / _That's your sweet spot!_  \n\n#### 典型测试结果示例 / Typical Test Results\n**Qwen3.6-35B + RTX 4060Ti 16GB**\n\n| 上下文大小 / Context | 生成速度 / Speed | 显存占用 / VRAM | 状态 / Status |\n|---------------------|------------------|-----------------|---------------|\n| 122880 (120K, 默认) | ~30 token/s | ~15.2 GB | ❌ 内存紧张 |\n| 118000 (118K) | ~29-36 token/s | ~15.1 GB | ❌ 内存紧张 |\n| **110000 (110K)** | **~90 token/s** | ~15.0 GB | ✅ 满速 |\n| 96K | ~86 token/s | ~14.5 GB | ✅ 满速 |\n| 64K | ~88 token/s | ~14.0 GB | ✅ 满速 |\n\n#### 核心结论 / Key Takeaways\n**中文** | **English**  \n- 通常甜点阈值 = 厂商标称最大值的 90-95%  \n  _Typically sweet spot = 90-95% of advertised maximum_  \n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%  \n  _Only 5-10% less context (completely unnoticeable) for 50-100% speed boost_  \n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行  \n  _**DO THIS FIRST!** All subsequent parameter testing should be done at the sweet spot_  \n\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例合集\n\n---\n\n### 案例1：Qwen3.5-MoE 35B + RTX 4060Ti 16GB（MoE 模型，仅供参考）\n\n#### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n#### 最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 2 | Prompt 最快，支持 2 并发 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n---\n\n### 案例2：Qwen3.6-35B Dense + RTX 4060Ti 16GB（Dense 模型，2026-04-26 最新测试，仅供参考）\n\n#### 优化成果\n**初始速度：~30 tokens/s → 最终速度：~90 tokens/s，提升 2-3 倍！**\n\n**📋 验证方法：**\n```bash\n# 标准 curl 测速命令（固定 temperature=0.7, max_tokens=100）\ncurl -s http://localhost:8080/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"messages\":[{\"role\":\"user\",\"content\":\"请写一段500字左右的技术博客文章，讨论本地部署大语言模型的性能优化方法\"}],\"max_tokens\":100,\"temperature\":0.7}'\n```\n\n**⚠️ 关键原则：GPU 内存覆盖就是生命线**\n> \"GPU 内存就是生命线，够用就快，不够用就慢。\"\n\n公式：**最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token开销**\n\n以 RTX 4060Ti 16GB + Qwen3.6-35B 为例：\n- 模型权重 ~13.4GB | KV缓存(ctx 110K) ~1.1GB | 计算缓冲 ~0.5GB | **总计 ~15GB**\n- 留出 ~1GB 缓冲，ctx-size=110000 是安全甜点\n\n#### 核心发现：GPU 内存覆盖原则\n| 上下文 | 速度 | 状态 |\n|--------|------|------|\n| 122880 (120K) | ~30 token/s | ❌ GPU 内存不足 |\n| 118000 (118K) | ~29-36 token/s | ❌ GPU 内存不足 |\n| **110000 (110K)** | **~90 token/s** | ✅ GPU 完全覆盖 |\n| 96K / 64K / 32K | ~86-88 token/s | ✅ 满速 |\n\n减少 8% 上下文，速度提升 **2-3 倍**，零质量损失！\n\n**GPU 内存分析 / GPU Memory Analysis:**\n| 项目 / Item | 占用 / Usage |\n|-------------|-------------|\n| 模型权重 | ~13.4 GB |\n| KV 缓存 (ctx 120K) | ~1.2 GB |\n| 计算缓冲区 | ~0.5 GB |\n| **总计** | **~15.2 GB** |\n| GPU 总 VRAM | 16 GB |\n| **剩余** | **~0.8 GB** |\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **110000（110K）** | GPU 完全覆盖，速度最快 |\n| `--threads` | 8 | 最佳 |\n| `-b / --batch-size` | 2048 | 最佳 |\n| `--parallel` | **1** | ❗ Dense 模型上 parallel=2 反而慢 40% |\n| `--flash-attn` | on | 必须开，长 Prompt 处理快 3-5 倍 |\n| `--cache-type-k/v` | q8_0 | q4_K 有兼容性问题 |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，110K 甜点阈值）\n```bash\n# Linux/WSL2（推荐，绑定到 localhost）\nllama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n> ⚠️ **生产环境建议**：如需对外提供服务，应通过 Nginx/Caddy 等反向代理 + HTTPS，不要直接暴露 llama-server。\n\n---\n\n### 案例3：Qwen3.6-27B Dense + RTX 4060Ti 16GB（2026-04-28 最新测试）\n\n**⚠️ 模型说明**：Qwen3.6-27B 是 Qwen3.6-35B 的更轻量版本，权重更小（~12GB vs ~13.4GB），但优化结论不完全相同！\n\n#### 优化成果\n**纯生成速度：~23.6 tok/s**\n\n#### 核心发现（与 35B 不同之处）\n\n**1. 理论计算不可靠！实际测试才是王道**\n- 理论公式算出甜点 = 110K（(16GB - 12GB - 1GB缓冲) ÷ KV每token ≈ 110K）\n- 实际测试 **110K 直接 CUDA OOM**\n- 真实甜点：**96K**（实测稳定，18.6 tok/s）\n- **结论：理论公式只能做起点参考，必须实际跑一遍才能确定**\n\n**2. Batch Size 对 27B 的影响与 35B 相反**\n- 35B（Dense）：2048 最佳\n- 27B（Dense）：**512 最佳**（2048 反而慢 6.6%）\n- 原因：27B 权重更小，GPU 有更多余量处理小 batch 的缓存效率\n\n**3. 推理模型的思考开销是硬伤**\n- Qwen3.6-27B 是推理模型（reasoning mode），内置思考过程\n- 简单问题（\"写一句诗\"）也要花 48 秒思考\n- 思考阶段输出 800+ reasoning chunks，但 max_tokens 被思考占满后无法输出\n- **如果不需要推理能力，换非推理版本（Qwen3.6-27B-Instruct 非推理版）体验更好**\n\n#### GPU 内存分析\n| 项目 | 占用 |\n|------|------|\n| 模型权重 | ~12 GB |\n| KV 缓存 (ctx 96K) | ~1.2 GB |\n| 计算缓冲区 | ~1.0 GB |\n| **总计** | **~14.2 GB** |\n| GPU 总 VRAM | 16 GB |\n| **剩余** | **~1.8 GB** |\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **96000** | 实测甜点（110K OOM） |\n| `--threads` | 8 | 比 16 省 50% CPU，速度差异 <2% |\n| `-b / --batch-size` | **512** | 27B 上 512 比 2048 快 6.6% |\n| `--parallel` | 1 | Dense 模型单请求最快 |\n| `--flash-attn` | on | off 会崩溃 |\n| `--cache-type-k/v` | q8_0 | 零质量损失，省显存 |\n\n#### 最终启动命令\n```bash\nllama-server -m \"Qwen3.6-27B-Q3_K_S.gguf\" \\\n  --n-gpu-layers 9999 --ctx-size 96000 --port 8080 --host 127.0.0.1 \\\n  --threads 8 --threads-batch 8 --mlock --parallel 1 \\\n  --kv-unified --flash-attn on -b 512 \\\n  --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n#### 配套配置\n**llama-server 守护进程** (`~/.config/systemd/user/llama-server.service`)\n```ini\n[Service]\nExecStart=/home/fenglai/llama.cpp/build/bin/llama-server \\\n  -m /home/fenglai/models/Qwen3.6-27B-Q3_K_S.gguf \\\n  --n-gpu-layers 9999 --ctx-size 96000 --port 8080 --host 127.0.0.1 \\\n  --threads 8 --threads-batch 8 --mlock --parallel 1 \\\n  --kv-unified --flash-attn on -b 512 \\\n  --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n**OpenClaw 配置** (`~/.openclaw/openclaw.json`)\n```json\n\"contextWindow\": 96000,\n\"maxTokens\": 48000\n```\n> ⚠️ OpenClaw 的 contextWindow 必须与 llama-server 的 --ctx-size 保持一致，否则会导致上下文截断或 OOM。maxTokens 设为 ctx-size 的一半左右，给 prompt 留出空间。\n\n#### OpenClaw 配置注意事项\n- `contextWindow` 必须等于 `--ctx-size`（96000）\n- `maxTokens` 建议设为 `ctx-size / 2`（48000），为 prompt 预留空间\n- `reserveTokensFloor`（compaction 保留 token）建议设为 20000，避免频繁压缩\n- 模型 `reasoning: true` 需开启，否则思考内容无法正确解析\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 `taskset` 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n> ⚠️ **安全提示**：此功能仅在 Linux/WSL2 下可用，Windows 下无等效命令。\n\n---\n\n## 核心原则\n\n1. **GPU 内存覆盖优先**：在完全使用专用 GPU 内存的前提下，找到最大上下文值 — 这是提升速度最快的优化\n2. **GPU 内存就是生命线**：够用就快，不够用就慢（GPU↔CPU 交换是最大性能杀手）\n3. **甜点公式只是起点**：公式计算 (GPU VRAM - 权重 - 缓冲) ÷ KV 每 token 开销，但**实际测试才是唯一真理**（27B 上公式算 110K，实际 96K 才是甜点）\n4. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n5. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n6. **量化不一定是损失**：有时候反而更快，一定要实际测试\n7. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n8. **不同模型结论不同**：MoE 和 Dense 最佳参数可能完全相反；同系列不同大小（27B vs 35B）的 batch size 最优值也可能相反\n9. **推理模型的思考开销**：Qwen3.6 等推理模型内置 thinking chain，TTFT 极长（40-50s），不适合需要低延迟的对话场景\n10. **OpenClaw 配置必须对齐**：`contextWindow` 必须等于 `--ctx-size`，`maxTokens` 约等于 `ctx-size / 2`，否则上下文异常\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\n## 安全与调试建议\n\n### 参数调试安全指南\n1. **小步测试**：每次调整幅度不超过 10%，避免 OOM\n2. **监控显存**：使用 `nvidia-smi` 实时观察，确保不突破 GPU 上限\n3. **崩溃自救**：如果模型频繁崩溃，尝试减小 `--ctx-size` 或 `--batch-size`\n4. **云端辅助调试**：当本地模型因参数不当反复崩溃时，建议使用云端模型（OpenAI / Gemini / 通义千问等）进行推理验证和逻辑测试。本地环境只用于性能调优，不用于逻辑正确性验证\n5. **参数记录**：所有测试参数必须记录，避免重复试错\n6. **避免生产配置泄露**：不要在公网文档、代码仓库中暴露 llama-server 的内部参数\n\n### 反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 35B 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n**示例（来自 Qwen3.6-27B Dense 实战，2026-04-28）：**\n1. ❗ **理论计算不可靠**：公式算出 110K 甜点，实际 110K 直接 CUDA OOM，真实甜点 96K。必须实测！\n2. ❗ **Batch size 结论因模型而异**：35B Dense 上 2048 最优，27B Dense 上 512 反而快 6.6%。不要照搬！\n3. ❗ **推理模型有思考开销**：Qwen3.6 内置推理链，简单问题也要 40-50 秒 TTFT，不适合日常对话\n4. ❗ **threads-batch 影响**：--threads-batch 8 比默认 1 提升 prompt 处理速度\n5. ❗ **OpenClaw contextWindow 必须匹配**：配置里的 contextWindow/maxTokens 要跟 --ctx-size 对齐，否则上下文异常\n\n> 💡 **重要提醒**：不同模型、不同量化版本的最佳参数差异可能很大。**不要直接套用**他人参数，必须实际测试。如果本地模型因参数设置不当频繁崩溃，可先用云端模型做逻辑验证，本地只用于性能调优。\n\nFile v3.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"3.1.0\",\n  \"publishedAt\": 1777374463048\n}\n\nFile v3.1.0:CHANGELOG.md\n\n# CHANGELOG\n\n## v3.1.0 (2026-04-28)\n\n### ✨ 新增\n- 新增 Qwen3.6-27B Dense + RTX 4060Ti 16GB 实战案例\n- 新增推理模型（reasoning models）思考开销说明：Qwen3.6 内置推理链，TTFT 40-50 秒\n- 新增 OpenClaw 配置对齐指南：contextWindow/maxTokens 必须与 --ctx-size 匹配\n\n### 🐛 修正\n- 甜点公式从\"唯一真理\"降级为\"起点参考\"，强调理论计算不可靠，实测才是王道（27B 上公式算 110K OOM，实际甜点 96K）\n- batch-size 最优值因模型大小而异：35B Dense 上 2048 最优，27B Dense 上 512 反而快 6.6%\n- 核心原则从 7 条扩展至 10 条\n\n---\n\n## v1.2.0 (2026-04-26)\n\n### ✨ 国际化\n- 完整中英文双语版本（Bilingual），全球用户可用\n- Frontmatter description 改为英文，便于搜索引擎索引\n- 所有章节标题、核心概念、步骤说明均提供中英文对照\n- 保留完整的中文详细步骤说明\n\n---\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v3.1.0:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n---\n\n## 五大反常识发现总结\n\n1. **默认 batch size 巨坑**：只有 512，改成 2048 直接快 67.7%！\n2. **KV 量化不是损失**：8bit KV 反而让 Prompt 处理快了 128%！\n3. **Flash Attention 对 MoE 真香**：虽然生成慢 1.3%，但 Prompt 快 128%！\n4. **线程不是越多越好**：8 线程比 12/16 都快！\n5. **ubatch-size 千万别改**：默认的 512 就是最佳的，改了反而慢 60%！\n\nFile v3.1.0:skill-card.md\n\n## Description:\n\nComplete methodology for local LLM performance optimization using a four-phase control-variable process to tune llama.cpp and llama-server parameters across hardware.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[hoperealize](https://clawhub.ai/user/hoperealize)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to benchmark local llama.cpp and llama-server deployments, compare launch parameters, and produce recommended configurations for performance, context length, and stability.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Example llama-server commands could expose a local model service if copied into an externally reachable deployment.\n\nMitigation: Keep llama-server bound to localhost unless a reverse proxy, HTTPS, and deployment-specific access controls are configured.\n\nRisk: Parameter tuning can trigger out-of-memory failures or mismatched context settings on local hardware.\n\nMitigation: Validate settings against the target GPU and align OpenClaw contextWindow and maxTokens with the selected llama-server context size.\n\nRisk: Cloud model checks used during tuning may receive sensitive prompts if operators reuse private test data.\n\nMitigation: Use non-sensitive prompts for cloud validation and keep private or regulated content out of external model calls.\n\n## Reference(s):\n\n- [llama.cpp](https://github.com/ggerganov/llama.cpp)\n- [ClawHub skill page](https://clawhub.ai/hoperealize/skills/llama-params-optimizer)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown with benchmark tables, command examples, and configuration snippets]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces hardware-specific recommendations that should be validated on the target machine.]\n\n## Skill Version(s):\n\n3.1.0 (source: frontmatter, changelog, server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v3.0.0: 4 files, 12285 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (2036b), example-qwen3.5-moe-4060ti.md (4538b), SKILL.md (18936b)\n\nFile v3.0.0:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 3.0.0\ndescription: >\n  Complete methodology for local LLM performance optimization.\n  Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU runs at full speed.\n  Step-by-step 4-phase 10-step control variable testing process.\n  Works for ALL llama.cpp / llama-server models on ANY hardware.\nauthor: fenglai\nkeywords: [llama.cpp, performance optimization, local llm, llama-server, quantization, long context, control variable testing, speed optimization]\ntags: [llm, performance, optimization, local-first, chinese-support]\n---\n\n# llama.cpp 启动参数优化技能 / llama.cpp Parameter Optimization Guide\n\n**中文** | **English**  \n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。  \n_A standardized methodology for optimizing local LLM deployment parameters, using rigorous control variable testing to find the optimal performance/quality balance._\n\n**⚠️ 安全声明 / Safety Notice**\n- 本技能仅用于 **本地部署** 参数优化，所有测试应在隔离环境中进行。\n- **llama-server 和 llama.cpp 二进制文件**应仅从官方 GitHub 仓库 (https://github.com/ggerganov/llama.cpp) 获取，避免使用第三方来源。\n- **网络绑定安全**：本地开发/测试时建议绑定 `127.0.0.1`（localhost），生产环境必须通过反向代理 + HTTPS 暴露服务。\n- 参数调优可能触发 OOM 崩溃，**不确定最优参数时，建议使用云端模型（如 OpenAI/Gemini）进行推理验证**，本地只用于性能调优。\n- **不要在生产环境中使用本技能提供的示例命令直接暴露服务**，需根据实际安全需求调整。\n\n## 🎯 核心卖点 / Key Features\n- ✅ **GPU 内存覆盖原则** / _GPU Memory Coverage Principle_：在完全使用专用 GPU 内存的前提下，找到最大上下文值 | _Find max context while fully covering GPU memory_\n- ✅ **四阶段十步法控制变量测试** / _4-phase 10-step process_：完整的性能/质量评估 | _Comprehensive performance and quality evaluation_\n- ✅ **大量反常识踩坑经验** / _Battle-tested counterintuitive findings_：避免踩同样的坑 | _Avoid common pitfalls_\n- ✅ **通用方法论** / _Universal methodology_：提供系统化测试框架，具体参数需结合实际硬件验证 | _Provides a systematic testing framework; specific parameters must be validated against actual hardware._\n- ✅ **实战验证** / _Real-world proven_：35B+4060Ti 实战案例：从 ~30 token/s → ~90 token/s，提升 2-3 倍 | _35B + 4060Ti real case: ~30 → ~90 token/s, 2-3x improvement_\n\n## 适用场景 / When to Use\n\n**中文** | **English**  \n新模型首次部署，需要找到最佳启动参数  \n_First-time deployment of a new model, finding optimal launch parameters_  \n新硬件环境下的性能调优  \n_Performance tuning on new hardware_  \nllama.cpp / llama-server 启动参数优化  \n_llama.cpp / llama-server launch parameter optimization_  \n验证量化损失、长上下文能力等核心特性  \n_Verify quantization loss, long context capabilities, and other core features_\n\n---\n\n## 完整评估流程 / Complete Methodology\n_**4 phases, 10 steps**_\n\n---\n\n### 📊 第一阶段：基准建立 / Phase 1: Establish Baseline\n\n#### 步骤 1：建立初始基准 / Step 1: Run at default parameters\n**中文** | **English**  \n在默认参数下运行，记录基础性能数据：  \n_Run with default parameters and record baseline performance:_  \n```\n✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数 / Step 2: List all parameters to test\n**中文** | **English**  \n列出所有可能影响性能的参数：  \n_List all parameters that may affect performance:_  \n| 参数 / Parameter | 典型测试值 / Typical values |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试 / Phase 2: Control Variable Testing\n\n#### 步骤 3：逐个参数控制变量测试 / Step 3: Test one parameter at a time\n**中文** | **English**  \n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**  \n_**Core principle: Change only ONE parameter each time, keep ALL others at baseline!**_  \n\n❌ 错误做法 / Wrong way：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因  \n_Chain modification - change threads, then context, then FA - results can't be attributed_  \n✅ 正确做法 / Correct way：每次测试都回到基准配置，只改一个参数  \n_Return to baseline config for each test, change only one parameter_  \n\n#### 步骤 4：建立性能对比矩阵 / Step 4: Build comparison matrix\n\n**⚠️ 重要反常识发现 / Critical Counterintuitive Findings**\n- ❌ `--parallel 2` 不一定好 / Not always good：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益  \n  _On 4060Ti + 35B Dense, parallel=2 slows single request by 40% - scheduling overhead exceeds concurrency benefit_  \n- ✅ `--flash-attn on` 对长 Prompt 影响巨大 / Huge impact on long prompts：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍  \n  _300-500 → 1858 token/s, 3-5x faster, but only ±5% effect on regular generation_  \n- ❌ KV 缓存激进量化不一定好 / Aggressive KV quantization not always good：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，优先用 q8_0  \n  _q4_K can cause extremely slow loading on some llama.cpp versions - prefer q8_0_  \n\n**中文** | **English**  \n每个参数测试完成后，记录完整的对比表：  \n_After each parameter test, record complete comparison table:_  \n\n**示例：线程数对比 / Example: Thread count comparison**\n| 线程数 / Threads | 生成速度 / Gen Speed | Prompt 速度 / Prompt Speed | 变化 / Change | 推荐 / Recommend |\n|------------------|----------------------|-----------------------------|---------------|------------------|\n| 8 | 84.8 | 80.0 | 基准 / Baseline | 🏆 最佳 / Best |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：GPU 内存甜点阈值 / Priority: GPU Memory Sweet Spot\n**MUST DO first - highest ROI optimization!**\n\n**中文** | **English**  \n这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！  \n_This is the highest ROI optimization you can do - typically 50-100% speed boost with ZERO quality loss!_\n\n#### 背景 / Background\n**中文** | **English**  \n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：  \n_Almost every model + GPU combination has a cliff-like performance threshold:_  \n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值  \n  _Below threshold: GPU fully utilized, maximum theoretical speed_  \n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB  \n  _Above threshold: Speed drops by 40-60% (half speed), but VRAM only increases 30-50MB_  \n\n这不是线性下降，是跳崖式下降！原因通常是：  \n_This is NOT a linear degradation, but a cliff! Common causes:_  \n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍  \n   _GDDR memory bank alignment - cross-bank access latency increases 3-5x_  \n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页  \n   _FlashAttention tile size threshold - exceeding triggers cache swapping_  \n3. 大页内存分配失败，TLB 命中率骤降  \n   _Large page memory allocation failure - TLB hit rate plummets_  \n\n#### 标准测试方法 / Standard Testing Method\n**中文** | **English**  \n1. **从厂商标称的最大上下文开始** / _Start from manufacturer's advertised maximum_（比如 128K）  \n2. **每次降 4K** / _Reduce by 4K each time_（必须是 2 的幂次相关步长 / Must be power-of-2 aligned）  \n3. 每次都跑一次完整测速（生成 600 token 左右） / _Run full speed test each time (~600 tokens)_  \n4. 找到 **速度突然跳涨的那个点** / _Find the point where speed suddenly jumps_，就是你的黄金甜点阈值 / _That's your sweet spot!_  \n\n#### 典型测试结果示例 / Typical Test Results\n**Qwen3.6-35B + RTX 4060Ti 16GB**\n\n| 上下文大小 / Context | 生成速度 / Speed | 显存占用 / VRAM | 状态 / Status |\n|---------------------|------------------|-----------------|---------------|\n| 122880 (120K, 默认) | ~30 token/s | ~15.2 GB | ❌ 内存紧张 |\n| 118000 (118K) | ~29-36 token/s | ~15.1 GB | ❌ 内存紧张 |\n| **110000 (110K)** | **~90 token/s** | ~15.0 GB | ✅ 满速 |\n| 96K | ~86 token/s | ~14.5 GB | ✅ 满速 |\n| 64K | ~88 token/s | ~14.0 GB | ✅ 满速 |\n\n#### 核心结论 / Key Takeaways\n**中文** | **English**  \n- 通常甜点阈值 = 厂商标称最大值的 90-95%  \n  _Typically sweet spot = 90-95% of advertised maximum_  \n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%  \n  _Only 5-10% less context (completely unnoticeable) for 50-100% speed boost_  \n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行  \n  _**DO THIS FIRST!** All subsequent parameter testing should be done at the sweet spot_  \n\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例合集\n\n---\n\n### 案例1：Qwen3.5-MoE 35B + RTX 4060Ti 16GB（MoE 模型，仅供参考）\n\n#### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n#### 最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 2 | Prompt 最快，支持 2 并发 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n---\n\n### 案例2：Qwen3.6-35B Dense + RTX 4060Ti 16GB（Dense 模型，2026-04-26 最新测试，仅供参考）\n\n#### 优化成果\n**初始速度：~30 tokens/s → 最终速度：~90 tokens/s，提升 2-3 倍！**\n\n**📋 验证方法：**\n```bash\n# 标准 curl 测速命令（固定 temperature=0.7, max_tokens=100）\ncurl -s http://localhost:8080/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"messages\":[{\"role\":\"user\",\"content\":\"请写一段500字左右的技术博客文章，讨论本地部署大语言模型的性能优化方法\"}],\"max_tokens\":100,\"temperature\":0.7}'\n```\n\n**⚠️ 关键原则：GPU 内存覆盖就是生命线**\n> \"GPU 内存就是生命线，够用就快，不够用就慢。\"\n\n公式：**最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token开销**\n\n以 RTX 4060Ti 16GB + Qwen3.6-35B 为例：\n- 模型权重 ~13.4GB | KV缓存(ctx 110K) ~1.1GB | 计算缓冲 ~0.5GB | **总计 ~15GB**\n- 留出 ~1GB 缓冲，ctx-size=110000 是安全甜点\n\n#### 核心发现：GPU 内存覆盖原则\n| 上下文 | 速度 | 状态 |\n|--------|------|------|\n| 122880 (120K) | ~30 token/s | ❌ GPU 内存不足 |\n| 118000 (118K) | ~29-36 token/s | ❌ GPU 内存不足 |\n| **110000 (110K)** | **~90 token/s** | ✅ GPU 完全覆盖 |\n| 96K / 64K / 32K | ~86-88 token/s | ✅ 满速 |\n\n减少 8% 上下文，速度提升 **2-3 倍**，零质量损失！\n\n**GPU 内存分析 / GPU Memory Analysis:**\n| 项目 / Item | 占用 / Usage |\n|-------------|-------------|\n| 模型权重 | ~13.4 GB |\n| KV 缓存 (ctx 120K) | ~1.2 GB |\n| 计算缓冲区 | ~0.5 GB |\n| **总计** | **~15.2 GB** |\n| GPU 总 VRAM | 16 GB |\n| **剩余** | **~0.8 GB** |\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **110000（110K）** | GPU 完全覆盖，速度最快 |\n| `--threads` | 8 | 最佳 |\n| `-b / --batch-size` | 2048 | 最佳 |\n| `--parallel` | **1** | ❗ Dense 模型上 parallel=2 反而慢 40% |\n| `--flash-attn` | on | 必须开，长 Prompt 处理快 3-5 倍 |\n| `--cache-type-k/v` | q8_0 | q4_K 有兼容性问题 |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，110K 甜点阈值）\n```bash\n# Linux/WSL2（推荐，绑定到 localhost）\nllama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n\n# 如果需要 CPU 亲和性绑定（+5% 左右）\ntaskset -c 0-7 llama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n> ⚠️ **生产环境建议**：如需对外提供服务，应通过 Nginx/Caddy 等反向代理 + HTTPS，不要直接暴露 llama-server。\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 `taskset` 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n> ⚠️ **安全提示**：此功能仅在 Linux/WSL2 下可用，Windows 下无等效命令。\n\n---\n\n## 核心原则\n\n1. **GPU 内存覆盖优先**：在完全使用专用 GPU 内存的前提下，找到最大上下文值 — 这是提升速度最快的优化\n2. **GPU 内存就是生命线**：够用就快，不够用就慢（GPU↔CPU 交换是最大性能杀手）\n3. **甜点公式**：最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token 开销\n3. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n4. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n5. **量化不一定是损失**：有时候反而更快，一定要实际测试\n6. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n7. **不同模型结论不同**：MoE 和 Dense 模型的最佳参数可能完全相反，不要经验主义\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\n## 安全与调试建议\n\n### 参数调试安全指南\n1. **小步测试**：每次调整幅度不超过 10%，避免 OOM\n2. **监控显存**：使用 `nvidia-smi` 实时观察，确保不突破 GPU 上限\n3. **崩溃自救**：如果模型频繁崩溃，尝试减小 `--ctx-size` 或 `--batch-size`\n4. **云端辅助调试**：当本地模型因参数不当反复崩溃时，建议使用云端模型（OpenAI / Gemini / 通义千问等）进行推理验证和逻辑测试。本地环境只用于性能调优，不用于逻辑正确性验证\n5. **参数记录**：所有测试参数必须记录，避免重复试错\n6. **避免生产配置泄露**：不要在公网文档、代码仓库中暴露 llama-server 的内部参数\n\n### 反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n> 💡 **重要提醒**：不同模型、不同量化版本的最佳参数差异可能很大。**不要直接套用**他人参数，必须实际测试。如果本地模型因参数设置不当频繁崩溃，可先用云端模型做逻辑验证，本地只用于性能调优。\n\nFile v3.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"3.0.0\",\n  \"publishedAt\": 1777206168654\n}\n\nFile v3.0.0:CHANGELOG.md\n\n# CHANGELOG\n\n## v1.2.0 (2026-04-26)\n\n### ✨ 国际化\n- 完整中英文双语版本（Bilingual），全球用户可用\n- Frontmatter description 改为英文，便于搜索引擎索引\n- 所有章节标题、核心概念、步骤说明均提供中英文对照\n- 保留完整的中文详细步骤说明\n\n---\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v3.0.0:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n---\n\n## 五大反常识发现总结\n\n1. **默认 batch size 巨坑**：只有 512，改成 2048 直接快 67.7%！\n2. **KV 量化不是损失**：8bit KV 反而让 Prompt 处理快了 128%！\n3. **Flash Attention 对 MoE 真香**：虽然生成慢 1.3%，但 Prompt 快 128%！\n4. **线程不是越多越好**：8 线程比 12/16 都快！\n5. **ubatch-size 千万别改**：默认的 512 就是最佳的，改了反而慢 60%！\n\nArchive v2.3.0: 4 files, 12277 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (2036b), example-qwen3.5-moe-4060ti.md (4534b), SKILL.md (18936b)\n\nFile v2.3.0:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 2.3.0\ndescription: >\n  Complete methodology for local LLM performance optimization.\n  Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU runs at full speed.\n  Step-by-step 4-phase 10-step control variable testing process.\n  Works for ALL llama.cpp / llama-server models on ANY hardware.\nauthor: fenglai\nkeywords: [llama.cpp, performance optimization, local llm, llama-server, quantization, long context, control variable testing, speed optimization]\ntags: [llm, performance, optimization, local-first, chinese-support]\n---\n\n# llama.cpp 启动参数优化技能 / llama.cpp Parameter Optimization Guide\n\n**中文** | **English**  \n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。  \n_A standardized methodology for optimizing local LLM deployment parameters, using rigorous control variable testing to find the optimal performance/quality balance._\n\n**⚠️ 安全声明 / Safety Notice**\n- 本技能仅用于 **本地部署** 参数优化，所有测试应在隔离环境中进行。\n- **llama-server 和 llama.cpp 二进制文件**应仅从官方 GitHub 仓库 (https://github.com/ggerganov/llama.cpp) 获取，避免使用第三方来源。\n- **网络绑定安全**：本地开发/测试时建议绑定 `127.0.0.1`（localhost），生产环境必须通过反向代理 + HTTPS 暴露服务。\n- 参数调优可能触发 OOM 崩溃，**不确定最优参数时，建议使用云端模型（如 OpenAI/Gemini）进行推理验证**，本地只用于性能调优。\n- **不要在生产环境中使用本技能提供的示例命令直接暴露服务**，需根据实际安全需求调整。\n\n## 🎯 核心卖点 / Key Features\n- ✅ **GPU 内存覆盖原则** / _GPU Memory Coverage Principle_：在完全使用专用 GPU 内存的前提下，找到最大上下文值 | _Find max context while fully covering GPU memory_\n- ✅ **四阶段十步法控制变量测试** / _4-phase 10-step process_：完整的性能/质量评估 | _Comprehensive performance and quality evaluation_\n- ✅ **大量反常识踩坑经验** / _Battle-tested counterintuitive findings_：避免踩同样的坑 | _Avoid common pitfalls_\n- ✅ **通用方法论** / _Universal methodology_：提供系统化测试框架，具体参数需结合实际硬件验证 | _Provides a systematic testing framework; specific parameters must be validated against actual hardware._\n- ✅ **实战验证** / _Real-world proven_：35B+4060Ti 实战案例：从 ~30 token/s → ~90 token/s，提升 2-3 倍 | _35B + 4060Ti real case: ~30 → ~90 token/s, 2-3x improvement_\n\n## 适用场景 / When to Use\n\n**中文** | **English**  \n新模型首次部署，需要找到最佳启动参数  \n_First-time deployment of a new model, finding optimal launch parameters_  \n新硬件环境下的性能调优  \n_Performance tuning on new hardware_  \nllama.cpp / llama-server 启动参数优化  \n_llama.cpp / llama-server launch parameter optimization_  \n验证量化损失、长上下文能力等核心特性  \n_Verify quantization loss, long context capabilities, and other core features_\n\n---\n\n## 完整评估流程 / Complete Methodology\n_**4 phases, 10 steps**_\n\n---\n\n### 📊 第一阶段：基准建立 / Phase 1: Establish Baseline\n\n#### 步骤 1：建立初始基准 / Step 1: Run at default parameters\n**中文** | **English**  \n在默认参数下运行，记录基础性能数据：  \n_Run with default parameters and record baseline performance:_  \n```\n✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数 / Step 2: List all parameters to test\n**中文** | **English**  \n列出所有可能影响性能的参数：  \n_List all parameters that may affect performance:_  \n| 参数 / Parameter | 典型测试值 / Typical values |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试 / Phase 2: Control Variable Testing\n\n#### 步骤 3：逐个参数控制变量测试 / Step 3: Test one parameter at a time\n**中文** | **English**  \n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**  \n_**Core principle: Change only ONE parameter each time, keep ALL others at baseline!**_  \n\n❌ 错误做法 / Wrong way：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因  \n_Chain modification - change threads, then context, then FA - results can't be attributed_  \n✅ 正确做法 / Correct way：每次测试都回到基准配置，只改一个参数  \n_Return to baseline config for each test, change only one parameter_  \n\n#### 步骤 4：建立性能对比矩阵 / Step 4: Build comparison matrix\n\n**⚠️ 重要反常识发现 / Critical Counterintuitive Findings**\n- ❌ `--parallel 2` 不一定好 / Not always good：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益  \n  _On 4060Ti + 35B Dense, parallel=2 slows single request by 40% - scheduling overhead exceeds concurrency benefit_  \n- ✅ `--flash-attn on` 对长 Prompt 影响巨大 / Huge impact on long prompts：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍  \n  _300-500 → 1858 token/s, 3-5x faster, but only ±5% effect on regular generation_  \n- ❌ KV 缓存激进量化不一定好 / Aggressive KV quantization not always good：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，优先用 q8_0  \n  _q4_K can cause extremely slow loading on some llama.cpp versions - prefer q8_0_  \n\n**中文** | **English**  \n每个参数测试完成后，记录完整的对比表：  \n_After each parameter test, record complete comparison table:_  \n\n**示例：线程数对比 / Example: Thread count comparison**\n| 线程数 / Threads | 生成速度 / Gen Speed | Prompt 速度 / Prompt Speed | 变化 / Change | 推荐 / Recommend |\n|------------------|----------------------|-----------------------------|---------------|------------------|\n| 8 | 84.8 | 80.0 | 基准 / Baseline | 🏆 最佳 / Best |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：GPU 内存甜点阈值 / Priority: GPU Memory Sweet Spot\n**MUST DO first - highest ROI optimization!**\n\n**中文** | **English**  \n这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！  \n_This is the highest ROI optimization you can do - typically 50-100% speed boost with ZERO quality loss!_\n\n#### 背景 / Background\n**中文** | **English**  \n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：  \n_Almost every model + GPU combination has a cliff-like performance threshold:_  \n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值  \n  _Below threshold: GPU fully utilized, maximum theoretical speed_  \n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB  \n  _Above threshold: Speed drops by 40-60% (half speed), but VRAM only increases 30-50MB_  \n\n这不是线性下降，是跳崖式下降！原因通常是：  \n_This is NOT a linear degradation, but a cliff! Common causes:_  \n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍  \n   _GDDR memory bank alignment - cross-bank access latency increases 3-5x_  \n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页  \n   _FlashAttention tile size threshold - exceeding triggers cache swapping_  \n3. 大页内存分配失败，TLB 命中率骤降  \n   _Large page memory allocation failure - TLB hit rate plummets_  \n\n#### 标准测试方法 / Standard Testing Method\n**中文** | **English**  \n1. **从厂商标称的最大上下文开始** / _Start from manufacturer's advertised maximum_（比如 128K）  \n2. **每次降 4K** / _Reduce by 4K each time_（必须是 2 的幂次相关步长 / Must be power-of-2 aligned）  \n3. 每次都跑一次完整测速（生成 600 token 左右） / _Run full speed test each time (~600 tokens)_  \n4. 找到 **速度突然跳涨的那个点** / _Find the point where speed suddenly jumps_，就是你的黄金甜点阈值 / _That's your sweet spot!_  \n\n#### 典型测试结果示例 / Typical Test Results\n**Qwen3.6-35B + RTX 4060Ti 16GB**\n\n| 上下文大小 / Context | 生成速度 / Speed | 显存占用 / VRAM | 状态 / Status |\n|---------------------|------------------|-----------------|---------------|\n| 122880 (120K, 默认) | ~30 token/s | ~15.2 GB | ❌ 内存紧张 |\n| 118000 (118K) | ~29-36 token/s | ~15.1 GB | ❌ 内存紧张 |\n| **110000 (110K)** | **~90 token/s** | ~15.0 GB | ✅ 满速 |\n| 96K | ~86 token/s | ~14.5 GB | ✅ 满速 |\n| 64K | ~88 token/s | ~14.0 GB | ✅ 满速 |\n\n#### 核心结论 / Key Takeaways\n**中文** | **English**  \n- 通常甜点阈值 = 厂商标称最大值的 90-95%  \n  _Typically sweet spot = 90-95% of advertised maximum_  \n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%  \n  _Only 5-10% less context (completely unnoticeable) for 50-100% speed boost_  \n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行  \n  _**DO THIS FIRST!** All subsequent parameter testing should be done at the sweet spot_  \n\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例合集\n\n---\n\n### 案例1：Qwen3.5-MoE 35B + RTX 4060Ti 16GB（MoE 模型，仅供参考）\n\n#### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n#### 最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 2 | Prompt 最快，支持 2 并发 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n---\n\n### 案例2：Qwen3.6-35B Dense + RTX 4060Ti 16GB（Dense 模型，2026-04-26 最新测试，仅供参考）\n\n#### 优化成果\n**初始速度：~30 tokens/s → 最终速度：~90 tokens/s，提升 2-3 倍！**\n\n**📋 验证方法：**\n```bash\n# 标准 curl 测速命令（固定 temperature=0.7, max_tokens=100）\ncurl -s http://localhost:8080/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"messages\":[{\"role\":\"user\",\"content\":\"请写一段500字左右的技术博客文章，讨论本地部署大语言模型的性能优化方法\"}],\"max_tokens\":100,\"temperature\":0.7}'\n```\n\n**⚠️ 关键原则：GPU 内存覆盖就是生命线**\n> \"GPU 内存就是生命线，够用就快，不够用就慢。\"\n\n公式：**最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token开销**\n\n以 RTX 4060Ti 16GB + Qwen3.6-35B 为例：\n- 模型权重 ~13.4GB | KV缓存(ctx 110K) ~1.1GB | 计算缓冲 ~0.5GB | **总计 ~15GB**\n- 留出 ~1GB 缓冲，ctx-size=110000 是安全甜点\n\n#### 核心发现：GPU 内存覆盖原则\n| 上下文 | 速度 | 状态 |\n|--------|------|------|\n| 122880 (120K) | ~30 token/s | ❌ GPU 内存不足 |\n| 118000 (118K) | ~29-36 token/s | ❌ GPU 内存不足 |\n| **110000 (110K)** | **~90 token/s** | ✅ GPU 完全覆盖 |\n| 96K / 64K / 32K | ~86-88 token/s | ✅ 满速 |\n\n减少 8% 上下文，速度提升 **2-3 倍**，零质量损失！\n\n**GPU 内存分析 / GPU Memory Analysis:**\n| 项目 / Item | 占用 / Usage |\n|-------------|-------------|\n| 模型权重 | ~13.4 GB |\n| KV 缓存 (ctx 120K) | ~1.2 GB |\n| 计算缓冲区 | ~0.5 GB |\n| **总计** | **~15.2 GB** |\n| GPU 总 VRAM | 16 GB |\n| **剩余** | **~0.8 GB** |\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **110000（110K）** | GPU 完全覆盖，速度最快 |\n| `--threads` | 8 | 最佳 |\n| `-b / --batch-size` | 2048 | 最佳 |\n| `--parallel` | **1** | ❗ Dense 模型上 parallel=2 反而慢 40% |\n| `--flash-attn` | on | 必须开，长 Prompt 处理快 3-5 倍 |\n| `--cache-type-k/v` | q8_0 | q4_K 有兼容性问题 |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，110K 甜点阈值）\n```bash\n# Linux/WSL2（推荐，绑定到 localhost）\nllama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n\n# 如果需要 CPU 亲和性绑定（+5% 左右）\ntaskset -c 0-7 llama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n> ⚠️ **生产环境建议**：如需对外提供服务，应通过 Nginx/Caddy 等反向代理 + HTTPS，不要直接暴露 llama-server。\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 `taskset` 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n> ⚠️ **安全提示**：此功能仅在 Linux/WSL2 下可用，Windows 下无等效命令。\n\n---\n\n## 核心原则\n\n1. **GPU 内存覆盖优先**：在完全使用专用 GPU 内存的前提下，找到最大上下文值 — 这是提升速度最快的优化\n2. **GPU 内存就是生命线**：够用就快，不够用就慢（GPU↔CPU 交换是最大性能杀手）\n3. **甜点公式**：最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token 开销\n3. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n4. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n5. **量化不一定是损失**：有时候反而更快，一定要实际测试\n6. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n7. **不同模型结论不同**：MoE 和 Dense 模型的最佳参数可能完全相反，不要经验主义\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\n## 安全与调试建议\n\n### 参数调试安全指南\n1. **小步测试**：每次调整幅度不超过 10%，避免 OOM\n2. **监控显存**：使用 `nvidia-smi` 实时观察，确保不突破 GPU 上限\n3. **崩溃自救**：如果模型频繁崩溃，尝试减小 `--ctx-size` 或 `--batch-size`\n4. **云端辅助调试**：当本地模型因参数不当反复崩溃时，建议使用云端模型（OpenAI / Gemini / 通义千问等）进行推理验证和逻辑测试。本地环境只用于性能调优，不用于逻辑正确性验证\n5. **参数记录**：所有测试参数必须记录，避免重复试错\n6. **避免生产配置泄露**：不要在公网文档、代码仓库中暴露 llama-server 的内部参数\n\n### 反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n> 💡 **重要提醒**：不同模型、不同量化版本的最佳参数差异可能很大。**不要直接套用**他人参数，必须实际测试。如果本地模型因参数设置不当频繁崩溃，可先用云端模型做逻辑验证，本地只用于性能调优。\n\nFile v2.3.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"2.3.0\",\n  \"publishedAt\": 1777205881227\n}\n\nFile v2.3.0:CHANGELOG.md\n\n# CHANGELOG\n\n## v1.2.0 (2026-04-26)\n\n### ✨ 国际化\n- 完整中英文双语版本（Bilingual），全球用户可用\n- Frontmatter description 改为英文，便于搜索引擎索引\n- 所有章节标题、核心概念、步骤说明均提供中英文对照\n- 保留完整的中文详细步骤说明\n\n---\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v2.3.0:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n---\n\n## 五大反常识发现总结\n\n1. **默认 batch size 巨坑**：只有 512，改成 2048 直接快 67.7%！\n2. **KV 量化不是损失**：8bit KV 反而让 Prompt 处理快了 128%！\n3. **Flash Attention 对 MoE 真香**：虽然生成慢 1.3%，但 Prompt 快 128%！\n4. **线程不是越多越好**：8 线程比 12/16 都快！\n5. **ubatch-size 千万别改**：默认的 512 就是最佳的，改了反而慢 60%！\n\nArchive v2.2.0: 4 files, 12277 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (2036b), example-qwen3.5-moe-4060ti.md (4534b), SKILL.md (18936b)\n\nFile v2.2.0:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 2.1.0\ndescription: >\n  Complete methodology for local LLM performance optimization.\n  Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU runs at full speed.\n  Step-by-step 4-phase 10-step control variable testing process.\n  Works for ALL llama.cpp / llama-server models on ANY hardware.\nauthor: fenglai\nkeywords: [llama.cpp, performance optimization, local llm, llama-server, quantization, long context, control variable testing, speed optimization]\ntags: [llm, performance, optimization, local-first, chinese-support]\n---\n\n# llama.cpp 启动参数优化技能 / llama.cpp Parameter Optimization Guide\n\n**中文** | **English**  \n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。  \n_A standardized methodology for optimizing local LLM deployment parameters, using rigorous control variable testing to find the optimal performance/quality balance._\n\n**⚠️ 安全声明 / Safety Notice**\n- 本技能仅用于 **本地部署** 参数优化，所有测试应在隔离环境中进行。\n- **llama-server 和 llama.cpp 二进制文件**应仅从官方 GitHub 仓库 (https://github.com/ggerganov/llama.cpp) 获取，避免使用第三方来源。\n- **网络绑定安全**：本地开发/测试时建议绑定 `127.0.0.1`（localhost），生产环境必须通过反向代理 + HTTPS 暴露服务。\n- 参数调优可能触发 OOM 崩溃，**不确定最优参数时，建议使用云端模型（如 OpenAI/Gemini）进行推理验证**，本地只用于性能调优。\n- **不要在生产环境中使用本技能提供的示例命令直接暴露服务**，需根据实际安全需求调整。\n\n## 🎯 核心卖点 / Key Features\n- ✅ **GPU 内存覆盖原则** / _GPU Memory Coverage Principle_：在完全使用专用 GPU 内存的前提下，找到最大上下文值 | _Find max context while fully covering GPU memory_\n- ✅ **四阶段十步法控制变量测试** / _4-phase 10-step process_：完整的性能/质量评估 | _Comprehensive performance and quality evaluation_\n- ✅ **大量反常识踩坑经验** / _Battle-tested counterintuitive findings_：避免踩同样的坑 | _Avoid common pitfalls_\n- ✅ **通用方法论** / _Universal methodology_：提供系统化测试框架，具体参数需结合实际硬件验证 | _Provides a systematic testing framework; specific parameters must be validated against actual hardware._\n- ✅ **实战验证** / _Real-world proven_：35B+4060Ti 实战案例：从 ~30 token/s → ~90 token/s，提升 2-3 倍 | _35B + 4060Ti real case: ~30 → ~90 token/s, 2-3x improvement_\n\n## 适用场景 / When to Use\n\n**中文** | **English**  \n新模型首次部署，需要找到最佳启动参数  \n_First-time deployment of a new model, finding optimal launch parameters_  \n新硬件环境下的性能调优  \n_Performance tuning on new hardware_  \nllama.cpp / llama-server 启动参数优化  \n_llama.cpp / llama-server launch parameter optimization_  \n验证量化损失、长上下文能力等核心特性  \n_Verify quantization loss, long context capabilities, and other core features_\n\n---\n\n## 完整评估流程 / Complete Methodology\n_**4 phases, 10 steps**_\n\n---\n\n### 📊 第一阶段：基准建立 / Phase 1: Establish Baseline\n\n#### 步骤 1：建立初始基准 / Step 1: Run at default parameters\n**中文** | **English**  \n在默认参数下运行，记录基础性能数据：  \n_Run with default parameters and record baseline performance:_  \n```\n✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数 / Step 2: List all parameters to test\n**中文** | **English**  \n列出所有可能影响性能的参数：  \n_List all parameters that may affect performance:_  \n| 参数 / Parameter | 典型测试值 / Typical values |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试 / Phase 2: Control Variable Testing\n\n#### 步骤 3：逐个参数控制变量测试 / Step 3: Test one parameter at a time\n**中文** | **English**  \n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**  \n_**Core principle: Change only ONE parameter each time, keep ALL others at baseline!**_  \n\n❌ 错误做法 / Wrong way：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因  \n_Chain modification - change threads, then context, then FA - results can't be attributed_  \n✅ 正确做法 / Correct way：每次测试都回到基准配置，只改一个参数  \n_Return to baseline config for each test, change only one parameter_  \n\n#### 步骤 4：建立性能对比矩阵 / Step 4: Build comparison matrix\n\n**⚠️ 重要反常识发现 / Critical Counterintuitive Findings**\n- ❌ `--parallel 2` 不一定好 / Not always good：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益  \n  _On 4060Ti + 35B Dense, parallel=2 slows single request by 40% - scheduling overhead exceeds concurrency benefit_  \n- ✅ `--flash-attn on` 对长 Prompt 影响巨大 / Huge impact on long prompts：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍  \n  _300-500 → 1858 token/s, 3-5x faster, but only ±5% effect on regular generation_  \n- ❌ KV 缓存激进量化不一定好 / Aggressive KV quantization not always good：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，优先用 q8_0  \n  _q4_K can cause extremely slow loading on some llama.cpp versions - prefer q8_0_  \n\n**中文** | **English**  \n每个参数测试完成后，记录完整的对比表：  \n_After each parameter test, record complete comparison table:_  \n\n**示例：线程数对比 / Example: Thread count comparison**\n| 线程数 / Threads | 生成速度 / Gen Speed | Prompt 速度 / Prompt Speed | 变化 / Change | 推荐 / Recommend |\n|------------------|----------------------|-----------------------------|---------------|------------------|\n| 8 | 84.8 | 80.0 | 基准 / Baseline | 🏆 最佳 / Best |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：GPU 内存甜点阈值 / Priority: GPU Memory Sweet Spot\n**MUST DO first - highest ROI optimization!**\n\n**中文** | **English**  \n这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！  \n_This is the highest ROI optimization you can do - typically 50-100% speed boost with ZERO quality loss!_\n\n#### 背景 / Background\n**中文** | **English**  \n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：  \n_Almost every model + GPU combination has a cliff-like performance threshold:_  \n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值  \n  _Below threshold: GPU fully utilized, maximum theoretical speed_  \n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB  \n  _Above threshold: Speed drops by 40-60% (half speed), but VRAM only increases 30-50MB_  \n\n这不是线性下降，是跳崖式下降！原因通常是：  \n_This is NOT a linear degradation, but a cliff! Common causes:_  \n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍  \n   _GDDR memory bank alignment - cross-bank access latency increases 3-5x_  \n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页  \n   _FlashAttention tile size threshold - exceeding triggers cache swapping_  \n3. 大页内存分配失败，TLB 命中率骤降  \n   _Large page memory allocation failure - TLB hit rate plummets_  \n\n#### 标准测试方法 / Standard Testing Method\n**中文** | **English**  \n1. **从厂商标称的最大上下文开始** / _Start from manufacturer's advertised maximum_（比如 128K）  \n2. **每次降 4K** / _Reduce by 4K each time_（必须是 2 的幂次相关步长 / Must be power-of-2 aligned）  \n3. 每次都跑一次完整测速（生成 600 token 左右） / _Run full speed test each time (~600 tokens)_  \n4. 找到 **速度突然跳涨的那个点** / _Find the point where speed suddenly jumps_，就是你的黄金甜点阈值 / _That's your sweet spot!_  \n\n#### 典型测试结果示例 / Typical Test Results\n**Qwen3.6-35B + RTX 4060Ti 16GB**\n\n| 上下文大小 / Context | 生成速度 / Speed | 显存占用 / VRAM | 状态 / Status |\n|---------------------|------------------|-----------------|---------------|\n| 122880 (120K, 默认) | ~30 token/s | ~15.2 GB | ❌ 内存紧张 |\n| 118000 (118K) | ~29-36 token/s | ~15.1 GB | ❌ 内存紧张 |\n| **110000 (110K)** | **~90 token/s** | ~15.0 GB | ✅ 满速 |\n| 96K | ~86 token/s | ~14.5 GB | ✅ 满速 |\n| 64K | ~88 token/s | ~14.0 GB | ✅ 满速 |\n\n#### 核心结论 / Key Takeaways\n**中文** | **English**  \n- 通常甜点阈值 = 厂商标称最大值的 90-95%  \n  _Typically sweet spot = 90-95% of advertised maximum_  \n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%  \n  _Only 5-10% less context (completely unnoticeable) for 50-100% speed boost_  \n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行  \n  _**DO THIS FIRST!** All subsequent parameter testing should be done at the sweet spot_  \n\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例合集\n\n---\n\n### 案例1：Qwen3.5-MoE 35B + RTX 4060Ti 16GB（MoE 模型，仅供参考）\n\n#### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n#### 最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 2 | Prompt 最快，支持 2 并发 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n---\n\n### 案例2：Qwen3.6-35B Dense + RTX 4060Ti 16GB（Dense 模型，2026-04-26 最新测试，仅供参考）\n\n#### 优化成果\n**初始速度：~30 tokens/s → 最终速度：~90 tokens/s，提升 2-3 倍！**\n\n**📋 验证方法：**\n```bash\n# 标准 curl 测速命令（固定 temperature=0.7, max_tokens=100）\ncurl -s http://localhost:8080/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"messages\":[{\"role\":\"user\",\"content\":\"请写一段500字左右的技术博客文章，讨论本地部署大语言模型的性能优化方法\"}],\"max_tokens\":100,\"temperature\":0.7}'\n```\n\n**⚠️ 关键原则：GPU 内存覆盖就是生命线**\n> \"GPU 内存就是生命线，够用就快，不够用就慢。\"\n\n公式：**最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token开销**\n\n以 RTX 4060Ti 16GB + Qwen3.6-35B 为例：\n- 模型权重 ~13.4GB | KV缓存(ctx 110K) ~1.1GB | 计算缓冲 ~0.5GB | **总计 ~15GB**\n- 留出 ~1GB 缓冲，ctx-size=110000 是安全甜点\n\n#### 核心发现：GPU 内存覆盖原则\n| 上下文 | 速度 | 状态 |\n|--------|------|------|\n| 122880 (120K) | ~30 token/s | ❌ GPU 内存不足 |\n| 118000 (118K) | ~29-36 token/s | ❌ GPU 内存不足 |\n| **110000 (110K)** | **~90 token/s** | ✅ GPU 完全覆盖 |\n| 96K / 64K / 32K | ~86-88 token/s | ✅ 满速 |\n\n减少 8% 上下文，速度提升 **2-3 倍**，零质量损失！\n\n**GPU 内存分析 / GPU Memory Analysis:**\n| 项目 / Item | 占用 / Usage |\n|-------------|-------------|\n| 模型权重 | ~13.4 GB |\n| KV 缓存 (ctx 120K) | ~1.2 GB |\n| 计算缓冲区 | ~0.5 GB |\n| **总计** | **~15.2 GB** |\n| GPU 总 VRAM | 16 GB |\n| **剩余** | **~0.8 GB** |\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **110000（110K）** | GPU 完全覆盖，速度最快 |\n| `--threads` | 8 | 最佳 |\n| `-b / --batch-size` | 2048 | 最佳 |\n| `--parallel` | **1** | ❗ Dense 模型上 parallel=2 反而慢 40% |\n| `--flash-attn` | on | 必须开，长 Prompt 处理快 3-5 倍 |\n| `--cache-type-k/v` | q8_0 | q4_K 有兼容性问题 |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，110K 甜点阈值）\n```bash\n# Linux/WSL2（推荐，绑定到 localhost）\nllama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n\n# 如果需要 CPU 亲和性绑定（+5% 左右）\ntaskset -c 0-7 llama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n> ⚠️ **生产环境建议**：如需对外提供服务，应通过 Nginx/Caddy 等反向代理 + HTTPS，不要直接暴露 llama-server。\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 `taskset` 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n> ⚠️ **安全提示**：此功能仅在 Linux/WSL2 下可用，Windows 下无等效命令。\n\n---\n\n## 核心原则\n\n1. **GPU 内存覆盖优先**：在完全使用专用 GPU 内存的前提下，找到最大上下文值 — 这是提升速度最快的优化\n2. **GPU 内存就是生命线**：够用就快，不够用就慢（GPU↔CPU 交换是最大性能杀手）\n3. **甜点公式**：最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token 开销\n3. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n4. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n5. **量化不一定是损失**：有时候反而更快，一定要实际测试\n6. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n7. **不同模型结论不同**：MoE 和 Dense 模型的最佳参数可能完全相反，不要经验主义\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\n## 安全与调试建议\n\n### 参数调试安全指南\n1. **小步测试**：每次调整幅度不超过 10%，避免 OOM\n2. **监控显存**：使用 `nvidia-smi` 实时观察，确保不突破 GPU 上限\n3. **崩溃自救**：如果模型频繁崩溃，尝试减小 `--ctx-size` 或 `--batch-size`\n4. **云端辅助调试**：当本地模型因参数不当反复崩溃时，建议使用云端模型（OpenAI / Gemini / 通义千问等）进行推理验证和逻辑测试。本地环境只用于性能调优，不用于逻辑正确性验证\n5. **参数记录**：所有测试参数必须记录，避免重复试错\n6. **避免生产配置泄露**：不要在公网文档、代码仓库中暴露 llama-server 的内部参数\n\n### 反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n> 💡 **重要提醒**：不同模型、不同量化版本的最佳参数差异可能很大。**不要直接套用**他人参数，必须实际测试。如果本地模型因参数设置不当频繁崩溃，可先用云端模型做逻辑验证，本地只用于性能调优。\n\nFile v2.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"2.2.0\",\n  \"publishedAt\": 1777205787519\n}\n\nFile v2.2.0:CHANGELOG.md\n\n# CHANGELOG\n\n## v1.2.0 (2026-04-26)\n\n### ✨ 国际化\n- 完整中英文双语版本（Bilingual），全球用户可用\n- Frontmatter description 改为英文，便于搜索引擎索引\n- 所有章节标题、核心概念、步骤说明均提供中英文对照\n- 保留完整的中文详细步骤说明\n\n---\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v2.2.0:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n---\n\n## 五大反常识发现总结\n\n1. **默认 batch size 巨坑**：只有 512，改成 2048 直接快 67.7%！\n2. **KV 量化不是损失**：8bit KV 反而让 Prompt 处理快了 128%！\n3. **Flash Attention 对 MoE 真香**：虽然生成慢 1.3%，但 Prompt 快 128%！\n4. **线程不是越多越好**：8 线程比 12/16 都快！\n5. **ubatch-size 千万别改**：默认的 512 就是最佳的，改了反而慢 60%！\n\nArchive v2.1.0: 4 files, 12152 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (2036b), example-qwen3.5-moe-4060ti.md (4534b), SKILL.md (18687b)\n\nFile v2.1.0:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 2.1.0\ndescription: >\n  Complete methodology for local LLM performance optimization.\n  Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU runs at full speed.\n  Step-by-step 4-phase 10-step control variable testing process.\n  Works for ALL llama.cpp / llama-server models on ANY hardware.\nauthor: fenglai\nkeywords: [llama.cpp, performance optimization, local llm, llama-server, quantization, long context, control variable testing, speed optimization]\ntags: [llm, performance, optimization, local-first, chinese-support]\n---\n\n# llama.cpp 启动参数优化技能 / llama.cpp Parameter Optimization Guide\n\n**中文** | **English**  \n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。  \n_A standardized methodology for optimizing local LLM deployment parameters, using rigorous control variable testing to find the optimal performance/quality balance._\n\n**⚠️ 安全声明 / Safety Notice**\n- 本技能仅用于 **本地部署** 参数优化，不引导任何公网暴露或生产环境配置。\n- 所有测试应在隔离环境中进行，避免影响生产服务。\n- **不建议将 llama-server 绑定到 `0.0.0.0`**，如需外部访问应通过反向代理 + HTTPS。\n- 参数调优可能触发 OOM 崩溃，**不确定最优参数时，建议使用云端模型（如 OpenAI/Gemini）进行推理验证**，本地只用于性能调优。\n\n## 🎯 核心卖点 / Key Features\n- ✅ **GPU 内存覆盖原则** / _GPU Memory Coverage Principle_：在完全使用专用 GPU 内存的前提下，找到最大上下文值 | _Find max context while fully covering GPU memory_\n- ✅ **四阶段十步法控制变量测试** / _4-phase 10-step process_：完整的性能/质量评估 | _Comprehensive performance and quality evaluation_\n- ✅ **大量反常识踩坑经验** / _Battle-tested counterintuitive findings_：避免踩同样的坑 | _Avoid common pitfalls_\n- ✅ **通用方法论** / _Universal methodology_：提供系统化测试框架，具体参数需结合实际硬件验证 | _Provides a systematic testing framework; specific parameters must be validated against actual hardware._\n- ✅ **实战验证** / _Real-world proven_：35B+4060Ti 实战案例：从 ~30 token/s → ~90 token/s，提升 2-3 倍 | _35B + 4060Ti real case: ~30 → ~90 token/s, 2-3x improvement_\n\n## 适用场景 / When to Use\n\n**中文** | **English**  \n新模型首次部署，需要找到最佳启动参数  \n_First-time deployment of a new model, finding optimal launch parameters_  \n新硬件环境下的性能调优  \n_Performance tuning on new hardware_  \nllama.cpp / llama-server 启动参数优化  \n_llama.cpp / llama-server launch parameter optimization_  \n验证量化损失、长上下文能力等核心特性  \n_Verify quantization loss, long context capabilities, and other core features_\n\n---\n\n## 完整评估流程 / Complete Methodology\n_**4 phases, 10 steps**_\n\n---\n\n### 📊 第一阶段：基准建立 / Phase 1: Establish Baseline\n\n#### 步骤 1：建立初始基准 / Step 1: Run at default parameters\n**中文** | **English**  \n在默认参数下运行，记录基础性能数据：  \n_Run with default parameters and record baseline performance:_  \n```\n✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数 / Step 2: List all parameters to test\n**中文** | **English**  \n列出所有可能影响性能的参数：  \n_List all parameters that may affect performance:_  \n| 参数 / Parameter | 典型测试值 / Typical values |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试 / Phase 2: Control Variable Testing\n\n#### 步骤 3：逐个参数控制变量测试 / Step 3: Test one parameter at a time\n**中文** | **English**  \n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**  \n_**Core principle: Change only ONE parameter each time, keep ALL others at baseline!**_  \n\n❌ 错误做法 / Wrong way：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因  \n_Chain modification - change threads, then context, then FA - results can't be attributed_  \n✅ 正确做法 / Correct way：每次测试都回到基准配置，只改一个参数  \n_Return to baseline config for each test, change only one parameter_  \n\n#### 步骤 4：建立性能对比矩阵 / Step 4: Build comparison matrix\n\n**⚠️ 重要反常识发现 / Critical Counterintuitive Findings**\n- ❌ `--parallel 2` 不一定好 / Not always good：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益  \n  _On 4060Ti + 35B Dense, parallel=2 slows single request by 40% - scheduling overhead exceeds concurrency benefit_  \n- ✅ `--flash-attn on` 对长 Prompt 影响巨大 / Huge impact on long prompts：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍  \n  _300-500 → 1858 token/s, 3-5x faster, but only ±5% effect on regular generation_  \n- ❌ KV 缓存激进量化不一定好 / Aggressive KV quantization not always good：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，优先用 q8_0  \n  _q4_K can cause extremely slow loading on some llama.cpp versions - prefer q8_0_  \n\n**中文** | **English**  \n每个参数测试完成后，记录完整的对比表：  \n_After each parameter test, record complete comparison table:_  \n\n**示例：线程数对比 / Example: Thread count comparison**\n| 线程数 / Threads | 生成速度 / Gen Speed | Prompt 速度 / Prompt Speed | 变化 / Change | 推荐 / Recommend |\n|------------------|----------------------|-----------------------------|---------------|------------------|\n| 8 | 84.8 | 80.0 | 基准 / Baseline | 🏆 最佳 / Best |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：GPU 内存甜点阈值 / Priority: GPU Memory Sweet Spot\n**MUST DO first - highest ROI optimization!**\n\n**中文** | **English**  \n这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！  \n_This is the highest ROI optimization you can do - typically 50-100% speed boost with ZERO quality loss!_\n\n#### 背景 / Background\n**中文** | **English**  \n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：  \n_Almost every model + GPU combination has a cliff-like performance threshold:_  \n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值  \n  _Below threshold: GPU fully utilized, maximum theoretical speed_  \n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB  \n  _Above threshold: Speed drops by 40-60% (half speed), but VRAM only increases 30-50MB_  \n\n这不是线性下降，是跳崖式下降！原因通常是：  \n_This is NOT a linear degradation, but a cliff! Common causes:_  \n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍  \n   _GDDR memory bank alignment - cross-bank access latency increases 3-5x_  \n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页  \n   _FlashAttention tile size threshold - exceeding triggers cache swapping_  \n3. 大页内存分配失败，TLB 命中率骤降  \n   _Large page memory allocation failure - TLB hit rate plummets_  \n\n#### 标准测试方法 / Standard Testing Method\n**中文** | **English**  \n1. **从厂商标称的最大上下文开始** / _Start from manufacturer's advertised maximum_（比如 128K）  \n2. **每次降 4K** / _Reduce by 4K each time_（必须是 2 的幂次相关步长 / Must be power-of-2 aligned）  \n3. 每次都跑一次完整测速（生成 600 token 左右） / _Run full speed test each time (~600 tokens)_  \n4. 找到 **速度突然跳涨的那个点** / _Find the point where speed suddenly jumps_，就是你的黄金甜点阈值 / _That's your sweet spot!_  \n\n#### 典型测试结果示例 / Typical Test Results\n**Qwen3.6-35B + RTX 4060Ti 16GB**\n\n| 上下文大小 / Context | 生成速度 / Speed | 显存占用 / VRAM | 状态 / Status |\n|---------------------|------------------|-----------------|---------------|\n| 122880 (120K, 默认) | ~30 token/s | ~15.2 GB | ❌ 内存紧张 |\n| 118000 (118K) | ~29-36 token/s | ~15.1 GB | ❌ 内存紧张 |\n| **110000 (110K)** | **~90 token/s** | ~15.0 GB | ✅ 满速 |\n| 96K | ~86 token/s | ~14.5 GB | ✅ 满速 |\n| 64K | ~88 token/s | ~14.0 GB | ✅ 满速 |\n\n#### 核心结论 / Key Takeaways\n**中文** | **English**  \n- 通常甜点阈值 = 厂商标称最大值的 90-95%  \n  _Typically sweet spot = 90-95% of advertised maximum_  \n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%  \n  _Only 5-10% less context (completely unnoticeable) for 50-100% speed boost_  \n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行  \n  _**DO THIS FIRST!** All subsequent parameter testing should be done at the sweet spot_  \n\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例合集\n\n---\n\n### 案例1：Qwen3.5-MoE 35B + RTX 4060Ti 16GB（MoE 模型，仅供参考）\n\n#### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n#### 最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 2 | Prompt 最快，支持 2 并发 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n---\n\n### 案例2：Qwen3.6-35B Dense + RTX 4060Ti 16GB（Dense 模型，2026-04-26 最新测试，仅供参考）\n\n#### 优化成果\n**初始速度：~30 tokens/s → 最终速度：~90 tokens/s，提升 2-3 倍！**\n\n**📋 验证方法：**\n```bash\n# 标准 curl 测速命令（固定 temperature=0.7, max_tokens=100）\ncurl -s http://localhost:8080/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"messages\":[{\"role\":\"user\",\"content\":\"请写一段500字左右的技术博客文章，讨论本地部署大语言模型的性能优化方法\"}],\"max_tokens\":100,\"temperature\":0.7}'\n```\n\n**⚠️ 关键原则：GPU 内存覆盖就是生命线**\n> \"GPU 内存就是生命线，够用就快，不够用就慢。\"\n\n公式：**最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token开销**\n\n以 RTX 4060Ti 16GB + Qwen3.6-35B 为例：\n- 模型权重 ~13.4GB | KV缓存(ctx 110K) ~1.1GB | 计算缓冲 ~0.5GB | **总计 ~15GB**\n- 留出 ~1GB 缓冲，ctx-size=110000 是安全甜点\n\n#### 核心发现：GPU 内存覆盖原则\n| 上下文 | 速度 | 状态 |\n|--------|------|------|\n| 122880 (120K) | ~30 token/s | ❌ GPU 内存不足 |\n| 118000 (118K) | ~29-36 token/s | ❌ GPU 内存不足 |\n| **110000 (110K)** | **~90 token/s** | ✅ GPU 完全覆盖 |\n| 96K / 64K / 32K | ~86-88 token/s | ✅ 满速 |\n\n减少 8% 上下文，速度提升 **2-3 倍**，零质量损失！\n\n**GPU 内存分析 / GPU Memory Analysis:**\n| 项目 / Item | 占用 / Usage |\n|-------------|-------------|\n| 模型权重 | ~13.4 GB |\n| KV 缓存 (ctx 120K) | ~1.2 GB |\n| 计算缓冲区 | ~0.5 GB |\n| **总计** | **~15.2 GB** |\n| GPU 总 VRAM | 16 GB |\n| **剩余** | **~0.8 GB** |\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **110000（110K）** | GPU 完全覆盖，速度最快 |\n| `--threads` | 8 | 最佳 |\n| `-b / --batch-size` | 2048 | 最佳 |\n| `--parallel` | **1** | ❗ Dense 模型上 parallel=2 反而慢 40% |\n| `--flash-attn` | on | 必须开，长 Prompt 处理快 3-5 倍 |\n| `--cache-type-k/v` | q8_0 | q4_K 有兼容性问题 |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，110K 甜点阈值）\n```bash\n# Linux/WSL2（推荐，绑定到 localhost）\nllama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n\n# 如果需要 CPU 亲和性绑定（+5% 左右）\ntaskset -c 0-7 llama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 110000 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n> ⚠️ **生产环境建议**：如需对外提供服务，应通过 Nginx/Caddy 等反向代理 + HTTPS，不要直接暴露 llama-server。\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 `taskset` 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n> ⚠️ **安全提示**：此功能仅在 Linux/WSL2 下可用，Windows 下无等效命令。\n\n---\n\n## 核心原则\n\n1. **GPU 内存覆盖优先**：在完全使用专用 GPU 内存的前提下，找到最大上下文值 — 这是提升速度最快的优化\n2. **GPU 内存就是生命线**：够用就快，不够用就慢（GPU↔CPU 交换是最大性能杀手）\n3. **甜点公式**：最大上下文 = (GPU VRAM - 模型权重 - 安全缓冲) ÷ KV 缓存每 token 开销\n3. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n4. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n5. **量化不一定是损失**：有时候反而更快，一定要实际测试\n6. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n7. **不同模型结论不同**：MoE 和 Dense 模型的最佳参数可能完全相反，不要经验主义\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\n## 安全与调试建议\n\n### 参数调试安全指南\n1. **小步测试**：每次调整幅度不超过 10%，避免 OOM\n2. **监控显存**：使用 `nvidia-smi` 实时观察，确保不突破 GPU 上限\n3. **崩溃自救**：如果模型频繁崩溃，尝试减小 `--ctx-size` 或 `--batch-size`\n4. **云端辅助调试**：当本地模型因参数不当反复崩溃时，建议使用云端模型（OpenAI / Gemini / 通义千问等）进行推理验证和逻辑测试。本地环境只用于性能调优，不用于逻辑正确性验证\n5. **参数记录**：所有测试参数必须记录，避免重复试错\n6. **避免生产配置泄露**：不要在公网文档、代码仓库中暴露 llama-server 的内部参数\n\n### 反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n> 💡 **重要提醒**：不同模型、不同量化版本的最佳参数差异可能很大。**不要直接套用**他人参数，必须实际测试。如果本地模型因参数设置不当频繁崩溃，可先用云端模型做逻辑验证，本地只用于性能调优。\n\nFile v2.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"2.1.0\",\n  \"publishedAt\": 1777205616940\n}\n\nFile v2.1.0:CHANGELOG.md\n\n# CHANGELOG\n\n## v1.2.0 (2026-04-26)\n\n### ✨ 国际化\n- 完整中英文双语版本（Bilingual），全球用户可用\n- Frontmatter description 改为英文，便于搜索引擎索引\n- 所有章节标题、核心概念、步骤说明均提供中英文对照\n- 保留完整的中文详细步骤说明\n\n---\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v2.1.0:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n---\n\n## 五大反常识发现总结\n\n1. **默认 batch size 巨坑**：只有 512，改成 2048 直接快 67.7%！\n2. **KV 量化不是损失**：8bit KV 反而让 Prompt 处理快了 128%！\n3. **Flash Attention 对 MoE 真香**：虽然生成慢 1.3%，但 Prompt 快 128%！\n4. **线程不是越多越好**：8 线程比 12/16 都快！\n5. **ubatch-size 千万别改**：默认的 512 就是最佳的，改了反而慢 60%！\n\nArchive v2.0.0: 4 files, 10836 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (2036b), example-qwen3.5-moe-4060ti.md (4534b), SKILL.md (15342b)\n\nFile v2.0.0:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 2.0.0\ndescription: >\n  Complete methodology for local LLM performance optimization.\n  Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU runs at full speed.\n  Step-by-step 4-phase 10-step control variable testing process.\n  Works for ALL llama.cpp / llama-server models on ANY hardware.\nauthor: fenglai\nkeywords: [llama.cpp, performance optimization, local llm, llama-server, quantization, long context, control variable testing, speed optimization]\ntags: [llm, performance, optimization, local-first, chinese-support]\n---\n\n# llama.cpp 启动参数优化技能 / llama.cpp Parameter Optimization Guide\n\n**中文** | **English**  \n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。  \n_A standardized methodology for optimizing local LLM deployment parameters, using rigorous control variable testing to find the optimal performance/quality balance._\n\n## 🎯 核心卖点 / Key Features\n- ✅ **GPU 内存覆盖原则** / _GPU Memory Coverage Principle_：在完全使用专用 GPU 内存的前提下，找到最大上下文值 | _Find max context while fully covering GPU memory_\n- ✅ **四阶段十步法控制变量测试** / _4-phase 10-step process_：完整的性能/质量评估 | _Comprehensive performance and quality evaluation_\n- ✅ **大量反常识踩坑经验** / _Battle-tested counterintuitive findings_：避免踩同样的坑 | _Avoid common pitfalls_\n- ✅ **通用方法论** / _Universal methodology_：任何模型、任何硬件都可以直接套用 | _Works for any model, any hardware_\n- ✅ **实战验证** / _Real-world proven_：35B+4060Ti 实战案例：从 ~30 token/s → ~90 token/s，提升 2-3 倍 | _35B + 4060Ti real case: ~30 → ~90 token/s, 2-3x improvement_\n\n## 适用场景 / When to Use\n\n**中文** | **English**  \n新模型首次部署，需要找到最佳启动参数  \n_First-time deployment of a new model, finding optimal launch parameters_  \n新硬件环境下的性能调优  \n_Performance tuning on new hardware_  \nllama.cpp / llama-server 启动参数优化  \n_llama.cpp / llama-server launch parameter optimization_  \n验证量化损失、长上下文能力等核心特性  \n_Verify quantization loss, long context capabilities, and other core features_\n\n---\n\n## 完整评估流程 / Complete Methodology\n_**4 phases, 10 steps**_\n\n---\n\n### 📊 第一阶段：基准建立 / Phase 1: Establish Baseline\n\n#### 步骤 1：建立初始基准 / Step 1: Run at default parameters\n**中文** | **English**  \n在默认参数下运行，记录基础性能数据：  \n_Run with default parameters and record baseline performance:_  \n```\n✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数 / Step 2: List all parameters to test\n**中文** | **English**  \n列出所有可能影响性能的参数：  \n_List all parameters that may affect performance:_  \n| 参数 / Parameter | 典型测试值 / Typical values |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试 / Phase 2: Control Variable Testing\n\n#### 步骤 3：逐个参数控制变量测试 / Step 3: Test one parameter at a time\n**中文** | **English**  \n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**  \n_**Core principle: Change only ONE parameter each time, keep ALL others at baseline!**_  \n\n❌ 错误做法 / Wrong way：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因  \n_Chain modification - change threads, then context, then FA - results can't be attributed_  \n✅ 正确做法 / Correct way：每次测试都回到基准配置，只改一个参数  \n_Return to baseline config for each test, change only one parameter_  \n\n#### 步骤 4：建立性能对比矩阵 / Step 4: Build comparison matrix\n\n**⚠️ 重要反常识发现 / Critical Counterintuitive Findings**\n- ❌ `--parallel 2` 不一定好 / Not always good：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益  \n  _On 4060Ti + 35B Dense, parallel=2 slows single request by 40% - scheduling overhead exceeds concurrency benefit_  \n- ✅ `--flash-attn on` 对长 Prompt 影响巨大 / Huge impact on long prompts：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍  \n  _300-500 → 1858 token/s, 3-5x faster, but only ±5% effect on regular generation_  \n- ❌ KV 缓存激进量化不一定好 / Aggressive KV quantization not always good：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，优先用 q8_0  \n  _q4_K can cause extremely slow loading on some llama.cpp versions - prefer q8_0_  \n\n**中文** | **English**  \n每个参数测试完成后，记录完整的对比表：  \n_After each parameter test, record complete comparison table:_  \n\n**示例：线程数对比 / Example: Thread count comparison**\n| 线程数 / Threads | 生成速度 / Gen Speed | Prompt 速度 / Prompt Speed | 变化 / Change | 推荐 / Recommend |\n|------------------|----------------------|-----------------------------|---------------|------------------|\n| 8 | 84.8 | 80.0 | 基准 / Baseline | 🏆 最佳 / Best |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：GPU 内存甜点阈值 / Priority: GPU Memory Sweet Spot\n**MUST DO first - highest ROI optimization!**\n\n**中文** | **English**  \n这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！  \n_This is the highest ROI optimization you can do - typically 50-100% speed boost with ZERO quality loss!_\n\n#### 背景 / Background\n**中文** | **English**  \n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：  \n_Almost every model + GPU combination has a cliff-like performance threshold:_  \n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值  \n  _Below threshold: GPU fully utilized, maximum theoretical speed_  \n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB  \n  _Above threshold: Speed drops by 40-60% (half speed), but VRAM only increases 30-50MB_  \n\n这不是线性下降，是跳崖式下降！原因通常是：  \n_This is NOT a linear degradation, but a cliff! Common causes:_  \n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍  \n   _GDDR memory bank alignment - cross-bank access latency increases 3-5x_  \n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页  \n   _FlashAttention tile size threshold - exceeding triggers cache swapping_  \n3. 大页内存分配失败，TLB 命中率骤降  \n   _Large page memory allocation failure - TLB hit rate plummets_  \n\n#### 标准测试方法 / Standard Testing Method\n**中文** | **English**  \n1. **从厂商标称的最大上下文开始** / _Start from manufacturer's advertised maximum_（比如 128K）  \n2. **每次降 4K** / _Reduce by 4K each time_（必须是 2 的幂次相关步长 / Must be power-of-2 aligned）  \n3. 每次都跑一次完整测速（生成 600 token 左右） / _Run full speed test each time (~600 tokens)_  \n4. 找到 **速度突然跳涨的那个点** / _Find the point where speed suddenly jumps_，就是你的黄金甜点阈值 / _That's your sweet spot!_  \n\n#### 典型测试结果示例 / Typical Test Results\n**Qwen3.6-35B + RTX 4060Ti 16GB**\n\n| 上下文大小 / Context | 生成速度 / Speed | 显存占用 / VRAM | 状态 / Status |\n|---------------------|------------------|-----------------|---------------|\n| 122880 (120K, 默认) | ~30 token/s | ~15.2 GB | ❌ 内存紧张 |\n| 118000 (118K) | ~29-36 token/s | ~15.1 GB | ❌ 内存紧张 |\n| **110000 (110K)** | **~90 token/s** | ~15.0 GB | ✅ 满速 |\n| 96K | ~86 token/s | ~14.5 GB | ✅ 满速 |\n| 64K | ~88 token/s | ~14.0 GB | ✅ 满速 |\n\n#### 核心结论 / Key Takeaways\n**中文** | **English**  \n- 通常甜点阈值 = 厂商标称最大值的 90-95%  \n  _Typically sweet spot = 90-95% of advertised maximum_  \n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%  \n  _Only 5-10% less context (completely unnoticeable) for 50-100% speed boost_  \n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行  \n  _**DO THIS FIRST!** All subsequent parameter testing should be done at the sweet spot_  \n\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例合集\n\n---\n\n### 案例1：Qwen3.5-MoE 35B + RTX 4060Ti 16GB（MoE 模型）\n\n#### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n#### 最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 2 | Prompt 最快，支持 2 并发 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n---\n\n### 案例2：Qwen3.6-35B Dense + RTX 4060Ti 16GB（Dense 模型，2026-04-26 最新测试）\n\n#### 优化成果\n**初始速度：~30 tokens/s → 最终速度：~90 tokens/s，提升 2-3 倍！**\n\n#### 核心发现：GPU 内存覆盖原则\n| 上下文 | 速度 | 状态 |\n|--------|------|------|\n| 122880 (120K) | ~30 token/s | ❌ GPU 内存不足 |\n| 118000 (118K) | ~29-36 token/s | ❌ GPU 内存不足 |\n| **110000 (110K)** | **~90 token/s** | ✅ GPU 完全覆盖 |\n| 96K / 64K / 32K | ~86-88 token/s | ✅ 满速 |\n\n减少 8% 上下文，速度提升 **2-3 倍**，零质量损失！\n\n**GPU 内存分析 / GPU Memory Analysis:**\n| 项目 / Item | 占用 / Usage |\n|-------------|-------------|\n| 模型权重 | ~13.4 GB |\n| KV 缓存 (ctx 120K) | ~1.2 GB |\n| 计算缓冲区 | ~0.5 GB |\n| **总计** | **~15.2 GB** |\n| GPU 总 VRAM | 16 GB |\n| **剩余** | **~0.8 GB** |\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **110000（110K）** | GPU 完全覆盖，速度最快 |\n| `--threads` | 8 | 最佳 |\n| `-b / --batch-size` | 2048 | 最佳 |\n| `--parallel` | **1** | ❗ Dense 模型上 parallel=2 反而慢 40% |\n| `--flash-attn` | on | 必须开，长 Prompt 处理快 3-5 倍 |\n| `--cache-type-k/v` | q8_0 | q4_K 有兼容性问题 |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，110K 甜点阈值）\n```cmd\n# Windows\nllama-server.exe -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 122880 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n\n# Linux/WSL2（加上CPU亲和性绑定，+5%）\ntaskset -c 0-7 llama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 122880 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 taskset 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n---\n\n## 核心原则\n\n1. **GPU 内存覆盖优先**：在完全使用专用 GPU 内存的前提下，找到最大上下文值 — 这是提升速度最快的优化\n2. **GPU 内存就是生命线**：够用就快，不够用就慢（GPU↔CPU 交换是最大性能杀手）\n3. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n4. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n5. **量化不一定是损失**：有时候反而更快，一定要实际测试\n6. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n7. **不同模型结论不同**：MoE 和 Dense 模型的最佳参数可能完全相反，不要经验主义\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\nFile v2.0.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"2.0.0\",\n  \"publishedAt\": 1777201599334\n}\n\nFile v2.0.0:CHANGELOG.md\n\n# CHANGELOG\n\n## v1.2.0 (2026-04-26)\n\n### ✨ 国际化\n- 完整中英文双语版本（Bilingual），全球用户可用\n- Frontmatter description 改为英文，便于搜索引擎索引\n- 所有章节标题、核心概念、步骤说明均提供中英文对照\n- 保留完整的中文详细步骤说明\n\n---\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v2.0.0:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n---\n\n## 五大反常识发现总结\n\n1. **默认 batch size 巨坑**：只有 512，改成 2048 直接快 67.7%！\n2. **KV 量化不是损失**：8bit KV 反而让 Prompt 处理快了 128%！\n3. **Flash Attention 对 MoE 真香**：虽然生成慢 1.3%，但 Prompt 快 128%！\n4. **线程不是越多越好**：8 线程比 12/16 都快！\n5. **ubatch-size 千万别改**：默认的 512 就是最佳的，改了反而慢 60%！\n\nArchive v1.2.0: 4 files, 10567 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (2036b), example-qwen3.5-moe-4060ti.md (4534b), SKILL.md (14713b)\n\nFile v1.2.0:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 1.2.0\ndescription: >\n  Complete methodology for local LLM performance optimization.\n  Discover the \"context sweet spot\" - 6% less context for 75% faster speed with ZERO quality loss.\n  Step-by-step 4-phase 10-step control variable testing process.\n  Works for ALL llama.cpp / llama-server models on ANY hardware.\nauthor: fenglai\nkeywords: [llama.cpp, performance optimization, local llm, llama-server, quantization, long context, control variable testing, speed optimization]\ntags: [llm, performance, optimization, local-first, chinese-support]\n---\n\n# llama.cpp 启动参数优化技能 / llama.cpp Parameter Optimization Guide\n\n**中文** | **English**  \n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。  \n_A standardized methodology for optimizing local LLM deployment parameters, using rigorous control variable testing to find the optimal performance/quality balance._\n\n## 🎯 核心卖点 / Key Features\n- ✅ **独创「上下文甜点阈值」发现方法** / _Discover the \"context sweet spot\"_：零质量损失，速度提升 50-100% | _Zero quality loss for 50-100% speed boost_\n- ✅ **四阶段十步法控制变量测试** / _4-phase 10-step process_：完整的性能/质量评估 | _Comprehensive performance and quality evaluation_\n- ✅ **大量反常识踩坑经验** / _Battle-tested counterintuitive findings_：避免踩同样的坑 | _Avoid common pitfalls_\n- ✅ **通用方法论** / _Universal methodology_：任何模型、任何硬件都可以直接套用 | _Works for any model, any hardware_\n- ✅ **实战验证** / _Real-world proven_：35B+4060Ti 实战案例：从 49 token/s → 86 token/s，提升 75% | _35B + 4060Ti real case: 49 → 86 token/s, 75% improvement_\n\n## 适用场景 / When to Use\n\n**中文** | **English**  \n新模型首次部署，需要找到最佳启动参数  \n_First-time deployment of a new model, finding optimal launch parameters_  \n新硬件环境下的性能调优  \n_Performance tuning on new hardware_  \nllama.cpp / llama-server 启动参数优化  \n_llama.cpp / llama-server launch parameter optimization_  \n验证量化损失、长上下文能力等核心特性  \n_Verify quantization loss, long context capabilities, and other core features_\n\n---\n\n## 完整评估流程 / Complete Methodology\n_**4 phases, 10 steps**_\n\n---\n\n### 📊 第一阶段：基准建立 / Phase 1: Establish Baseline\n\n#### 步骤 1：建立初始基准 / Step 1: Run at default parameters\n**中文** | **English**  \n在默认参数下运行，记录基础性能数据：  \n_Run with default parameters and record baseline performance:_  \n```\n✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数 / Step 2: List all parameters to test\n**中文** | **English**  \n列出所有可能影响性能的参数：  \n_List all parameters that may affect performance:_  \n| 参数 / Parameter | 典型测试值 / Typical values |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试 / Phase 2: Control Variable Testing\n\n#### 步骤 3：逐个参数控制变量测试 / Step 3: Test one parameter at a time\n**中文** | **English**  \n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**  \n_**Core principle: Change only ONE parameter each time, keep ALL others at baseline!**_  \n\n❌ 错误做法 / Wrong way：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因  \n_Chain modification - change threads, then context, then FA - results can't be attributed_  \n✅ 正确做法 / Correct way：每次测试都回到基准配置，只改一个参数  \n_Return to baseline config for each test, change only one parameter_  \n\n#### 步骤 4：建立性能对比矩阵 / Step 4: Build comparison matrix\n\n**⚠️ 重要反常识发现 / Critical Counterintuitive Findings**\n- ❌ `--parallel 2` 不一定好 / Not always good：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益  \n  _On 4060Ti + 35B Dense, parallel=2 slows single request by 40% - scheduling overhead exceeds concurrency benefit_  \n- ✅ `--flash-attn on` 对长 Prompt 影响巨大 / Huge impact on long prompts：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍  \n  _300-500 → 1858 token/s, 3-5x faster, but only ±5% effect on regular generation_  \n- ❌ KV 缓存激进量化不一定好 / Aggressive KV quantization not always good：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，优先用 q8_0  \n  _q4_K can cause extremely slow loading on some llama.cpp versions - prefer q8_0_  \n\n**中文** | **English**  \n每个参数测试完成后，记录完整的对比表：  \n_After each parameter test, record complete comparison table:_  \n\n**示例：线程数对比 / Example: Thread count comparison**\n| 线程数 / Threads | 生成速度 / Gen Speed | Prompt 速度 / Prompt Speed | 变化 / Change | 推荐 / Recommend |\n|------------------|----------------------|-----------------------------|---------------|------------------|\n| 8 | 84.8 | 80.0 | 基准 / Baseline | 🏆 最佳 / Best |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：上下文甜点阈值 / Priority: Find Context Sweet Spot\n**MUST DO first - highest ROI optimization!**\n\n**中文** | **English**  \n这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！  \n_This is the highest ROI optimization you can do - typically 50-100% speed boost with ZERO quality loss!_\n\n#### 背景 / Background\n**中文** | **English**  \n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：  \n_Almost every model + GPU combination has a cliff-like performance threshold:_  \n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值  \n  _Below threshold: GPU fully utilized, maximum theoretical speed_  \n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB  \n  _Above threshold: Speed drops by 40-60% (half speed), but VRAM only increases 30-50MB_  \n\n这不是线性下降，是跳崖式下降！原因通常是：  \n_This is NOT a linear degradation, but a cliff! Common causes:_  \n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍  \n   _GDDR memory bank alignment - cross-bank access latency increases 3-5x_  \n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页  \n   _FlashAttention tile size threshold - exceeding triggers cache swapping_  \n3. 大页内存分配失败，TLB 命中率骤降  \n   _Large page memory allocation failure - TLB hit rate plummets_  \n\n#### 标准测试方法 / Standard Testing Method\n**中文** | **English**  \n1. **从厂商标称的最大上下文开始** / _Start from manufacturer's advertised maximum_（比如 128K）  \n2. **每次降 4K** / _Reduce by 4K each time_（必须是 2 的幂次相关步长 / Must be power-of-2 aligned）  \n3. 每次都跑一次完整测速（生成 600 token 左右） / _Run full speed test each time (~600 tokens)_  \n4. 找到 **速度突然跳涨的那个点** / _Find the point where speed suddenly jumps_，就是你的黄金甜点阈值 / _That's your sweet spot!_  \n\n#### 典型测试结果示例 / Typical Test Results\n**Qwen3.6-35B + RTX 4060Ti 16GB**\n\n| 上下文大小 / Context | 生成速度 / Speed | 显存占用 / VRAM | 状态 / Status |\n|---------------------|------------------|-----------------|---------------|\n| 128K (厂商标称 / advertised) | 48.9 token/s | 15928MiB | ❌ Half speed |\n| 124K | 50.6 token/s | 15969MiB | ❌ Half speed |\n| **120K (黄金点 / SWEET SPOT)** | **86.4 token/s** | 15931MiB | ✅ Full speed |\n| 96K | 86.1 token/s | 15666MiB | ✅ Full speed |\n\n#### 核心结论 / Key Takeaways\n**中文** | **English**  \n- 通常甜点阈值 = 厂商标称最大值的 90-95%  \n  _Typically sweet spot = 90-95% of advertised maximum_  \n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%  \n  _Only 5-10% less context (completely unnoticeable) for 50-100% speed boost_  \n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行  \n  _**DO THIS FIRST!** All subsequent parameter testing should be done at the sweet spot_  \n\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例合集\n\n---\n\n### 案例1：Qwen3.5-MoE 35B + RTX 4060Ti 16GB（MoE 模型）\n\n#### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n#### 最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 2 | Prompt 最快，支持 2 并发 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n---\n\n### 案例2：Qwen3.6-35B Dense + RTX 4060Ti 16GB（Dense 模型，2026-04-26 最新测试）\n\n#### 优化成果\n**初始速度：48.9 tokens/s → 最终速度：86.4 tokens/s，提升 77%！**\n\n#### 核心发现：断崖式甜点阈值\n| 上下文 | 速度 | 状态 |\n|--------|------|------|\n| 128K（厂商默认） | 48.9 token/s | ❌ 腰斩 |\n| 124K | 50.6 token/s | ❌ 腰斩 |\n| **120K（甜点阈值）** | **86.4 token/s** | ✅ 满速 |\n| 96K / 64K / 32K | 83-86 token/s | ✅ 满速 |\n\n仅减少 6% 上下文，速度提升 **77%**，零质量损失！\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **122880（120K）** | 甜点阈值，再大直接腰斩 |\n| `--threads` | 8 | 最佳 |\n| `-b / --batch-size` | 2048 | 最佳 |\n| `--parallel` | **1** | ❗ Dense 模型上 parallel=2 反而慢 40% |\n| `--flash-attn` | on | 必须开，长 Prompt 处理快 3-5 倍 |\n| `--cache-type-k/v` | q8_0 | q4_K 有兼容性问题 |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，120K甜点阈值）\n```cmd\n# Windows\nllama-server.exe -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 122880 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n\n# Linux/WSL2（加上CPU亲和性绑定，+5%）\ntaskset -c 0-7 llama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 122880 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 taskset 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n---\n\n## 核心原则\n\n1. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n2. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n3. **量化不一定是损失**：有时候反而更快，一定要实际测试\n4. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n5. **不同模型结论不同**：MoE 和 Dense 模型的最佳参数可能完全相反，不要经验主义\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\nFile v1.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"1.2.0\",\n  \"publishedAt\": 1777179688622\n}\n\nFile v1.2.0:CHANGELOG.md\n\n# CHANGELOG\n\n## v1.2.0 (2026-04-26)\n\n### ✨ 国际化\n- 完整中英文双语版本（Bilingual），全球用户可用\n- Frontmatter description 改为英文，便于搜索引擎索引\n- 所有章节标题、核心概念、步骤说明均提供中英文对照\n- 保留完整的中文详细步骤说明\n\n---\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v1.2.0:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n---\n\n## 五大反常识发现总结\n\n1. **默认 batch size 巨坑**：只有 512，改成 2048 直接快 67.7%！\n2. **KV 量化不是损失**：8bit KV 反而让 Prompt 处理快了 128%！\n3. **Flash Attention 对 MoE 真香**：虽然生成慢 1.3%，但 Prompt 快 128%！\n4. **线程不是越多越好**：8 线程比 12/16 都快！\n5. **ubatch-size 千万别改**：默认的 512 就是最佳的，改了反而慢 60%！\n\nArchive v1.1.2: 4 files, 8457 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (1739b), example-qwen3.5-moe-4060ti.md (4534b), SKILL.md (10731b)\n\nFile v1.1.2:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 1.1.2\ndescription: >\n  本地大模型性能调优完整方法论。独创上下文甜点阈值发现，零质量损失，速度直接翻倍。包含四阶段十步法控制变量测试流程，适用于 llama.cpp / llama-server 所有模型所有硬件。\nauthor: fenglai\nkeywords: [llama.cpp, 性能优化, 本地大模型, llama-server, 量化, 长上下文, 控制变量测试]\ntags: [llm, performance, optimization, local-first]\n---\n\n# llama.cpp 启动参数优化技能\n\n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。\n\n## 🎯 核心卖点\n- ✅ 独创「上下文甜点阈值」发现方法，零质量损失，速度提升 50-100%\n- ✅ 四阶段十步法控制变量测试，完整的性能/质量评估\n- ✅ 大量反常识踩坑经验，避免踩同样的坑\n- ✅ 任何模型、任何硬件都可以直接套用\n- ✅ 35B+4060Ti 实战案例：从 49 token/s → 86 token/s，提升 75%\n\n## 适用场景\n\n- 新模型首次部署，需要找到最佳启动参数\n- 新硬件环境下的性能调优\n- llama.cpp / llama-server 启动参数优化\n- 验证量化损失、长上下文能力等核心特性\n\n---\n\n## 完整评估流程（四阶段十步法）\n\n---\n\n### 📊 第一阶段：基准建立\n\n#### 步骤 1：建立初始基准\n在默认参数下运行，记录基础性能数据：\n```\n✅ 记录项：\n- 生成速度 (tokens/s)\n- Prompt 处理速度 (tokens/s)\n- 显存占用峰值 (GB)\n- 首字延迟 (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数\n列出所有可能影响性能的参数：\n| 参数 | 典型测试值 |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试\n\n#### 步骤 3：逐个参数控制变量测试\n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**\n\n❌ 错误做法：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因\n✅ 正确做法：每次测试都回到基准配置，只改一个参数\n\n#### 步骤 4：建立性能对比矩阵\n\n**⚠️  重要反常识发现（2026-04-26 更新）：**\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益，不要盲信经验\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍，但普通生成速度影响只有 ±5%\n- ❌ KV 缓存激进量化不一定好：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，甚至完全卡住，优先用 q8_0\n每个参数测试完成后，记录完整的对比表：\n\n**示例：线程数对比**\n| 线程数 | 生成速度 | Prompt 速度 | 变化 | 推荐 |\n|--------|---------|------------|------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：上下文甜点阈值（必做，性价比最高）\n\n**这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！**\n\n#### 背景\n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：\n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值\n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB\n\n这不是线性下降，是跳崖式下降！原因通常是：\n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍\n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页\n3. 大页内存分配失败，TLB 命中率骤降\n\n#### 标准测试方法\n1. **从厂商标称的最大上下文开始**（比如 128K）\n2. **每次降 4K**（必须是 2 的幂次相关步长，不要用 3K/5K 这种）\n3. 每次都跑一次完整测速（生成 600 token 左右）\n4. 找到 **速度突然跳涨的那个点**，就是你的黄金甜点阈值\n\n#### 典型测试结果示例（Qwen3.6-35B + 4060Ti 16GB）\n| 上下文大小 | 生成速度 | 显存占用 | 状态 |\n|------------|----------|----------|------|\n| 128K (厂商标称) | 48.9 token/s | 15928MiB | ❌ 腰斩 |\n| 124K | 50.6 token/s | 15969MiB | ❌ 腰斩 |\n| **120K (黄金点)** | **86.4 token/s** | 15931MiB | ✅ 满速 |\n| 96K | 86.1 token/s | 15666MiB | ✅ 满速 |\n\n#### 核心结论\n- 通常甜点阈值 = 厂商标称最大值的 90-95%\n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%\n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例合集\n\n---\n\n### 案例1：Qwen3.5-MoE 35B + RTX 4060Ti 16GB（MoE 模型）\n\n#### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n#### 最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 2 | Prompt 最快，支持 2 并发 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n---\n\n### 案例2：Qwen3.6-35B Dense + RTX 4060Ti 16GB（Dense 模型，2026-04-26 最新测试）\n\n#### 优化成果\n**初始速度：48.9 tokens/s → 最终速度：86.4 tokens/s，提升 77%！**\n\n#### 核心发现：断崖式甜点阈值\n| 上下文 | 速度 | 状态 |\n|--------|------|------|\n| 128K（厂商默认） | 48.9 token/s | ❌ 腰斩 |\n| 124K | 50.6 token/s | ❌ 腰斩 |\n| **120K（甜点阈值）** | **86.4 token/s** | ✅ 满速 |\n| 96K / 64K / 32K | 83-86 token/s | ✅ 满速 |\n\n仅减少 6% 上下文，速度提升 **77%**，零质量损失！\n\n#### 最佳参数\n| 参数 | 最佳值 | 说明 |\n|------|--------|------|\n| `--ctx-size` | **122880（120K）** | 甜点阈值，再大直接腰斩 |\n| `--threads` | 8 | 最佳 |\n| `-b / --batch-size` | 2048 | 最佳 |\n| `--parallel` | **1** | ❗ Dense 模型上 parallel=2 反而慢 40% |\n| `--flash-attn` | on | 必须开，长 Prompt 处理快 3-5 倍 |\n| `--cache-type-k/v` | q8_0 | q4_K 有兼容性问题 |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，120K甜点阈值）\n```cmd\n# Windows\nllama-server.exe -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 122880 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n\n# Linux/WSL2（加上CPU亲和性绑定，+5%）\ntaskset -c 0-7 llama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 122880 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 taskset 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n---\n\n## 核心原则\n\n1. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n2. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n3. **量化不一定是损失**：有时候反而更快，一定要实际测试\n4. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n5. **不同模型结论不同**：MoE 和 Dense 模型的最佳参数可能完全相反，不要经验主义\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\nFile v1.1.2:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"1.1.2\",\n  \"publishedAt\": 1777179272970\n}\n\nFile v1.1.2:CHANGELOG.md\n\n# CHANGELOG\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v1.1.2:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n---\n\n## 五大反常识发现总结\n\n1. **默认 batch size 巨坑**：只有 512，改成 2048 直接快 67.7%！\n2. **KV 量化不是损失**：8bit KV 反而让 Prompt 处理快了 128%！\n3. **Flash Attention 对 MoE 真香**：虽然生成慢 1.3%，但 Prompt 快 128%！\n4. **线程不是越多越好**：8 线程比 12/16 都快！\n5. **ubatch-size 千万别改**：默认的 512 就是最佳的，改了反而慢 60%！\n\nArchive v1.1.1: 4 files, 8111 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (1444b), example-qwen3.5-moe-4060ti.md (4534b), SKILL.md (9802b)\n\nFile v1.1.1:SKILL.md\n\n---\nname: llama-params-optimizer\nversion: 1.1.1\ndescription: >\n  本地大模型性能调优完整方法论。独创上下文甜点阈值发现，零质量损失，速度直接翻倍。包含四阶段十步法控制变量测试流程，适用于 llama.cpp / llama-server 所有模型所有硬件。\nauthor: fenglai\nkeywords: [llama.cpp, 性能优化, 本地大模型, llama-server, 量化, 长上下文, 控制变量测试]\ntags: [llm, performance, optimization, local-first]\n---\n\n# llama.cpp 启动参数优化技能\n\n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。\n\n## 🎯 核心卖点\n- ✅ 独创「上下文甜点阈值」发现方法，零质量损失，速度提升 50-100%\n- ✅ 四阶段十步法控制变量测试，完整的性能/质量评估\n- ✅ 大量反常识踩坑经验，避免踩同样的坑\n- ✅ 任何模型、任何硬件都可以直接套用\n- ✅ 35B+4060Ti 实战案例：从 49 token/s → 86 token/s，提升 75%\n\n## 适用场景\n\n- 新模型首次部署，需要找到最佳启动参数\n- 新硬件环境下的性能调优\n- llama.cpp / llama-server 启动参数优化\n- 验证量化损失、长上下文能力等核心特性\n\n---\n\n## 完整评估流程（四阶段十步法）\n\n---\n\n### 📊 第一阶段：基准建立\n\n#### 步骤 1：建立初始基准\n在默认参数下运行，记录基础性能数据：\n```\n✅ 记录项：\n- 生成速度 (tokens/s)\n- Prompt 处理速度 (tokens/s)\n- 显存占用峰值 (GB)\n- 首字延迟 (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数\n列出所有可能影响性能的参数：\n| 参数 | 典型测试值 |\n|------|-----------|\n| `--threads` | 4 / 8 / 12 / 16 / CPU 核心数 |\n| `-b / --batch-size` | 512 / 1024 / 2048 / 4096 |\n| `--ctx-size` | **重要！优先测试！先找甜点阈值，再测其他参数** |\n| `--flash-attn` | on / off |\n| `--cache-type-k/v` | 不量化 / q8_0 / q4_0 |\n| `--parallel` | 1 / 2 / 4 |\n| `--ubatch-size` | 256 / 512 / 1024 |\n\n---\n\n### ⚡ 第二阶段：控制变量性能测试\n\n#### 步骤 3：逐个参数控制变量测试\n**核心原则：每次只改一个参数，其他所有参数保持基准不变！**\n\n❌ 错误做法：链式修改，改完线程改上下文，再改 FA，结果混在一起无法归因\n✅ 正确做法：每次测试都回到基准配置，只改一个参数\n\n#### 步骤 4：建立性能对比矩阵\n\n**⚠️  重要反常识发现（2026-04-26 更新）：**\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%，调度开销超过了并发收益，不要盲信经验\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：开启前 300-500 token/s，开启后 1858 token/s，快了 3-5 倍，但普通生成速度影响只有 ±5%\n- ❌ KV 缓存激进量化不一定好：q4_K 在某些版本的 llama.cpp 上会导致模型加载速度极慢，甚至完全卡住，优先用 q8_0\n每个参数测试完成后，记录完整的对比表：\n\n**示例：线程数对比**\n| 线程数 | 生成速度 | Prompt 速度 | 变化 | 推荐 |\n|--------|---------|------------|------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n---\n\n### 🎯 优先测试：上下文甜点阈值（必做，性价比最高）\n\n**这是所有优化里性价比最高的一项，通常能白嫖 50-100% 的速度提升，零质量损失！**\n\n#### 背景\n几乎所有模型+显卡的组合，都存在一个断崖式的性能阈值：\n- ✅ 阈值以下：GPU 跑满，速度达到理论最大值\n- ❌ 阈值以上：速度直接腰斩（40-60%），但显存只多占了 30-50MB\n\n这不是线性下降，是跳崖式下降！原因通常是：\n1. GDDR 显存 Bank 对齐边界，跨 Bank 访问延迟翻 3-5 倍\n2. FlashAttention 的 Tile 块大小阈值，超过之后触发缓存换页\n3. 大页内存分配失败，TLB 命中率骤降\n\n#### 标准测试方法\n1. **从厂商标称的最大上下文开始**（比如 128K）\n2. **每次降 4K**（必须是 2 的幂次相关步长，不要用 3K/5K 这种）\n3. 每次都跑一次完整测速（生成 600 token 左右）\n4. 找到 **速度突然跳涨的那个点**，就是你的黄金甜点阈值\n\n#### 典型测试结果示例（Qwen3.6-35B + 4060Ti 16GB）\n| 上下文大小 | 生成速度 | 显存占用 | 状态 |\n|------------|----------|----------|------|\n| 128K (厂商标称) | 48.9 token/s | 15928MiB | ❌ 腰斩 |\n| 124K | 50.6 token/s | 15969MiB | ❌ 腰斩 |\n| **120K (黄金点)** | **86.4 token/s** | 15931MiB | ✅ 满速 |\n| 96K | 86.1 token/s | 15666MiB | ✅ 满速 |\n\n#### 核心结论\n- 通常甜点阈值 = 厂商标称最大值的 90-95%\n- 上下文只少 5-10%（完全感知不到），速度提升 50-100%\n- **这一步必须第一个做！** 所有后续参数测试都应该在甜点阈值下进行\n\n---\n\n### ✅ 第三阶段：质量验证\n\n#### 步骤 5：量化损失验证\n对比开/关量化的输出质量，使用相同的 Prompt + 温度=0.1 最小化随机性：\n```\n测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失\n```\n\n#### 步骤 6：上下文回忆能力测试\n使用「密钥召回法」验证长上下文能力：\n```\n测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率\n```\n\n**典型测试距离：**\n- 短距离：~1000 token\n- 中距离：~20000 token\n- 长距离：~50000 token（根据最大上下文调整）\n\n#### 步骤 7：基本能力冒烟测试\n验证模型的基础能力没有因为参数调整而下降：\n```\n测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和\n```\n\n---\n\n### 🎯 第四阶段：综合评估与产出\n\n#### 步骤 8：多维度综合评分\n| 维度 | 权重 | 评分标准（10分制） |\n|------|------|-------------------|\n| **性能** | 50% | 生成速度(30%) + Prompt速度(20%) |\n| **质量** | 40% | 量化损失(15%) + 上下文回忆(15%) + 基本能力(10%) |\n| **稳定性** | 10% | 启动成功率、运行稳定性、API兼容性 |\n\n#### 步骤 9：反常识发现总结\n**必须记录所有反直觉的结论！** 这些是最有价值的经验：\n\n**示例（来自 Qwen3.5-MoE 实战）：**\n1. ❗ 默认 batch size 是 512，改成 2048 直接快 67.7%！\n2. ❗ KV q8_0 量化不是损失，反而让 Prompt 处理快了 128%！\n3. ❗ Flash Attention 对 MoE 模型：生成慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n4. ❗ 线程不是越多越好：8 线程比 12/16 都快！\n5. ❗ 链式测试会严重误导结论：必须严格控制变量！\n\n#### 步骤 10：产出最终最佳配置\n最终输出：\n1. ✅ 最佳性能配置（最快速度）\n2. ✅ 最佳上下文配置（最大窗口）\n3. ✅ 综合推荐配置（平衡最佳）\n4. ✅ 一键启动的完整命令\n\n---\n\n## 实战案例：Qwen3.5-MoE + RTX 4060Ti 16GB\n\n### 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n### 最终最佳参数\n| 参数 | 最佳值 | 收益 |\n|------|--------|------|\n| `--threads` | 8 | +2.4% |\n| `-b / --batch-size` | 2048 | +67.7% 最大提升！ |\n| `--ctx-size` | 65536（最快）或 262144（最大） | 64K 比 256K 快 3.7 倍 |\n| `--flash-attn` | on | Prompt +128%，生成 -1.3% |\n| `--cache-type-k/v` | q8_0 | Prompt +128%，省 512MB，零质量损失 |\n| `--parallel` | 1（推荐） / 2 | ❗ 注意：在 4060Ti + 35B Dense 上，parallel=2 反而慢 40%；MoE 模型上可以提升，建议自己测试 |\n| `--ubatch-size` | 默认 512 | 改了反而慢 17-60% |\n\n### 最终最佳启动命令（Qwen3.6-35B Dense + 4060Ti，120K甜点阈值）\n```cmd\n# Windows\nllama-server.exe -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 122880 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n\n# Linux/WSL2（加上CPU亲和性绑定，+5%）\ntaskset -c 0-7 llama-server -m \"你的模型路径.gguf\" --n-gpu-layers 9999 --ctx-size 122880 --port 8080 --host 0.0.0.0 --threads 8 --mlock --parallel 1 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 进阶：CPU 亲和性绑定（+1-5% 速度，聊胜于无）\nLinux/WSL2 下可以用 taskset 把线程绑到同一物理核心簇上，减少跨核通讯开销：\n```bash\ntaskset -c 0-7 llama-server ...\n```\n注意：核心范围要和你的 `--threads` 参数对应，不要跨 CCX 模块。\n\n---\n\n## 核心原则\n\n1. **控制变量高于一切**：每次只改一个参数，其他全部保持不变\n2. **不要只看生成速度**：Prompt 处理速度同样重要，甚至更重要\n3. **量化不一定是损失**：有时候反而更快，一定要实际测试\n4. **默认参数通常很保守**：一定要测试更大的 batch size、不同的线程数\n5. **不同模型结论不同**：MoE 和 Dense 模型的最佳参数可能完全相反，不要经验主义\n\n---\n\n## 快速检查清单\n\n每次优化前过一遍：\n- [ ] 已记录默认参数下的基准速度\n- [ ] 已列出所有待测试的参数\n- [ ] 每次测试只改一个参数\n- [ ] 已验证量化损失（如果开了量化）\n- [ ] 已测试长上下文回忆能力\n- [ ] 已做基本能力冒烟测试\n- [ ] 已记录所有反常识的发现\n- [ ] 已产出最终的一键启动命令\n\nFile v1.1.1:_meta.json\n\n{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"1.1.1\",\n  \"publishedAt\": 1777179155034\n}\n\nFile v1.1.1:CHANGELOG.md\n\n# CHANGELOG\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法\n\nFile v1.1.1:example-qwen3.5-moe-4060ti.md\n\n# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.\n\nArchive v1.1.0: 4 files, 7886 bytes\n\nFiles: _meta.json (141b), CHANGELOG.md (1139b), example-qwen3.5-moe-4060ti.md (4534b), SKILL.md (9365b)","readmeExcerpt":"Skill: llama-params-optimizer Owner: hoperealize Summary: Complete methodology for local LLM performance optimization. Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU... Tags: latest:3.1.0, llama.cpp:2.0.0, local-llm:2.0.0, optimization:2.0.0, performance:2.0.0 Version history: v3.1.0 | 2026-04-28T11:07:43.048Z | user 新增 Qwen3.6-27B 实战案例；修正甜点公式为起点参考；batch-size 因模型而异；推理","codeSnippets":[],"executableExamples":[{"language":"text","snippet":"✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)"},{"language":"text","snippet":"测试方法：\n1. 关 KV 量化（FP16），输出结果 A\n2. 开 KV q8_0 量化，相同 Prompt，输出结果 B\n3. 人工对比 A 和 B，判断是否有可感知的质量损失"},{"language":"text","snippet":"测试方法：\n1. 构造长 Prompt：前面是大量无关填充文本\n2. 在 Prompt 的 10% / 50% / 90% 位置分别藏一个随机密钥\n3. 问模型：「文档中的秘密密钥是什么？」\n4. 记录不同距离的召回成功率"},{"language":"text","snippet":"测试用例：\n1. 简单数学题：小明有5个苹果，给了小红2个，又买了3个，现在有几个？\n2. 简单逻辑题：正方形边长4cm，面积是多少？\n3. 简单代码题：用Python写一个函数求列表偶数的和"},{"language":"bash","snippet":"curl -s http://localhost:8080/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"messages\":[{\"role\":\"user\",\"content\":\"请写一段500字左右的技术博客文章，讨论本地部署大语言模型的性能优化方法\"}],\"max_tokens\":100,\"temperature\":0.7}'"},{"language":"bash","snippet":"# 标准 curl 测速命令（固定 temperature=0.7, max_tokens=100）\ncurl -s http://localhost:8080/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\"messages\":[{\"role\":\"user\",\"content\":\"请写一段500字左右的技术博客文章，讨论本地部署大语言模型的性能优化方法\"}],\"max_tokens\":100,\"temperature\":0.7}'"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: llama-params-optimizer\nversion: 3.1.0\ndescription: >\n  Complete methodology for local LLM performance optimization.\n  Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU runs at full speed.\n  Step-by-step 4-phase 10-step control variable testing process.\n  Works for ALL llama.cpp / llama-server models on ANY hardware.\n  Cases: Qwen3.5-MoE, Qwen3.6-35B, Qwen3.6-27B (2026-04-28).\nauthor: fenglai\nkeywords: [llama.cpp, performance optimization, local llm, llama-server, quantization, long context, control variable testing, speed optimization, reasoning models, OpenClaw config]\ntags: [llm, performance, optimization, local-first, chinese-support]\n---\n\n# llama.cpp 启动参数优化技能 / llama.cpp Parameter Optimization Guide\n\n**中文** | **English**  \n标准化的 LLM 本地部署启动参数优化评估流程，通过严格的控制变量测试，找到最佳的性能/质量平衡点。  \n_A standardized methodology for optimizing local LLM deployment parameters, using rigorous control variable testing to find the optimal performance/quality balance._\n\n**⚠️ 安全声明 / Safety Notice**\n- 本技能仅用于 **本地部署** 参数优化，所有测试应在隔离环境中进行。\n- **llama-server 和 llama.cpp 二进制文件**应仅从官方 GitHub 仓库 (https://github.com/ggerganov/llama.cpp) 获取，避免使用第三方来源。\n- **网络绑定安全**：本地开发/测试时建议绑定 `127.0.0.1`（localhost），生产环境必须通过反向代理 + HTTPS 暴露服务。\n- 参数调优可能触发 OOM 崩溃，**不确定最优参数时，建议使用云端模型（如 OpenAI/Gemini）进行推理验证**，本地只用于性能调优。\n- **不要在生产环境中使用本技能提供的示例命令直接暴露服务**，需根据实际安全需求调整。\n\n## 🎯 核心卖点 / Key Features\n- ✅ **GPU 内存覆盖原则** / _GPU Memory Coverage Principle_：在完全使用专用 GPU 内存的前提下，找到最大上下文值 | _Find max context while fully covering GPU memory_\n- ✅ **四阶段十步法控制变量测试** / _4-phase 10-step process_：完整的性能/质量评估 | _Comprehensive performance and quality evaluation_\n- ✅ **大量反常识踩坑经验** / _Battle-tested counterintuitive findings_：避免踩同样的坑 | _Avoid common pitfalls_\n- ✅ **通用方法论** / _Universal methodology_：提供系统化测试框架，具体参数需结合实际硬件验证 | _Provides a systematic testing framework; specific parameters must be validated against actual hardware._\n- ✅ **实战验证** / _Real-world proven_：35B+4060Ti 案例：~30 → ~90 token/s，提升 2-3 倍；27B 案例：~23.6 tok/s，验证理论公式不可靠 | _Multiple cases: MoE 262% boost, Dense 2-3x, 27B theoretical formula fails_\n\n## 适用场景 / When to Use\n\n**中文** | **English**  \n新模型首次部署，需要找到最佳启动参数  \n_First-time deployment of a new model, finding optimal launch parameters_  \n新硬件环境下的性能调优  \n_Performance tuning on new hardware_  \nllama.cpp / llama-server 启动参数优化  \n_llama.cpp / llama-server launch parameter optimization_  \n验证量化损失、长上下文能力等核心特性  \n_Verify quantization loss, long context capabilities, and other core features_\n\n---\n\n## 完整评估流程 / Complete Methodology\n_**4 phases, 10 steps**_\n\n---\n\n### 📊 第一阶段：基准建立 / Phase 1: Establish Baseline\n\n#### 步骤 1：建立初始基准 / Step 1: Run at default parameters\n**中文** | **English**  \n在默认参数下运行，记录基础性能数据：  \n_Run with default parameters and record baseline performance:_  \n```\n✅ 记录项 / Metrics to record：\n- 生成速度 / Generation speed (tokens/s)\n- Prompt 处理速度 / Prompt processing speed (tokens/s)\n- 显存占用峰值 / Peak VRAM usage (GB)\n- 首字延迟 / Time to first token (ms)\n```\n\n#### 步骤 2：枚举所有待测试参数 / Step 2: Li"},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7ers0mgs9t4jm7cy6s7fpktd82kzr0\",\n  \"slug\": \"llama-params-optimizer\",\n  \"version\": \"3.1.0\",\n  \"publishedAt\": 1777374463048\n}"},{"path":"CHANGELOG.md","content":"# CHANGELOG\n\n## v3.1.0 (2026-04-28)\n\n### ✨ 新增\n- 新增 Qwen3.6-27B Dense + RTX 4060Ti 16GB 实战案例\n- 新增推理模型（reasoning models）思考开销说明：Qwen3.6 内置推理链，TTFT 40-50 秒\n- 新增 OpenClaw 配置对齐指南：contextWindow/maxTokens 必须与 --ctx-size 匹配\n\n### 🐛 修正\n- 甜点公式从\"唯一真理\"降级为\"起点参考\"，强调理论计算不可靠，实测才是王道（27B 上公式算 110K OOM，实际甜点 96K）\n- batch-size 最优值因模型大小而异：35B Dense 上 2048 最优，27B Dense 上 512 反而快 6.6%\n- 核心原则从 7 条扩展至 10 条\n\n---\n\n## v1.2.0 (2026-04-26)\n\n### ✨ 国际化\n- 完整中英文双语版本（Bilingual），全球用户可用\n- Frontmatter description 改为英文，便于搜索引擎索引\n- 所有章节标题、核心概念、步骤说明均提供中英文对照\n- 保留完整的中文详细步骤说明\n\n---\n\n## v1.1.2 (2026-04-26)\n\n### 🐛 修正\n- 将实战案例拆分为两个：MoE 模型（262%提升）和 Dense 模型（77%提升），避免参数混淆\n- 每个案例单独列出最佳参数，明确区分不同模型类型的差异\n- 补充 120K 甜点阈值的完整对比数据表格\n\n---\n\n## v1.1.1 (2026-04-26)\n\n### 🐛 修正\n- 更新实战案例的最终启动命令，从 64K 修正为实测最优的 120K 甜点阈值\n- 修正 `--parallel` 参数的推荐说明：Dense 35B 模型上 parallel=2 反而慢 40%，建议保持 1\n- 补充 Linux/WSL2 的 CPU 亲和性绑定启动命令\n\n---\n\n## v1.1.0 (2026-04-26)\n\n### ✨ 重大更新\n- 新增「上下文甜点阈值」优先测试章节，这是目前性价比最高的优化方法\n  - 详细解释了断崖式性能下降的原理（显存Bank对齐、FlashAttention块大小、大页内存）\n  - 标准化的4步测试方法，任何模型/硬件都可以复用\n  - 附带 Qwen3.6-35B + RTX 4060Ti 的完整测试案例\n  - 上下文仅少6%，速度提升75%，零质量损失\n\n### 📝 更新反常识发现列表\n- ❌ `--parallel 2` 不一定好：在 4060Ti + 35B 组合上，单请求速度反而下降 40%\n- ✅ `--flash-attn on` 对长 Prompt 影响巨大：3-5 倍提升\n- ❌ q4_K KV 缓存可能有兼容性问题：加载速度极慢，优先用 q8_0\n\n### 🆕 新增内容\n- CPU 亲和性绑定章节：+1-5% 免费提升，Linux/WSL2 适用\n\n---\n\n## v1.0.0 (2026-04-26)\n\n### ✨ 初始版本\n- 完整的四阶段十步法控制变量测试流程\n- Qwen3.5-MoE 35B 实战案例，性能提升 262%\n- 所有关键参数的最佳实践和测试方法\n- 长上下文召回验证、量化损失验证等质量测试方法\n- 多维度综合评分方法"},{"path":"example-qwen3.5-moe-4060ti.md","content":"# 实战案例：Qwen3.5-MoE 35B + RTX 4060Ti 16GB\n\n## 测试环境\n- 模型：Qwen3.6-35B-A3B-APEX-I-Mini.gguf（Q3_K_M，13.3GB）\n- 显卡：NVIDIA RTX 4060Ti 16GB\n- CPU：i5-14600KF\n- 软件：llama.cpp b8925\n\n---\n\n## 优化成果\n**初始速度：23.4 tokens/s → 最终速度：84.8 tokens/s，提升 262%！**\n\n---\n\n## 完整测试数据\n\n### 1. 线程数测试\n| 线程数 | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|--------|---------|------------|------------|------|\n| 8 | 84.8 | 80.0 | 基准 | 🏆 最佳 |\n| 12 | 83.1 | 70.2 | -2.0% | |\n| 16 | 83.5 | 75.0 | -1.5% | |\n\n**结论：线程不是越多越好，8 线程最佳。**\n\n---\n\n### 2. Batch Size 测试\n| batch size | 生成速度 | Prompt 速度 | 生成速度变化 | 推荐 |\n|------------|---------|------------|------------|------|\n| 512（默认） | 51.2 | 35.0 | 基准 | ❌ 太慢！ |\n| 1024 | 54.3 | 35.5 | +6.1% | |\n| 2048 | 84.8 | 80.0 | +67.7% | 🏆 最佳 |\n| 4096 | 85.3 | 85.0 | +67.9% | |\n\n**重大发现：默认 batch size 只有 512，改成 2048 直接快 67.7%！这是本次最大的性能提升点！**\n\n---\n\n### 3. Flash Attention + KV 量化测试\n| 配置 | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------|---------|------------|---------|------------|------|\n| FA off + 不量化 | 85.9 | 35.0 | 基准 | 基准 | |\n| FA on + KV q8_0 | 84.8 | 80.0 | -1.3% | +128.6% | 🏆 最佳 |\n| FA on + KV q4_0 | 84.8 | 59.4 | -0.0% | +69.7% | |\n\n**反常识发现：**\n1. KV 量化不是损失！8bit KV 反而让 Prompt 处理快了 128%！\n2. Flash Attention 对 MoE 模型：生成只慢 1.3%，但 Prompt 快 128%，整体收益巨大！\n3. q8_0 是最佳平衡点，q4_0 的 Prompt 速度下降明显。\n\n---\n\n### 4. 上下文窗口测试\n| ctx-size | 生成速度 | Prompt 速度 | 生成变化 | 推荐 |\n|----------|---------|------------|---------|------|\n| 65536（64K） | 84.8 | 80.0 | 基准 | 🏆 速度优先 |\n| 131072（128K） | 24.0 | 45.4 | -71.7% | |\n| 262144（256K） | 22.9 | 32.7 | -73.0% | 📚 上下文优先 |\n\n**结论：上下文翻倍，速度几乎减半。根据使用场景选择。**\n\n---\n\n### 5. 并行会话数测试\n| --parallel | 生成速度 | Prompt 速度 | 生成变化 | Prompt 变化 | 推荐 |\n|------------|---------|------------|---------|------------|------|\n| 1 | 86.6 | 64.4 | +2.1% | -19.5% | |\n| 2（默认） | 84.8 | 80.0 | 基准 | 基准 | 🏆 最佳 |\n| 4 | 84.8 | 46.5 | +0.0% | -41.9% | ❌ |\n\n**结论：--parallel 2 是最佳平衡点，Prompt 速度最快，还支持 2 并发。**\n\n---\n\n### 6. 微批量大小测试\n| ubatch-size | 生成速度 | 变化 | 推荐 |\n|--------------|---------|------|------|\n| 256 | 70.9 | -17.5% | ❌ |\n| 512（默认） | 84.8 | 基准 | 🏆 别动！ |\n| 1024 | 34.2 | -60.2% | ❌ |\n\n**重大警告：千万别改 ubatch-size！默认的 512 就是最佳的，改了反而慢 17-60%！**\n\n---\n\n## 质量验证结果\n\n| 测试项 | 结果 |\n|--------|------|\n| KV q8_0 量化质量对比 | ✅ 无任何可感知的质量损失 |\n| 短距离回忆（1000 token） | ✅ 100% 正确 |\n| 中距离回忆（40000 token） | ✅ 100% 正确 |\n| 简单数学/推理 | ✅ 100% 正确 |\n| 简单代码生成 | ✅ 正常 |\n\n---\n\n## 综合评分\n\n| 维度 | 权重 | 得分 |\n|------|------|------|\n| 性能 | 50% | 9.5/10 |\n| 质量 | 40% | 9.4/10 |\n| 稳定性 | 10% | 10.0/10 |\n| **总分** | 100% | **9.5/10** 🏆 |\n\n---\n\n## 最终最佳配置\n\n### ⚡ 方案一：速度优先（84.8 tokens/s + 80 tokens/s Prompt）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 65536 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 2 --kv-unified --flash-attn on -b 2048 --cache-type-k q8_0 --cache-type-v q8_0\n```\n\n### 📚 方案二：上下文优先（256K 超大窗口）\n```cmd\nllama-server.exe -m \"Qwen3.6-35B-A3B-APEX-I-Mini.gguf\" --n-gpu-layers 9999 --ctx-size 262144 --port 8080 --host 127.0.0.1 --threads 8 --mlock --parallel 2 --kv-unified --flas"},{"path":"skill-card.md","content":"## Description:\n\nComplete methodology for local LLM performance optimization using a four-phase control-variable process to tune llama.cpp and llama-server parameters across hardware.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[hoperealize](https://clawhub.ai/user/hoperealize)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and engineers use this skill to benchmark local llama.cpp and llama-server deployments, compare launch parameters, and produce recommended configurations for performance, context length, and stability.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Example llama-server commands could expose a local model service if copied into an externally reachable deployment.\n\nMitigation: Keep llama-server bound to localhost unless a reverse proxy, HTTPS, and deployment-specific access controls are configured.\n\nRisk: Parameter tuning can trigger out-of-memory failures or mismatched context settings on local hardware.\n\nMitigation: Validate settings against the target GPU and align OpenClaw contextWindow and maxTokens with the selected llama-server context size.\n\nRisk: Cloud model checks used during tuning may receive sensitive prompts if operators reuse private test data.\n\nMitigation: Use non-sensitive prompts for cloud validation and keep private or regulated content out of external model calls.\n\n## Reference(s):\n\n- [llama.cpp](https://github.com/ggerganov/llama.cpp)\n- [ClawHub skill page](https://clawhub.ai/hoperealize/skills/llama-params-optimizer)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Shell commands, Configuration, Guidance]\n\n**Output Format:** [Markdown with benchmark tables, command examples, and configuration snippets]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Produces hardware-specific recommendations that should be validated on the target machine.]\n\n## Skill Version(s):\n\n3.1.0 (source: frontmatter, changelog, server release metadata)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Complete methodology for local LLM performance optimization. Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU... Skill: llama-params-optimizer Owner: hoperealize Summary: Complete methodology for local LLM performance optimization. Core principle: maximize context while fully covering GPU memory — find the sweet spot where GPU... Tags: latest:3.1.0, llama.cpp:2.0.0, local-llm:2.0.0, optimization:2.0.0, performance:2.0.0 Version history: v3.1.0 | 2026-04-28T11:07:43.048Z | user 新增 Qwen3.6-27B 实战案例；修正甜点公式为起点参考；batch-size 因模型而异；推理","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1482,"uniquenessScore":47,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T11:35:50.761Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T11:35:50.761Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T14:14:52.887Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}