didii_个人页
didii
文章
0
问答
2
视频
0
个人介绍
暂无个人介绍
擅长的技术
暂无更多信息
2025年09月
-
09.01 15:37:35
回答了问题
2025-09-01 15:37:35
如何利用 AI 提升数据库运维效率？
赞111 踩0 评论0
2025年08月
-
08.25 16:30:01回答了问题
2025-08-25 16:30:01
Kimi-K2-Instruct 开了挂一般的推理和调用，底层魔法是什么？
赞27 踩0 评论0
暂无更多信息
-
回答了问题
2025-09-01
如何利用 AI 提升数据库运维效率？
1.希望 AI 能结合历史负载、SQL执行计划和监控指标，提前识别出可能的慢查询、磁盘 IO 瓶颈、连接数爆发等问题，而不是等到故障发生再处理。优化建议：不仅仅报错，还能给出“可能原因”和“对应解决方案”。例如发现慢查询后，能提示是索引缺失、SQL 写法不当还是资源分配不足。高风险操作必须人工确认，比如索引删除、大规模参数修改、存储引擎切换等。 2、体验 DAS Agent 的感受和建议最大的感受是它减少了我在“反复排查日志 + 试错验证”上的时间。过去我们团队遇到数据库性能抖动，需要一遍遍跑 explain 或抓取慢查询日志，现在 DAS Agent 会直接在控制台给出“高消耗 SQL 列表 + 优化建议”，省去了很多低效的体力活。另外在资源调度上，DAS Agent 会结合历史工单和经验库自动判断是不是该扩容，而不是一味提醒“CPU 过高”。这种建议更“懂业务”，而不是冷冰冰的指标。 建议：希望能附带“为什么推荐这样做”的解释，比如索引覆盖的原理、预计能减少多少查询时间，这样 DBA 更容易信任。目前支持的 MySQL、MongoDB 已经够常见，但如果后续能支持 PostgreSQL、Oracle 兼容场景，对企业用户的覆盖度会更高。赞111 踩0 评论0 -
回答了问题
2025-08-25
Kimi-K2-Instruct 开了挂一般的推理和调用，底层魔法是什么？
Mixture-of-Experts（MoE）架构 Kimi-K2 是一个混合专家模型（Mixture-of-Experts, MoE），总参数量高达 1 万亿，每次推理激活的专家参数量约为 320 亿，有效降低推理时的计算负担，同时提升模型容量和表达能力。Hugging FaceGitHubarXiv 每个 token 在处理时调度若干专家（如每 token 8 个专家），从而在不同子网络间动态选择最合适的专家组合。Hugging FaceGitHub MuonClip 优化器 使用了 Muon 优化器的变体 —— MuonClip，特别针对 MoE 在大规模训练时容易出现的不稳定（如 loss spike）做了改进。加入了 QK-clip 技术，使得训练过程更加平稳。arXiv Kimi-K2 使用 MuonClip 在超过 15.5 万亿 tokens 上进行预训练，几乎无训练失稳情况。arXivHugging Face Agentic Intelligence：Post-training + RL + Tool-use 优化 模型设计时注重 Agentic（代理式）能力，在 post-training 阶段加入了大量的代理式数据合成流程，以及一个联合的强化学习阶段（RL stage），通过与真实或模拟环境的交互不断强化其“自行动作推理”能力。arXiv 这种训练让模型在面对复杂指令、工具调用、任务分解时能自律决策，有非常强的自动决策能力。arXivGitHubTogether AI Reflex-grade（“反射级”）模型 + 原生工具调用能力 “Reflex-grade” 通常指模型能快速反应、即时推理，不需要多步“Chain-of-Thought”（CoT）的冗长处理，就能给出响应。Kimi-K2-Instruct 正是这样一个 reflex-grade 模型。Hugging FaceGitHubReddit 在 API 层面，Kimi-K2-Instruct 拥有“native tool use”设计，允许把工具 Schema（JSON）直接传给模型，它即可自主选择何时调用、调用哪个工具—不依赖外部指令插入。Together AIGitHub赞26 踩0 评论0
滑动查看更多
暂无更多信息