既然不想被卡脖子，我就把 DeepSeek-R1 部署到了国产算力上。这话说出来轻飘飘的，背后是连续三周的失眠和至少五位数的试错成本。四十岁的人了，还在跟 CUDA 版本、驱动兼容性、显存碎片这些底层玩意儿死磕，说出来都觉得有点悲壮。但没办法，去年 GPT-4 API 说涨价就涨价，说限流就限流，半夜三点被客户的自动化流程报警叫醒，那种脖子被人掐住的感觉，我不想再体验第二次了。
国产算力平台，名字我就不提了，文档写得跟天书一样。官方给的 DeepSeek 部署指南，第一步“确保环境配置正确”就卡了我两天。他们的驱动不是标准 NVIDIA 驱动，是魔改版，为了适配他们的硬件架构。CUDA 11.8 装上去，跑个简单的矩阵乘法都报错“不支持的 PTX 版本”。找客服，客服转技术，技术让我看一个三年前的 GitHub issue，里面讨论的解决方法早就过时了。最后是翻他们论坛一个不起眼的帖子，发现有个环境变量要设置，`export FORCE_CUDA_COMPAT=1`，这才把 PyTorch 的 CUDA 后端给骗过去。这种坑，没踩过的人根本想象不到，文档里一个字都没提。
模型加载是第二个鬼门关。DeepSeek-R1 的 32B 版本，光是权重文件就 60 多个 G。他们的云盘 I/O 性能是个谜，有时候能跑到 500MB/s，有时候就卡在 20MB/s 不动。第一次加载模型，花了整整四十分钟，然后因为显存碎片化导致 OOM（内存溢出）。他们的显存管理跟标准 CUDAMalloc 不太一样，需要手动设置一个内存池的预留比例。我写了个脚本，监控显存分配，发现加载过程中会产生大量 100MB 以下的小碎片，最后可用连续显存反而不够了。解决方案是调整 `max_split_size_mb`，并且分阶段加载模型：先加载到 CPU，再用 `torch.cuda.empty_cache()` 清空缓存，最后用 `model.to(device)` 配合 `pin_memory=True` 的 DataLoader 一点点搬过去。这个过程，像在豆腐上雕花，手稍微一抖，全盘皆崩。
真正的挑战在推理优化。直接调用 `model.generate()`，第一个 token 的生成延迟（Time to First Token）高达 1200 毫秒，这完全没法用到对实时性要求高的对话或者工具调用场景里。我一开始怀疑是模型本身的问题，后来用 Nsight Systems 做性能剖析，发现 70% 的时间花在了 kernel 启动的 overhead 和内存拷贝上。他们的硬件对连续大矩阵运算优化还行，但对小 batch size、动态序列长度的 attention 计算，调度效率很低。
我的优化策略分了三层。第一层，算子融合。用 Triton 重写了关键位置的 LayerNorm 和 Rotary Embedding 计算，把几个小 kernel 合并成一个，减少了 GPU 启动次数和全局内存访问。第二层，缓存预热。服务启动后，先跑一个预热脚本，用一些典型的 prompt 模板（比如“你好”、“请总结以下内容”）预先跑几遍，让 GPU 的指令缓存和显存中的计算图“热”起来。第三层，也是最关键的一层，投机采样（Speculative Decoding）的轻量化实现。我没用复杂的草案模型，而是用了一个极简的 N-gram 缓存来预测下一个 token 的候选集，让大模型只做验证。这套组合拳打下来，在 32K 上下文长度、生成 100 个 token 的典型场景下，TTFT 压到了 180 毫秒以内，平均每个 token 的生成时间在 35 毫秒左右。这个数据，已经接近我在 A100 上跑优化后 Llama 3 的水平了。
搞完这一切，我坐在电脑前，看着监控面板上平稳的延迟曲线和极低的错误率，没有兴奋，只有一种深沉的疲惫和一点点的安心。四十岁，技术人的中年危机不是体力下降，而是你赖以生存的整个技术栈可能一夜之间被颠覆，或者被“卡脖子”。把核心的推理能力攥在自己手里，跑在自己能控制的硬件上，这种感觉，比多接两个外包项目踏实得多。这不是情怀，这是最现实的生存策略。护城河不是你知道多少种调 API 的方法，而是当所有 API 都对你关闭或者贵得用不起时，你还能不能从螺丝刀和焊锡开始，自己搭出一个能用的系统。今天，我算是给自己挖了一锹土。
