Files

T

CI / build-and-test (push) Has been cancelled

Details

Initial commit: E4B-MarkBase model integration with passing tests

- E4B-MarkBase model (42 layers, 4.4GB) loaded successfully
- All Phase 1-6 tests passed (model loading, forward pass, vision/audio towers, token generation, performance)
- All stress tests passed (5/5 in 127.6s)
  - Concurrent inference
  - Memory stress (67.5 tok/s, 0 NaN)
  - Continuous generation
  - Batch processing
  - Long-running stability
- Swift Metal inference engine with multimodal support

2026-06-23 18:12:35 +08:00

4.2 KiB

Raw Blame History

Gemma-4 26B-Standard 模型验证状态

测试日期

2026-06-20

模型信息

模型: gemma-4-26b-standard
位置: /Users/accusys/MarkBase12B/models/gemma-4-26b-standard/
大小: 15GB
层数: 30层
Hidden size: 2816
Vocab size: 262144
量化: 4-bit (group_size=32, custom quantization)

已完成的修复

1. SIMD Attention Kernel Softcapping Bug ✅

问题: SIMD kernels 硬编码了错误的 softcapping
修复: 移除 softcapping，因为 text model 不需要
文件: OptimizedKernels.metal (lines 79-82, 94-95)
验证: Forward pass 完成，无 NaN

2. Sampler Temperature=0.0 Bug ✅

问题: temperature=0.0 导致 divide by zero，产生 NaN/Infinity
修复: 当 temperature=0.0 时使用 greedySample
文件: Sampler.swift (lines 22-32)
验证: Sampler 现在正确选择 token ID

3. Quantization Scales Normalization ✅

问题: Scales 异常大（119-121），而 E4B scales 是 ±0.04（3000倍差异）
原因: 26B 使用 "custom" 量化方法，scales 未按 hidden_size 缩放
修复: 将 scales 除以 hidden_size (2816)
文件: Model.swift (lines 266-272)
验证: Scales 现在在正常范围（0.04左右）

当前问题

Logits 数值仍然偏大 ⚠️

现状: Logits max=6164，min=3600
对比: E4B logits max=30，min=-30
差距: ~200倍差异
原因: 可能 hidden state 需要额外缩放，或模型使用不同的 normalization

生成的文本仍是乱码 ⚠️

输出: "ArrayRef ArrayRef ArrayRef..."
原因: Logits 数值不正确导致总是选择同一个 token（ID=192064）
对比: E4B 生成的是更合理的混合语言文本

性能数据

Benchmark 结果

Token generation: 40.0 tok/s（比 E4B 27.7 tok/s 快）
Forward pass: 成功完成（无 NaN）
Loading time: ~5s
Run time: 3.05s per run

详细对比

指标	26B-Standard	E4B-MarkBase	状态
Forward pass	✅ 完成	✅ 完成	OK
Token generation speed	40 tok/s	27.7 tok/s	✅ 26B 更快
Scales range (修正后)	0.04	0.04	✅ 相同
Logits range	3600-6164	-30 to 30	❌ 异常
Generated text	ArrayRef...	Mixed text	❌ 乱码
Temperature=0 handling	✅ Fixed	✅ Fixed	OK

分析结论

26B 模型的量化方法与 E4B 不同

groupSize: 32（E4B 是 64）
quant_method: "custom"（非标准）
Scales: 需要除以 hidden_size 才能正常化
Hidden state: 可能需要额外的缩放因子

可能需要的额外修复

Hidden state normalization: 可能需要将 final norm 后的 hidden state 缩放
LM head scaling: 可能需要额外的 logit scaling
模型格式: 26B 可能使用完全不同的推理策略

建议

短期: 继续使用 E4B-MarkBase（稳定可靠）
中期: 研究 26B 的 quant_method="custom" 具体实现
长期: 实现 MLX 原生支持，或重新量化 26B 为标准格式

文件修改总结

OptimizedKernels.metal: 移除 SIMD attention softcapping（2处）
Sampler.swift: 修复 temperature=0.0 divide by zero bug
Model.swift: 添加 scales normalization for groupSize=32
Layer.swift: Forward pass synchronization（之前已修复）
PerformanceBenchmark.swift: 添加调试输出

下一步行动

Option 1: 深入研究 26B 量化 ⚠️

分析 MLX quant_method="custom" 的具体实现
找出正确的 hidden state 缩放因子
可能需要 1-2天研究

Option 2: 测试其他 26B 模型 ✅

测试 gemma-4-26b-a4b-it-4bit（需要实现 MoE）
测试其他社区提供的 26B 量化版本
寻找使用标准量化的 26B 模型

Option 3: 继续使用 E4B ✅（推荐）

E4B 稳定可靠，性能良好（27.7 tok/s）
支持 Vision + Audio + Text multimodal
完整测试通过
可立即用于生产

验证状态: Forward pass 成功 ✅ → Logits 异常 ⚠️ → 文本生成乱码 ❌
根本原因: 26B 使用非标准量化方法
推荐方案: 继续使用 E4B-MarkBase 或深入研究 26B 量化
预计修复时间: 1-2天（如果研究量化方法）

4.2 KiB Raw Blame History Unescape Escape