- 博客(157)
- 收藏
- 关注
RSS订阅原创 80 行 PyTorch 从零写 DeepSeek 的 MLA：量一遍 KV cache、踩一遍 absorption，你才会明白 vLLM 为什么要加专用内核
本文用 80 行 PyTorch 把 DeepSeek V2/V3 的 MLA 从论文推到能跑，然后在 RTX 3090 上量化了三件事：cache 体积（比同规模 MHA 小 56.9x，3090 实测一致）、朴素实现的 decode 开销（16k 上下文 MLA 反而比 MHA 慢约 4x）、absorption 和 decoupled RoPE 在数学上的等价与冲突关系（两行 einsum 即可看清）。最后补一版 absorbed decode 在 16k 上下文上拿到 1.61x 提速，解释了为什么
2026-05-02 14:18:42
450
原创 `torch.compile` 不是“开了就快“：RTX 3090 上 12 组对照给出该开、该关、该换模式的边界
`torch.compile` 并不是"开了就快"。本文在 RTX 3090 + PyTorch 2.9.1 + bf16 条件下，用一个 6 层手写 Transformer 做了 12 组对照实验：batch=1/seq=128 下 compile 提速 2.87x，但 batch=16/seq=128 下反而慢 9%。同时给出冷启动 2.5-7 秒、dynamic=False 时每个新 shape 付 ~1 秒重编译税的实测数据，并解释了为什么 reduce-overhead 在 decode 阶段能比
2026-05-02 13:11:45
454
原创 别把 `vLLM-Omni` 当成给 `vllm` 加个多模态插件：我实测后，先卡住的是版本对齐、`--omni` 入口和硬件 recipe
这篇文章围绕热门项目 vLLM-Omni 的第一条可用上手路径展开，不再复述 README，而是用官方安装文档、CLI 源码、支持模型列表、community recipe 讨论和两轮本地实验，拆清它为什么不该被理解成“给 vllm 加一个多模态插件”。我分别测试了 `vllm==0.19.0` 与 `vllm==0.20.0` 两条安装路线，验证旧命令会先卡在 `libcudart.so.12`，当前文档推荐路线则能跑通 `vllm-omni serve --omni --help` 与 `collect
2026-05-01 11:19:21
378
原创 别被“3B 激活参数”骗了：Qwen3.6-27B 和 35B-A3B，先按部署路径选，再看 benchmark
这篇文章聚焦 Qwen3.6-27B 与 Qwen3.6-35B-A3B 的落地顺序，不再只比参数量，而是结合官方模型卡、Hub metadata 与 config.json，对比权重体积、分片数、长上下文、工具调用命令和 MoE 复杂度。结论很直接：第一次自托管 coding agent，先试 27B 更稳；35B-A3B 更适合明确要研究 sparse MoE 的第二阶段。
2026-05-01 10:12:30
4082
原创 别急着 clone 热门训练跟踪项目 SwanLab 的 main 分支：我实测后先卡住的不是可视化，而是 `nanoid`、`logdir` 和 `watch` 这 3 个入口
这篇文章围绕最近活跃的训练跟踪项目 SwanLab 做了一次工程化首验收：我没有先看 dashboard，而是先测试 source install、offline 日志路径、resume 本地语义和 `swanlab watch` 入口。实测发现 current main 分支会先踩 `nanoid` 缺依赖、`logdir=` 参数未生效，以及 `watch` 命令源码未完整实现这 3 个坑；同时用 PyPI 稳定版做对照，给出更稳的试用顺序和接入建议。
2026-05-01 09:18:49
376
原创 官方 demo 只有 20 行，但我把 TabPFN 改成自己的 CSV 后，真正先卡住的是许可证、列类型和 `predict()` 调用方式
这篇文章围绕一个真实落地问题展开：把 TabPFN 官方 demo 改成自己的 CSV 时，为什么最先卡住的往往不是精度，而是默认 v2.6 的许可证链路、列类型处理和 `predict()` 调用方式。我复现了 headless 环境下的 `TabPFNLicenseError`，再用开源 `ModelVersion.V2` 跑通带字符串类别列和缺失值的 CSV，对比 raw DataFrame、one-hot 与逐条预测的耗时和效果，给出本地 PoC、批量预测和部署边界上的具体建议。
2026-05-01 08:15:38
391
原创 别再把 TGI 当 2026 年自建推理的默认起点：官方已进 maintenance mode，我建议按这张表选 vLLM、SGLang 和 TensorRT-LLM
这篇文章围绕 TGI 进入 maintenance mode 后的一个现实问题展开：2026 年自建开源模型推理服务，还该不该继续把 TGI 当默认起点？我结合 TGI、vLLM、SGLang、TensorRT-LLM 的官方 README、文档和 GitHub 活跃度，对比它们在通用 serving、前沿推理、RL/post-training 和 NVIDIA 极限优化上的定位差异，并给出新团队、后训练团队与存量 TGI 团队各自更合适的学习与迁移顺序。
2026-04-30 17:14:01
197
原创 `VibeVoice` 这么火，先别急着 clone：我读完文档、源码和最近 Issues 后，建议你先按任务类型选 ASR、Realtime 还是 TTS
本文把热门语音 AI 仓库 VibeVoice 拆成 ASR-7B、Realtime-0.5B、TTS-1.5B 三条路线来判断：哪条适合长音频转写，哪条适合英文低延迟播报，哪条目前更像论文入口而非完整工程路径。我结合官方文档、vLLM 启动脚本、pyproject 和最新 issues，重点解释 24GB 单卡边界，以及为什么新手不该一上来就冲 TTS。
2026-04-30 17:06:25
323
原创 别把 KV cache 量化当“白送长上下文”：我 clone 热门项目 TurboQuant 后，先卡住的不是显存，而是 README 漂移、2-bit value 瓶颈和 hybrid decod
本文围绕热门 GitHub 项目 TurboQuant 做一次工程化拆解：我先验证 README 与当前仓库快照是否一致，再用 CPU 最小实验比较 2-bit/4-bit value 的质量差异，并结合 vLLM adapter 与 hybrid decode 源码判断它真正省下的是存储还是计算。读完你会更清楚，第一次接入这类 KV cache 压缩项目时该先验证什么、该优先调哪一个位宽。
2026-04-30 16:12:33
362
原创 别把 `auto-deep-researcher-24x7` 当自动炼丹黑箱：我 clone 这周 GitHub 热门项目后，更看重的是 0 成本监控、恒定记忆和 SSH 远端执行
这篇文章围绕最近走红的 `auto-deep-researcher-24x7`，结合 clone、技术报告、架构文档、Issues 和本地 40 个单测结果，拆解它为什么不是“自动科研黑箱”，而是一套面向深度学习实验循环的工具箱：核心价值在 zero-cost monitoring、恒定记忆、最小工具集和本机控远端 GPU 的 SSH backend，适合谁、不适合谁也因此更清楚。
2026-04-30 15:11:58
386
原创 别只把 `GLM-5V-Turbo` 当成截图转代码：我读完论文、文档和 GUI Agent 示例后，更在意它把感知、规划、执行塞进了同一个模型
如果一款视觉模型只是想做“图片到 HTML”，它最自然的产品描述通常会围绕三个词展开：截图、还原、生成。但的官方文档不是这么写的。docs.z.ai在模型 overview 里把它定义为输入不只是图片，还包括；目标不只是代码生成，还包括；它被直接定位为能和这类 agent 工作流配合的模型。这三个信号叠在一起，说明它想切入的不是“前端美工辅助”这么窄的场景，而是更宽的视觉参与式编程和 agent 执行。
2026-04-30 14:23:31
437
原创 别把两个本地模型都叫 `checkpoint-1000`：我用 3 个 Transformers 版本实测后，发现 `trust_remote_code` 还会撞 `HF_MODULES_CACHE`
本文围绕一个很隐蔽的 Transformers 工程坑展开：当你用 `trust_remote_code=True` 加载两个本地自定义模型时，如果它们最后一级目录同名，发布版可能把两份不同源码写进同一个 `HF_MODULES_CACHE` 动态模块目录。我用 5.5.3、5.7.0 和 2026-04-30 当天的 main 分支做最小实验，并结合 `dynamic_module_utils.py` 源码解释为什么 PyPI 最新版仍会撞缓存，以及当前最值得做的止损方案。
2026-04-30 09:16:28
187
原创 GitHub 热门项目 `modded-nanogpt` 实测：把“90 秒训练 124M”搬到 RTX 3090 后，先炸的不是显存，而是 Hopper 专用内核
本文围绕当日热门 GitHub 项目 `modded-nanogpt` 展开，不复述它在 8xH100 上“90 秒训练 124M” 的成绩，而是直接把 current master 搬到本地 RTX 3090 上做最小复现实验。通过源码定位、内核导入和 warmup 诊断，我确认阻塞并不先来自显存，而是 `triton_kernels.py` 里写死的 `sm90` fused CE 内核，以及 `flash-attention-3` 的 Hopper/TMA 路径。读完你能判断它适不适合当消费级 GPU
2026-04-30 08:21:14
404
原创 `DataLoader` 的 `num_workers` 不是越大越快：我用 3 类数据集实测后，发现瓶颈根本不在 worker 数
本文围绕一个经常被误传的经验值展开：`DataLoader` 的 `num_workers` 并不是越大越快。我基于 20 核 CPU + RTX 3090 设计了 3 类最小实验，分别覆盖内存 Tensor、CPU 预处理和磁盘小文件读取，并拆开首轮与稳态耗时，验证了何时该坚持 `num_workers=0`，何时要搭配 `persistent_workers=True` 才能真正提升吞吐。
2026-04-29 23:00:17
160
原创 Transformers 5.x 升级后为什么 `AutoTokenizer` 会把 CamemBERT 切成字符？4 组实验讲透 tokenizer 元数据回归与止损方案
本文聚焦 2026-04-29 刚暴露的 Transformers 5.x tokenizer 升级回归：同一个 CamemBERT 仓库，在 4.57.6 下分成 23/41 个 token，在 5.7.0 下却膨胀到 78/188 个。我用 4 组最小实验拆开 tokenizer_config.json、tokenizer.json 与 AutoTokenizer 的选类逻辑，验证 use_fast=True 失效原因，并给出 PreTrainedTokenizerFast、元数据补丁和版本 pin 的
2026-04-29 21:35:02
354
原创 Transformers 里二分类为什么会被你训练成“零损失”？4 组实验讲透 `num_labels=1` + `single_label_classification` 的配置陷阱
本文聚焦 Transformers 最新修复的二分类配置坑：把任务写成 `num_labels=1` + `single_label_classification` 时，loss 可能恒为 0，标签出现 1 还会越界。我用 4 组最小 BERT 实验对比错误配置、标准 2-logit 方案和单 logit BCE 方案，并验证 5.7.0 的新 guard，给出可直接落地的修正清单。
2026-04-29 20:59:25
294
原创 Accelerate 断点续训为什么会把 shuffle 顺序打回第 0 轮？4 组实验讲透 `save_state/load_state` 的 DataLoader 坑
本文围绕 Accelerate 1.13.0 的断点续训坑展开：当你开启 use_seedable_sampler=True 并使用 save_state/load_state 恢复训练时，DataLoader 的 epoch 计数不会被默认持久化，shuffle 顺序可能直接回放到 epoch 0。我用 4 组最小实验验证了完整 epoch 恢复、中途恢复、skip_first_batches 的边界以及自定义 checkpoint 补丁，并给出可直接落地的止损方案。
2026-04-29 20:31:06
382
原创 Transformers 自定义模型为什么一保存就报 PermissionError？4 个最小实验讲透 `register_for_auto_class` 的只读权限坑
本文围绕 Transformers 自定义模型导出中的一个新坑展开：当你用 register_for_auto_class 打包模型，而源码文件在仓库里是只读状态时，save_pretrained 不仅会把 custom_model.py 和相对导入文件复制成只读，还可能在同一次保存流程里直接抛出 PermissionError。我基于 4 组最小实验验证了失败路径、HF_MODULES_CACHE 的连带影响，以及 monkey patch copymode 的临时止损方案。
2026-04-29 18:09:12
370
原创 PyTorch 2.9 里 torch.compile 为什么首个请求更慢？4 组 GPU 实验讲透冷启动、重编译与止损方案
本文围绕 PyTorch 2.9 中 torch.compile 的一个典型工程坑展开：为什么离线 benchmark 看起来不错，线上首个请求却更慢，batch size 一变 p99 还会抖。我基于 RTX 3090 做了 4 组最小实验，分别验证固定 shape 的冷启动成本、shape 变化触发的重编译、dynamic=True 对可变 batch 的缓解效果，以及 regional compilation 对首请求 SLA 的价值，并给出可直接落地的排查与配置清单。
2026-04-29 17:37:36
397
原创 【运维】Ubuntu上WebDAV挂载与自动同步完整指南
WebDAV (Web Distributed Authoring and Versioning) 是一种基于HTTP的协议，常用于云存储服务如Cloudreve、NextCloud等。在Linux系统中挂载WebDAV可以让我们像使用本地文件夹一样操作远程存储，本文将详细介绍在Ubuntu系统上挂载WebDAV并实现自动双向同步的几种方法。davfs2：适合需要高性能本地访问的场景rclone：功能最全面，推荐大多数用户使用智能脚本：解决挂载过程中的各种技术问题。
2025-09-22 11:57:05
2124
1
原创 【运维】Linux inotify watches 限制问题解决方案
inotify文件被创建、删除、修改目录被创建、删除文件被移动或重命名文件权限发生变化Linux inotify watches 限制是开发环境中常见的问题，特别是使用需要监控大量文件的 IDE 时。通过适当调整系统参数，可以有效解决这个问题。关键是要根据实际需求设置合适的值，并考虑系统资源的使用情况。重要提示：修改系统参数前请确保了解其影响，建议在测试环境中先验证配置的正确性。
2025-09-05 14:47:02
1178
1
原创 【Elasticsearch】k-NN 搜索深度解析：参数优化与分数过滤实践
监控召回率：定期评估 num_candidates 设置是否足够性能测试：根据实际数据量调整 window_size分数阈值设定：基于业务需求和数据分布确定合理阈值。
2025-08-26 17:26:40
983
原创 【深度学习】Transformer 注意力机制与 LoRA target_modules 详解
覆盖注意力核心：这四个模块构成了自注意力机制的完整流程参数效率平衡：在性能和计算效率之间取得最佳平衡广泛适用性：适用于大多数 embedding 微调任务实践验证：在众多实验中证明了其有效性对于 embedding 模型微调，这个配置通常是最佳选择！
2025-08-26 15:55:29
752
原创 【机器学习】从KNN算法到图像风格迁移：原理与实践
图像风格迁移的目标是将一张图像的艺术风格应用到另一张图像上，同时保持原图像的内容结构。比如，我们可以将梵高《星夜》的绘画风格应用到一张普通的风景照片上。KNN在图像风格迁移中的应用是一个很好的例子，展示了如何将简单的算法思想应用到复杂的实际问题中。通过巧妙地将局部纹理模式作为特征，将颜色信息作为标签，KNN算法成功地实现了基础的风格迁移功能。特征工程的重要性：选择合适的特征表示是算法成功的关键问题转化的艺术：将复杂问题转化为已知算法可以处理的形式算法适用性的边界。
2025-08-26 09:25:19
501
原创 【Python】Poetry install 卡死问题处理
Poetry install 卡死问题主要是由于密钥环访问问题引起的。通过禁用 keyring 或配置 Poetry 不使用密钥环，可以有效解决这个问题。建议在项目配置中永久禁用密钥环功能，避免后续安装时再次遇到类似问题。
2025-08-01 14:00:55
666
原创 【网络】DHCP Option详解
动态主机配置协议（DHCP）是现代网络中的核心协议，它通过标准化的选项机制为客户端提供网络配置信息。本文基于RFC1533和RFC2132两个重要规范，详细解析DHCP选项的定义、分类、作用和使用方法。DHCP选项系统为网络配置提供了灵活且可扩展的机制。精确控制：为不同类型的客户端提供定制化的网络配置简化管理：通过集中化的DHCP服务器管理网络参数提高效率：减少手动配置错误，提高网络部署速度增强功能：支持现代网络应用的各种需求。
2025-07-28 17:44:31
3304
原创 【运维】HuggingFace缓存目录结构详解
内容寻址存储：通过哈希值确保文件完整性版本管理：支持多个版本的模型共存空间优化：通过符号链接和去重节省存储空间并发控制：通过锁文件防止下载冲突断点续传：支持大文件的断点续传理解这个目录结构，不仅能帮助你更好地管理模型文件，还能在遇到问题时快速定位和解决问题。无论是开发环境还是生产环境，掌握这些知识都能让你更加高效地使用HuggingFace生态系统。本文基于HuggingFace Transformers库的实际使用经验编写，如有疑问或建议，欢迎在评论区讨论。
2025-07-28 14:56:54
1290
原创 【运维】Smartctl安装及使用指南
Smartctl是硬盘健康监控的重要工具，通过定期使用可以有效预防硬盘故障。定期检查：建立检查计划，及时发现问题参数解读：理解关键指标的含义和阈值故障处理：掌握常见问题的诊断和解决方法预防为主：通过监控和预警避免数据丢失重要提醒：硬盘故障可能导致数据丢失，建议在发现异常时及时备份数据并考虑更换硬盘。
2025-07-28 10:33:58
1755
原创 【大模型】Hugging Face常见模型格式详解
Hugging Face支持多种模型格式，每种格式都有其特定的优势和使用场景。使用场景：开发、测试、生产部署硬件环境：CPU、GPU、边缘设备性能要求：速度、内存、精度安全要求：生产环境的安全性兼容性：跨平台、跨框架需求通过合理选择模型格式，可以显著提升模型的部署效率和运行性能。建议在实际使用中根据具体需求进行测试和优化，找到最适合的格式组合。
2025-07-23 16:06:08
1986
原创 【运维】SGLang服务器参数配置详解
SGLang提供了丰富的参数配置选项，开发者可以根据实际需求进行精细调优。关键是要在性能、内存使用和并发能力之间找到平衡点。建议在生产环境中进行充分的压力测试，找到最适合的参数组合。通过合理配置这些参数，可以显著提升大语言模型的推理性能和资源利用率。
2025-07-22 21:48:47
3465
原创 【运维】SGLang 安装指南
SGLang 是一个高性能的大语言模型推理框架，支持多种安装方式。本文档提供了详细的安装步骤和常见问题解决方案。
2025-07-22 17:04:35
3530
原创 【工具】Cursor中国封锁解决方案
软路由方案更适合有技术基础的用户，设置复杂但效果稳定；代理软件方案更适合普通用户，设置简单但需要选择优质的代理服务。选择适合自己的方案，即可恢复Cursor的正常使用。随着网络环境的变化，可能需要定期调整和优化配置。
2025-07-17 11:00:58
28683
5
原创 【LLM】OpenRouter调用Anthropic Claude上下文缓存处理
通过在工具调用后添加用户消息的方式，我们成功绕过了OpenRouter在tool消息中无法设置缓存的限制。这种方法在保持对话语义完整性的同时，实现了有效的缓存管理，为Agent应用的成本控制提供了实用的解决方案。
2025-07-16 15:52:30
2182
原创 【LLM】OpenRouter 指定模型供应商指南
通过合理配置 OpenRouter 的provider提升响应速度：选择延迟最低的供应商控制成本：选择价格最优的供应商确保稳定性：避免因供应商不可用导致的服务中断在实际应用中，建议根据具体需求制定供应商选择策略，并实现适当的容错机制以保证服务的可靠性。
2025-07-16 14:57:15
2461
原创 【LLM】Qwen3 完全关闭思考过程(vllm)
根据官方示例，可以通过在提示词里提示模型不输出思考过程，比如提示词直接写【no_thinking】或者【不思考】，在一些场景下都能work，但从结构上来看，其还是会输出的标签。我们可以通过调整提示词模版的方式，伪装为告诉模型已经完成了思考的形式，进而让模型不输出思考过程。具体操作方式如下。
2025-07-15 10:41:16
12455
原创 【工具】Pycharm隐藏文件类型或目录
设置方式如下图所示，进入设置后，在Editor -> File Types -> Ignored Files and Folders 中添加你想忽略的文件类型/目录即可。在使用Pycharm时候，有的项目文件不是我们所关注的，Pycharm默认会隐藏一部分文件，但其他的需要手动设置。类似的，如果你想显示，也可以同理删除掉一些选项。
2025-07-09 11:00:30
880
原创 【运维】使用Knot kdig测试DoH服务速度
DNS over HTTPS (DoH) 是一种通过HTTPS协议进行DNS查询的技术，提供更好的隐私保护和安全性。本文将介绍如何安装Knot DNS工具并使用kdig命令测试不同DoH服务提供商的响应速度。Knot DNS是由CZ.NIC开发的高性能权威DNS服务器，同时也提供了强大的DNS客户端工具kdig。kdig是dig命令的现代化替代品，支持DNS over HTTPS (DoH)、DNS over TLS (DoT)等新协议。Knot kdig是优秀的DoH测试工具。
2025-07-08 00:59:08
1769
原创 【架构】结构化并发：现代编程中的并发范式革命
结构化并发是一种编程范式，它将并发操作组织成清晰的层次结构，确保并发任务的生命周期被明确管理。子任务不能超出其父任务的生命周期。结构化并发代表了并发编程的未来发展方向。
2025-07-04 17:33:40
902
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人