异构模型接入与 DeepSeek 实践

这批新资料证明，Claude 生态正在越来越异构：有人在 Claude Desktop 里接 DeepSeek-V4，有人在 Claude Code 里直接跑 DeepSeek 或 GLM-5.2，结果既带来了更灵活的模型选择，也暴露出缓存、性能和上下文策略的新问题。 [[raw/2026-04-29/DracoVibeCoding/如何在Claude Desktop里配置DeepSeek-V4.md|来源: 如何在Claude Desktop里配置DeepSeek-V4.md]] [[raw/2026-04-30/day253/Claude Code 接入DeepSeek｜缓存暴涨实测.md|来源: Claude Code 接入DeepSeek｜缓存暴涨实测.md]]

Claude Desktop 的异构接入

Draco 的实践说明，Claude Desktop 已经可以被当作更大的模型入口壳：表层还是 Claude 生态，底层却可以换成 DeepSeek 等模型。 [[raw/2026-04-29/DracoVibeCoding/如何在Claude Desktop里配置DeepSeek-V4.md|来源: 如何在Claude Desktop里配置DeepSeek-V4.md]]

Claude Code 场景的代价

day253 的实测提醒了更现实的一面：模型一换，缓存策略、上下文成本和会话行为不一定跟着稳，尤其在长任务中会迅速放大。 [[raw/2026-04-30/day253/Claude Code 接入DeepSeek｜缓存暴涨实测.md|来源: Claude Code 接入DeepSeek｜缓存暴涨实测.md]]
这跟旧资料里提到的模型混搭、成本治理是一脉相承的：问题从来不是”能不能接”，而是”接进来以后 harness 能不能兜住”。 [[raw/2026-04-24/秋芝2046/Openclaw养龙虾秘籍大公开！【安全+省钱】.md|来源: Openclaw养龙虾秘籍大公开！【安全+省钱】.md]]

GLM-5.2 的异构接入

GLM-5.2 通过 Anthropic 兼容 API 可以作为 Claude Code 的 drop-in 模型接入，配置方式与 DeepSeek 类似，在 settings.json 中设置环境变量即可：

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://open.bigmodel.cn/api/anthropic",
    "ANTHROPIC_AUTH_TOKEN": "你的智谱 API Key",
    "ANTHROPIC_MODEL": "glm-5.2",
    "ANTHROPIC_SMALL_FAST_MODEL": "glm-5.2"
  }
}

注意模型名后缀约定：GLM-5.2 的长上下文能力（1M 标称）在配置时需添加 [1m] 后缀以启用完整上下文窗口。 [[raw/2026-06-19/三元同学/我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬.md|来源: 我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬.md]]

跨端一致性审计：1M 上下文的独特用例

三元同学将 iOS（Swift）和 Android（Kotlin）两个原生端的全量源码一次性喂给 GLM-5.2（实际消耗 471K token），单次请求耗时 125 秒，模型成功定位到多端实现中的真实不一致问题：

绑定状态更新来源不一致：iOS 用后端返回的 response.user.email 更新本地状态，Android 用用户输入的 email——当后端做规范化处理时，两端显示会出现偏差
安卓独有逻辑缺失：微信占位邮箱过滤是 Android 独有的，iOS 完全没有
邮箱校验严格度差异：Android 用完整正则校验，iOS 仅检查 @ 和 .，判定条件明显有问题
死代码：Android 设置了绑定成功提示文案但从未显示，用户绑完没有任何成功反馈

这些 bug 的特点是单看任一端代码都发现不了，只有同时将两端全量代码放在同一个上下文窗口内才能暴露。200K 窗口的模型做不到这一点——单独一端代码就快塞满窗口了。 [[raw/2026-06-19/三元同学/我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬.md|来源: 我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬.md]]

有效长度与应用可用性

GLM-5.2 的 1M 标称上下文面临与其他 1M 模型相同的核心质疑：标称长度不等于有效长度。 窗口开得下不代表喂到 80 万 token 的位置还记得之前的约束。很多模型喂到 25-30 万就开始”失忆”，加上长上下文又慢又贵，“能跑”和”用得起”是两码事。

GLM-5.2 的应对是从注意力结构入手——KV8 和 HiSparse 优化系列从注意力机制层面压低长序列的成本与效果衰减，这也是”有效长度”能接近标称长度的关键。 [[raw/2026-06-19/三元同学/我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬.md|来源: 我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬.md]]

排名数据

Code Arena 前端编程盲测榜上，GLM-5.2 排第 2（1595 分），第 1 是 Claude Fable 5，但 Fable 5 已停止采样。在目前所有真正可用的模型中，GLM-5.2 排第一，超越 Opus 4.8（1561/1541）。 [[raw/2026-06-19/三元同学/我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬.md|来源: 我把两个 App 的全部源码一次性喂给了 GLM-5.2，让它找茬.md]]

异构模型的技术底座差异

异构模型接入后表现差异的深层原因在于底层架构的各异。不同模型在归一化方式、注意力机制、采样策略上的选择各不相同，直接影响缓存行为、推理速度和上下文效果。

归一化方式：当前主流大模型普遍采用 Pre-Norm + RMSNorm 架构，并去掉了几乎所有 Linear 层的 Bias。RMSNorm 相比 LayerNorm 减少了约一半的 Reduction 操作和大量减法指令，寄存器占用更低。Post-Norm 到 Pre-Norm 的演进本质上是 NLP 把 CV 领域 ResNet-v1 到 ResNet-v2 的路又走了一遍。 [[raw/2026-06-17/腾讯程序员/拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md|来源: 拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md]]
Softmax 与 Attention 优化：Safe Softmax（-M 防上溢）和 $\sqrt{d_k}$ 缩放是标准做法。Online Softmax 将 3 Pass 访存降为单次流式计算，是 FlashAttention 的核心基础。FlashAttention 从 v1 到 v4 的演进显示了注意力机制优化的深度——v2 解决了 HBM 中间态写回问题，v3/v4 引入 Persistent Kernel、TMA 多播和 SFU/ALU 混合 exp。FA4 中 75-90% 的 exp 用硬件 SFU，10-25% 用 ALU 多项式逼近，原因是 Blackwell 的 Tensor Core 算力翻倍但 SFU 数量未同比例扩展。 [[raw/2026-06-17/腾讯程序员/拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md|来源: 拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md]]
采样策略差异：Gumbel-Max Trick 在 vLLM 中通过 q.exponential_() → probs.div_(q).argmax() 将概率采样转化为 GPU 友好的并行 argmax，统一了贪心和随机采样的执行流。跨卡推理时，argmax(logit + g) 只需一次 All-Reduce(MAX with index)，通信量从 O(V) 降到 O(world_size)。不同模型在采样策略上的实现差异（multinomial vs Gumbel-Max）会影响异构接入时的生成行为一致性。 [[raw/2026-06-17/腾讯程序员/拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md|来源: 拆解大模型几项核心操作背后的数学与 Infra 优化逻辑.md]]
长上下文机制差异：GLM-5.2 的 KV8/HiSparse 从注意力结构优化长序列成本与衰减，而其他模型的 1M 上下文可能依赖不同的稀疏注意力或 KV 缓存策略。这些差异使得异构接入时”看起来都支持长上下文”，但有效长度和实际表现可能天差地别。

矛盾与视角差异

三元同学的 GLM-5.2 实测显示”单次 125 秒处理 470K token 有效”，与此前 day253 对异构模型长上下文成本膨胀的警示形成对比。关键在于场景差异：三元同学使用的是 Prefill 密集型的一次性审计任务（喂入+推理），而 day253 关注的是一步步累积的多轮交互——后者的上下文成本会随会话长度非线性放大。